city of phoenix public transit department … · city of phoenix public transit department request...

CITY OF PHOENIX

PUBLIC TRANSIT DEPARTMENT

REQUEST FOR PROPOSALS

RFP PTD16-002

COMPUTER AIDED DISPATCH / AUTOMATIC VEHICLE LOCATOR (CAD/AVL) SYSTEM

PRE-PROPOSAL CONFERENCE: WEDNESDAY, FEBRUARY 24, 2016

1:00 P.M. MST (LOCAL TIME) 302 NORTH FIRST AVENUE, ROOM 7A

PHOENIX, AZ 85003

PROPOSAL DUE DATE: WEDNESDAY MARCH 23, 2016 2:00 P.M. MST (LOCAL TIME)

302 NORTH FIRST AVENUE, SUITE 900 PHOENIX, AZ 85003

City of Phoenix Contact: Elizabeth Kellim, Contracts Specialist II

Office: (602) 256-3239 FAX: (602) 495-2002

[email protected]

CITY OF PHOENIX PUBLIC TRANSIT DEPARTMENT

RFP PTD16-002 - COMPUTER AIDED DISPATCH / AUTOMATIC VEHICLE LOCATOR (CAD/AVL) SYSTEM

i

TABLE OF CONTENTS SECTION PAGE 1. INTRODUCTION

1.1 Introduction ...................................................................................................... 1 1.2 Contractual Relationship ................................................................................. 1 1.3 Background ..................................................................................................... 1 1.4 Goals and Objectives ...................................................................................... 2 1.5 Schedule of Events ......................................................................................... 3 1.6 Solicitation Transparency Policy .................................................................... 3 1.7 Pre-proposal Conference ................................................................................ 4 1.8 Site Visit .......................................................................................................... 4 1.9 Definition of Key Terms ................................................................................... 4

2. SCOPE OF WORK

2.1 Project Overview ............................................................................................. 8 2.2 General Project Requirements ...................................................................... 10 2.3 Interface Requirements ................................................................................. 11 2.4 Automated Vehicle Telematics System ......................................................... 12 2.5 Rail Vehicle Subsystem Integration ............................................................... 13 2.6 Project Documentation Submittals ................................................................ 14 2.7 Mini Fleet Testing .......................................................................................... 16 2.8 Reports .......................................................................................................... 17 2.9 Automatic Passenger System (APC) ............................................................ 17 2.10 Extended Maintenance .................................................................................. 17 2.11 CAD/AVL System Requirements ................................................................... 18

3. INSTRUCTIONS TO PROPOSERS

3.1 Inquires ........................................................................................................ 107 3.2 City’s Vendor Self-Registration And Notification ......................................... 107 3.3 Proposal Submittal Instructions ................................................................... 107 3.4 Proposer Responsibility ............................................................................... 108 3.5 Proposal Guidelines. ................................................................................... 109 3.6 Proposal Format .......................................................................................... 109 3.7 Financial Responsibility ............................................................................... 110 3.8 Proposer Exceptions ................................................................................... 110 3.9 Addenda ...................................................................................................... 110 3.10 Proposer Rights ........................................................................................... 111 3.11 City Reservation of Rights ........................................................................... 111 3.12 Late Proposals Not Considered .................................................................. 111 3.13 RFP Inconsistencies or Error ...................................................................... 111 3.14 Proposer Errors or Omissions ..................................................................... 112 3.15 Proposer Incurred Costs ............................................................................. 112 3.16 Modification or Withdrawal of Proposal ....................................................... 112 3.17 Proposer Certification .................................................................................. 112 3.18 Discounts ..................................................................................................... 112 3.19 City’s Right to Disqualify for Conflict of Interest .......................................... 112 3.20 Covenant Against Contingent Fees ............................................................. 112



ii

3.21 Execution of Agreement .............................................................................. 112

4. EVALUATION AND AWARD 4.1 Proposal Evaluation, Negotiation and Selection ......................................... 114 4.2 Evaluation Committee ................................................................................. 114 4.3 Evaluation of Competitive Proposals ........................................................... 114 4.4 Protest Procedure ....................................................................................... 118

5. SPECIAL TERMS AND CONDITIONS

5.1 Method of Payment and Invoicing ............................................................... 120 5.2 Price ............................................................................................................ 120 5.3 Alteration in Character of Work ................................................................... 120 5.4 Unsatisfactory Performance ........................................................................ 121 5.5 Performance Surety .................................................................................... 121 5.6 Indemnification of City Against Liability ....................................................... 121 5.7 Insurance Requirements ............................................................................. 122 5.8 Intellectual Property and Special Terms and Conditions ............................. 124 5.9 Contractor and Subcontractor Worker Background Screening ................... 126 5.10 Access Controls, Badge and Key Access Procedures ................................ 128

6. GENERAL TERMS AND CONDITIONS 6.1 Equal Employment Opportunity ................................................................... 131 6.2 Non-waver of Liability .................................................................................. 131 6.3 Contract Oversight ...................................................................................... 131 6.4 Licenses and Permits .................................................................................. 131 6.5 Legal Worker Requirements ........................................................................ 131 6.6 Damage to City Property ............................................................................. 132 6.7 Contractor Incurred Risks ............................................................................ 132 6.8 Failure to Comply ........................................................................................ 132 6.9 Contract Closeout ........................................................................................ 132 6.10 Transition Cooperation Agreement ............................................................. 132 6.11 Hazardous Material Requirements (SDS) ................................................... 133 6.12 Compliance with Hazardous Materials Management .................................. 134

7. FEDERAL TRANSIT ADMINISTRATION (FTA) REQUIRED CLAUSES 7.1 No Obligation by the Federal Government .................................................. 136 7.2 Program Fraud and False or Fraudulent Statements or Related Acts ........ 136 7.3 Access to Records … .................................................................................. 136 7.4 Federal Changes ......................................................................................... 137 7.5 Civil Rights .................................................................................................. 137 7.6 Termination ................................................................................................. 138 7.7 Incorporation of FTA Terms ........................................................................ 139 7.8 Certification Regarding Debarment and Suspension .................................. 140 7.9 Buy America ................................................................................................ 140 7.10 Disputes ...................................................................................................... 140 7.11 Lobbying ...................................................................................................... 141 7.12 Clean Air ...................................................................................................... 141



iii

7.13 Clean Water ................................................................................................ 141 7.14 Cargo Preference – Use of United States-Flag Vessels ............................. 141 7.15 Fly America ................................................................................................. 142 7.16 Privacy Act .................................................................................................. 142 7.17 Energy Conservation ................................................................................... 142 7.18 Recycled Products ...................................................................................... 142 7.19 Access Requirements for Persons with Disabilities .................................... 143 7.20 National Transportation Communications for ITS Protocol ......................... 143 7.21 Disadvantaged Business Enterprise Program ............................................. 143

8. SUBMITTAL FORMS

8.1 Price Proposal and Financial Information .................................................... 156 8.2 Certification Form ........................................................................................ 160 8.3 Payment Terms ........................................................................................... 161 8.4 Addenda Certification .................................................................................. 163 8.5 Debarment and Suspension Certification .................................................... 164 8.6 Lobbying Certification .................................................................................. 165 8.7 Buy America Certification ............................................................................ 166 ATTACHMENTS

Attachment A – Outreach Efforts (DBE Form) Attachment B-1 and B-2 – DBE Forms Attachment C - Draft Agreement Attachment D - Vehicle Equipment Inventory Attachment E – Software and Hardware Maintenance



1

SECTION 1 – INTRODUCTION 1.1 INTRODUCTION

The City of Phoenix Public Transit Department (CITY) requests proposals from qualified firms for a Computer Aided Dispatch / Automatic Vehicle Locator (CAD/AVL) System solution with comprehensive hardware and software maintenance and support in accordance with the terms and conditions set forth in Request for Proposals (RFP) PTD16-002. The sixteen (16) year contract will include an initial design and installation period of up to two (2) years, a three (3) year warranty and five (5) years extended maintenance with optional extensions of six (6) years on a two-year increment bases. The contract will commence on July 1, 2016, or upon full execution by both parties, whichever occurs last.

1.2 CONTRACTUAL RELATIONSHIP The information in this RFP is not intended to completely define the proposed contractual relationship to be entered into by the CITY and the successful Proposer. Proposers are advised to read carefully the Draft Contract (RFP Attachment C), to which the successful Proposer will be bound. These contract terms may be amended at the sole discretion of the CITY at any time during the RFP process and/or prior to Contract award.

1.3 BACKGROUND CITY and Transit Partners operate under the Valley Metro name which is comprised of sixteen regional cities and towns within Maricopa County, the fourth largest county in the nation with a population of nearly four million residents. The existing CAD/AVL regional system includes five major operating and maintenance facilities for bus, circulator, and paratransit vehicles, one major operating and maintenance facility for light rail, fifteen park and ride locations, nine main transit centers supporting bus and/or rail passengers with several major structural facilities at multi-user high-density locations, two primary Operation and Control Centers (OCC) and seven secondary dispatch centers with critical responsibilities for overseeing transit system operations. Additional facilities may come online during the procurement process of this solicitation. The CITY and Transit Partners contract with transit operations service providers to deliver cost effective mass transit service throughout the region. The CAD/AVL system is used by the Transit Agency, as defined herein, primarily as a contract monitoring tool, utilizing the system’s data analytics to measure service levels and to develop and refine efficient transit services. Transit operations service providers utilize the CAD/AVL system to conduct day-to-day operations, as well as monitor their provision of services. The current CAD/AVL system has been in service for well over 12 years and has now reached end-of-life. The existing CAD/AVL system is comprised of three major components: onboard equipment (1,012 vehicles), backend (8 central servers, 17 local and remote dispatch stations), and a Transit Agencies’-owned 450 MHz radio frequency (RF) network for data/voice communications. The existing regional CAD/AVL system supports both fixed route fleet and paratransit vehicles and currently does not include Light Rail vehicles.



2

This contract includes the replacement of the existing CAD/AVL system to provide the required functional requirements such as: network security, scalability, functionality, and interoperability with existing and pertinent regional transit applications as detailed by functional requirements in Section 2 of this RFP document. The new CAD/AVL solution will leverage the Transit Agency-owned new radio communication system and implement the new onboard vehicle architecture as detailed by functional requirements herein.

1.4 GOALS AND OBJECTIVES 1.4.1 It is the aim of the CITY and Transit Partners to provide effective and efficient public

transportation; enhance overall transportation capacity; reduce traffic congestion, air pollution and the use of petroleum fuels; and improve the quality of urban development. The goals are: Provide a high quality, safe and secure public transportation system. Operate a system that is sensitive to the needs of seniors and persons with

disabilities. Operate as effectively as possible. Operate as efficiently and economically as possible to provide service at lowest

cost to both passengers and taxpayers. Achieve effective communication with passengers, general public, news media,

and community leaders. Provide greater mobility throughout the region by providing better access to

public facilities and local and regional destinations. Avoid use of private automobiles for as many trips as possible, thus minimizing

congestion and air pollution. Provide connection to local, express and fixed route bus routes. Provide connections to outlying parking facilities. Provide connections to the METRO light rail system.

1.4.2 The transit system adheres to a set of objectives by which progress towards

achieving these goals can be measured. These objectives fall into four broad categories that address level of service, efficiency and economy, safety, and communications: The system seeks to reach potential riders by initiating new or improved service

whenever possible and operating in concert with passenger demand. Reduce operating costs, simplify fare structures, coordinate fixed route and

special transit services, improve operating efficiency, and involve private sector in the provision of public transportation to enhance system productivity.

Seeks safety of passengers and employees through well-maintained equipment, regularly monitored vehicles, and the use of reasonable risk control techniques.

Good public communications is an important responsibility for the system both in terms of publicizing transit services and obtaining valuable information about transportation demand and passenger needs. Cooperating with public agency developed marketing program, coordinating with other local and regional transportation agencies, and incorporating community input promotes transit use regionally.



3

Each transit contractor to the CITY and Transit Partners is expected to strive to achieve these goals and objectives.

1.5 SCHEDULE OF EVENTS The schedule outlines the tentative schedule of major activities of the RFP process. The CITY reserves the right to amend this schedule if necessary.

Date

Event

February 11, 2016

Notice of RFP posted on the CITY’s internet site

February 24, 2016

Pre-proposal conference (1:00 p.m. MST)

February 24, 2016

Site Visits of vehicles (immediately following pre-proposal)

March 9, 2016

Last date for submission of written inquiries (5:00 p.m. MST)

March 23, 2016

Proposal package submission deadline (2:00 p.m. MST)

April 26-27, 2016

Proposal demonstrations (if requested)

May 25, 2016

Notice of award recommendation

July 1, 2016

Contract start date

1.6 SOLICITATION TRANSPARENCY POLICY

Consistent with Phoenix City Code 43-36, beginning on the date the RFP is issued and until the date the Contract is awarded or the RFP withdrawn, all persons or entities that respond to this RFP (PTD16-002) to provide a CAD/AVL system solution, including their authorized employees, agents, representatives, proposed partner(s), subcontractor(s), joint venturer(s), member(s), or any of their lobbyists or attorneys, (collectively, the Proposer) shall refrain from any direct or indirect contact with any person (other than the designated Contracting Officer and/or Contracts Specialist II) who may play a part in the selection process, including members of the evaluation panel, the City Manager, Assistant City Manager, Deputy City Managers, Department heads, the Mayor and other members of the Phoenix City Council. As long as the RFP is not discussed, Proposers may continue to conduct business with the CITY and discuss business that is unrelated to this RFP with CITY staff. Proposers may discuss their proposal or the RFP with the Mayor or one or more members of the Phoenix City Council, provided such meetings are scheduled through the Contracting Officer, Ms. Kimberly Hayden, conducted in person at 200 West Washington, Phoenix, Arizona 85003, and are posted as open meetings with the City Clerk at least twenty-four (24) hours prior to the scheduled meetings. The City Clerk will be responsible for posting



4

the meetings. The posted notice will identify the participants and the subject matter, as well as invite the public to participate. With respect to the selection of the successful Proposer, the City Manager and/or City Manager’s Office will continue the past practice of exerting no undue influence on the process. In all solicitations of bids and proposals, any direction on the selection from the City Manager and/or City Manager’s Office and Department Head (or representative) to the proposal review panel or selecting authority must be provided in writing to all prospective proposers. This policy is intended to create a level playing field for all Proposers, assure that contracts are awarded in public, and protect the integrity of the selection process. Proposers that violate this policy will be disqualified.

1.7 PRE-PROPOSAL CONFERENCE Proposers are strongly encouraged to attend the pre-proposal conference. The pre-proposal conference will be held at the date, time and location indicated in Section 1.5, Schedule of Events. The terms, conditions, and scope of work will be reviewed and discussed. Technical questions will not be addressed at the pre-proposal conference or site visit but may be submitted in writing in accordance with RFP Section 3.1 “Inquires.”

1.8 SITE VISIT A one-time site visit of a bus, para transit, and a light-rail car will be conducted immediately following the pre-proposal conference. Submission of a proposal will be prima facie evidence that the Proposer is, in fact, aware of all vehicle conditions affecting performance and proposal prices.

1.9 DEFINITION OF KEY TERMS A.R.: City of Phoenix Administrative Regulation. A.R.S.: Arizona Revised Statutes. Agreement: The Contract to be negotiated and entered into by the CITY and a successful Proposer for the Work described in this RFP. Authorized Signee: The person who is executing the Contract for the Proposer and is authorized to bind the Proposer. Automated Passenger Counter (APC): An automated means of counting boarding and alighting passenger. AVL: Automatic Vehicle Locator. BAFO: Best and Final Offer.



5

CAD: Computer Aided Dispatch. CFR: Code of Federal Regulation. City: The City of Phoenix, a municipal corporation, specifically the City of Phoenix Public Transit Department. Contract: The legal agreement executed between the City of Phoenix and the successful Proposer. Contract Administrator: The CITY employee assigned to ensure compliance with the terms of the Contract. Contracting Officer: The CITY contact person responsible for all matters regarding this RFP. Contractor: A successful Proposer who enters into a Contract with the CITY to provide the services specified in this RFP. Deadhead (Miles and Hours): The miles and hours that a vehicle travels when out of revenue service. Fiscal Year: A year that begins on July 1 and ends in the following year on June 30. FTA: Federal Transit Administration. Fixed Route Services: Services provided on a repetitive, fixed schedule basis along a specific route with vehicles stopping to pick-up and deliver passengers to specific locations; each fixed route trip serves the same origins and destinations. Headway: The time interval between vehicles moving in the same direction on a particular route. Layover / Recovery Time: The hours scheduled at the end of the route before the departure time of the next trip. May: Indicates something that is not mandatory but permissible. Missed Trip: A trip that is not fifty percent (50%) completed, is later than the next scheduled trip, or is more than thirty (30) minutes late to its scheduled destination. Non-revenue Vehicle: A vehicle that is used to support transit services but is not used in Revenue Service. Onboard: A location (mobile) within a service vehicle in accordance with the Scope of Services.



6

Operators: The personnel (other than security agents) scheduled to be aboard vehicles in revenue operations. Performance: The ability of a Proposer to comply with the required Scope of Work and specifications and to function in a reliable and otherwise satisfactory manner under actual operating conditions. Also, the ability of a Proposer to comply, during the expected Contract life, with all contractual terms and conditions specified in this RFP. Phoenix Public Transit: A department within the City of Phoenix that owns and operates transit service for the CITY, the largest member of the regional transit system (Valley Metro). Proposal: A written document submitted by a Proposer in response to the Request for Proposals. Proposer: Any person or firm submitting a competitive proposal. Public Transit Director: The person who has the capacity to execute the contract for the CITY and has complete and final authority except as limited herein. Revenue Hour: The hours operated when a vehicle is available to the general public and there is an expectation of carrying passengers who directly pay fares, are subsidized by public policy, or provide payment through some contractual arrangement. Revenue service excludes deadhead, vehicle maintenance testing, school bus service, and special event service. Revenue Mile: The miles operated when a vehicle is available to the general public and there is an expectation of carrying passengers who directly pay fares, are subsidized by public policy, or provide payment through some contractual arrangement. Revenue service excludes deadhead, vehicle maintenance testing, school bus service, and special event service. RPTA: The Valley Metro Regional Public Transportation Authority, funded by local governments to provide coordinated, multi-modal transit options to residents of the Valley. Shall, Will, Must: Indicates a mandatory requirement. Solicitation: This Request for Proposals (RFP) and all associated addenda and attachments.

Sub-systems: All onboard CAD/AVL components including onboard surveillance system and exterior head signs Subcontractor: Any person, firm, entity or organization, other than the employees of Contractor, who contracts with Contractor to furnish labor, or labor and materials, in connection with the Work, whether directly or indirectly, on behalf of Contractor. System: The complete CAD/AVL replacement in accordance with the Scope of Services.



7

Transit Agency: CITY and Transit Partners. Transit Partners: Includes City of Tempe, City of Scottsdale and the Regional Public Transportation Authority and Valley Metro Rail. Vehicle Hours (Miles): The hours (miles) that a vehicle is scheduled to or actually travels from the time it pulls out from its garage to go into revenue service to the time it pulls in from revenue service. It is often called “platform time.” Work/Service/Program/Project/Solution: Any and all of the labor, material, services, supervision, tools, machinery, equipment, supplies, facilities, and support used by Contractor in accordance with achieving the specification and requirements for which the CITY has contracted with Contractor as called for by the agreement and necessary to the completion thereof. Working Days: Normal business days of CITY offices, unless otherwise specifically noted.



8

SECTION 2 – SCOPE OF WORK 2.1 PROJECT OVERVIEW

2.1.1 Introduction

CITY and its Transit Partners are soliciting proposals for a turnkey System to service Bus, Paratransit, Light-Rail, and selected supervisor vehicles. The System shall adhere to specific requirements for network security, scalability, functionality, and interoperability with existing and pertinent regional Transit applications as detailed by functional requirements in this RFP document. In 2013, CITY and Transit Partners hired a third party transit consultant firm to evaluate the existing regional CAD/AVL system and an agency owned 450 MHz radio system. The consultants were tasked with providing a set of alternatives to replace/upgrade the existing CAD/AVL system and radio network. As a result of this study, an updated radio frequency network architecture was selected along with a new onboard vehicle system architecture that meets both CITY and Transit Partner CAD/AVL requirements.

CITY anticipates awarding a contract based on best value, technical design, and technical approach as determined by CITY-established procurement guidelines to a single contractor for the purchase and installation, including a comprehensive system extended maintenance contract, and training program. It is anticipated that all tasks associated with planning, installation, testing and acceptance will require a period not to exceed eighteen (18) months.

2.1.2 Acronyms and Abbreviations ACK Acknowledgement MID Module Identification ADA Americans with Disabilities Act MTBF Mean Time Between Failures AGC Automatic Gain Control NAT Network Address Translation

AP Access Point NEC National Electric Code

ASCII American Standard Code for Information Interchange

NEMA National Electrical Manufacturer’s Association

AVL Automatic Vehicle Locator PCU Power Conditioning Unit APC Automatic Passenger Counter PRTT Priority Request to Talk ASA Automatic Stop Annunciation OCC Operations Control Center

BI Business Intelligence

O/S Operating System

BUS Any service vehicle use to transport passengers

PCMCIA Personal Computer Memory Card International Association

CAD Computer-Aided Dispatch

PCU Power Conditioning Unit

CCTV Closed Circuit Television (Onboard Surveillance System)

PID Passenger Information Display(s)



9

cont’d

CFR Code of Federal Regulations PMT Passenger Miles Traveled

CITY City of Phoenix Public Transit Department

RDT Remote Dispatch Terminal

COP City of Phoenix RFI Radio Frequency Interference DC Direct Current RSS Really Simple Syndication DVI Driver Vehicle Inspection RTT Request to Talk EA Emergency Alarm SAE Society of Automotive Engineers EMI Electromagnetic Interference SNMP Simple Network Management Protocol

FCC Federal Communications Commission

SOP Standard Operating Procedures

FDR Final Design Review TSP Traffic Signal Priority

GUI Graphic User Interface

UL Underwriters Laboratories Incorporated

ICD Interface Control Documents UPT Unlinked Passenger Trips

IP Internet Protocol

VAC Voltage Alternating Current

ITD City of Phoenix Information Technology Department

VDC Voltage Direct Current

IVU In-Vehicle Unit VID Vehicle Identification KPI Key Performance Indicators VLU Vehicle Logic Unit LAN Local Area Network VoIP Voice over Internet Protocol LED Light Emitting Diode WAN Wide Area Network MDT Mobile Digital Unit WLAN Wireless Local Area Network MGR Mobile Gateway Router XML eXtensible Markup Language

2.1.3 Background

The CITY owns a large LAN/WAN network and currently supplies the infrastructure, servers, and desktops required by the CAD/AVL vendor via a minimum hardware requirements agreement. CITY’s network currently exists within a corporate enterprise network controlled by a separate and distinct CITY department, Information Technology Department (ITD). Contractor must adhere to audit and security standards set forth by ITD to safeguard CITY’s data. The existing CAD/AVL system uses a Transit Agency owned 450 MHz radio frequency system for voice and data communications. A new replacement radio system is tentatively scheduled to be installed and implemented in phases. The first phase is scheduled for completion by March 7, 2016 and tentatively scheduled to be fully functional by June 2018. Transit Agency uses the GIRO HASTUS software for bus and rail regional scheduling. The HASTUS schedules are updated quarterly to the existing CAD/AVL system. The scheduled updates are performed manually by CITY staff to the CAD/AVL system. The Paratransit vehicles use Trapeze PASS for manifest management and operations. The Paratransit vehicles utilize onboard CAD/AVL equipment as a pass thru for the Trapeze Paratransit application.



10

CITY has a dedicated Information Technology (IT) team to perform day-to-day regional infrastructure and back end systems support. Transit Agency coordinates short and long term System planning to ensure standardization throughout the Transit organization.

2.2 GENERAL PROJECT REQUIREMENTS The objective of this contract is to provide an efficient, cost-compliant and reliable CAD/AVL System (System) replacement in the manner, and timeframe identified in the RFP document. Unless specified, the requirements herein apply to all modes of transportation including bus, paratransit, and rail. It is the primary goal of Transit Agency to acquire proven multimodal CAD/AVL technology that will: 2.2.1. Provide a robust, unified multimodal CAD/AVL solution;

2.2.2. Provide a safe, seamless transit system for customers that support leading-edge passenger

information for trip planning such as next bus passenger information to be available online, via mobile applications, and at transit stops;

2.2.3. Follow and apply industry best practices to improve transit service and operations;

2.2.4. Provide an adaptable system that will support and improve business processes for contracted services by creating more efficient oversight for performance metrics;

2.2.5. Maximize the lifespan of the complete system by providing software and hardware that are easily upgradeable, maintain backward compatibility, component replaceable and interoperable to maintain the highest level of service;

2.2.6. Provide more efficient, coordinated operations between contracted service transit divisions and Transit Partners by improving intra-operability;

2.2.7. Leverage new Transit Agency owned radio communications system to maximize coverage reliability for the service area;

2.2.8. Provide a fully redundant voice/data communication system;

2.2.9. “Future proof” the voice and data radio system for future system deployments, expansions, and upgrades;

2.2.10. Ensure safety for customers and operators providing more efficient incident response and management;

2.2.11. Maximize the integration and utilization of the onboard equipment to improve data accuracy for fare collection and passenger counting systems;

2.2.12. “Future proof” the onboard system for future system deployments and upgrades;

2.2.13. Improve automated reporting for ongoing vehicle maintenance to provide efficiencies in monitoring and pro-active maintenance activities;



11

2.2.14. Provide reporting efficiencies for, and greater reliability of, Key Performance Indicators (KPI) by automatically calculating and reporting items such as lost service, on-time performance, and maintenance issues at a more granular level;

2.2.15. Provide more efficient operations by developing standardization across the different partners and contracted service providers for data reporting, collection, scheduling and various operational procedures; and

2.2.16. Improve operations by providing a system that is adaptable, configurable and intuitive to use that simplifies changes and customizations necessary for operations and reporting.

2.3 INTERFACE REQUIREMENTS

This section describes interfaces that the System shall support in order to provide all required functions herein. Contractor shall coordinate and implement all defined interfaces.

2.3.1. System interfaces shall utilize the capabilities already present in the existing Transit Agency

systems to be interfaced, so as to minimize the need for modifications to those systems. Contractor shall provide all interfaces in full compliance with the functional requirements of each existing systems current specifications and in the format designated or approved by CITY for future interfaces.

2.3.2. System interfaces shall provide a secure means of data exchange, including providing historical and real-time data such as vehicle position and schedule adherence data on the fleet.

2.3.3. System performance shall not be affected by data transfer activity to and from other Transit systems.

2.3.4. System shall utilize and interface with the Transit Agency’s new radio system. The Transit Agency is deploying a Motorola MotoTrbo 3 site Connect Plus Radio System with an Avtec Scout IP Dispatch Console. Contractor shall use the MotoTrbo System as a backup for both voice and data communications. During the design and review process Contractor shall work with the CITY and the radio vendor to finalize and determine the best configuration to meet the Transit Agency’s mobile communications requirements as required in this solicitation. The system has 15 individual timeslots available for voice and data at the same time. Contractor shall interface the CAD/AVL solution into the MotoTrbo Connect Plus System for voice and data communications via wireline or using a control station (donor radio) using protocols outlined in the Motorola MotoTrbo Application Developer Program or Avtec API. Contractor shall be a current MotorTrbo Application Developer. If Contractor is not, they may apply for membership by sending an email to [email protected]. Applying for membership does not imply that membership will be granted. Additional questions regarding the new radio system can be directed to the vendor listed below.

2.3.5. Train CITY staff to maintain the interface architecture.

2.3.6. Provide the Interface Control Document (ICD) upon final design of each interface. Any changes on the ICD shall be provided to the CITY at Final Acceptance.



12

2.3.7. Work with the vendors required to facilitate the proposed solution to provide the interfaces required by the Transit Agency. Contractor shall complete all work necessary and assume all costs associated with producing the required interfaces.

2.3.8. Contractor shall not require CITY or Transit Partners to be involved in coordination and management of any agreement between itself and the respective vendors concerning the required interface.

2.3.9. Network Access to System Historical Data

2.3.9.1. System shall allow extraction of System historical data in common machine-readable formats that can be used in other Transit applications.

2.3.9.2. All such access shall be via a System information retrieval function accessed through a web browser.

2.3.10. Contractor shall work with all vendors listed below as well as any future vendors to provide the interfaces required by Transit Agency.

Software/Component Vendor

Fare Collection System Scheidt & Bachmann

Scheduling Software GIRO

Surveillance System UTC/Apollo

Trip Planner Trapeze

PASS Trapeze

Radio Creative Communications / Motorola

GTFS Google

Content Manager/Player FourWinds Interactive

2.4. AUTOMATED VEHICLE TELEMATICS SYSTEM

2.4.1. The System shall provide a module that includes a real-time and passive alarm data function to

assist Transit Agency to make vehicle preventive and breakdown maintenance decisions. The telematics module shall allow Transit Agency to identify fleet defects and patterns in vehicle maintenance in order to increase efficiencies.

2.4.2. The telematics module shall be integrated with onboard multiplex and powertrain system to provide engine level reporting on components such as, but not limited to; Heating, Ventilation and Air-Conditioning (HVAC), engine control module, electronic I/O modules, transmission control module, and automatic braking system. The telematics solution shall have the capability to perform real-time vehicle diagnostics and be configured to include priority alarms detection while monitoring vehicles.



13

2.4.3. The System shall monitor additional onboard sensors and multiplex systems such as, but not limited to:

2.4.3.1. Pressures - oil, hydraulic 2.4.3.2. Braking events - hard braking events 2.4.3.3. Temperature - engine oil, engine coolant, transmission fluid 2.4.3.4. Fluid levels - engine oil, engine coolant, transmission fluid, fuel 2.4.3.5. Fuel Consumption 2.4.3.6. Other circuits such as wheelchair ramp deploy, bus kneel activation, and door

open/closed.

2.4.4. The module shall have a configuration tool that allows the System Administrator to set thresholds for alarms, alarm frequencies and which data shall be transferred immediately. Data that is not transferred immediately shall automatically be sent “over-the-air” via backup radio or WLAN upon returning to the garage or maintenance facilities.

2.4.5. The module shall have the capability to identify vehicle alarms on the vehicle Mobile Data Terminal if required by Transit Agency.

2.4.6. The module shall be integrated with Contractor’s CAD/AVL application.

2.4.7. The solution shall be software driven and not hardware based.

2.5. RAIL VEHICLE SUBSYSTEM INTEGRATION Contractor shall provide, install, integrate and test a complete Passenger Information Rail Vehicle Subsystem. The Passenger Information Rail Vehicle Subsystem shall consist of all necessary vehicle hardware and central control components including hardware, software and software tools. Contractor shall: 2.5.1. Provide and install 50 complete sets of vehicle CAD/AVL borne components for integration,

installation (to include utilizing Transit Agency’s furnished Mototrbo Radio system), and testing for unified CAD/AVL communications and functionality as defined in this solicitation..

2.5.2. Provide CAD/AVL components that meet federal rail requirements. 2.5.3. Fully integrate, to the extent possible, Passenger Information Rail Subsystem with Contractor’s

CAD/AVL System to include but not be limited to all function requirements as specified in this Scope of Work (MDT, APC system, Mobile router, Covert Microphone, etc.).

2.5.4. Interface and integrate with onboard rail APC systems.

2.5.5. Verify, test and demonstrate as necessary, to satisfy Transit Agency that the entire Rail Subsystem will operate as required.

2.5.6. Include a GPS-based AVL function. All vehicles shall report GPS location regardless of whether

the vehicles are moving, have no assigned routes, or whether or not the vehicles are logged into the CAD/AVL System.



14

2.5.7. The integration of electronic digital signs onboard Light-Rail vehicles is not inclusive of this Scope of Work.

2.5.8. Contractor system software shall utilize Rail Passenger Information System to dynamically

provide Bus to Light-Rail route information including transfer information as required in functional requirement section 3008.1.2.

2.6. PROJECT DOCUMENTATION SUBMITTALS

Contractor shall provide the following items to the CITY upon Final Acceptance:

2.6.1. Equipment Removal Plan Contractor shall coordinate with Transit Agency and deliver an Equipment Removal Plan that meets each Transit Agency's requirements. The equipment removal plan shall include the process and steps of removing and packaging the existing items below separately: 2.6.1.1. Vehicle Logical Units and associated components

Contractor shall package removed equipment and provide a serialized inventory list together with the equipment one (1) business day after the equipment is removed to appropriate Transit Agency.

2.6.2. Design Diagrams

Contractor shall submit all documentation and design diagrams during Preliminary Design Review and FDR for the following:

2.6.2.1. Electrical Diagrams

2.6.2.2. Mechanical Diagrams

2.6.2.3. Network Security Diagrams

Accompanying Excel document with access control lists and firewall rules

configuration requirements. Diagrams must show interconnections between the separate networks and what

ports are open closed in the diagram.

2.6.2.4. Block Diagrams

Block diagrams and WLAN radio frequency coverage plot and floor plans shall be provided showing all major components at each of the following sites: o Central Data Center o Central and Remote Traffic Control Centers o Facility Site plan and equipment layout. o All Garage and maintenance facilities

Block diagrams and plan views of device locations showing all major components in each Bus, Rail and Paratransit vehicle by type.



15

2.6.2.5. Network Diagrams

Contractor shall provide both logical and physical network infrastructure diagrams of the System to show the following: o Interconnections between separate networks o Nodes within the System. o All new and existing equipment.

Estimated Data Bandwidth Report

Contractor shall provide a report of the network bandwidth utilization by the System. The report shall indicate minimum, maximum, average and total (weekly, monthly and yearly) data bandwidth utilization in table format per: o Node o Locations o Device o Mode o Vehicle

Contractor shall include the assumptions used to generate the information in the report.

Quality Assurance Plan (QAP)

Contractor shall submit the QAP for review and Transit Agency approval.

2.6.2.6. System Design Document. Contractor shall deliver a detailed system design document containing, at a minimum, the following: CAD/AVL System features, functions, commands, and reports.

User Workstation configurations, control arrangements, and display screen

images.

MDT configurations, control arrangements, and display screen: images.

Detailed data flow diagrams for all major use case scenarios.

Time synchronization mechanisms for all devices.

Database Design Diagram

2.6.2.7. Field Equipment and Subsystem Acceptance test plan and procedures.

2.6.2.8. System Integration Test plan and procedures.

2.6.2.9. Factory Acceptance Test plan and procedures.



16

2.6.2.10. All Test plan documentation to be approved by Transit Agency.

2.6.2.11. Data backup and recovery plan.

2.6.2.12. Transit Agency Onboard Vehicle Architecture Description List.

2.6.2.13. APC System and Procedures Manual.

2.6.2.14. Vehicle in a Box. Complete "vehicle in a box" simulating the bus, rail and paratransit vehicles and the System in live environment including, but not limited to:

MDT

VLU

Informational Signage

Mototrbo Radio (to be provided by Transit Agency)

Farebox (bus only, to be provided by Transit Agency)

Network communication equipment required to allow "vehicle in a box" to be

self-contained.

Power inverters to supply required power to "vehicle in a box" via standard 120V AC, 15amp circuit.

2.6.2.15. Software Interface Plan. Contractor shall provide detailed design specifications on

software interfaces as required.

2.6.2.16. Description and illustrations of Bus Traffic Control Center workstations.

2.6.2.17. Training program plan, materials and equipment as required.

2.6.2.18. Description and locations of power installations including bonding and grounding that will be performed.

2.6.2.19. Reliability Matrix

2.6.2.20. Contractor shall provide documentation of the reliability in MTBF of the equipment including a description of their maintainability and life expectancy.

2.7. MINI FLEET TESTING

Contractor will complete a full System test on a mini fleet to validate System operates per the functional requirements in this contract. The specifics on the mini fleet testing will be determined during the design and review process.



17

Any system testing and specifics of system design in this contract will be established and mutually agreed upon as part of the System Design process, and shall require final approval by Transit Agency.

2.8. REPORTS

2.8.1. PRE/POST DRIVER VEHICLE INSPECTION (DVI) REPORTS Transit Agency utilizes DVIs to comply with vehicle safety and vehicle state of good repair requirements. Contractor’s System shall work with third party solutions for DVI support as well as provide a built in DVI solution that is customizable to meet the needs of Transit Agency. Contractor shall at a minimum provide an electronic method that will report safety issues and vehicle good state of repair items as determined during the design review process.

2.9. AUTOMATIC PASSENGER SYSTEM (APC)

2.9.1. Equipment Contractor shall install APC equipment in all fixed-route fleet vehicles. Contractor shall utilized existing APC system on Light-Rail vehicles. Contractor shall install APC system on 10% of the Paratransit vehicles.

2.9.2. Reporting Contractor shall include an APC system solution to dynamically collect and prepare Unlinked Passenger Trips (UPT) and Passenger Miles Traveled (PMT) data for bus, paratransit, and Light-Rail passengers reporting. Contractor shall ensure that Transit Agency has a process and procedures in place directing use of this functionality in a manner that meets all National Transit Database (NTD) dynamic reporting requirement set by the FTA. 2.9.2.1. APC benchmarking plan for the first year. 2.9.2.2. APC maintenance plan for subsequent years. 2.9.2.3. Validation of the APC data for UPT and PMT data against a separate manual sample

covering a full year. 2.9.2.4. Development of procedures, as necessary, for adjusting the APC data for UPT and

PMT to replicate the data produced through manual sampling.

2.10. EXTENDED MAINTENANCE

2.10.1. Software Support Services Contract Contractor, as part of this contract, shall include a three (3) year comprehensive software support service contract as defined in Attachment E. After the three year software warranty, Contractor shall automatically commence to the Extended Maintenance as defined in Attachment E. The extended maintenance shall be no less than five (5) years with the option to extend six additional years in two-year incremental bases at the sole discretion of the CITY. Contractor shall provide a standard software maintenance and system support service contract to cover any research and development costs associated with maintaining central and fixed end software functionality as stipulated in this contract. Transit Agency acknowledges that any new software functionality not stipulated in final system acceptance is not covered. Please refer to Attachment E for software maintenance and support services requirements.



18

2.10.2. Hardware Support Services Contract Contractor shall include a minimum of three (3) year standard manufacturer warranty as defined in Attachment E for all hardware at no charge to the Transit Agency. In addition, Contractor shall provide a comprehensive hardware maintenance and support service, commencing after expiration of manufacturer hardware warranty. Contractor shall offer no less than five (5) years with the option to extend six additional years in two-year incremental bases at the sole discretion of the Transit Agency. The maintenance and support services shall cover any research and development costs associated with maintaining onboard equipment and functionality for the life of the contract, including any interoperability issue that may occur over the life of the contract. Contractor shall manage firmware updates and system documentation. Transit Agency acknowledges that any new hardware functionality not stipulated in final system acceptance is not covered. Refer to Attachment E for hardware maintenance and support services requirements. Contractor shall separate, for billing purposes, maintenance, repair, and replacement service invoicing as determined by CITY.

2.10.3. On-Site Support Specialist Contractor shall provide an on-site application and hands-on technical expert to ensure CAD/AVL system performance and system uptime requirements are maintained as specified on the Transit Agency’s Extended Maintenance Contract requirements in Attachment E.

2.11. CAD/AVL SYSTEM REQUIREMENTS The CAD/AVL system shall meet the hardware/software functional requirements as described in the functional requirements matrix below. These requirements are industry best practice standards along with specific Transit Agency requirements. The functional requirements are broken down into the following categories:

General Onboard Central Data and Reporting Yard Communication

1000 GENERAL SYSTEM REQUIREMENTS

1000.1.1 The following requirements apply to all subsystems, unless more specific requirements are defined in subsequent subsystem requirements sections.

1001 REQUIREMENTS

1001.1.1 No current functionality shall be removed or rescinded regardless of statements in these requirements without written consent of the Transit Agency.

1001.1.2 The central system functions and functionality shall not be removed or rescinded regardless of the statements in these requirements without the written consent of the Transit Agency.



19


1001.1.3 Current interfaces to external systems and applications (e.g., scheduling, maintenance, reporting, etc.) in the system shall be maintained and/or upgraded, and shall not be removed without the written consent of the Transit Agency.

1001.1.4 The onboard and central system equipment and functionality shall be integrated with the selected communications alternative and provide functions meeting or exceeding the communications requirements.

1001.1.5 The onboard and central system equipment and functionality shall be inclusive of bus, paratransit andlight‐rail vehicles.

1001.1.6 Contractor shall provide Design Review and Supplemental Documentation as requested by Transit Agency.

1002 PHYSICAL AND MATERIALS

1002.1 General Physical and Material Requirements

1002.1.1 Contractor shall provide a complete hardware specifications list for system hardware that shall include,but may not be limited to, the following: all needed computer processing devices, keyboards and navigation devices, and displays for devices, workstations and servers as well as for all networking and communications equipment to be supplied and/or procurement by Transit Agency.

1002.1.2 Contractor shall review existing central equipment (server, storage, switches, router) to be used at time of deployment and recommend necessary upgrades or supplemental equipment.

1002.1.3 The central system shall reside on a Transit Agency IT subnet, as opposed to being a separate “stand‐alone” network. Transit Agency workstations shall be able to operate in a controlled access environment; Contractor shall provide all required ports and IP addresses and server names to Transit Agency.

1002.1.4 All onboard equipment shall be designed for use in the transit bus, paratransit and light‐rail industry, with specific attention to ergonomics, reliability, efficiency, and safety for passengers, operators, maintenance personnel and other system users.

1002.1.5 Equipment furnished under these specifications shall be the latest model in current production, as offered to commercial trade, and shall conform to quality workmanship standards and use materials consistent with transit industry requirements.

1002.1.6 Contractor shall represent that all equipment offered under these specifications is new. Used, shopworn, demonstrator, prototype, re‐manufactured, reconditioned, or discontinued equipment shall not be supplied under this contract.

1002.1.7 All equipment shall be constructed in accordance with best commercial practice, with such practices described in the associated design documentation. The design and construction shall provide for the following: 1. Reliable and stable operation, 2. Minimum maintenance and alignment procedures, with a minimum of special tools, 3. Minimum number and variety of assemblies and spare parts, 4. Maximum attention to human factors engineering and ergonomic design, and 5. Simplified design and rapid fault isolation to reduce the requirement for maintenance personnel.



20


1002.1.8 All fasteners including screws, nuts, and washers shall be stainless steel or an approved alternate non‐corrosive material; no self‐tapping screws shall be used unless specifically approved. All fasteners used in on‐board equipment or any other equipment subject to vibration shall include reasonable protections to avoid loosening due to vibration. Tamper proof fasteners may be required.

1002.1.9 All parts shall be made of corrosive resistant material, such as plastic, stainless steel, anodized aluminum or brass. Protection against galvanic reactions between dissimilar metals shall be provided. All parts shall be constructed with materials and quality suited to the intended use.

1002.1.10 Contractor shall use modular design wherever feasible.

1002.1.11 Standard, commercially available components shall be used wherever possible.

1002.1.12 All functionally identical modules and assemblies shall be fully interchangeable between like modules for other units of the same type of equipment. Components with non‐identical functions shall not be nor shall they appear to be interchangeable.

1002.1.13 Unless otherwise approved, all modules and assemblies shall be connected using standardized durable, positive‐locking, and indexed quick disconnect fasteners.

1002.1.14 Equipment, assemblies and components shall be identified by a part number and/or serial number, permanently and legibly affixed directly to the surface.

1002.1.15 All data shall be maintained in non‐volatile memory.

1002.2 Central Site Equipment and Systems Requirements

1002.2.1 Central site servers shall adhere to the Transit Agencies’ virtual infrastructure requirements.

1002.2.2 Central site servers shall have documentation and ability to withstand IP address changes with minimal staff interaction. IP address changes may occur during disaster recovery or organization IP scheme changes.

1002.3 Redundant Central Systems

1002.3.1 The central system hardware/software shall operate in a fully redundant environment. Contractor shall implement and integrate a parallel backup central system at a location separate from the primary central system. The backup central system shall maintain full operation indefinitely, with automatic and immediate failover if the primary central system becomes not fully operational.

1002.3.2 The central system shall have redundant connections to the cellular data WAN link, voice radio system WAN link, and Transit Agency’s WAN to garages and user workstations.

1002.3.3 The backup system shall have provisions to connect temporary workstations directly to the backup system if needed.

1002.3.4 Redundant central site servers shall be located at the Disaster Recovery site as designated by Transit Agency.

1003 SOFTWARE AND NETWORK

1003.1 General Software and Hardware Requirements



21


1003.1.1 All software shall be the current version in production at the time of installation, and shall include version control numbers.

1003.1.2 All Contractor‐supplied software, provided under this contract shall be the most current released version at the time of system acceptance. In the event that there is a version change prior to the completion of software development, Contractor shall update all applicable systems with the then‐current version of software with Transit Agency approval at no additional cost.

1003.1.3 All software, software modules and objects shall contain version control numbers or other unique version/build identification numbers.

1003.1.4 All foundation software supplied shall be compliant with Transit Agency operating system and application software standards.

1003.1.5 Contractor shall utilize Transit Agency network.

1003.1.6 All software supplied shall be compliant with the following operating system and application software standards: 1. Transit Agency’s current operating system or approved equivalent for all workstations 2. Microsoft VERSION or approved equivalent for all applications requiring Microsoft components.

3. Software shall support all Microsoft patches within 30 days of patch release.

4. Software shall have ability to run on current Microsoft Version operating system within six (6) months of release.

1003.1.7 All workstations shall use dynamic IP addressing assignments, unless otherwise approved by Transit Agency.

1003.1.8 On‐board hardware/firmware shall be updated to reflect the current generation at the time of Preliminary and Final Design.

1003.1.9 Contractor shall specify hardware for Transit Agency with capacity adequate to support Transit Agencyapplications and other Contractor applications involved in the solution, maps, data and associated files required for operation, with 100% expansion capacity of the specified hardware.

1003.1.10 All central site software shall be written in a common and nonproprietary language.

1003.1.11 CAD/AVL shall utilize open database architecture for all database fields and functions and shall be non‐proprietary.

1003.1.12 Features shall be provided to identify the software module versions on each device, and verify that they are the correct or most recent versions for that device.

1003.1.13 Software shall be organized in a modular, Transit Agency configurable manner.

1003.1.14 Transit Agency‐specific parameters shall not be hard‐coded in the source‐code. They shall be Transit Agency system administrator‐configurable.

1003.1.15 Unless otherwise approved for selected on‐board equipment, IP References whether for internal or external use shall use a 4 octet IP address scheme. Transit Agency will define and host these IP addresses.



22


1003.1.16 Application software (both user and system) shall be portable, i.e., the source code shall be transferable to other computers using the same hardware, database software and operating system without any modifications or use of hardware key.

1003.1.17 The central System application software shall scale without modification to newer, higher performance hardware, operating systems and other system components (including but not limited to database, web server, etc.).

1003.1.18 The system shall have the capability of hardware and software extension to include new or additional features.

1003.1.19 The system shall be designed to migrate to updated versions of hardware and software and operating systems.

1003.1.20 All central system user interfaces shall have online help features (including a help menu) with context sensitive help available by pressing the <F1> function key and Tooltips. All functions shall be accessible via the keyboard or mouse and not be limited to web accessible content.

1003.1.21 Contractor shall design all components of the system, from the fixed end to the mobile systems, so that all gear remains synchronized to the same time source at all times. The time source shall be derived from Transit Agency‐designated time service and synchronize with the following components: 1. CAD/AVL sub‐system, including on‐board equipment. 2. System Management sub‐system. 3. Radio Console sub‐system. 4. Logging Recorder sub‐system. 5. Telephone sub‐system.

1003.1.22 The system date and time shall adjust automatically for leap years and holidays. Holidays shall be Transit Agency configurable to include holidays observed by Transit Agency, as well as limited or special service days such as the day before or after a holiday. Special service dates, including holidays, shall be available through a database table and not be calculated by CAD/AVL. Daylight savings/standard time shall be configured to be enabled or disabled by Transit Agency.

1003.1.23 The system date and time shall provide the same date for service times associated with Transit Agency’s Transit Service Day, where number of hours in one day is based on start and end of service regardless of service extending past midnight. This feature shall be configurable by Transit Agency.

1003.1.24 Data transferred from a device or system shall not be purged or written over until a successful transfer is confirmed. In the event that a transfer is not successful and the device is unable to re‐attempt a transfer, it shall revert to the previous version of the data automatically and without corruption. Any data transfer failure shall be logged, alerted, and recorded.

1003.1.25 For critical failures affecting next day service, the system shall automatically notify specified Transit Agency staff via email and/or phone. The number of staff notified and their contact information shall be configurable by Transit Agency. Contractor shall identify key processes that should be monitored through an external monitoring system. Contractor shall have the ability for the application to independently monitor key processes and automatically restart the system if required.

1003.1.26 Features shall be provided to ensure that all system‐created files are uniquely identified, and that no files are lost or missed during data transfer.



23


1003.1.27 Verification features shall be provided to confirm that there have been no losses of data at any point in the system.

1003.1.28 All devices shall include functionality to extract data directly from the device using a laptop computer or other device in the event that the device is unable to transfer data through the system due to device damage or communications malfunction. Tools and processes for this shall be described in the Design Documentation.

1003.1.29 All software licenses, warranties, and software keys shall be in Transit Agency’s name.

1003.1.30 The system shall have a similar look and feel across the user interface for applications, menus, and screens and shall use consistent vocabulary. Interface vocabulary and field names within the system shall be modifiable by system administrators.

1003.1.31 The system shall offer an integrated telematics solution for vehicle‐level (i.e. engine‐level, transmission, tire pressure, odometer reading, articulating, HVAC, etc.) reporting and/or shall include standard performance monitoring to include canned reports and dashboards.

1003.1.32 The system shall dynamically inventory and manage vehicle equipment configuration file to facilitate patch management and/or component auditing.

1003.1.33 The Central system shall be optimized for a virtual environment and not contain traditional clustering (ex: Microsoft Clusters).

1003.2 Network, System Security and Backup Requirements

1003.2.1 System shall be an end‐to‐end IP based solution. System shall be compatible with IPv4 and IPv6

1003.2.2 During implementation, Contractor shall describe in detail their monitoring applications for servers and other central systems necessary for the CAD/AVL system and shall integrate into Transit Agency SNMP based monitoring software.

1003.2.3 Transit Agency will provide the physical network and networking equipment for the CAD/AVL to connect all system equipment (e.g., dispatch consoles, servers, WLAN access points) using its existing corporate network. Core CAD/AVL operational components (dispatch workstations, servers, WLAN access points via firewall, remote access servers, VoIP), shall reside on separate virtual LANs on this network within an address space and numbering convention to be provided by Transit Agency.

1003.2.4 Back end equipment shall utilize Transit Agency designated time service, at least once daily, to acquire timing.

1003.2.5 Management information, reporting, and general purpose workstations shall reside on Transit Agency’s corporate LAN, and Contractor shall be responsible for providing any interfaces required in order to make CAD/AVL applications available on those workstations without the need to procure or use a separate workstation for the CAD/AVL functions.

1003.2.6 Contractor shall develop a comprehensive System Security Plan, which identifies the system elements that require protection, potential threats and risks, and mechanisms, procedures and processes to deter, detect and neutralize such threats and risks. The plan shall also identify any expectations or responsibilities of Transit Agency related to the provision of system security. This plan must be reviewed and approved by Transit Agency.



24


1003.2.7 The system shall provide Transit Agency configurable access control based on Transit Agency’s Active Directory Logons for the following user groups and classifications: 1. User groups will be based on the major system functions to be provided and will be determined as part of the System Design. Examples include system administrators, dispatchers, etc. A minimum of 10 user groups shall be supported. 2. Each user group shall support a minimum of four (4) user classifications such as “User”, “Senior User”, “Supervisor”, and “Administrator”. 3. The system shall include functionality to assign a master set of privileges to each user group, and activate a certain subset or combination of privileges for each specific user classification. 4. The system shall include reasonable flexibility to add, delete and modify the user groups and classifications, and to adjust the privileges assigned to each classification, as part of normal system operations.

1003.2.8 Transit Agency will be responsible for assigning all system access privileges, and Contractor shall comply with Transit Agency requirements for strong password protection and password change policies. Password change policies may be different between central site servers, dispatch workstations, and on‐board equipment. The system shall LDAP compliant.

1003.2.9 Passwords shall be displayed encrypted.

1003.2.10 User and database schema owner password maintenance shall include the ability of the user to periodically change passwords in a simple and straightforward manner. Preference shall be given to implementation which provides the user with a single GUI based password change mechanism. No password shall be embedded at the user workstation level, and no password shall be unencrypted at the application server level.

1003.2.11 All system access shall be logged, secured (unable to edit), available in a system administrator report (RPT‐1: System Administrator Report), and sent to the Transit Agency's external log aggregator.

1003.2.12 Contractor shall adapt the CAD/AVL authentication mechanism to integrate with Transit Agency's existing Active Directory system at the time of system acceptance, using a design consistent with the current Transit Agency authentication infrastructure. The CAD/AVL system authentication mechanism shall be independent of the immediate availability of the Transit Agency Active Directory implementation, based on secure synchronization of authentication data sourced from Active Directory to the system.

1003.2.13 The system shall allow Transit Agency personnel with assigned privileges (e.g. Transit Agency personnel, System Administrator, etc.) to reset forgotten passwords.

1003.2.14 Application logons, logoffs and failed logons shall be logged, secured (unable to edit), available in a report for auditing purposes, and sent to Transit Agency's external log aggregator.



25


1003.2.15 The CAD/AVL shall provide for the following alarms, and shall include an interface to the existing Transit Agency SNMP management platform to provide a notification to Transit Agency specified groups for the following faults, as well as send alarm notifications to the Transit Agency's external log aggregator. Alarm triggers shall include, but not be limited to, the following: 1. A network device or communications fault; 2. A security breach; 3. A device fault; 4. A failed or incomplete data transfer; and 5. Server services failure.

1003.2.16 All alarms shall be logged and stored in a database, along with a history of corrective actions. Users with associated privileges shall be able to manually override alarms. Alarms that are manually overridden shall reactivate at a System Administrator ‐defined period until corrective action is taken and the alarm cleared.

1003.2.17 In order to support system monitoring and trouble shooting, system shall be configurable to allow for remote connections/access to be initiated via Windows, Apple, Android, other smart phone device, or tablet.

1003.2.18 The CAD/AVL shall generate a device status report for queried vehicles that provides: 1. All mutually agreed on‐board devices in use, which vehicle they are assigned to, date of last software or firmware update, current software or firmware version, and current schedule, route and stop version information. 2. System faults during the day. All reports shall be modifiable by Transit Agency and show full source code. Reports shall not be dependent upon the CAD/AVL application (i.e., parameters from CAD/AVL passed through to reports).

1003.2.19 The system shall include a data archiving and retrieval solution to be approved by Transit Agency.

1003.2.20 The system design shall meet Transit Agency standards for data recovery. These will be provided by Transit Agency during the initial design phase.

1003.2.21 Contractor shall provide a comprehensive data archive, backup, and recovery plan and the equipment and systems necessary to implement the plan.

1003.2.22 The system shall incorporate all needed hardware and software tools to archive and un‐archive data offline, and to restore any data to online systems needed for system recovery.

1003.2.23 Contractor shall specify archival database to hold a minimum of five (5) years data based on the estimated space requirements for data. Contractor shall work with Transit Agency to port data to Transit Agency‐managed data warehouse.

1003.2.24 Functionality shall be provided to execute routine (e.g. daily and weekly) backups through the Transit Agency’s existing network backup system. Contractor software shall be configured to work with Transit Agency’s current and future backup software to successfully backup all critical components.

1003.2.25 Contractor shall provide secure long term databases that will hold a rolling five (5) years of all CAD/AVL data that will be used for claims and legal purposes.

1003.3 System Test/Development Environment



26


1003.3.1 The central system shall include a separate System Administration and test/development environment installed on the Transit Agency Enterprise network. For test/development, this environment shall be entirely disconnected from the production central system, which shall enable potential changes to the software configuration to be developed and tested at Transit Agency prior to their implementation in the production central system. The test environment on the Enterprise network shall reside on separate servers, hostnames, IP addresses, and storage. Contractor shall provide detailed instructions and means for deploying a Test/Development environment. This would include scripts that account for changes such as IP addresses, Ports, DNS, ODBC, TNSNAMES, etc. Contractor shall provide detailed instructions for refreshing the Test/Development environment with fresh data from Production.

1004 ELECTRICAL AND ENVIRONMENTAL

1004.1 General Electrical and Environmental Requirements

1004.1.1 Equipment installed in Transit Agency offices or facilities shall operate from a nominal line voltage of 120 or 208 VAC, within voltage tolerances of +10% to –10%, and a frequency range of 57 Hz to 64 Hz.

1004.1.2 All equipment installed at stops/terminals shall operate from a nominal line voltage of 120 VAC, within voltage tolerances of +10% to –20%, and a frequency range of 57 Hz to 63 Hz without equipment damage.

1004.1.3 Contractor shall provide equipment that meets applicable specifications and criteria of the UL, NEC, the regulations of the State and local jurisdictions, along with all federal regulations. Contractor shall be responsible for securing UL and other electrical certifications, and shall be responsible for any costs associated with the certification process, permits and inspections.

1004.1.4 All equipment shall be compliant with applicable sections of the 47 CFR Part 15 of FCC rules and regulations regarding Radio Frequency Devices.

1004.1.5 All enclosures, chassis, assemblies, panels, switch boxes, terminal boxes, and similar enclosures or structures shall be grounded to a common ground point to avoid ground loops and potential differences. Acceptable grounds are through the bus frame/chassis using a through bolt, nut and lock washer, or the negative post of the bus battery. Grounds shall not be carried through hinges, existing bolted joints (except those specifically designed as electrical connectors), or power plant mounting.

1004.1.6 All enclosures, chassis, assemblies, panels, switch boxes, terminal boxes, and similar enclosures or structures shall be grounded to a common ground point to avoid ground loops and potential differences. Grounds shall not be carried through metal underground gas piping systems or aluminum electrodes.

1004.2 Equipment and Systems Requirements

1004.2.1 All Central Site (CAD) software servers and associated equipment shall be located at designated location prescribed by Transit Agency. The central site equipment associated with the Disaster Recovery site shall be located at designated locations prescribed by Transit Agency. Contractor shall survey Transit Agency’s existing office environmental conditions and DR site upgrade scope of work and confirm that it is adequate for the proposed central site equipment and systems.



27


1004.2.2 Equipment shall maintain specified performance while operating in a controlled environment of +50°F to +95°F, relative humidity (non‐condensing) less than 80%.

1004.2.3 All outdoor equipment (e.g. WLAN access points/antennas) shall be designed for and suitably protected against exposure to drastic fluctuations between day and nighttime temperatures, flood, large hail, strong winds, tornado, dust storms, and other environmental conditions prevalent in the Phoenix area and Mountain Regions of the State of Arizona.

1004.2.4 Outdoor enclosures shall include any provisions necessary to maintain the internal equipment at the manufacturer’s specified temperature and humidity.

1004.2.5 Outdoor enclosures shall be designed to prevent entry of moisture during a driving rainstorm, to minimize entry of dust, and designed for use in a mobile environment subjected to dirt, water, oil, and cleaning solvents. Exposed enclosures shall be IP 66 or NEMA 4 rated.

1004.2.6 Unless otherwise approved by the Transit Agency Project Manager, all equipment shall be designed for installation in a standard nineteen (19) inch rack, and shall meet seismic requirements for Zone 3.

1005 DOCUMENTATION

1005.1 All testing and training documentation shall be reviewed and approved by Transit Agency prior to implementation. Testing documentation shall include performance based criteria as well as specific pass/fail criteria (standard). Training documentation shall be reflected in development of appropriate SOP documentation and echo steps and principles where possible.

1005.2 Contractor shall provide final release of SOP and all documentation to reflect the configuration and system finally accepted.

1005.3 Contractor shall maintain documentation as changes to the system are made. All updated documentation shall be provided to Transit Agency.

1005.4 As part of the design documentation, Contractor shall provide Interface Control Documents and/or Open Application Programming Interface (API) documentation for integration points with Transit Agency as well as detailed information on views to the data sets and database for reporting purposes.

1005.5 Contractor shall provide detailed and most recent version of full documentation for importing static schedule and map data, as well as map update processes and procedures for Transit Agency review.

1006 TRAINING

1006.1 Contractor shall provide detailed and most recent version of full training documentation for Transit Agency review. Upon content approval, Contractor shall provide twelve (12) bound hardcopies and two (2) electronic copies. Contractor shall provide on‐site training as requested by Transit Agency.

2000

ON‐BOARD SYSTEM REQUIREMENTS

2001 OVERVIEW



28

2001.1.1 Contractor shall be responsible for providing all necessary hardware for Transit Agency’s bus, paratransit, and Light‐Rail fleets as specified in the following table:

Transit Agency Equipment

COP Transit Partners Valley Metro Rail

Fleet Fixed Para Para Fixed Rail

Vehicle Logic Unit

503 126 0 327 50

Color Touch Mobile Data Terminal

503 126 0 327 50

Telematics Solution

503 126 0 327 0

Automated Stop Annunciator

503 126 0 0 0

Mobile Gateway Router

503 126 0 327 50

Antenna 503 126 0 327 50

Radio 503 126 0 327 50

GPS unit 503 126 0 327 50

Transit Agency anticipates that approximately 100 vehicles will be replaced during or after the award of this contract. Contractor shall coordinate and make appropriate accommodation with Transit Agency on identifying/reallocation target vehicle allocated for new onboard system upgrades as needed.

2001.1.2 The System shall integrate with the following other onboard Systems: 1. MGR 2. Overhead destination sign [bus only] 3. Exterior destination sign [bus only] 4. Farebox [bus only] 5. Emergency Alarm (EA) 6. Onboard Apollo Surveillance System 7. APC system 8. Mobile Radio 9. ASA 10. PID 11. Drivetrain (via J1708/J1939) [bus and paratransit] 12. Transit Signal Priority [bus only]



29

2002 GENERAL ON‐BOARD REQUIREMENTS

2002.1.1 The on‐board equipment shall be designed to provide a usable life of no less than 16 years.

2002.1.2 Onboard equipment shall use (as applicable) microprocessor technology that is current and available in the market.

2002.1.3 It is Transit Agency's desire that on‐board equipment adopt, to the extent feasible, Transit Agency's information technology standards with respect to chips, operating systems, and network interfaces. At a minimum, unless otherwise approved, all microprocessor‐based devices shall be Internet Protocol (IP) addressable, and shall utilize Ethernet or USB communications wherever possible. Discrete sensors and low‐level processing devices may utilize other communications.

2002.1.4 Unless otherwise specified, all on‐board equipment shall have a minimum 40,000 hours MTBF.

2002.1.5 Unless otherwise approved, internal (to the on‐board equipment) batteries shall not be used to maintain parameter information in on‐board equipment when it is in its powered down state. Internal batteries may be used for certain, very limited functions such as maintaining the operation of a real‐time clock when the equipment is powered down, provided that power is consumed from the batteries only when the equipment is powered down, and that such batteries have a minimum life of five (5) years when the equipment is stored in inventory, and ten plus (10+) years of life when the equipment is in operation. The system shall check the battery state and create a warning message if the battery has to be replaced. Battery status indicator lights shall be easily visible from a mounted position. Battery replacement shall not require complex tools or specialized personal.

2002.1.6 Onboard equipment shall be capable of being disassembled and/or fit through a vehicle door and installed in the radio cabinet (average fleet cabinet size is H 44” by W 22 ½” L 20”) located behind the driver seat.

2002.1.7 Onboard equipment, including all exterior connectors and exposed ports, shall be rated for Ingress Protection 54 for interior equipment, IP 65 for exterior equipment and designed for use in a mobile environment subjected to dirt, water, oil, and cleaning solvents.

2002.1.8 Contractor shall include reasonable provisions to protect all equipment and components from common vandalism, unauthorized access and physical abuse as may be expected on transit vehicles and at stops.

2002.1.9 Equipment of the same type must be identical in mounting characteristics across each vehicle type and model.

2002.1.10 Equipment of the same type must be identical in mounting characteristics and inter‐unit cabling across the entire fleet, so that a replacement piece of equipment is installable without modification in any vehicle in which it might be used. This requirement does not apply to mounting brackets that may be unique to each vehicle type and configuration.

2002.1.11 Any retrofit or post‐delivery change to one item of one type of equipment shall be reviewed with the Transit Agency Project Manager and, upon Transit Agency approval, changes shall be made identically to all units procured (except modifications that are clearly understood by Contractor and Transit Agency to be experimental). Unique mounting brackets shall be interchangeable between vehicles of the same vehicle type.

2002.1.12 All on‐board equipment shall be "hot swappable" and shall not require manual configuration on the vehicle in order to be fully operational.

2002.1.13 The installation, configuration, and initialization method for all equipment must permit simple replacement (i.e. remove and replace) within ten (10) minutes in the event of a device failure.



30

2002.1.14 In the event that any existing vehicle wiring, switches or contact points are used, Contractor shall be responsible for testing and certifying that the wiring, switches or contact points are in an acceptable state and suitable for reuse. In the event that such wiring, switches or contact points are not suitable for reuse, Contractor shall immediately upon discovery, notify Transit Agency that replacement is required.

2002.1.15 On‐board Equipment shall operate at any inclination/ orientation, with the exception of APC sensors or other such devices that require a specific orientation for operation.

2002.1.16 On‐board equipment shall meet the following environmental specifications: 1. Operating Temperatures between 14 Degrees Fahrenheit (°F) and +120°F during normal operations, with the ability to operate in temperatures of up to 150°F for at least thirty (30) minutes. 2. Storage Temperatures between – 4°F and +175°F. 3. Humidity: 98% / 151° profile per SAE 1455 or approved equivalent standard. 4. Shock: 18g of 2 milliseconds. 5. Operating Vibration: 3‐axis 10‐500 Hz per SAE 1455 or approved equivalent standard. 6. Endurance Vibration: 3‐axis 28‐800 Hz per SAE 1455 or approved equivalent standard.

2002.1.17 On‐board equipment shall meet or exceed the following electrical requirements: 1. Be designed for operation at a nominal voltage of +12 to +24 VDC, with an operating range of 9 to 36 VDC. 2. Be able to withstand sustained voltage levels of up to 36 VDC for up to 10 minutes. 3. Shall not suffer corruption of data when the power dips below 9 VDC. 4. Shall not be damaged by very high (10 times nominal voltage) short duration (up to 10 milliseconds) peak voltage.

2002.1.18 Contractor shall design a system architecture which illustrates existing equipment, new equipment, existing system interfaces and new system interfaces. Contractor shall develop detailed system architecture drawings.

2002.1.19 Contractor shall provide a description of all on‐board memory (i.e. VLU and MDT, and MGR), to include:1. Memory classification (e.g. PCMCIA Flash, memory stick sRAM, etc.) and storage capacity 2. Memory usage, by classification, including but not limited to: O/S, firmware, configuration data, map data, schedule data, ASA sound files, logged operational data, and spare growth.

2002.1.20 Contractor shall provide ASA sound files, including but not limited to: type (e.g. MP3, WAV, etc.), and frequency and bit depth. The sound files shall provide sufficient clarity that the content is understandable throughout the bus interior area in revenue service operation with a full load of passengers.

2002.1.21 The design of all fonts, key assignments, menu structures, colors, and screen layouts shall be determined as part of Preliminary System Design and shall be based on input and requirements provided by Transit Agency as part of the design process. Future changes to these structures and assignments shall be configurable by Transit Agency at no additional cost to the Transit Agency.

2002.1.22 All Operator configurable settings for on‐board equipment shall restore to Transit Agency’s default settings upon shutdown/start up.

2003 ON‐BOARD EQUIPMENT ELECTRICAL AND ENVIRONMENTAL REQUIREMENTS

2003.1.1 All mobile devices shall be fused or contain supplemental (to the vehicle circuit breakers) circuit breakers. Fuses or circuit breakers shall clearly indicate when they have been tripped. Fuses or circuit breakers shall be used both at the source and on the equipment.

2003.1.2 All mobile devices shall be fused or contain supplemental circuit breakers.



31

2003.1.3 All on‐board equipment shall be designed for installation and operation in transit vehicle or Rail vehicle environment as specified by Transit Agency.

2003.1.4 Contractor shall provide power inverter or conditioning equipment to fulfill the requirements.

2003.1.5 Protection shall be provided against RFI and EMI emission sources, as well as internal conductive or inductive emissions.

2003.1.6 Protection shall be provided against RFI and EMI emission sources, as well as internal conductive or inductive emissions. Operation of equipment shall not be affected by the electromagnetic fields generated by infrastructure, by overhead catenaries at distances as close as eighteen (18) feet, or by local power distribution lines at distances as close as fifty (50) feet.

2003.1.7 All equipment provided shall be designed to be unaffected by RFI, EMI, power surges, dips and electrical noise typically found in transit buses and especially in the Transit Agency mall shuttle electric hybrid vehicles. The mall buses, powered by a high voltage hybrid electric system with a positive grounding system, can generate substantial EMI and noise. Proposers shall properly design and furnish a system that can work reliably under the environment.

2003.1.8 The provided mobile hardware shall comply with Transit Agency’s required environmental certifications. The specific tests to be performed will be established and mutually agreed upon as part of the System Design process, and approved by Transit Agency.

2003.1.9 If Contractor’s equipment has been tested to different specifications than those defined above, Contractor shall identify the environmental testing requirements used and results that were obtained. Such alternatives are subject to approval by Transit Agency.

2003.1.10 In the event that specific type of on‐board equipment cannot meet the specified electrical requirements, Contractor shall include power inverter or conditioning equipment that will be necessary to fulfill the requirements. Costs for such equipment shall be included in the price proposal.

2003.1.11 On‐board equipment shall include hardware circuitry and software functionality to automatically reboot or restart an on‐board device in the event of a software or hardware freeze, crash or process failure. As part of the Design Documentation, Contractor shall specifically describe how on‐board devices recover in the event of a power drop or power interruption during the device boot‐up process, and while the device is in operation.

2003.1.12 The PCU shall be at a minimum an IMark DC2412‐20, IMark stock number 601420 or approved equal. If the current draw of the electronics is calculated to be greater than 20 Amps, Contractor shall propose a similar PCU with sufficient capacity.

2003.1.13 The vehicle equipment layout shall include a PCU DC to DC converter.

2003.1.14 To prevent draining of the bus batteries during shutdowns over long weekends the current draw of the bus‐mounted CAD/AVL equipment and radios with the master switch in the off position shall not prevent a vehicle ignition after sitting over a 96 hour period.

2003.1.15 As part of the Design Documentation, Contractor shall indicate full operational and quiescent operating voltage and current drain for each on‐board component proposed.

2003.1.16 Transit Agency shall not be required to provide power conditioners and filters for Contractor provided on‐board equipment.

2003.1.17 On‐board devices shall meet 47 CFR Part 15 of FCC rules and regulations related to generation of and susceptibility to RFI.



32

2003.1.18 Operation of on‐board equipment shall not affect or be affected by vehicle components, such as engine ignition, or other on‐board equipment including vehicle power supplies, radios, automatic vehicle identification systems, fare collection systems, on‐board video surveillance and on‐board data collection and processing equipment.

2003.1.19 On‐board devices, associated cabling, and antennas shall be designed, installed, and placed such that any device whether or not it is designed to transmit RF, shall not interfere with, or degrade the performance of any other device or with different components within the same device.

2003.1.20 The system shall be equipped with protective and filtering devices to protect the system and its memory from electrical fluctuation typically found in a transit bus vehicles including but not limited to over voltage, under voltage, transient, power surge/dip during engine or other bus equipment startup, alternator and other equipment noises, etc.

2003.1.21 Contractor, at its sole expense, shall be responsible for conducting any RFI and EMI tests necessary to demonstrate compliance with these requirements. Alternatively, Contractor may request a waiver of certain tests by providing certificates of compliance for identical equipment tested and certified as part of another project. All waivers shall be granted at Transit Agency’s sole discretion.

2003.1.22 Unless otherwise approved, all devices, cables and connectors shall be shielded and grounded.

2003.1.23 Wire dress shall allow sufficient slack on either end of a cable for three additional “re‐terminations” on either end (approximately six (6) to eight (8) inches on each end depending on connector types) without excess tension. Extra cable shall be included for service loop.

2003.1.24 Wire splices shall not be used.

2003.1.25 Wire and cable ties shall not be so tight as to cause indentation and damage to the insulation.

2003.1.26 Adhesive mounted bases shall not be used to support wire ties or cable supports.

2003.1.27 All conductors within each enclosure shall be installed away from metal edges, bolt heads, and other sharp or interfering points.

2003.1.28 All conductors providing connections between components shall be provided with strain‐relief, and be clear of moving objects that could damage either the conductor or the object.

2003.1.29 All terminations and cables shall be clearly indexed, labeled and schematically identifiable. Labels shall not peel off or abrade with normal cable installation, handling and use. Labels shall be at each end of the cable.

2003.1.30 All wire labels shall be non‐metallic and shall resist standard lubricants and cleaning solvents.

2003.1.31 When components must be connected to each other through individual wires, the wiring shall be incorporated into a wiring “harness,” where each branch of each circuit can be separated from others for troubleshooting. Wiring harnesses, in addition to individual wires, shall be insulated/protected (e.g., split loom) to protect wire insulation against vibration.

2004 VEHICLE LOGIC UNIT (VLU)

2004.1 VLU Hardware Requirements

2004.1.1 The VLU shall be designed for installation and operation in a transit bus, para transit, and railenvironment. 1. The VLU shall include provisions to protect against vibration, water ingress, vandalism, and corrosion2. The VLU shall not have any moving parts (other than possibly a cooling fan)



33

2004.1.2 Contractor shall be responsible for determining the final location of VLU installation on each different vehicle type and configuration, subject to approval from Transit Agency.

2004.1.3 The VLU shall be a physically separate device.

2004.1.4 The primary processor shall be current generation Intel, Motorola, other brand name, or equal designed to operate under a currently supported version of an embedded or mobile version of Microsoft Windows, QNX or Linux.

2004.1.5 The VLU shall include at minimum the following ports and interfaces:

1. Two (2) opto‐isolated SAE J1708: one for Transit devices, and one (1) for drivetrain;

2. Opto‐isolated SAE J1939 for drivetrain;

3. Ethernet;

4. Universal Serial Bus (USB);

5. RS‐232 and SAE J1708/J1939 for communication with the existing Luminator and destination signs 6. Other ports and interfaces as required for specific device‐to‐device communications.

2004.1.6 Transit Agency is concerned about the potential impact of quiescent power draw on vehicle power supplies, and requires that active power management logic and circuitry be supplied as part of, or with, the VLU in order to gracefully remove power to all on‐board devices when the vehicle master switch is turned to the "off" position. Should Contractor require that any components receive power when the vehicle master switch is in the "off" position, either temporarily or at all times, Contractor shall identify those components and the projected quiescent power draw.

2004.1.7 The VLU shall manage power to listed on‐board devices as follows:1. The VLU shall have a Transit Agency configurable parameter of zero (0) to 180 minutes that controls the power down of all on‐board components after the vehicle master switch is turned to “off”. 2. The VLU shall inform all managed devices to initiate a graceful power‐down at a Transit Agency configurable time zero (0) to 30 minutes before power‐down is activated. 3. Upon reaching the power‐down threshold, the VLU shall remove power from all connected devices, including the VLU. 4. Upon the vehicle master switch being turned to anything other than “off”, the vehicle shall apply or maintain power to all connected devices and reset the timer. 5. If the vehicle Operator has not logged off, the system shall automatically log off, prior to power down activation.

2004.1.8 The VLU shall store the accumulated data in a non‐volatile memory with sufficient capacity to hold 30 days of data assuming up to 20 revenue hours per day.



34

2004.1.9 The VLU must monitor and log, with the Automated Vehicle Location time and coordinates, the following existing discrete external circuits: 1. Front door and Rear door, open and close; 2. Kneel, and return from kneel (raise); 3. Lift or Ramp deploy, and return from deploy (stow); 4. Optional Bike rack sensor; 5. “Stop Requested” light, activation; 6. Headlight activation and deactivation; 7. Future “Yield to Bus” light, activation and deactivation; 8. Turn Signals, activation and deactivation; 9. Hazard Lights, activation and deactivation; 10. Master‐Run switch, change in status (Off, Day‐Run, Night‐Run, Park); 11. Ignition, activation and deactivation; 12. Emergency Alarm use; 13. Vehicle maintenance monitoring (e.g. oil pressure, check engine light, tire pressure, etc.); 14. Start motion; and 15. Not in motion.

2004.1.10 The VLU shall support functionality of the following data sets, and must have sufficient non‐volatile memory to simultaneously store the following:

1. Entire set of current schedule data (including special services);

2. Twenty (20) weeks of incremental schedule changes, for current schedule;

3. Entire set of future schedule data (i.e., next run‐board);

4. Entire set of current ASA announcements;

5. Fifty‐two (52) weeks of incremental ASA announcements, for current schedule;

6. Entire set of future ASA announcements;

7. Current configuration data;

8. Three (3) days of APC data records from the existing, and any future, IRIS APC analyzers;

9. Destination sign errors;

10. Future configuration data;

11. Current firmware;

12. Future firmware;

13. Any other data recording needs identified in this RFP; and

14. 100% memory spare storage for growth, summing above requirements.

2004.2 VLU Functional Requirements

2004.2.1 The VLU shall integrate seamlessly with a Mobile Gateway Router.

2004.2.2 The VLU shall process data received from the AVL and shall correlate it with Operator identification (ID), date, time (both 24 hour system clock and 36 hour service day clock), route, block, trip, and location.



35

2004.2.3 The VLU shall reconcile any discrepancies between the different sensors and position inputs of the AVL to provide the most accurate vehicle location information. Vehicle location information shall be correlated with routes and stops as provided in the configuration data.

2004.2.4 The VLU shall process and manage the transmission of data to/from the central system through the MGR as follows: 1. Routine data including: schedule adherence, vehicle location data, messaging and communications requests, and event information on an event or polling basis via the radio system. 2. Priority data including PRTT, priority messages, and alarms on an immediate basis via the radio system. 3. On‐board equipment configuration data updates, non‐critical logged or accumulated data, and other “batch” data via the WLAN.

2004.2.5 The VLU shall be responsible for initiating and verifying the successful completion of data transfers, and shall not delete data until a successful transfer has been completed and confirmed.

2004.2.6 The VLU shall include functionality to re‐transmit data in the event of an unsuccessful transmission.

2004.2.7 In the event of an uncompleted file transfer, the VLU shall reinitiate the file transfer at the next opportunity, from the point where the previous file transfer ended such that data which had previously been transferred does not need to be retransmitted.

2004.2.8 The VLU through the MGR shall manage the downloading of new configuration data that may include schedule updates, route/stop updates, Operator ID updates, application updates, etc. as follows: 1. The VLU shall maintain both the current configuration data as well as one set of future configuration data that will automatically become the current configuration data once the defined activation date has arrived. 2. The VLU shall periodically check for configuration updates whenever it is within WLAN coverage. 3. If a configuration data update is available, the VLU shall manage the download process and update other on‐board equipment (the VLU shall provide a message on the MDT that a download and update is occurring so that the Operator is aware). The VLU shall automatically install updated firmware or configuration data it has received into all appropriate devices connected to the VLU. 4. To minimize potential impacts on pull‐out, the VLU shall include functionality to download only the schedule and Operator ID information on startup. Functionality shall be provided to manage the download of voluminous data (such as an application update) so that it is only downloaded and installed on shutdown or during non‐operating hours. 5. If the VLU is unable to complete download of configuration data, via the MGR and WLAN, it shall continue using the previous configuration data.

2004.2.9 The VLU shall include functionality and external interfaces to provide GPS location, time information, and/or trigger messages to other on‐vehicle systems.

2004.2.10 The VLU shall run diagnostics and report any problems with on‐board components (including the VLU itself, MDT, Radio, MGR connectivity, and AVL).

2004.2.11 The VLU shall automatically recognize any system process failure or lock‐up, log the problem and attempt a restart. If restart of the process fails, notification shall be sent to the Operator via the MDT and logged in the VLU for download at the end of the day.

2004.2.12 The VLU shall support remote diagnostics that allow central system access to check operations and functionality of the VLU, including the ability to reset the VLU and operate restricted functions to maintenance staff (e.g. resetting parameters such as volumes, MDT screen settings).



36

2004.2.13 In addition to providing routine position updates, the VLU shall record date, time and AVL position when the following events occur: 1. Arrival into and departure from areas of Transit Agency configurable dimensions that define the stops, timepoints, and pull‐out/pull‐in locations (for these events the current schedule adherence shall also be recorded). 2. Every activation and deactivation of each monitored circuit, including: Door open/close, Kneel/Raise, Lift/Ramp deploy/stow, Merge‐Warning Light, Stop‐Requested light, Turn Signals, motion sensors on‐board. 3. First stop or timepoint of the first route. 4. Every toggling of operational conditions, including: Operator key‐press on MDT, off‐route and return‐to‐route, early/late and return‐to‐on‐time, Operator over‐ride of destination sign.

2004.2.14 Upon entering the defined zone for each stop, the VLU shall log the maximum speed as detected by the GPS receiver and the accumulated distance as detected from the vehicle odometer, since previous stop record.

2004.2.15 In addition to monitoring and logging the discrete circuits specified in these requirements, the VLU shall log, with AVL time and location, the following operational conditions: 1. Vehicle Off‐Route or On‐Route (by Transit Agency configurable thresholds); 2. Vehicle Early, Late or On‐Time (by Transit Agency configurable thresholds); 3. Vehicle "bunching" and gapping (by Transit Agency configurable thresholds); 4. Text Message status change (including full message text): Sent, Received, Read, Acknowledged, Updated, Deleted; and 5. Vehicle Idle (ignition on and stationary for more than ten (10) seconds, with all doors closed).

2004.2.16 The VLU shall monitor diagnostic information for the Transit J1708, and log the following statistics upon every change in logon status or ignition status: 1. By Module Identification (MID): Time of last good received packet, Total good received packets, Total good transmitted packets. 2. Total bad (collision/checksum) packets received. 3. Total bad (collision/checksum) packets transmitted.

2004.2.17 The VLU shall monitor diagnostic information for on‐board systems, and log the following statistics upon every change in logon status or ignition status: 1. Radio Statistics (Total: Polls, Transmits, Re‐Transmits, Receives, Errors, Fallback, etc.); 2. Navigation Quality (Time: Duration, Good GPS Navigation, Good Alternate Navigation, Poor Navigation, etc.); 3. All current VLU configuration data; 4. Odometer Statistics, since previous record (total traveled distance, current calibration factor); 5. WLAN Statistics, since previous record (VLU awake time, WLAN coverage time, data packets sent, data packets received, file transmissions/receptions attempted per file, file transmissions/receptions completed per file); 6. All received text messages that are displayed to an Operator; and 7. All instances of lost voice and data radio coverage exceeding 15 seconds when back in communications for more than ten (10) seconds.



37

2004.2.18 The VLU will serve as a “Black Box”, storing the following data in a five (5) minute circular buffer with a minimum two (2) second and maximum one second resolution: time, AVL location, and speed as detected by the GPS receiver data. The entire five (5) minute buffer is to be logged, plus a subsequent two (2) minutes, when any of the following conditions are met: 1. Rapid acceleration or deceleration, as determined by the VLU based on GPS receiver input or by a G‐force sensor. 2. Any Operator‐generated message is sent to dispatch that requires a dispatch response, specifically: Request to Talk (RTT), Priority Request to Talk (PRTT), any “Emergency” or “Mechanical” message.

2004.2.19 The VLU schedule data shall include geographic areas of Transit Agency configurable dimensions (“trigger boxes”), which may or may not be associated with other schedule points (Stops, Time Points, Trip Start/End), which will initiate special VLU functions.

1. Examples include: Change external route/destination sign; Initiate TSP status change (enable/disable/activate/deactivate); Initiate ASA announcements and/or “clears”; Inform VLU of locations where GPS is known to be degraded.

2. The system shall enable Transit Agency to maintain these trigger boxes within the scheduling database, independently without need for any software changes.

3. The system shall support the creation, deletion, and relocation of trigger boxes and the designation or adjustment of the VLU action upon entering or exiting the trigger box.

2004.2.20 When a vehicle is moving while not following a scheduled path (e.g. off‐Route, or no schedule), the VLU must log AVL time, position, and heading at least every 30 seconds, and whenever the current vehicle heading changes by more than ten (10) degrees from the previously logged heading.

2004.2.21 The VLU shall monitor certain drivetrain data elements when drivetrain J1708 and/or J1939 is available on a vehicle.

2004.2.22 When drivetrain J1708 and/or J1939 is available on a vehicle, the VLU shall monitor certain drivetrain data elements, at a minimum two (2) second and maximum one (1) second resolution, and perform the following additional functions: 1. Enhanced VLU “Black Box” buffer to include the following available drivetrain data: i. Speed, Acceleration, Braking, Transmission Torque, Transmission Gear, Anti‐lock Braking System (ABS) in use, Traction Control System (TCS) in use, Air Pressure, idle time; and ii. Transit Agency will provide a list of drivetrain parameters to be monitored. This list will be part of the VLU configuration data, and easily modified by the Transit Agency. 2. Parameter Threshold Monitoring: The Transit Agency will provide a list of drivetrain parameters to be monitored, with minimum and maximum thresholds to be logged. This list will be part of the VLU configuration data, and easily modified by Transit Agency. The VLU shall initially log whenever a parameter threshold is exceeded. Subsequent logging will occur whenever a parameter changes by three (3) or more increments of the monitored resolution, until after the parameter is within the acceptable minimum to maximum range. 3. Error Reporting: VLU will monitor certain drivetrain data elements, and report this data to Dispatch when any “Mechanical” message is generated by the Operator, or whenever the vehicle automatically “de‐rates”. The monitored data will include: i. Every error‐code received in the last ten (10) minutes; ii. Current: Engine Temperature, Oil Temperature, Oil Pressure, Transmission Temperature, Transmission Pressure, Air Pressure; and iii. The Transit Agency will provide a list of drivetrain parameters to be monitored. This list will be part of the VLU configuration data, and easily modified by the Transit Agency.



38

2004.2.23 The VLU, in conjunction with the AVL, shall determine schedule adherence in real‐time on the vehicle, without the need for central computation and communications.

2004.2.24 VLU shall log transmission of every operator‐generated message to dispatch.

2004.2.25 VLU shall log receipt of every incoming text message, with the entire message text. VLU shall also log every change to the status (Operator Read, Operator Delete, Operator Acknowledge, Automatic Update/Replace, Automatic Delete) of any received text message.

2004.2.26 VLU shall transmit to CAD whenever a vehicle is determined to be operating on one of the predefined alternate route segments stored in the VLU.

2004.2.27 The VLU shall be capable of preventing power loss during a scheduled layover.

2004.2.28 The VLU farebox interface shall support a single point logon. The single point logon shall logon the farebox or override the current logon on the farebox.

2004.2.29 The VLU shall update the farebox data when there is a change to the run, route, trip, Operator, or fareset.

2004.2.30 Upon request from the farebox, the VLU shall send the current location.

2004.2.31 VLU shall be able to receive farebox alarms generated by the farebox.

2004.2.32 VLU shall support a new feature to estimate the causes of delays beyond a Transit Agency configurable time threshold that includes:

1. Vehicle speed versus average conditions in normal local service operations,

2. Duration of vehicle door open/closed,

3. APC activity and rough on‐board loads, and

4. Distance traveled over period configurable period of time.

2004.2.33 VLU shall calculate based on an automated algorithm whether delays are likely generated by: 1. Traffic delays, 2. Heavy boardings, and 3. Late trip start/departure.

2004.2.34 VLU shall display estimated causes to the Operator on the MDT, and log causes and inputs from the Operator through the MDT. Data shall be downloaded to the central system with the performance queue indications.

2004.2.35 Contractor shall collect actual real world data during pilot fleet testing as the basis for refinement of the algorithm. The automated selection of causes for delays at time points shall be accurate to 80% or better.

2004.2.36 VLU shall be directly integrated with the new mobile voice/data radio per the communications requirements with the data mode of the radio used for fallback operations.

2004.2.37 VLU shall determine if data communications services from the MGR have been lost per the communications requirements and initiate fallback data communications through the mobile radio.

2004.2.38 VLU shall determine if data communications services from the MGR have been restored per the communications requirements and re‐establish data communications through the MGR.

2004.2.39 The new factory VLU software build should have a way to test interoperability communications with all peripherals components connected to the VLU at the factory.



39

2004.3 VLU Performance Requirements

2004.3.1 The VLU shall be fully operational within 90 seconds of power restoration for warm starts, and 150 seconds for cold starts under typical ambient conditions.

2004.3.2 Logged data shall be stored in non‐volatile memory, and shall not become corrupted due to any power condition, including: spike, drop, or loss.

2004.3.3 The system shall be capable of syncing the on‐board DVR system with the VLU time.

2004.3.4 Interruption of a configuration data download/transfer shall not cause a failure of the on‐board equipment or prevent such equipment from being fully functional.

2005 AUTOMATED VEHICLE LOCATION (AVL) ‐ Implemented as part of VLU

2005.1 AVL Hardware Requirements

2005.1.1 All vehicles shall be equipped with an AVL that includes, but is not limited to, the following hardware elements: 1. All equipment shall be appropriately labeled; 2. A secondary position system consisting of an odometer interface or other dead‐reckoning device; 3. A GPS receiver, installed in the VLU as a replaceable/upgradeable card; 4. An exterior mounted, watertight integrated GPS and WLAN antenna; 5. All cables, wiring, connectors and labels; 6. All mounting brackets, mounting hardware, sealant, and associated installation materials; and 7. Antenna ground planes for all vehicles where the vehicle chassis cannot be used as a ground plane.

2005.1.2 The GPS receiver shall be a minimum 16 channel device, and shall include Wide Area Augmentation System protocols.

2005.1.3 Recognizing that GPS with Wide Area Augmentation System provides only limited accuracy and availability, the AVL shall include one (1) or more secondary positioning systems (revenue service vehicles only). An odometer interface only solution is not acceptable. The secondary positioning system shall be at a level of accuracy to support other on‐board systems, such as ASA, in situations when the GPS signal is not available.

2005.1.4 The AVL system shall provide an arrival and departure time each time the vehicle stops, and shall also provide arrival and departure times for each coded timepoint regardless of whether the vehicle has stopped or passed by the timepoint.

2005.1.5 Contractor shall provide evidence in the design documentation that the proposed GPS antenna is compatible with the GPS receiver.

2005.2 AVL Functional Requirements

2005.2.1 The AVL shall provide real‐time position (latitude/longitude), speed, time and heading data to the VLU.

2005.2.2 The AVL, using GPS time, shall provide the master time sync to all on‐board devices supplied and/or integrated under the contract. When the AVL is operational and GPS time is being received, all on‐board devices shall be synchronized on at least an hourly basis to within +/‐ one (1) second between themselves and with the central CAD system. In case there are periods when GPS time is not being received, a real‐time clock shall be provided (as part of the VLU) that shall ensure that on‐board devices can at least be time synchronized with the VLU on an hourly basis.



40

2005.2.3 The AVL shall be designed for operation in downtown urban, suburban, and rural areas, including the ability to continue logical vehicle position tracking when a GPS signal is not available or is degraded. This could include, but is not limited to, environments such as mountainous areas, office tower "Urban Canyons", tunnels, multimodal transit centers, garages and transit yards.

2005.2.4 Location data shall be sufficiently precise to accurately and reliably identify the location of each Transit Agency vehicle on the street network.

2005.2.5 The AVL system shall utilize Wide Area Augmentation System as the primary sources of position calculation. A secondary position system shall be used to correct GPS position data.

2005.2.6 The AVL shall, at all times, provide current position information to the VLU, for the purpose of reporting vehicle position in real‐time and for recording events.

2005.2.7 The AVL shall utilize calibrated odometer pulses and gyrocompass inputs for secondary positioning purposes.

2005.2.8 The AVL/VLU shall automatically adjust and calibrate the odometer inputs independently for each vehicle to account for factors such as: minor variations or errors in the odometer signal, changes in tire pressures and wear, replacement of tires, and other vehicle specific factors which impact the odometer signal over time.

2005.2.9 Following installation and calibration of the on‐board systems, the odometer shall be demonstrated to have less than a 2% margin of error through use of a test run.

2005.2.10 Calibration of the vehicle odometers at the time of equipment installation shall be the responsibility of Contractor.

2005.3 AVL Performance Requirements

2005.3.1 The AVL shall be accurate to within 10 feet of actual location at least 95% of the time.

2005.3.2 AVL shall provide the current updated vehicle position to the VLU, at least every second.

2005.3.3 Vehicle location computation lag time shall not exceed two (2) seconds in the vehicle (lag time is defined as the time it takes to compute position information, correct it, and update the on‐board systems).

2005.3.4 To enable verification of AVL accuracy, the AVL shall provide logging capability to record every positional input (raw GPS, raw secondary input(s)) at least every two (2) seconds in addition to all calculated positions (raw GPS position, raw secondary position(s), and estimated position).

2006 MOBILE DATA TERMINAL (MDT)

2006.1 MDT Hardware Requirements

2006.1.1 The MDT shall be a rugged computing device designed for operation in a transit environment.

2006.1.2 The MDT shall seamlessly integrate with the new MGR through an Ethernet connection.

2006.1.3 All storage shall be solid‐state. No disks or hard drives shall be permitted, though removable memory cards will be permitted.

2006.1.4 The MDT shall be equipped with a color, liquid crystal display touch‐screen that meets the following requirements: 1. Ability to be used by Operators wearing gloves. 2. Ability to be readable by Operators wearing polarized lenses. 3. Must be readable in direct sunlight and must offer a low‐glare setting for nighttime operation.



41

2006.1.5 Screen size shall be a minimum of 6.5 inches as measured diagonally.

2006.1.6 The MDT touch screen shall have a video graphics array (VGA) of 640 x 480 pixels or higher resolution. Contractor may propose a lower resolution screen with Transit Agency approval.

2006.1.7 The MDT touch screen shall have a service life of sixteen (16) years in normal transit use that includes frequent activation of the same area of the screen (e.g. a request to talk icon).

2006.1.8 The MDT display shall include functionality to display different font sizes, icons, colors and styles on the screen.

2006.1.9 The MDT display shall include functionality to display both text and icon‐based messages and key labels.

2006.1.10 The MDT shall contain a speaker and tone generator to be used to provide audio alerts. The MDT shall include a volume control for these functions that is accessible to the Operator.

2006.1.11 The MDT shall be the minimum size reasonable within these requirements and human factors design constraints, as space within the Operator compartment of the vehicle is limited.

2006.1.12 The system shall provide a covert microphone, which can be mounted separately from the MDT. The mounting location, orientation and sensitivity for the covert microphone shall be approved by Transit Agency, with the covert microphone able to allow a dispatcher listening to the covert audio to be able to understand speech at a normal spoken level from the Operator compartment and its immediate vicinity.

2006.1.13 The system shall provide capability to support separate mounting for covert microphone from the MDT.

2006.1.14 The MDT shall support fixed route and paratransit service needs as an update to the current deployment.

2006.2 MDT Functional Requirements

2006.2.1 An MDT shall be installed in each designated fleet vehicle, and shall act as the interface between the Operator and all on‐board devices connected to the VLU or MGR.

2006.2.2 At a minimum, the MDT shall provide the following functions: 1. Operator logon and logoff; 2. Operator validation for correct vehicle, block, etc.; 3. Voice radio control; 4. Two‐way text messaging between the Operator and dispatch; 5. Notifications of route and schedule adherence and re‐routes; 6. Operator monitoring for connected/integrated on‐board devices; 7. The ability to operate and control the internal and external Public Address (PA) systems, provided that the PA amplifier has the necessary control inputs; 8. Emergency alarm indications for both alarm activation, covert microphone on, and alarm received; 9. Displays of paratransit manifest and selection of drop‐offs & pick‐ups and Operator paddle information;

10. Detour information; and

11. Provide visual MAP of route.

2006.2.3 New messages shall beep once and light up. New messages will remain lit until cleared by Operator.



42

2006.2.4 The MDT displays for fixed route shall be mocked up by Contractor and reviewed by the Transit Agencyin at least two separate meetings. Final displays shall be implemented for testing purposes, with one round of revisions following the first stage of operational testing.

2006.2.5 The MDT displays for paratransit operations will include all data and functions from the current system taking advantage of the improved touch display functionality.

2006.2.6 The MDT displays for paratransit shall be mocked up by Contractor and reviewed by the Transit Agencyin at least two separate meetings. Final displays shall be implemented for testing purposes, with one round of revisions following the first stage of operational testing.

2006.2.7 The MDT shall be designed for simple and intuitive use by Operators from varied educational backgrounds. The MDT shall be configured such that a typical vehicle Operator can be trained to use it within one hour. MDT layout design will be performed with Transit Agency input throughout the process.

2006.2.8 The MDT shall display at a minimum, current system time and schedule adherence status (early/late clock, or off route) as part of its normal in‐service display. 1. “Voice Mode” for a normal call with dispatch; 2. “Systems OK” if the vehicle is connected with the fixed end; 3. “Fallback” if the data connection is lost and vehicle is in open 2‐way radio mode; 4. “Message Received” when fixed end receives and acknowledges an Operator generated call to dispatch; and 5. "Connection" to yard Wi‐Fi network.

2006.2.9 The MDT shall require a valid logon to access Operator and/or system administrative functionality, for all revenue and non‐revenue users.

2006.2.10 A Transit Agency assigned Operator ID number shall be used for logon. It shall not be necessary to enter a separate password in addition to the Operator ID except for non‐operator functions (e.g. maintenance functions).

2006.2.11 The MDT shall support multiple subsets of functions based upon user’s role. For example:

1. Base type shall be a bus Operator, and allow only MDT operational functions;

2. A minimum of two (2) maintenance types, to access different MDT maintenance functions;

3. A supervisor type, to access different Supervisor functions; and

Passwords are required for non‐operator logons. Passwords must be easily changed via configuration download. Contractor shall provide a secure methodology for password creation including the ability to handle lost passwords and request frequent changes to passwords.

2006.2.12 The MDT shall automatically configure and initialize itself for operation, when the power is turned on, with the default screen being the home screen.

2006.2.13 The system shall allow any vehicle to re‐initiate scheduled service on disrupted blocks, from either: 1. The location of service disruption/ cancellation; 2. The current scheduled time and location; or 3. The current location of the replacement vehicle.

2006.2.14 The Operator shall always be allowed to select any pre‐scheduled block, including placeholder blocks, instead of the Operator’s pre‐scheduled block.



43

2006.2.15 Operator shall have the ability to select from a set of pre‐defined and Transit Agency approved screen themes that will set colors to assist those who may be color challenged or other special visual requirements. Contrast and brightness shall adjust automatically with varying light conditions.

2006.2.16 The MDT shall include default backlight, brightness, contrast audio and tone settings. Default settings shall be able to be modified by Operators within a set parameter.

2006.2.17 The interface, menu structure of the MDT, pre‐defined messages, MDT tones and default settings shall be programmable through configuration data.

2006.2.18 At a minimum, the following logon functions shall be provided: 1. The system shall require the Operator to logon. MDT shall notify the Operator of failure to logon or of improper or invalid logon (i.e., non‐existent block or another Operator and/or vehicle already logged onto that block, etc.) and prompt for re‐entry. 2. The MDT shall require the Operator to acknowledge and confirm the log on including the Operator ID and block ID. 3. The logon function shall associate the Operator ID with name and background information, with the vehicle and with the scheduled work. 4. The MDT shall notify the Operator, and require confirmation from the Operator if (s) he is selecting a block other than the one (s) he is assigned. 5. Based upon the Operator ID only, the MDT shall look‐up the assigned block from the pre‐scheduled Operator run information. If the Operator ID does not have a valid pre‐scheduled block, then the MDT shall request the block assignment from the CAD real‐time “Extra Board” or relief assignments table. This table shall automatically be updated on every vehicle, whenever the CAD table is updated, via the WLAN and/or cellular data communications. 6. Upon completion of MDT logon, the VLU shall communicate the logon associations (Vehicle/Operator/Block) to CAD for integrity checks. Any invalid or duplicate assignment thus found will prompt dispatch action to resolve the issue. 7. Based upon the logon block, CAD shall look‐up the assigned vehicle from the real‐time vehicle assignments table, and if the assigned vehicle is different from the logon vehicle: i. Notify dispatch. ii. Notify Operator. 8. MDT shall support future automated logon by swiping or using a proximity card. 9. The MDT shall initialize all on‐board devices integrated with the VLU via the MGR in a single action upon successful logon. 10. During logon the central system shall prevent the vehicle from operating on an invalid or outdated schedule, excluding fictitious schedules.

2006.2.19 Whenever the MDT, MGR or VLU resets due to power loss or reboot, the MDT shall automatically re‐logon to the last Operator/Block assignment, if that Operator/Block assignment is still valid for the same service day.

2006.2.20 Any manual MDT configuration changes from Operator may be selected by Operator to be stored in their configuration.

2006.2.21 MDT shall automatically initiate a logoff when a vehicle returns to any Transit Agency storage yard (garage), and the vehicle ignition is powered‐off. This logoff will include de‐associating with the voice radio system.

2006.2.22 The MDT display shall permit display of graphical and map‐based images indicating turn‐by‐turn directions to follow the current route if the status is on route, or the directions to follow to return to route.



44

2006.2.23 The system shall include the following voice radio Communications Interface (RTT, PRTT):1. The MDT shall allow Operators to request voice communications via the radio system with both an RTT and a PRTT button. 2. Operators shall receive text and auditory notification when they have been entered into the queue for PRTT or RTT. 3. When pressing RTT or PRTT, the MDT shall present a drop‐down list or screen of most common messages and control functions associated with voice radio control.

2006.2.24 The MDT shall support transmission of pre‐defined messages to dispatch that includes but is not limited to: 1. Logon/logoff/system test/maintenance, 2. Critical messages, 3. Vehicle status report (on time, early, late, on route, off route), 4. Out of service, 5. Call for a field supervisor, 6. Vehicle mechanical problem, and 7. A minimum of 40 other routine or “canned” messages from vehicle to dispatcher.

2006.2.25 Pre‐defined messages sets and the order the messages are presented shall be Transit Agency configurable according to Transit Agency standard operating practices.

2006.2.26 Messages shall have a minimum of five levels of priority based on the definitions below: 1. Emergency alarm – Priority 1 (highest) 2. Emergency messages such as requests for medical assistance or notification of an incident – Priority 2 3. Critical messages that may include requests for service – Priority 3 4. Routine/non‐critical representing typical day‐to‐day operational messages that may be transmitted back and forth – Priority 4 5. Non‐critical messages that are automatically logged into the system for integration with Transit Agency’s maintenance database – Priority 5 (lowest).

2006.2.27 Message management functionality shall include: 1. A one‐time audible and on‐going visible indication for each unread message in the incoming message queue and how many messages are in that queue. The MDT shall also indicate when there are no more messages to be read. 2. Functionality to automatically move priority messages received from dispatch to the front of the queue, and provide visual and audible indications that a priority message has been received. 3. Functionality to skip a message in the queue, delete a message from the queue only after it has been displayed, or save a message in memory until a logoff has occurred. 4. Any message sent by or to an MDT shall be time stamped and note the Operator or dispatcher that sent it. Any message not confirmed as received, within two (2) data communication cycles, shall be re‐sent. Confirmation of receipt shall display to the Operator and be available to the dispatcher via a summary view. 5. The MDT shall support automatic cancel and update/replacement of messages in the MDT message queue. Actions to cancel or update messages would be initiated by the dispatcher. 6. Operators shall be notified when messages are cancelled, modified by dispatch or when messages expire. 7. MDTs shall make available through a summary view or display confirmation to dispatch when a message is received and when it was read. 8. All data messages sent by the Operator shall activate the data communications for transmission to dispatch. 9. Emergency alarms shall be transmitted immediately to dispatch as a high priority data



45

communication. If data radio does not have sufficient signal or receipt of alarm is not confirmed within 15 seconds, the alarm shall be retransmitted as a data message over the voice radio system. 10. The MDT shall be able to receive a minimum of 255 characters in a message consisting of ASCII coded characters in the range of decimal 32 to decimal 126. The MDT shall allow scrolling through the message at 64 characters or more per scroll action. The MDT shall be able to display multiple text sizes and multiple lines of text. 11. Messages displayed to the Operator shall be in a large font (approximately 18 point) that is readable by an Operator with 20/20 eyesight from a distance of three (3) feet. Summary lists, tables of data, etc. may be displayed at a smaller font. Operator personalization may allow an Operator to increase the font size up to 28 point. 12. Text shall appear on the MDT screen in a readable left to right format regardless of the number of consecutive characters used by a dispatcher without spaces.

2006.2.28 All MDT audio tones shall be designed by the Transit Agency.

2006.2.29 Except for emergency alarm messages, the MDT shall include a visual indicator on the screen, and programmable tone, confirming that a sent message has been received by the central dispatch system, regardless of whether the dispatcher has responded or not. Audio tones shall correlate to the priority of the message, and be configured to Transit Agency approved standards.

2006.2.30 For an emergency alarm message, the MDT shall provide Operator with a “discrete” visible indication that an alarm has been activated. “Discrete” is defined as an indication that would only be known to a trained Operator.

2006.2.31 The MDT shall include the following schedule adherence and re‐route functionality:

1. The MDT shall indicate to Operators if a vehicle is operating ahead of, or behind, schedule. This shall be in the form of an “Early/Late” clock in the following syntax: “+/‐ HH:MM”, where “+” is late and “‐” is early. The “Early/Late” clock shall be updated at least every ten (10) seconds.

2. When commanded from the central system, the MDT shall indicate to an Operator when they need to hold to address a headway maintenance issue.

3. The MDT shall indicate, both audibly and visibly, for Operator to proceed – e.g. “leave” layover– without need for communications to dispatch.

4. The MDT shall have ability to display graphical and map‐based images (both pre‐defined and ad hoc generated by dispatch) including routing instructions (left on x, right on y, etc.).

5. VLU shall automatically notify CAD whenever vehicle is operating on alternate route segment.



46

2006.2.32 The MDT display configuration and functions shall include:

1. The interface and menu structure of the MDT display shall be designed for flexible allocation of key information, message space and size.

2. The MDT display shall use a hierarchical multi‐page menu structure. The MDT shall include functionality to scroll through a page and switch between pages. The message menu structure on the MDTs shall be logical and easy to navigate. Operators shall be able to access all functions with three (3) selections or less.

3. Message selection, variable inputs, and interpretation of received messages shall be from menus and pop‐ups that may change based on context.

4. Reconfiguration of key size, location on the screen, menu allocation, label, etc. shall be possible through an update of configuration data, and shall not require an application level change.

5. In no event shall such controls allow the screen to be set such that the text is unreadable, or volume cannot be comfortably heard by an Operator. Default settings and range limits shall be set via configuration data and shall not be modifiable by the Operator.

6. The MDT shall automatically notify the Operator of departure status (i.e. countdown clock) for every layover and pullout.

7. The MDT shall notify the Operator of a late pullout with an escalating series of notifications beginning a set time (configurable by Transit Agency) past the scheduled pull‐out.

2006.2.33 The MDT shall allow for future changes to fonts, key assignments, menu structures, colors, and screen layouts. Changes to these structures and assignments shall be configurable by Transit Agency and the configuration must be easily uploaded to the MDT from the Central System.

2006.2.34 The MDT shall provide maintenance personnel with a set of maintenance and test screen(s), which can be accessed only with the appropriate log‐on. Functions and screens shall provide on‐board device diagnostic and troubleshooting information, and functionality to change default configuration values or limits for display brightness and contrast, and volume settings. MDT maintenance screens must update their information at least once every second and must include the following minimum functions: 1. Radio configuration, and statistics; 2. WLAN configuration, and statistics; 3. Odometer configuration, and statistics; 4. Status of discrete circuits (open or closed, high or low, etc.); 5. Status of J1708/J1939 (total sent, total received, last MID received); 6. Status of J1708/J1939, by MID (total sent, total received, last message time); 7. Status of Ethernet connectivity to MGR; 8. AVL location (Latitude/Longitude) and status; 9. Status and test screens for connected devices (APC, ASA, Destination Signs, onboard surveillance system, internal and external headsigns); and 10. Erase selected downloaded data, thus forcing new WLAN download.

2006.2.35 Once the VLU notifies the MDT to shutdown, the MDT shall provide 60 seconds advance visual and audio warning, to allow the Operator to cancel shutdown prior to the MDT automatic logoff and shut down.

2006.2.36 Operator logons shall be maintained during an Operator’s scheduled run under all conditions, including power interruptions.

2006.2.37 Override of the destination sign control shall be controllable through the MDT; all changes made shall be logged.



47

2006.2.38 The MDT shall provide a maintenance function with a real‐time interface to all attached discrete signals.

2006.2.39 The MDT shall be provided with a “quick reference card” summarizing basic operational processes and functions, to be included in the Operators’ book.

2006.2.40 The MDT screens shall be developed specific to Transit Agency needs through the following process: 1. Contractor develops draft screen mock‐ups for each and every MDT display screen fulfilling the requirements noted in the entirety of these system and communications requirements. 2. Contractor shall conduct an in‐person of the screens of an actual MDT unit with the Transit Agency. 3. Modified displays are developed based on Transit Agency comments and prepared for testing purposes. 4. Following operational testing, the displays are finalized based on testing results and any additional Transit Agency requested revisions. 5. Final displays are implemented for the entire fleet.

2006.2.41 The MDT screens shall be separate and unique for fixed route and paratransit needs, and paratransit MDT screens shall be developed specific to Transit Agency needs through the following process: 1. Contractor develops draft screen mock‐ups for each and every MDT display screen fulfilling the requirements noted in the entirety of these system and communications requirements. 2. Contract reviews in person the screens on an actual MDT unit with the Transit Agency. 3. Modified displays are developed based on Transit Agency comments and prepared for testing purposes. 4. Following operational testing, the displays are finalized based on testing results and any additional Transit Agency requested revisions. 5. Final displays are implemented for the entire fleet.

2006.2.42 The MDT shall support a simplified version of Operator indications of causes for fixed route service delays at time points, including: 1. Display of potential likely causes of delay for Operator selection when prompted or reaching a time point. 2. Highlighting of the automatically determined cause of delay (based on VLU calculations). 3. Request for confirmation of the cause of delay when the vehicle is stopped at a time point. 4. Removal of the causes of delay selections from the screen or graying out when the vehicle is within scheduled thresholds.

2006.2.43 The MDT shall provide the ability to activate a TSP emitter or device for testing purposes and shall provide diagnostic screens for ensuring TSP file versions and relevant TSP data and files are up to date and accurate.

2006.3 MDT Performance Requirements

2006.3.1 The MDT shall be fully operational within startup times equal to or less than those specified for the MGR and VLU.

2006.3.2 The MDT shall be fully operational within 30 seconds of power up or power restoration.

2006.3.3 The MDT and integrated systems shall be fully initialized and operational within 30 seconds after successful employee logon.

2006.3.4 Data shall not be corrupted due to short‐term power interruptions (e.g. vehicle startup or power‐down.), including complete loss of vehicle power.



48

2006.3.5 The MDT shall not “freeze up” in the event that power is applied in the incorrect order (ignition sense versus continuous power on the load side of the master switch), or due to short‐term power interruptions (e.g. vehicle startup or power‐down), including complete loss of vehicle power.

2007 MOBILE GATEWAY ROUTER (MGR)

2007.1 MGR Hardware Requirements

2007.1.1 Contractor shall supply a Mobile Gateway Router (MGR) with both wireless and wired Ethernet functionality. The MGR shall be a separate device from the VLU or MDT. The onboard gateway shall be InMotion/Sierra Wireless Part # oMG 2032, SKU# IMTOMG2032‐01.

2007.1.2 The gateway shall be equipped with a minimum of 1 GB of internal storage as data storage capacity.

2007.1.3 The MGR shall include a minimum of two (2) USB 2.0 connections.

2007.1.4 The MGR shall provide a minimum of eight (8) Ethernet ports.

2007.1.5 The wireless modem or communications device shall be easily replaceable to accommodate changes in technology and wireless standards. A PCMCIA device may be used.

2007.1.6 The MGR shall be connected to an external integrated GPS/WLAN antenna via appropriate cabling and connectors.

2007.1.7 Contractor shall provide an on‐board Ethernet network to interconnect CAD/AVL on‐board components, existing on‐board equipment, and future on‐board devices.

2007.1.8 The MGR shall support the following wireless services: 1. 3G and 4G wireless communications from common carriers through a compatible cellular modem to include, but not limited to LTE; 2. WLAN “Wi‐Fi” supporting 802.11 g, n, and AC standards; 3. Worldwide Interoperability for Microwave Access (WiMAX) supporting 802.16x standards; 4. Licensed 4.9 GHz spectrum. The use of 4.9GHz will not be implemented under this contract; however, the MGR shall support this functionality without additional software or hardware development and the functionality shall be tested as part of testing; and 5. Act as an access point capable of providing Wi‐Fi service that is secure and on a separate subnet firewalled from the on‐board LAN. On‐board Wi‐Fi service will not be implemented under this contract, however, the MGR shall support this functionality without additional software or hardware development and the functionality shall be tested as part of testing.

2007.1.9 The MGR shall be supplied with an internal 802.11g/n/ac compatible wireless card.

2007.1.10 Transit Agency will be responsible for any recurring cellular fees.

2007.2 MGR Functional Requirements

2007.2.1 The MGR shall be integrated with on‐board CAD/AVL components, other existing on‐board systems, and multiple 802.11x WLAN SSID networks to provide an integrated, multi‐path gateway for all on‐board systems.

2007.2.2 The MGR and WLAN shall support the Wi‐Fi Protected Access 2 (WPA2) security and communications protocols.

2007.2.3 The VLU must allow all data, downloaded via WLAN, to be stored until a future specified implementation date.



49

2007.2.4 Multi‐Network Roaming: The gateway shall automatically switch wide area traffic between available wireless networks according to administrator‐defined switching policies. Routing policies shall be based upon, at a minimum, network availability, network priority, time of day, vehicle location, and bandwidth capacity.

2007.2.5 The MGR shall be used to route traffic between devices using one‐to‐one Network Address Translation (NAT) between on‐board device addresses and outward‐facing addresses, and/or through the WLAN, to the appropriate on‐board device.

2007.2.6 The MGR shall support a reserved IP address subnet for all on‐board IP‐addressable devices on the vehicle.

2007.2.7 The NAT scheme shall have a unique Internet Protocol (IP) address to uniquely identify each vehicle in the system, and support routing of traffic to/from a specific vehicle, and to/from a specific device on that vehicle.

2007.2.8 All on‐board devices of the same type (e.g. all MDT’s) shall utilize a common IP address for that device type which that is identical across the fleet. IP addresses will be assigned by Transit Agency.

2007.2.9 The MGR shall support IPsec VPN services.

2007.2.10 The MGR shall provide Stateful Firewall Services capable of firewalling between all LAN and WLAN ports.

2007.2.11 The MGR shall be configurable to control which on‐board systems and applications can perform outbound communications utilizing a given WLAN connection based on the speed of the outbound connections (i.e. which systems and applications can communicate whenever communications are available, and which can communicate only when high‐speed communications are available).

2007.2.12 The MGR shall have the capability to assign different levels of priority to data from individual on‐board systems and applications for the ingress interfaces (LAN interfaces to MGR) and the egress interfaces (WLAN interfaces).

2007.2.13 The VLU shall allow WLAN batch data processing to be initiated whenever the vehicle is within WLAN coverage of an approved SSID and the scheduled departure from layover is more than five (5) minutes beyond current time.

2007.2.14 MGR shall be interfaced with the VLU to provide data communications and indicate when data communications have been lost. The VLU shall initiate fallback data communications through the mobile data radio per the communications requirements.

2007.2.15 MGR shall be interfaced with the VLU to provide data communications and indicate when data communications have been restored. The VLU shall re‐establish data communications through the MGR per the communications requirements.

2007.3 MGR Management Reporting Capabilities

2007.3.1 Management Data Collection: The communication gateway shall collect, retain and periodically transmit to a centralized management sever, a minimum of once per day, pertinent management information for the reporting period. Reported management information shall include: 1. Volume of transmitted data for each available wireless network type; 2. Volume of received data for each available wireless network type; 3. Availability of each wire area network link, referenced by vehicle location; 4. Visibility and signal strength of Wi‐Fi access points, referenced by vehicle location; 5. Vehicle supply voltage; and Available reports shall have associated SQL query code shown in report creation and editing.



50

2007.4 MGR Management Data Presentation

2007.4.1 General Display and Reporting Requirements: Management information reports and status displays on the centralized management server shall be accessible to either local or remote users via a browser‐based interface.

2007.4.2 Gateway Status Display: The following status information shall be presented on a single status monitoring screen for each logical group of gateway devices. Display layout and gateway groupings shall be definable by the system administrator:

1. Unit ID

2. Unit IP Address

3. Vehicle voltage level

4. Unit operating temperature

5. Elapsed time since last gateway heartbeat

6. Duration that unit has been accessible in current calendar day

7. Total received bytes for the current month

8. Total transmit bytes for the current month

9. Software version

2007.4.3 Status Exception Reporting: Reported status parameters shall be monitored by the system, with status exception events automatically detected according to administrator‐defined threshold values. Such exceptions shall be highlighted by color coding of status display element sand shall be reported to remote administrators via email.

2007.4.4 Management Information Reports: The system shall be capable of reporting trends in accessibility of each gateway and wide area network availability by location. It shall be possible to generate management information reports on an ad hoc basis or automatically at scheduled times. Report output shall be saved on the server and optionally distributed to an email list.

2007.5 ON‐BOARD Network and WLAN Integration

2007.5.1 The CAD system shall provide Transit Agency with the ability to do software/firmware upgrades over the WLAN.

2007.5.2 Contractor shall interface the VLU with the MGR to be provided as part of this contract, to access the on‐board network, including interfaces with other on‐board devices, the WLAN and cellular data communications capabilities to be made available to the VLU via the MGR.

2007.5.3 The interface between the VLU and the MGR shall be via a Transit Agency‐approved industrial‐grade switch equipped with eight standard RJ‐45 Ethernet ports, capable of 100MBps full duplex and suited for use in the on‐board environment as defined in these specifications. This eight‐port switch shall be supplied, installed and integrated by Contractor, and shall be compatible from an Ethernet networking perspective with the MGR, so that together these two devices form a cohesive combined on‐board networking infrastructure. Use of an Ethernet port on the eight‐port switch shall be indistinguishable from use of an Ethernet port on the MGR, from the perspective of the overall on‐board networking functionality being established.

2008 APPLICATION REQUIREMENTS VIA WLAN



51

2008.1.1 Maintenance functions within the MDT shall allow a trained and authorized mechanic to erase selected downloaded data, and force a high‐priority download from central that will be completed within ten (10) minutes.

2008.1.2 Any download of complete, non‐incremental, data to all vehicles must be completed within one (1) day. This assumes the vehicle WLAN is active for ten (10) minutes each morning before leaving the garage, and for one (1) hour each evening upon return to the garage.

2008.1.3 The WLAN shall be used to download configuration data and software updates, and upload diagnostics and on‐board system performance data.

2008.1.4 The VLU shall automatically initiate data transfer when the vehicle is in range of an Access Point, and require no Operator interaction.

2008.1.5 The System shall be able to manage incomplete transfers of data files between the vehicle and central system.

2008.1.6 The System shall seamlessly continue data transfers at any Access Point, regardless of which Access Point last handled the data transfer.

2008.1.7 The System shall include positive acknowledgement between central dispatch and the vehicle that adata transfer has been successfully completed. Data shall not be purged until such time as a successfully complete data transfer has been recorded, and the data has been properly handled.

2008.1.8 The System shall maintain a mechanism to assure that all required data has been successfully transferred over the WLAN, and report any discrepancies.

2008.1.9 The System shall provide a mechanism to send only “patches” of large files over WLAN and reconstitute the original file on the other end of the WLAN.

2008.1.10 The System shall provide a versioning mechanism for files to be immediately downloaded to a vehicle, but delay implementation of the file on the vehicle until some later date.

2009 EMERGENCY ALARM (EA)

2009.1 EA Hardware Requirements

2009.1.1 Emergency alarm switches and associated hardware, cabling and appurtenances shall be supplied for fixed route and paratransit revenue vehicles.

2009.1.2 Contractor shall determine the location for emergency alarm activation switches in all vehicle types and configurations based on input from the Transit Agency vehicle maintenance and operations staff, as well as contracted services providers. The switches shall be installed in the same location for all vehicles. Number of switches shall be determined during Design and Review.

2009.1.3 The emergency alarm activation switch shall be installed in a location easily accessible to the vehicleOperator, and positioned such that activation can be done without visibly alerting a customer on the vehicle or in the boarding area. For each vehicle type, the alarm switch location shall be approved by Transit Agency.

2009.1.4 In the event that data radio communications is not available, the emergency alarm shall be transmitted over selected communications solution.

2009.2 EA Functional Requirements

2009.2.1 The Operator shall be notified covertly in the event of emergency alarm activation, and within ten (10) seconds of dispatch acknowledgement. The indication shall be identifiable only by a trained Operator and shall be developed by Contractor with Transit Agency.



52

2009.2.2 Emergency alarm shall not require a user ID or password to communication with the Operator and will not limit open mic during an emergency status, when the Operator picks up the handset the open mic is cancelled.

2009.2.3 Emergency alarm shall not interfere with the ability to send text messages to the Operator.

2009.2.4 Activation of the PRTT and emergency alarm shall initiate continuous tracking of the vehicle with the highest priority being given to the vehicle for data communications. Once the emergency alarm has been activated, dispatchers shall be able to use the central software to command the VLU to send audio from the covert microphone to dispatch.

2009.2.5 The emergency alarm circuit shall be monitored continuously for continuity, and any faults shall be reported on the MDT and provided to dispatch.

2009.2.6 An automatic self‐diagnostic test shall be performed at startup for the emergency alarm switch to ensure proper operation, and shall not require Operator or Dispatch interaction.

2010 AUTOMATED STOP ANNUNCIATION (ASA)

2010.1 ASA General Functional Requirements

2010.1.1 ASA system shall use WLAN, managed by the VLU and central systems, to transfer all specified data to/from the ASA system.

2010.1.2 ASA system shall allow definition of all configuration and announcement data to include begin and end effective dates. 1. Vehicle equipment shall allow one (1) “Current” set of data to be active and allowed to be incrementally updated without requiring a complete replacement. 2. Vehicle equipment shall allow at least one (1) “Future” set of data to be pending and allowed to be incrementally updated without requiring a complete replacement.

2010.1.3 All ASA messages shall comply with requirements of the ADA and design criteria mutually agreed to by Transit Agency and Contractor.

2010.1.4 Contractor shall participate in public meetings with advocacy groups regarding ASA design, configuration, etc.

2010.1.5 System shall provide remote and location ASA diagnostic capability such as data download status, initiate and discontinue stop –based announcements remotely, by bus vehicle, map‐based selection tool, or via global settings.

2010.2 ASA ON‐BOARD Processing

2010.2.1 ASA shall be capable of generating the following messages: 1. Internal audible and/or visible location‐based announcements (next stop, customer service, transfers, etc.); 2. Internal time‐based (e.g. reoccurring scheduled message at a time interval) audible and/or visible customer service announcements; 3. Internal Operator initiated audible and/or visible customer service announcements; 4. External audible bus arrival announcements; and 5. The next stop aide button shall differentiate between normal and mobility‐aid boardings.

2010.2.2 A vehicle Operator shall not be required to configure the ASA or initialize it in order for it to operate, nor require any Operator input to make any automated announcement.

2010.2.3 VLU shall provide a function for the Operator to test the ASA system by playing in succession (external audible, internal audible, internal readerboard) the destination sign test message.



53

2010.2.4 ASA shall not require any manual intervention on a vehicle to update configuration or announcement data.

2010.2.5 Internal location‐based announcements shall be activated based upon one or more location specific triggers provided by the VLU. Triggers will be configurable by Transit Agency.

2010.2.6 The VLU shall provide triggers to selectively enable and disable the external announcements. External announcements shall be activated by a combination of messages available on the SAE J1708/J1587 Transit data bus. Content shall be based upon destination sign code, and frequency shall be based upon door open/close messages.

2010.2.7 The VLU shall translate abbreviations (e.g. destination sign codes) in a logical way.

2010.2.8 Automatic customer service announcements shall be activated from a VLU trigger initiated from the operational schedule, and/or by time‐of‐day schedule (e.g. play announcement every twenty [20] minutes), and shall meet the following requirements: 1. Messages shall not interfere with timely location‐based announcements. 2. Through configuration data, it shall be possible to set customer service messages to play on the on‐board audio only, on‐board visual displays only, or both devices.

2010.2.9 Communication between the VLU and ASA shall be designed to guarantee bi‐directional message/command delivery and response.

2010.2.10 Both audible and visible messages shall begin playing within one (1) second of being triggered.

2010.2.11 ASA will not make any announcements if the current 36 hour operational service date falls outside the range of available effective dates within the configuration/announcement data.

2010.2.12 ASA shall include automated power‐up and power‐down functionality, keyed to the vehicle ignition.1. The power‐down shall be Transit Agency configurable timed between zero (0) and 240 minutes, after loss of ignition sense. 2. Within five (5) minutes after regaining ignition sense, the on‐board ASA system must power‐up and be fully functional.

2010.2.13 On‐vehicle ASA shall have sufficient memory to store both a “Current” and “Future” set of announcement data (both visible and audible) for every Transit Agency stop, with at least a one‐ 100% spare storage capacity.

2010.3 ASA ON‐BOARD Audio Annunciation

2010.3.1 Contractor shall use the existing PA system and speakers to play audio messages, or may propose to replace the existing PA system. In any event, Contractor is responsible for the overall audio quality of the ASA system, so as to achieve audio that can be understood throughout the passenger compartment throughout the range of typical operating conditions.

2010.3.2 Manual operation of the PA by the Operator shall override any ASA audio announcement.

2010.3.3 New (or replaced) PA systems shall include background noise suppression.

2010.3.4 The system shall include an Automatic Gain Control (AGC) circuit to automatically and independently adjust internal and external volumes depending on their respective ambient noise level detected. Each audio announcement played using AGC shall be played at a consistent volume determined by sampling the AGC immediately prior to playing the announcement.



54

2010.3.5 The default minimum and maximum volumes for the internal and external announcements, and Operator microphone, shall be separately adjustable to standard levels that are verifiable by a maintenance technician. The default minimum and maximum volume for external announcements shall be able to be set to distinct levels during a Transit Agency configurable time of day period.

2010.3.6 The minimum and maximum volumes for the internal and external announcements shall be independently controllable through triggers from the VLU. The system shall include at least five (5) selectable volume level settings for audible announcements.

2010.3.7 ASA shall allow Dispatch to remotely disable the system when necessary.

2010.3.8 ASA shall accept triggers to separately configure the default audible volume for both internal and external announcements, prior to any gain determined by the AGC circuit.

2010.3.9 ASA shall accept triggers to separately configure the default audible volume for both internal and external announcements, while disabling the AGC circuit.

2010.3.10 Through configuration data, it shall be possible to set the external arrival announcements to play once, play twice, or repeat in a loop while the door is open. If on a repeating loop, the repeat interval shall be settable by Transit Agency through configuration data.

2010.3.11 The external arrival announcements shall be repeated automatically if the front door remains open for greater than a pre‐determined time. Such time shall be settable by Transit Agency through configuration data.

2010.3.12 ASA shall allow Operators to manually replay the last internal or external and canned message(s).

2010.3.13 ASA shall allow Operators to manually play the route and destination externally at any stop (even if external message is not programmed for that location).

2010.4 ASA ON‐BOARD Visual Annunciation (Light Emitting Diode [LED] Readerboard )

2010.4.1 Contractor shall provide visual announcement readerboards, also known as passenger information displays (PIDs). Contractor must test PIDs to ensure proper operation and functional requirements are met.

2010.4.2 ASA readerboards shall be designed for 26 character length, and shall accept standard keyboard characters.

2010.4.3 The visual announcement shall display the message “STOP REQUESTED,” for a time period configurable by Transit Agency, after the existing customer stop request signaling device is pressed and after any next stop announcement in progress has been completed. If a next stop announcement message is triggered during the “STOP REQUESTED” display, it shall be initiated immediately after that display has timed out. Contractor will receive trigger from the existing stop request system.



55

2010.4.4 ASA shall display a time on the readerboard in twelve‐ (12‐ ) hour “HH:MM” format. 1. ASA time shall be automatically updated from a known good source (GPS, Atomic Clock, etc.). ASA time shall always be accurate to within +/‐ five (5) seconds from VLU time. 2. If no other message is being displayed, time will always be displayed while the vehicle master run switch is not off (Day Run, Night Run, and Park). 3. Time will always be left‐justified. 4. If any readerboard message is short enough to display concurrently with time (with five [5] pixel columns separation), non‐time message will be right‐justified (never using the final column). 5. If readerboard message is too long to display concurrently with time, time will not be displayed and non‐time message will be right‐justified (never using the final column). 6. Text to be displayed must be truncated before the final pixel column; otherwise readerboard will scroll the message.

2010.4.5 A minimum of two (2) readerboards shall be provided for vehicles 60 feet or greater in length (e.g. articulated vehicles).

2010.4.6 Readerboard shall be able to scroll messages longer than 26 characters (up to 60 characters in length). Messages that are longer than 26 characters shall scroll quickly and stop again to indicate that it is a continuation of the message.

2010.4.7 Speed of scrolling and timing shall be completely configurable by the Transit Agency.

2010.4.8 At least one (1) readerboard shall be legible from anywhere in the passenger compartment under the full range of ambient illumination conditions.

2010.4.9 Contractor shall be responsible for removal of existing signs and, if necessary, installation of a Transit Agency approved covering to conceal holes/gaps left by the existing “stop requested” signs prior to installation of PIDs

2010.5 ASA ON‐BOARD System Diagnostics

2010.5.1 ASA shall include self‐diagnostic capabilities.

2010.5.2 ASA shall log every received message/command, with an ASA status result.

2010.5.3 ASA shall log every error condition, including but not limited to: 1. Inability to begin any announcement, within one second of being triggered; 2. Inability to load a “current” announcement data set; 3. Any hardware failures; and 4. Any time update, which is more than +/‐ five (5) seconds from current ASA time.

2010.5.4 ASA shall log configuration status (inventory and/or version control) upon any change in status and upon every ignition‐on event.

2010.5.5 All ASA log files shall be uploaded to the central processing system through the WLAN controlled by the VLU, whenever ASA is within a Transit Agency WLAN coverage area.

2010.5.6 The ASA shall provide Transit Agency maintenance technicians with a means of testing and setting both the internal and external audio default volumes and ambient noise AGC circuits.

2011 ASA CENTRAL PROCESSING SYSTEM

2011.1.1 Transit Agency already has the necessary applications and procedures that allow placement of "triggers" within the AVL operational schedule to activate location‐based announcements, and manage unique announcement codes and snippets. Contractor may choose to either use Transit Agency's



56

existing centralized ASA management system, or provide an alternative ASA solution that will meet and exceed existing ASA functionality.

2011.1.2 Contractor shall provide, install, and integrate the latest version of their ASA processing and management system.

2012 AUTOMATED PASSENGER COUNTER (APC)

2012.1.1 Contractor shall procure and install Contractor‐recommended APC sensors, analyzers, and wiring appropriate to an APC installation on‐board on fixed route buses and selected paratransit vehicles.

2012.1.2 Contractor shall assume that installation will be performed when all other on‐board CAD/AVL system equipment is being installed.

2012.2 APC Integration

2012.2.1 The VLU shall interface with the existing APC analyzer equipment on all buses currently so equipped, using either a IBIS, or J‐1708 or J‐1939 based interface directly with the VLU and an Ethernet interface via the MGR.

2012.2.2 APC data shall be communicated to central system in real time.

2012.2.3 The system shall have the ability to store APC data on the VLU if no network connection is available.

2012.2.4 Contractor shall remove and provide to Transit Agency the existing APC data logging equipment and cabling from this existing data logging equipment to the APC analyzer.

2012.2.5 The CAD/AVL system shall record passenger counts for all bus stops including stops where no passenger activity has occurred in real‐time time (e.g. database records will show 0‐ons or 0 offs at bus stops with no activity). This shall not be calculated post processing.

2012.3 APC Hardware Requirements

2012.3.1 APC equipment shall be supplied, per manufacture recommendations, for each door of all fixed‐route vehicles.

2012.3.2 The APC system shall utilize Contractor recommended sensors for passenger counting capable of meeting the functional and performance requirements, and shall be designed for operation with various door widths considering the vehicle type and configuration.

2012.3.3 The APC system shall be provided with micro switches for door, and wheelchair lift.

2012.3.4 The APC system shall not interfere with operation of the doors.

2012.3.5 The APC system shall not interfere with passenger ingress or egress.

2012.3.6 The APC system hardware shall be installed in an accessible location suitable for easy access for maintenance or troubleshooting purposes.

2012.4 APC Functional Requirements



57

2012.4.1 The APC system shall automatically count passengers at each transit stop and in service stops made at non‐transit stops (for all transit vehicle entrances/exits, including the rear door and center door if applicable). The following data shall be recorded: 1. The number of boarding passengers (by door), 2. The number of alighting passengers (by door), 3. Wheelchair lift or ramp deployments, and 4. Errors.

2012.4.2 The system shall not allow manual correction of passenger counts to the original (source) data. The system shall provide features to manually correct data outputs (reported data) through the central system.

2012.4.3 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.

2012.4.4 APC data and reports shall be associated with Transit Agency stop, route, route variant, and trip identifiers.

2012.4.5 APC sensors shall function as specified.

2012.4.6 The combination of sensors and logic shall properly detect and indicate the correct passenger count regardless of whether single or multiple persons are simultaneously entering or exiting at a door, or any simultaneous or overlapping combination of entering and exiting persons, or any movement through the infrared beams that is not associated with boarding or alighting activity.

2012.4.7 The system shall record the use of devices including the wheelchair lift or ramp.

2012.4.8 The APC shall properly allocate boardings and alightings between different routes and route directions at terminals. This shall account for interlined trips, routes ending in loops, etc.

2012.4.9 The APC shall provide a data structure for both raw and corrected/final data.

2012.4.10 The APC shall provide high‐level analysis tools to analyze archived data.

2012.4.11 The APC counts shall reset at the end of each service day.

2012.5 APC Performance Requirements

2012.5.1 The APC system shall provide complete and accurate stop‐by‐stop boarding and alighting count data (for all stops – including stops for which there is no observed boarding or alighting activity).

2012.5.2 The APC system shall provide sufficient accuracy and reliability to meet FTA requirements for National Transit Database (NTD) reporting certification. Contractor shall provide evidence that the proposed APC solution has achieved FTA NTD certification in a prior installation, operated in a similar configuration, for a U.S. public transit agency.

2012.5.3 The APC system shall provide accurate passenger counts for interlined services, accounting for boardings, alightings, and carry‐through passengers from the first service to the second, interlined service. Carry‐over passengers shall be accounted for both an alighting from the first service and a boarding on the second service, even when the passenger remains on the vehicle.

2012.5.4 The APC system shall differentiate between revenue passengers and non‐passenger objects (e.g. carts, baggage, service animals).



58

2012.5.5 The APC system shall meet the following accuracy requirements for a sample count of 1,000 persons:1. Stop‐level boarding and alighting counts shall have an error rate of less than 5% error for at least 90% of all stop locations; and 2. Stop‐level boarding and alighting counts shall have an error rate of less than 10% error for at least 99% of all stop locations.

2012.5.6 System testing shall include verification of the APC performance requirements.

2013 REMOTE DISPATCH TERMINAL (RDT)

2013.1.1 As part of a new CAD/AVL system requirement, Transit Agency desires to attain a mobile dispatching and monitoring functionality using portable IT device (e.g. tablet computer, iPad, or similar).

2013.2 RDT Hardware Requirements

2013.2.1 RDT units shall provide mobile CAD functionality in selected Transit Agency non‐revenue vehicles.

2013.2.2 The RDTs shall be tablet computers or similar with integrated cellular data connectivity of 4G or better. Contractor shall recommend an appropriate device prior to procurement.

2013.2.3 Contractor will provide a sample of the recommended device with active cellular data account for testing purposes, and not procure the additional RDT devices until receiving Transit Agency written approval.

2013.2.4 RDT units shall provide web browser functionality to access dispatch functionality and Transit Agencynetwork files.

2013.2.5 RDT units shall be provided with in‐vehicle chargers and AC chargers/adapters.

2013.3 RDT Functional Requirements

2013.3.1 The RDT shall be equipped with GPS based location functionality and locations shall be displayed on dispatchers’ workstations and map displays as a non‐revenue vehicle with a unique icon.

2013.3.2 The RDT shall include functionality for the user to logon and logoff the CAD/AVL system with logon or in/out of service status displayed on the dispatchers’ workstations.

2013.3.3 The RDT shall provide computer aided dispatch and monitoring functionality similar to the central site CAD, including as a minimum the following functionality:

1. Remote fleet and vehicle monitoring;

2. Bi‐directional text messaging between the RDT and Central dispatch;

3. Receive, create, update and save incident reports and forms;

4. Remote fleet and vehicle monitoring management;

5. Display of system‐wide bus timetables;

6. Display of schedule performance;

8. Access to paddle (i.e. block schedule) information;

9. Ability to display incident/message queues;

10. Access to Trip Planning Data (this may be accomplished by providing Road Supervisors with Internet access to the Transit Agency web site); and

11. Ability to receive messages sent between buses and dispatch. Messages shall be configurable by line(s) or geographic area.



59

2013.3.4 The RDT shall contain a color map‐based display with functionality to provide the following views: 1. Area‐wide display showing all routes and vehicles within a zone or other geographic area. 2. Display showing a user‐selectable area. 3. Service display that allows the ability to select some or all of Transit Agency’s Fixed Route vehicles and non‐revenue vehicles. 4. Route display showing a specific transit route and all vehicles currently on the route. 5. Vehicle display to show the location of a specific vehicle on the map, and automatically track the vehicle (refreshing the map) as it moves.

2013.3.5 The map shall display vehicles using color‐coded icons per central system requirements. Color‐coding or icon changes shall be used to indicate vehicles that are on route and on schedule, off‐schedule, off‐route, or under an emergency alarm situation. Two (2) different icons shall be used to indicate early and late off‐schedule vehicles.

2013.3.6 The map display shall include pan and zoom functionality, and shall adjust the level of detail of the map based on the zoom level.

2013.3.7 The map display shall automatically center on a vehicle issuing an emergency alarm (where such alarm has been recorded or activated at dispatch).

2013.3.8 The RDT shall include functionality to present tabular displays and summaries of transit vehicle information including at a minimum: 1. Route ID, Block ID, VID, and Operator ID; 2. Vehicle status; 3. Communications status; 4. Alarms; 5. Schedule adherence; 6. Schedule timetables system wide (these can be static); and 7. Performance and incident queues.

2013.3.9 The RDT shall include functionality to automatically center in on a vehicle or vehicles by selecting a vehicle, block, route, or trip from a graphical or tabular display. This shall also include the ability to go directly from a tabular display to the corresponding information on the map and from the map to the corresponding entry in the tabular display.

2013.3.10 The RDT shall include functionality to query or search by Operator, vehicle by selecting a vehicle, block, route, or trip from a graphical or tabular display.

2013.3.11 The RDT shall include functionality to send canned or free form text messages to a vehicle or group of vehicles.

2013.3.12 The RDT shall have equivalent message handling capabilities to the fixed route MDT, plus the functions described below.

2013.3.13 The RDT shall include functionality to send pre‐defined messages to dispatch. Such messages shall be established through configuration data. Contractor shall define a comprehensive set of messages that shall include at a minimum the following:

1. Logon/logoff/system test/maintenance; 2. Critical messages; 3. Vehicle status report; 4. In/out‐of‐service; 5. Responding to road call; 6. Vehicle mechanical problem; and 7. Minimum of twenty (20) other pre‐programmed messages.



60

2013.3.14 The RDT shall include the following incident report management functionality: 1. Create, populate, prioritize and close incident report and forward to central dispatch. 2. Receive open or closed incident report from central dispatch. 3. Update open report received from central dispatch, and return updated information or closed report. 4. Store and retrieve reports. 5. Send a page or text message to a pager/wireless device if a critical incident report is received. 6. Ability to link to the Transit Agency ACID system.

2013.3.15 RDT incident reports shall be configurable from the central incident reporting system, allowing modifications to the reports in terms of arrangement, data fields, labeling, and data entry options.

2013.3.16 Tablet computers used for remote dispatch shall also include functionality to provide normal office functions such as Internet access, email, and business application operation without disrupting CAD/AVL operations.

2013.3.17 The RDT shall allow users to set status (e.g. available, on‐break/lunch, unavailable, etc.) and assignment information such as current assignment, finished assignments, time assigned and who made the assignment, etc. Status information set by RDT shall be recorded by the central system.

2013.3.18 The RDT shall have access to real‐time information. Real‐time information shall include bus arrival/departure times and bus location.

2013.4 RDT Performance Requirements

2013.4.1 The RDT shall avoid delays (including the selection of the commercial communications service and equipment) of more than ten (10) seconds in the updates of screens when in an area of appropriate coverage.

2014 INTEGRATION WITH OTHER ON‐BOARD SYSTEMS

2014.1 Overhead Destination Sign Integration Requirements

2014.1.1 The VLU shall integrate with existing Overhead Destination Signs, including: the forward exterior headsign, side exterior/interior destination signs, and aft exterior route indicator signs.

2014.1.2 The system shall automatically display the appropriate overhead destination sign message(s) based upon the route/block of service the vehicle is logged on to perform.

2014.1.3 The VLU shall generate a fault and log all overhead destination sign malfunctions on‐board the vehicle, including date, time, GPS location, route, VID, etc. These logs shall be available either through a system reporting function or through the WLAN communications with the vehicle.

2014.1.4 The VLU shall notify the Operator of overhead destination sign malfunctions.

2014.1.5 The VLU shall allow Operator or dispatcher override of destination sign code, and log such overrides.

2014.1.6 The system shall support display of an emergency message (e.g. “Emergency – Call 911” when an emergency alarm is initiated by the Operator. Emergency messages shall not be visible from any device in the vehicle interior, including but not limited to: window destination sign displays, the Mobile Data Terminal, or the Overhead Destination Sign control panel.

2014.1.7 The VLU shall receive headsign codes over the WLAN to update the headsign database file.

2014.1.8 The VLU shall display onboard headsign health status and offer remote reporting capabilities for asset management purposes and/or component monitoring.

2014.2 Farebox Integration Requirements



61

2014.2.1 Contractor shall integrate and/or maintain the existing single point log‐on for the CAD/AVL (VLU), farebox, and smartcard system. The system shall work with all functions of the farebox including interlining.

2014.2.2 Contractor shall ensure that all farebox integration and functionality recently resolved (as of August 2014) shall be retained in the upgrade of on‐board equipment and appropriate screens and functionality will be retained in the new MDT.

2014.3 ON‐BOARD Mobile Surveillance System Integration

2014.3.1 Surveillance System General Requirements

2014.3.1.a Transit Agency utilizes onboard surveillance systems (UTC MobileView or Apollo). The on‐board system shall integrate with Transit Agency's existing security camera system. Refer to Attachment D for vehicle equipment inventory.

2014.3.1.b The on‐board system shall provide the capability for authorized users to view a live video feed (e.g. in the event of a silent alarm activation) if and as supported by wireless bandwidth. Frame rate and video quality shall be adjustable based on available bandwidth.

2014.3.1.c The on‐board system shall provide the capability for previously recorded images to be downloaded and archived at a central location through the MGR.

2014.3.1.d The on‐board system shall provide the capability for CCTV images to be tagged for download if one of the conditions specified in the event of an emergency alarm, PRTT, or separate video record activation from the MDT occurs.

2014.3.1.e CCTV integration shall include periodic updates of CCTV date and time from the MGR.

2014.3.1.f The onboard Video and Audio Surveillance System shall be integrated with the new single, shared AVL system GPS antenna to provide synchronous position data for both systems.

2014.3.1.g The MGR shall include an Ethernet port to support wireless upload/download of video clips, configuration data, and health reports from the on‐board Video and Audio Surveillance, as well as live‐look‐in capabilities, using the vehicles shared wireless data communications infrastructure.

2014.3.1.h The system shall accept health status messages/alerts from the on‐board Video and Audio Surveillance system as part of CAD/AVL system maintenance reporting functions.

2014.3.1.i The system shall accept time synchronization for the MDT.

2014.3.1.j The system shall integrate with Apollo Video Technology’s onboard video surveillance system.

2014.3.1.k Contractor shall provide metadata to the RoadRunner system which will be recorded along with video; the system shall receive health data from the RoadRunner system; Apollo Video Technology’s RoadRunner system accepts NMEA format messages and transmits a standard JSON format.

2014.3.1.l Metadata provided by the system shall include Driver ID, route ID, GPS, events (such as silent alarm, event marker, excessive acceleration), brakes, lights, turn indicators, door, ramp, engine RPM, engine temperature, other engine faults, manifest (if applicable), odometer, VID, Fuel Ecomony, and stop ID.

2014.3.1.m Health information supplied to the system shall include video loss, over temperature, fan error, video blind, disk bad, and disk missing.

2014.3.1.n The preferred interface for receiving metadata is Apollo Video’s standard NMEA interface protocol. If another interface is selected, the CONTRATOR is required to contract with Apollo Video to develop / determine another method.



62

3000

CENTRAL SYSTEM REQUIREMENTS

3001 GENERAL REQUIREMENTS

2014.3.1.o The preferred method for CONTRACTOR’S system is to use a JSON format to retrieve health information from the onboard recording system such as video loss, drive errors, record errors, etc., via an Ethernet connection.

2014.4 SAE J1708T Integration

2014.4.1 SAE J1708T General Requirements

2014.4.1.a VLU shall integrate Transit Agency's existing SAE J1708T system.

2014.5 Transit Signal Priority (TSP) Integration

2014.5.1 TSP General Requirements (RPTA/Tempe Only)

2014.5.1.a VLU shall log all TSP activations/deactivations on‐board the vehicle, including date, time (HH.MM.SS), GPS location, route, VID, direction, etc. These logs shall be available either through a system reporting function or through the WLAN communications with the vehicle.

2014.5.1.b The VLU shall be able to command the activation and deactivation of an on‐board Transit Signal Priority (TSP) emitter, configurable to use either a RS‐232, J‐1708 or J‐1939 port, including ensuring that the emitter is deactivated as the default state.

2014.5.1.c VLU shall only enable Transit Signal Priority functionality when the vehicle is logged into revenue service, with on‐route status, door is closed, on a TSP enable route, and reached a predefined schedule threshold (Transit Agency configurable) to several minutes ahead or behind schedule.

2014.5.1.d VLU shall be configurable to activate the Transit Signal Priority emitter upon reaching a “check‐in” TSP interaction event on the approach to an intersection if no door is open, and deactivate the emitter upon reaching a “check‐out” TSP interaction event as it exits an intersection. TSP interaction events are defined in the imported route data as locations along route patterns.

2014.5.1.e VLU shall log all TSP emitter activations including the date/time and location.

2015 MOBILE TRAINING DEVICES “VEHICLES‐IN‐BOX”

2015.1.a CONTRACTOR shall provide bus‐in‐box solution for training system stakeholders.

2015.1.b CONTRACTOR shall provide paratransit‐in‐box solution for training system stakeholders.

2015.1.c CONTRACTOR shall provide light‐rail‐in‐box solution for training system stakeholders.

2015.1.d CONTRACTOR shall provide fully functional “vehicle‐in‐box” and “vehicle‐on‐board” training devices for system stakeholder. Vehicle‐in‐box training device will serve to train system users on fixed end equipment functionality such as bus drivers and supervisors. Vehicle‐on‐board device will serve to train electronic techs on fixed end component interconnections, repairs, and maintenance. All “vehicles‐in‐box” and “vehicle‐on‐board” solutions shall be determined and finalized during design review.



63

3000


3001.1.1 The CAD/AVL system shall reside as a subnet on the Transit Agency’s IT network, as opposed to being a “stand‐alone” system.

3001.1.2 Any “patches” recommended by the hardware or software Contractors, (including operating systems), shall not void CAD/AVL Contractor warranty.

3001.1.3 Contractor shall review central system hardware, virtualized environment, related equipment and make recommendations for any improvements or additions necessary to support the system requirements.

3002 PERFORMANCE REQUIREMENTS

3002.1.1 The system shall be designed for continuous operation without the need to manually “reboot” computers or devices or initiate process restarts.

3002.1.2 Any system‐initiated process restarts shall not interfere with normal system operations.

3002.1.3

System availability shall be 99.95% or better. For central systems including the voice/data communications and the CAD/AVL central and dispatching functionality, availability shall be determined by dividing total out‐of‐service time by Total operating time. Out of service time shall include unplanned system maintenance only.

3002.1.4 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 dispatch and system administrator.

3002.1.5 Commonly used database queries, queue displays, information windows, (route headways and block schedules within 0.5 seconds), and map displays shall be displayed within one (1) second from user initiation for hardwired workstations.

3002.1.6

Radio Voice Call Setup Time: Contractor will work with CITY’s radio vendor to ensure the process of Radio call set‐up (when a dispatcher requests a mobile radio to go to a talkgroup, notify the Operator to pick up the handset, and notify the dispatcher that the call has been set up) shall be completed at least 95% of the time in five (5) seconds or less and shall never exceed ten (10) seconds. This shall be a simple computer process requiring no more than one (1) or two (2) mouse clicks. Termination of the call shall be completed within one (1) second.

3002.1.7

Automatic Group Data Updates With Selected Functions: When a dispatcher selects a function that involves a group of vehicles, such as a bus spacing display (or route ladder), the position and status data for the vehicles being displayed shall be updated by the system within ten (10) seconds of the selection. Information on these displays shall not be limited. The vehicle/Operator level information that is usually available on the regular display shall be available on these special displays as well.

3002.1.8 The system shall report updated vehicle location of any vehicle selected by dispatch within ten (10) seconds of request from dispatch.

3002.1.9 The system shall report location of all GPS‐equipped assets within a Dispatcher‐selected geographic region within thirty (30) seconds of request from dispatch.

3003 DISPATCH CONSOLES



64

3000


3003.1.1 Contractor will work with the Transit Agency’s radio vendor to ensure dispatch consoles software and CAD/AVL application integrate and function on a single dispatch console (workstation).

3003.1.2 Dispatch consoles with voice radio functionality shall be integrated with the new CITY and Transit Partner’s radio communication solution.

3003.1.3

The workstation will be supplied by the CITY; an all radio dispatch software will be provided by radio vendor. CONTRACTOR shall supply the agency a minimum hardware compatibility list that include a minimum specification for computer processing devices, keyboards and navigation devices, and displays.

3003.1.4 All displays shall use pedestal mounted “flat screen” liquid crystal display technology and have a minimum 22‐inch diagonal measure, and four (4) displays shall be supported (including pedestals) for each workstation position.

3003.1.5 CAD and Radio functions shall be performed using a single keyboard and mouse.

3004 FUNCTIONAL REQUIREMENTS

3004.1 General CAD Functional Requirements

3004.1.1 All current CAD functionality will be retained or improved, no functions shall be removed or rescinded without written consent of the CITY.

3004.1.2 CONTRACTOR shall supply a full‐featured (by industry standards) CAD functionality that has been previously proven in transit operations. Contractor shall provide references for the system selected.

3004.1.3 The CAD system shall retain the current separation of information and access control by Contractor, Contractor garage, Transit Agency, and OCC.

3004.1.4 The CAD system shall be integrated with the data communications system. The CAD system will lose no functionality if Transit Agency changes cellular providers or cellular technology that operates at similar or better speeds.

3004.1.5 CAD software shall be able to detect failures and restart processes automatically. The system shall log the cause of the failure to the MS Windows™ application log.

3004.1.6 The CAD system shall allow dispatchers to seamlessly switch the handset between the voice/radio and telephone headset.

3004.1.7 CAD functional capabilities shall be the same across all dispatcher workstations provided for the system.



65

3000


3004.1.8

Current representations and management of fixed route service in the system shall be retained, including: 1. Run: This refers to the complete piece of work for an Operator (duties) that may include vehicle changes during the course of the day. 2. Linegroup Block/Driver Block: This refers to the complete piece of work for the vehicle or driver, which may include multiple routes/interlined trips, and Operators. 3. Route: This refers to the overall route identifier, under which there would be a series of patterns. 4. Branch: This refers to the series of points that designate a particular path or pattern. Multiple Patterns shall be allowed per route. 5. Trip: This refers to a specific one‐way trip for the vehicle related to start/end times and points. 6. Timepoints/Stops: Timepoint refers to point along a route where trips are assigned arrival or departure times. A stop is defined as an established location where public transport customers may board or alight from a transit vehicle in revenue service.

3004.1.9 The system shall include a user interface that is user friendly, accessible, and intuitive for all users.

3004.1.10 The CAD software shall use typical MS Windows‐style GUI conventions such as resizable windows, point and click, right click context menus, drop‐down menus, toolbars, color displays, icons, drag and drop, scroll bars, scroll wheel mouse, status bars, etc.

3004.1.11 The CAD system shall support mouse and keyboard inputs with all key features supported by keyboard shortcuts.

3004.1.12 The CAD system shall provide easy‐to‐read displays when dispatchers are situated a standard distance from the display (i.e. 20/20 vision at a distance of three (3) feet). The system shall allow for resizing of the font and changing of the font type based on user preferences/profiles.

3004.1.13

The CAD software shall allow individual dispatchers to: 1. Logon with appropriate password. 2. Logoff. 3. Enter standby or “break” mode that will automatically transfer work assignments to another dispatcher without requiring dispatchers to logoff the system.

3004.1.14

A minimum of five (5) levels of CAD access shall be allowed including:

1. Supervising Dispatcher: Ability to adjust all CAD software preferences;

2. Standard Dispatcher: Ability to adjust preferences (such as vehicle status color indications or icons);

3. System Administrator: Ability to adjust all CAD system/software preferences; and

4. Two additional Transit Agency defined levels.

3004.1.15 The CAD shall save all user preferences by user logon so that users may access their saved preferences from any CAD workstation.

3004.1.16 The CAD system shall provide an onscreen indication showing dispatcher status for all workstations including incident queues, active calls, etc.



66

3000


3004.1.17 All CAD workstations shall provide user‐friendly on‐line manuals and help functions.

3004.1.18 Drop down menus or equivalent shall allow dispatch access to PDF versions of Transit Agency procedures, phone database tables, processes, and read/write to checklists. This can be accomplished through providing access to existing OCC resources.

3004.1.19

The system shall allow dispatchers to remove a specific vehicle from the voice and data communications reporting set for a configurable (by the Transit Agency) amount of time. The intent of this is to limit communication error messages at dispatch when a vehicle is experiencing a long‐term voice and data communications issue. The system shall allow the dispatcher to temporarily silence alarms not attributed to emergencies.

3004.1.20 The system will maintain a log of all messages and incidents, which can then be sorted and accessed by all available fields to include specific incident, incident type, date, Operator, dispatcher, and other fields.

3004.1.21 The system shall notify Transit Agency customer service automatically by email and/or CAD text messaging of significant service disruptions, such as unusual delays, incidents, detours, or missed trips. The criteria to determine “significant” shall be configurable by the Transit Agency.

3004.1.22 Schedule adherence shall not be indicated to Operators, supervisors, or dispatchers for routes or blocks designated as “free running.” The system shall continue to collect route schedule adherence data while bus is free running.

3004.1.23

The CAD system shall provide the following basic views, which can be sorted by all available fields, in addition to the message queues: 1. Map displays (allowing for multiple map windows and zoom settings); 2. Route displays indicating vehicles relative to stops along a route; 3. Vehicle lists of all vehicles active in the system; 4. Operator lists of all Operators logged into the system; 5. Trip lists of all trips currently active in the system; 6. Incident or event lists (for work assigned to dispatcher or vehicle‐specific) which shows all actions conducted through the CAD; 7. Summaries of pull‐out/pull‐in status by first/last timepoint, location, block, and depot in separate summaries; 8. Operator ID or VMS ID; and 9. Operator First Name, Last Name, and employee ID.



67

3000


3004.1.24

Dispatchers and Street Supervisors shall have the ability to filter the vehicle location display by the following options:

1. Runboard (e.g. Regular).

2. Route number.

3. Route pattern.

4. Trip.

5. Line‐Group.

6. Division.

7. Branches.

8. Vehicle type.

9. Vehicle number.

10. In‐service and on‐schedule (by a(n) Transit Agency configurable period).

11. Behind schedule (by a(n) Transit Agency event configurable period).

12. Running early (by a(n) Transit Agency configurable period).

13. Out of service.

14. Last known location of powered down vehicles.

3004.1.25 It shall be possible for routes to be assigned to multiple dispatcher roles (e.g. fixed‐route dispatcher, Transit Agency personnel, or street supervisor) simultaneously.

3004.1.26 Dispatch workstations shall be integrated and appear to dispatchers as a seamless integrated solution regardless of the number or types of applications actually running.

3004.1.27 The system shall support and provide displays of Operator, trip and vehicle rosters/lists.

3004.1.28 The system shall allow Operators to indicate that vehicle is in layover status if layover occurs at a non‐pre‐assigned layover point.

3004.1.29 The system shall accommodate a “fictitious” route for training or testing purposes. A dispatcher shall be able to insert this route at any time without disrupting regular service routes.

3004.1.30 The system shall provide dispatchers with interlining information about a specific route, block or vehicle.

3004.1.31 Interlining information shall be used by the system to identify impacts of late pullouts, detours and/or bus‐bridge assignments and notify dispatcher of these impacts.

3004.1.32 System shall provide Transit Agency customizable route attributes, (e.g., high frequency, interlining routes, etc.) allowing for route prioritization in different classifications.



68

3000


3004.1.33

CAD shall allow for planned special events (e.g., <SPECIAL EVENT TYPE>) with additional supporting functions such as: 1. Predefined special routes, 2. Predefined detours, and 3. Predefined text messages, to Operators for the event buses.

3004.1.34

Mechanics, engineers, trainers, etc. that are operating buses, shall have unique login identification so that CAD/AVL can identify and track and correlate with non‐service status including: 1. Training 2. Dead‐head 3. Replacement vehicle 4. Testing

3004.1.35 The system shall not allow duplicate block ID’s with Operator logon. If more than one (1) Operatorlogs onto the same block, an automated message shall be sent to both Operators to verify login. The situation shall also generate an automated message to dispatch.

3004.1.36 CAD system shall allow dispatchers to remotely logon/off bus Operators from the system.

3004.1.37 All incoming incidents to each CAD/AVL dispatch console shall be able to generate an audible tone(s) to notify the dispatchers. All audible alarms shall be adjustable, in both volume and tone, by the system administrator.

3004.1.38 All drop‐down look up menus shall allow manual alphanumeric input to select desired item(s) (i.e. Combo box). The intent of this feature is to eliminate the need to scroll through a list to find the desired item.

3004.1.39

CAD shall support the ability of Dispatchers to issue special instructions to ad hoc or predefined geographic areas (e.g., area around an intersection, transit center, yard, etc.), which the Dispatcher can select to be sent either to routes crossing through the defined zone or to all vehicles within the selected area.

3004.1.40 CAD system shall provide Dispatchers with the appropriate contact information (including phone numbers and radio talk groups) for agencies during incidents, based on vehicle location within specific jurisdictions.

3004.1.41 Contractor system shall support the capability for dispatch to indicate that a bus stop is not in service; that information shall be propagated by the System to all routes and lines serving that stop.

3004.2 Vehicle Tracking

3004.2.1 Dispatchers need to be able to “track” a particular vehicle or portable radio by selecting each from a list of all available devices to be displayed on the AVL map.

3004.2.2 The performance and output of the CAD/AVL data and mapping software must be accurate, correctly reconciling to stop and street locations.

3004.2.3 All dispatch workstation displays and information (on a single workstation, as well as across all workstations) shall be consistent and show current and identical status within ten (10) seconds of one another.



69

3000


3004.2.4 The base frequency for updates to the location of each vehicle on the data network shall be no longer than every thirty (30) seconds. Any messages sent to/from the vehicle shall force a location update.

3004.2.5 The system shall indicate any vehicle that is not reporting back on regular intervals and/or over multiple polling cycles.

3004.2.6 CAD shall be able to accept location data from sources without MDTs, such as non‐revenue vehicles and portable radios, and display all resources as distinct layers and icons on the CAD maps.

3004.2.7

CAD/AVL system shall track location and status of any GPS‐enabled device, such as non‐revenue vehicles including field supervisors, maintenance, transit security, etc. These shall be illustrated as different icons for vehicle type and status. Other than the GPS‐enabled devices supplied under this work, Transit Agency will be responsible for supplying the GPS data feed. Contractor will provide required input parameters and access into the CAD system.

3004.2.8 CAD/AVL system shall allow the dispatcher to enter known cancelled blocks of service in advance, and this information shall be made available to other components of CAD/AVL such as pull‐out status, all performance summary displays, etc.

3004.2.9 The CAD system shall allow user(s) to manually relocate stale and/or non‐communicating vehicles to a (n) Transit Agency defined location (e.g. vehicles towed to garages).

3004.2.10 The CAD system shall be configured to allow customized filtering of GPS‐enabled devices by preconfigured groups (e.g. customer service, fare technicians, supervisors, etc.) tracked by real‐time GPS coordinates.

3004.2.11

CAD system shall be able to query the system at regular intervals to determine the location and number of buses that have not moved but should be moving (e.g. “Stuck”) within specific, Transit Agency‐configurable time periods. The CAD system shall be able to show all stuck vehicles simultaneously on the AVL map. Automatic notifications shall be sent to dispatch when such vehicles are identified, as well as when a stuck vehicle begins moving again (e.g. “Unstuck”).

3004.3 General CAD Communications

3004.3.1 The system shall set the priority of incoming calls through an alarm function. This shall be set through a series of Transit Agency configurable parameters that the incident recorder selects as information is entered into the system.

3004.3.2 The system shall display different vehicle icons based on vehicle status (e.g., communications lost, running early, running late, off route, etc.).

3004.3.3

Communications status shall be displayed to dispatchers where: communications with a vehicle are lost, recent position reports for a vehicle are not available, and sent messages that were not received due to communications failure. This shall be displayed as an icon or similar on both the message queue (as appropriate) and the AVL display. The parameters for these communication status notifications shall be configurable by Transit Agency.



70

3000


3004.3.4 When an item from the queue is selected, the system shall automatically provide dispatchers with vehicle information such as route, block, schedule, interlining and transfer data as well as Operator information including full time, part time, regular, regular relief, extra board, and vacation relief.

3004.3.5 The system map shall center on vehicle when the dispatcher selects a message or incident related to that vehicle. This feature shall be configurable by the Transit Agency, based upon message type, and/or by having the dispatcher select a message with the zoom/center option.

3004.3.6 All dispatch functions shall be supported by automatic messaging to trips/vehicles/Operators and confirmation messages to dispatch, and shall be logged in the CAD/AVL database.

3004.3.7 CAD shall provide a summary table or display that demonstrates the level of communications “reliability” with vehicles currently in operation. The system shall identify areas where communications fails for a number of vehicles (i.e., identify dead zones).

3004.3.8

All route or vehicle specific data communications (text messages or dispatch actions) shall be saved and forwarded to or from vehicles that may be out of communications at the time of the origination of the message (up to either a preset duration on the message or within a single operations day). Once the system confirms that communications have been re‐established, the fixed‐end or mobile equipment will re‐send the saved message. Once data communications have been re‐established the fixed end and mobile VLU/MDT gear shall send duplicate messages only one time until “acknowledged” by the recipient” via a data ACK message. The system shall identify messages with an initial submission time stamp.

3004.4 Voice Communications

3004.4.1 CAD shall support a Request To Talk (RTT) and Priority Request To Talk (PRTT) method of communications.

3004.4.2 Voice communications requests shall be separately highlighted and displayed in the communications queue.

3004.4.3 Only one (1) RTT and PRTT shall be displayed in the queue for each vehicle attempting to make a call. A PRTT will replace an RTT should the vehicle change from RTT to PRTT, whereas repeated presses of RTT or PRTT will simply update the existing message in the communications queue.

3004.4.4 Dispatchers shall be able to initiate voice communications by double‐clicking RTT or PRTT messages.

3004.4.5 Once connected, the message will display as being handled by the connecting dispatcher on all workstations displaying that message.

3004.4.6 RTT and PRTT shall not disappear off the communications queue until such time as they are dealt with by a dispatcher or deleted by a dispatcher.

3004.4.7 Emergency alarm shall take top priority in the communications queue, followed by PRTT and RTT respectively.

3004.4.8 All queue priority levels and destinations (i.e., database only, specific dispatchers, etc.) shall be configurable by the Transit Agency personnel or system administrator.



71

3000


3004.4.9 Dispatchers shall be able to select a listen‐in or default talk‐group which will transmit all voice communications for that talk‐group until another mode of communications is selected. This shall not interfere with dispatchers’ ability to perform other voice calls.

3004.4.10

Dispatchers shall be able to initiate voice communications by selecting voice communications function: 1. On a vehicle on the AVL map, 2. Pressing the appropriate hot key, 3. Pressing a function specific icon on the CAD display, 4. On the specific vehicle in the vehicle list, specific block or duty list, or Operator badge/name list, 5. Dragging around (or rubber‐banding) selection on the AVL map around an area with communications to each vehicle within the selected areas, and 6. Selecting the route, yard, or specific VIDs for communications.

3004.4.11 The system shall notify the dispatcher when the call cannot be setup and present the dispatcher with a choice to cancel the call or to continue trying to set up the call and notify the dispatcher when it was successful.

3004.4.12 The system shall notify the dispatcher visually and by tone when a call has connected and the dispatcher may begin speaking.

3004.4.13

Dispatchers shall be able to conduct the following type of voice calls: 1. One‐way group calls between the dispatcher and multiple vehicles defined by: a. Individual and/or multiple route(s) (including all vehicles currently interlining on that route), b. Specifically identified vehicles, c. Rubber band or map selection of all vehicles within a selected area in the map, d. Predefined graphical areas, e. By all buses from a specific Division/depot, f. By all buses in the fleet, and g. Conference calls between dispatch, buses, and support vehicles. 2. PA announcements on‐board a specific vehicle or group of vehicles as defined in (1) above. 3. Calls to a predefined talkgroup.

3004.4.14 System shall automatically and immediately locate and update vehicle information (route, location, status, etc.) when dispatcher takes a call.

3004.4.15

The system shall automatically notify dispatchers after a certain, Transit Agency‐configurable amount of time has passed, that a call or event has not been resolved/closed. The automatic notification shall be completely configurable by the Transit Agency for the time and event type. The Transit Agency personnel may override the preset notification time frame, up to double the preset time.

3004.4.16 Calls initiated from portable radios to dispatch shall provide a unique radio ID, which will be correlated with a name assigned to the radio and displayed to the dispatcher.

3004.4.17 Dispatchers shall be able to interrupt active radios over the air.



72

3000


3004.4.18 The CAD system shall support the ability for dispatchers to be able to switch between headsets and microphones during voice communications.

3004.4.19 System Administrator shall be able to disable/deactivate active mobile and portable radios over the air.

3004.4.20 A “right click” on a message in the queue shall provide the Dispatcher an option to open a voice call to the message initiator.

3004.5 Vehicle Conferencing

3004.5.1 System shall allow Dispatchers to seamlessly conference vehicle calls (e.g. silent alarm/emergency, maintenance calls, etc.) with calls made on the telephone (e.g. 9‐1‐1 emergency dispatch, maintenance department, etc.).

3004.5.2 Conference calls between vehicles and the VoIP phone system shall be compatible with the phone headset.

3004.6 Text Messaging

3004.6.1

The system shall provide two (2)‐way text messaging between transit vehicles and dispatchers. Dispatch shall have the capacity to initiate a text message by: 1. Selecting a message from the queue; 2. Selecting vehicle(s) from a list; 3. Selecting route(s), (including the option for all current and future vehicles interlining on that route) from a list; 4. Entering an Operator ID, VID or group ID, Division ID; 5. Entering a route ID or block ID; 6. Rubber band or map selection of all vehicles within a selected area in the map; 7. Predefined graphical areas; and 8. Fleet wide.

3004.6.2 The CAD system shall allow for separate configured canned message sets for fixed route versus paratransit fleets.

3004.6.3

The CAD system shall include “canned” (pre‐defined) and free form text messaging functionality to the fleet MDTs that will support a text message range with a minimum of one (1) character to 256 characters long. All canned messages shall be configurable by Transit Agency. The system shall allow local IT with appropriate system administration privileges to add, delete, or edit canned messages that are location‐specific.

3004.6.4 The CAD system shall provide for a minimum 40 “canned” messages per device type (MDT, Desktop, etc.) that may be broadcast from vehicles with MDTs to dispatch.

3004.6.5

The canned messages shall be separable into four (4) categories:1. Fixed route canned messages available on all fixed route vehicles; 2. Paratransit route canned messages available on all paratransit vehicles; 2. CAD dispatch canned messages available through the CAD workstation; and 3. Transit Agency‐Configurable (future grouping) available for a separate to be defined vehicle subset.



73

3000


3004.6.6

Canned text message types shall be determined by the Transit Agency and configured into the appropriate MDTs and CAD software. Where appropriate, canned responses to canned messages shall be available to both the vehicle and dispatcher, and responses will also be determined by the Transit Agency. Changes to canned messages will be uploaded through the Transit Agency WLAN.

3004.6.7 Changes/additions/deletions to dispatch and Operator canned messages shall be configurable by Transit Agency and shall include an easy to use user interface. Changes to canned messages shall be uploaded through the Transit Agency WLAN.

3004.6.8 CAD shall allow dispatchers to request confirmation of acknowledgement (ACK) responses that indicates a text message was received and read.

3004.6.9

Dispatchers shall be able to sort/filter the confirmation or acknowledgement responses in a summary table display by the following: 1. Acknowledged responses (including timestamp of when Operators responded) , 2. Date and Time responded, 3. Non‐responding vehicles, 4. Operator ID, and 5. VID.

3004.6.10 The system shall automatically resend ACK request messages to all non‐responding vehicles after a Transit Agency‐configurable amount of time has passed.

3004.6.11 The dispatcher shall be able to reply to a message in the queue in either a canned response or free‐form text message by double‐clicking on the appropriate message.

3004.6.12 When a dispatcher receives a message from a vehicle Operator, the system shall display the route, block, vehicle, VID, Operator’s name, employee number, location, route schedule adherence (RSA) status, time and pattern.

3004.6.13

Dispatcher shall be able to schedule text messages to be sent at logon or at some future time, to notify Operators of route changes, detours, or special announcements. Regardless of whether or not the message requires a response from the Operator, there shall be a notification to the dispatcher if the message was not received or viewed by the Operator for some reason.

3004.6.14 The system shall notify the dispatcher if a text message was not received and allow the dispatcher to cancel the message, or to continue trying and notify the dispatcher when it was successful.

3004.6.15 The system shall indicate the status (i.e. successful, failed, or pending) of sent messages in the message queue.

3004.6.16

Dispatchers shall be able to cancel, recall, edit or modify messages. Cancelled and recalled messages shall be logged, but disappear from the visible message queue. Dispatchers shall also have the ability to access, modify and reinstate cancelled and recalled messages that are no longer in the visible message queue.

3004.6.17 All changes made to messages and incidents shall be tracked.



74

3000


3004.6.18

Every message sent to a vehicle requires the receiving VLU to generate an automated acknowledgement that the message was received by that vehicle. All acknowledgement messages shall have a 95% (or higher) successful throughput, which shall be tested and verified during all stages of fleet installation.

3004.6.19 The CAD system shall monitor the acknowledgement status of all transmitted data and automatically resend messages to vehicles that have not acknowledged.

3004.6.20

The CAD system shall provide a tabular report for every sent message that has not been acknowledged by all expected vehicles, showing acknowledgement status by vehicle. This tabular report shall have the ability to cancel the message from further re‐sending to vehicles that have not received or acknowledged the message.

3004.6.21 The CAD system shall provide the ability for Dispatchers to send free form and canned text messages to the PID readerboards.

3004.7 Emergency Alarm (EA)

3004.7.1

The CAD system shall support emergency alarms (covert). When acknowledging an alarm the CAD system shall zoom and center the map display on the alarming vehicle and locate the nearest street supervisor vehicle when selected by dispatch. The scale for the zoom shall be configurable by Transit Agency.

3004.7.2 The CAD system shall allow dispatchers to downgrade emergency alarms to a lower message priority, or upgrade lower priority messages to an emergency alarm. The CAD system shall log all alarm status changes (create, upgrade, downgrade, and cancel).

3004.7.3 Activation of an emergency message shall place the vehicle in a priority status for frequency of location and message updates which will result in vehicle location and status updates at a rate that is configurable by Transit Agency.

3004.7.4 Activation of a covert alarm shall activate a covert microphone for “listen‐in” mode for a Transit Agency‐configurable time, unless downgraded by dispatch.

3004.7.5 The CAD system shall provide a continuous audible alert to dispatch when a covert alarm is activated until dispatch acknowledges the alarm.

3004.7.6 The CAD system shall provide a Transit Agency‐configurable, audible and visual alert to dispatch, RDTs, and others using the system when an emergency alarm is activated, and the CAD/AVL system shall monitor that vehicle continuously until otherwise specified by dispatch.

3004.7.7 Dispatchers shall be able to cancel, prolong, or immediately re‐enable “listen‐in” mode.

3004.8 Other Alarms and Notifications

3004.8.1 The CAD system shall be capable of indicating schedule adherence for all in‐service fixed route vehicles.



75

3000


3004.8.2

The default criteria for “running late” and “running hot” shall be Transit Agency configurable in minutes behind schedule, and minutes ahead of schedule. Transit Agency shall be able to configure in minutes for ahead of or behind schedule by route or globally. In addition, the CAD shall provide a separate Transit Agency configurable “late” parameter specifically to support transit signal priority (TSP) and other needs.

3004.8.3 CAD shall allow early and late schedule adherence messages to be filtered so as not to display in the communications queue.

3004.8.4 Schedule adherence shall be determined on the vehicles and communicated to the central system for display on the CAD workstations. Final calculations shall go to the CAD system.

3004.8.5

The CAD system shall generate an off‐route Attention Request (AR) message for vehicles deviating from routes by a Transit Agency‐configurable distance. There shall also be a tool that allows the system to receive detour and alternate route information that prevents the off‐route notification when a bus is on the detour or alternate route.

3004.8.6 CAD shall support reporting the current vehicle path (e.g. Scheduled, Scheduled Detour, Unscheduled, etc.) to downstream systems (e.g., Real‐time public information).

3004.8.7 The CAD system shall provide vehicle to vehicle and/or vehicle to dispatch notification to request to transfer. This message shall request the connecting bus to wait for two minutes.

3004.8.8 The CAD system shall generate an automated message for vehicles that have not performed a wheel chair lift test prior to pull out after a Transit Agency‐configurable amount of time or if vehicle has crossed a geographic threshold.

3004.9 Map Displays

3004.9.1 System shall have the ability to refresh schedule and/or map‐based data in CAD/AVL to allow for the management of detours or other mid‐sign up changes.

3004.9.2

The CAD system shall display vehicles and other GPS enabled devices via icons displayed in a map view (as well as vehicles and other GPS enabled devices indicated in a list). Icons shall be configured in the system and standard across CAD workstations. Icons shall clearly indicate position in relation to the map and direction of travel. A minimum of 12 icon types shall be available for configuration. Dispatchers shall be able to call up “flags” noting VIDs, Operator or personnel information (i.e. name, badge, and status), block/run number, route number, and Division as applicable. The system shall display detours in color to identify where route is being re‐routed.

3004.9.3 Each type of resource location icon shall include a Transit Agency configurable label (e.g. vehicle, route, Operator, etc.) that will always display.

3004.9.4 CAD system shall be able to display different portable radio and other GPS enabled subgroups as unique icons and filter which of these subgroups are displayed.

3004.9.5 The system shall also bring up the flags if the dispatcher hovers the cursor over the resource location icon.



76

3000


3004.9.6

Icons shall allow for the display of a Transit Agency‐configurable status such as: 1. In‐service and on‐schedule (by a Transit Agency‐configurable period), 2. Behind schedule (by a Transit Agency‐configurable period); 3. Running early (by a Transit Agency‐configurable period); 4. Out of service; 5. Not logged in; 6. Emergency/covert alarm activated; 7. Off‐route (by a Transit Agency‐configurable distance); 8. Communications interruption; 9. Vehicles at a layover; 10. Last known location of powered down vehicles; 11. Stale and/or non‐communicating vehicles; 12. “Stuck” or non‐moving vehicles; 13. “Available” for Loop Extras, Security, etc. available for use; 14. “Unavailable” for resources responding to incidents; and 15. Turn around loop should also show direction of travel on map.

3004.9.7

The digital mapping system shall be compatible with, and able to import, all layers from the Transit Agency’s Geographic Information Systems (GIS) data.

The mapping system shall utilize web‐based mapping services like ESRI, Google maps or City‐created maps. The system shall be compatible for upgrades utilizing current ESRI ArcGIS tools. The system shall provide ease of transition to the next versions of ESRI ArcGIS.

3004.9.8 The dispatcher shall be able to open, close, tile, or resize map windows.

3004.9.9

The map display shall be capable of displaying a variety of geographic features with names. It shall be possible for Dispatchers to independently set features to be visible or hidden by map layer without limitations on the numbers of layers. At a minimum, the map display shall display these features: 1. Freeways and highways (with appropriate shields and alternate names); 2. Major and minor streets (with appropriate names); 3. Rail track; 4. Transit centers; 5. Transfer points; 6. Bus stops and stations; 7. Landmarks; 8. Rivers, lakes, and other major bodies of water; 9. Parks; 10. City, county, and police boundaries/ jurisdictions; 11. Agency maintenance yards; 12. Airports, hospitals, police stations, fire stations, and schools; and 13. Any landmark designated by Transit Agency.



77

3000


3004.9.10

The map view shall include functionality for pan, zoom in/out, window zoom, and multiple map displays. The map display shall be Transit Agency‐configurable to display different levels of detail (such as street names) at different zoom levels. The system shall include functionality to use pre‐defined levels for common view requests.

3004.9.11 The map view shall support multiple preset map windows accessible by tabs or other windows style methods. Dispatchers shall be able to configure map windows unique to their workstation logon.

3004.9.12 The map display shall automatically update the display when new data becomes available to CAD.

3004.9.13 The CAD system shall be capable of tracking the last known location and direction of powered down GPS enabled devices.

3004.9.14

The dispatcher shall be able to center a map view on a vehicle, or track a vehicle by: 1. Selecting the vehicle on the map display; 2. Entering the block, vehicle, Operator ID, or route; 3. Selecting the vehicle from a list of vehicles; 4. Selecting a message from the queue; 5. Selecting the Operator from a list of Operators; or 6. Selecting the block from a list of blocks.

3004.9.15 Dispatchers shall be able to center a map view by entering a specific intersection and/or address or by clicking a location.

3004.9.16 Dispatchers shall have the ability to create, delete and change map views specific to their log‐on profile.

3004.9.17

The system shall include a function that allows for the identification of supervisor, security and support vehicles and GPS‐enabled Security mobile and portable radios closest to an individual vehicle selected by the dispatcher, and shall include the type and ID of the support vehicles or the portable radio.

3004.9.18 The dispatcher shall be able to review on the map display in a separate window the chronological sequence of reported locations for a specified GPS‐enabled device over a specified time period.

3004.9.19 The software shall provide controls to view the entire sequence of reported locations accurately from the beginning of the time period or to step through the sequence incrementally forwards or backwards.

3004.9.20 The system shall allow replay for a single GPS‐enabled device, selected set of GPS‐enabled devices or all GPS‐enabled devices on the selected map view for selected time period.

3004.9.21 The system shall allow selection of any time period for the historical data.

3004.9.22 The replay data shall include location reports, schedule adherence data or other collected information associated with the GPS‐enabled device available in the CAD system.

3004.9.23 All users accessing the CAD/AVL system, including workstation users, RDA users and Desktop Display Web Application users, shall be able to access the location playback function.

3004.9.24 The system shall allow the ability to switch easily between the operational and the flashback view.



78

3000


3004.10 Performance Summary Displays

3004.10.1

The CAD screens shall provide access to a route display showing the locations of all vehicles in service along a specified route, along with supporting information such as: 1. Headways, 2. Gapping, 3. Schedule status, 4. Scheduled departure, 5. Current route, 6. Next route, and 7. Dispatch action (added trip, etc.).

3004.10.2

The system shall provide a service summary display that summarizes schedule adherence, gapping/bunching, headways, and status by route and geographical area. Routes displayed for each dispatcher shall be filtered to include either all routes or only those routes for which they are assigned. This service summary data shall be captured in an easily readable report format.

3004.10.3 The CAD system shall provide tables displaying all current schedules and adherence by route, block, branch, VID, stop pattern and Operator.

3004.10.4 Performance summary displays shall allow for “drill‐down” selection by dispatchers where a dispatcher can select a route of interest and bring up the associated route display. From the route display, dispatchers shall be able to bring up block and vehicle tables.

3004.10.5 The System shall provide a pull‐in/pull‐out summary display for dispatchers that can be sorted by status of lateness, depot, VID, Operator number, and first and last name.

3004.10.6 The System shall provide a summary display for all active incidents for that operating day.

3004.10.7 A single service summary display shall be provided summarizing the on‐time performance, missed/served trips, and overall status by each route assigned to a dispatch position.

3004.10.8 Based on data reported by vehicles to central, a summary of reported causes for vehicles late at timepoints will be displayed.

3004.11 Resource Status Displays

3004.11.1

CAD shall provide a resource status summary display which allows a window view of: 1. Current support vehicle status (busy, available, assigned minor mechanical repairs, incident numbers being dealt with, etc.) as indicated through the RDT. 2. Current field support personnel status notes as entered by dispatch based on voice communications. 3. Information that can be populated into an incident such as employee name, badge number, vehicle number, unit ID, location, etc.

3004.11.2 Dispatchers shall be able to manually enter resource status into the resource status display screen.

3004.11.3 Status of all field resources shall be displayed on all workstations regardless of dispatcher work assignments.



79

3000


3004.11.4 Dispatchers shall be able to enter communications and other notes into the resource display which will be saved and stored in the CAD database.

3004.11.5

Dispatchers shall be able to locate the following screens and information from the resource status display: 1. Location of support resource on the AVL map. 2. Copies of active and current day incident forms dealt with by that support resource on the RDA.

3004.11.6

Dispatchers and Remote Dispatch Terminal (RDT) users shall be able to set status of RDT users (e.g. available, on‐break/lunch, unavailable, etc.) and assignment information such as current assignment, finished assignments, time assigned and who made the assignment, etc. Status information set by Dispatch shall be recorded by the central system.

3004.12 Incident Management and Forms

3004.12.1

All current CAD incident functionality shall be maintained and any modifications shall be agreed to in advance by the Transit Agency. Incident forms and functionality shall represent the latest version and highest level of functionality currently available from Contractor.

3004.12.2 The system shall document events/incidents with automated prompts for specific types of information, based on Transit Agency’s incident requirements. System shall provide unique incident ID number so that other documents and/or photos can be linked.

3004.12.3 CAD shall support an integrated incident/event forms functionality which operates in conjunction with the other CAD/AVL functions and displays.

3004.12.4 CAD shall allow for automated calculation of lost service from service related incident entry (e.g. through the selection of blocks, trips, or portions of trips between two stops)

3004.12.5

Dispatchers shall be able to initiate an incident/event by:

1. Selecting an incident/event generation function via hotkey, drop down menu, or button on a toolbar.

2. Selecting an incident/event generation function in relation to a particular vehicle from the AVL map or message queue, with the appropriate CAD available information populating the incident/event automatically.

3. Selecting an incident/event generation function from a vehicle list, block table, or stop list display with the appropriate CAD available information populating the incident/event automatically.

4. Automatic incident/event generation when certain Transit Agency‐configurable CAD events (i.e. covert alarms) occur.

3004.12.6 The CAD system shall support the ability to tag an incident record with an index or link to specific CCTV frame(s)/snippets.

3004.12.7 The CAD system shall generate a unique, progressive identification for each incident/event regardless of re‐booting the system. No CAD incident/event identification number shall be repeated.



80

3000


3004.12.8

Incident reports, message queues, and the CAD/AVL shall be directly integrated as follows: 1. The ability to create an incident/event in CAD/AVL by selecting a vehicle in CAD/AVL (either from a list or a map display). 2. Displaying of vehicle status relating to incidents. 3. Ability to center and quickly locate a vehicle on a map once an incident is generated. 4. Ability to bring up a stop display to note the nearest stop in comparison with the current vehicle location.

3004.12.9 The user interface shall support “speed keys” and “auto fill” for incident reports and message queue fields.

3004.12.10

The CAD shall include functionality to reopen incidents/events to add additional information regarding an incident or event. Each event shall contain a time/date/user stamp to note such information related for creation and with each set of edits. Maintenance incidents shall be transferred to the maintenance management system

3004.12.11

The CAD system shall notify users trying to access an incident/event if the incident/event is already accessed by another user. Multiple users shall not be allowed to modify the same incident simultaneously. Additional users shall be notified that the incident is under the control of another user shall be granted read‐only access until the incident is released by the editing user.

3004.12.12 CAD system shall support routing of messages (AR Queue) and incidents between dispatchers based on work assignments, previous dealings with the vehicle/incident, and ability to pass information between subsystems internal to the CAD/AVL solution.

3004.12.13 Maintenance‐related operational data collected from CAD/AVL shall be made available to the Maintenance Division (online/remotely) to allow for diagnosis.

3004.12.14 CAD system shall support the ability to transfer forms between dispatchers and Field Supervisors who are using RDT.

3004.12.15 The system shall provide an auto save feature for open incidents in the event of a system crash while working with an incident.

3004.12.16 The CAD system shall allow dispatcher to forward specific incident types to distribution groups. Types of incidents and distribution groups shall be configurable by the Transit Agency.

3004.12.17 Immediately upon closing an incident report, it shall be available to append and/or review by other users. Incident reports shall not be able to be edited or deleted once created.

3004.12.18 The CAD system shall ensure that all incidents are assigned to a dispatcher for response.

3004.13 Transfer Protection

3004.13.1 Pre‐planned, protected transfers shall be obtained from the scheduling data imported into the CAD/AVL.



81

3000


3004.13.2

CAD shall allow transfer protection parameters to be configured by the Transit Agency in advance for each transfer pair to include:

1. Time period during which a late feeder bus will prompt a message to wait on the receiving bus.

2. Time period to allow for passengers to transfer from one bus to another.

3. Time period after which the transfer will be considered failed and the receiving bus receives the message to proceed.

4. Number of minutes in advance of projected arrival of the incoming vehicle will the system start projecting whether the incoming vehicle's expected arrival to the transfer point will be after the receiving bus would need to be released.

3004.13.3 The CAD/AVL system shall include service management tools that alert dispatchers when a critical transfer or “meet” is not going to happen and a decision is needed. The alert shall be in a visual and auditory format that can be configured (i.e. auditory alarm can be turned off) by dispatch.

3004.13.4 Dispatchers shall be able to manually enforce a protected transfer to indicate the receiving bus should hold for a longer duration than the base configuration.

3004.13.5 Dispatchers shall be able to release protected transfer(s).

3004.13.6 Transfer notification between bus and rail. Contractor devices shall provide ability for bus controller to notify rail controller of pending transfers.

3004.14 Configuration Requirements

3004.14.1

The CAD system shall allow for the distribution of work amongst dispatchers by configurable groups of routes, service types, operational function, VID, blocks, routes or trips, with all data associated with a block, or trips on that route being directed to particular dispatchers. The workload assignment shall be such that no active route can remain unassigned. Regardless of route assignments, all dispatchers must have the ability to see and monitor all vehicles in the system at all times.

3004.14.2

The system shall allow messages and incidents to be “routable” and assigned to the appropriate dispatcher based on work assignments and/or time‐based parameters. All follow ups, updates, and related messages for that vehicle or block shall be routed to the same dispatcher and also available for display to all dispatchers. 1. The queues shall be Transit Agency‐configurable and sorted based on priority, user, or workstation. 2. Certain messages, both to and from a vehicle, shall be routable to the desktop application running at the Division from which the vehicle is assigned.

3004.14.3

Garage‐based roles shall provide filtering that includes all of the following: 1. Scheduled blocks by specified Garage, 2. Scheduled personnel by specified Garage, and 3. Assigned vehicles by specified Garage.



82

3000


3004.14.4

The following types of vehicle status shall be flagged as exceptions, through the use of a different color or other means. They shall also trigger an alert directed to the dispatchers: 1. Behind schedule by a Transit Agency‐configurable period, 2. Running early by a Transit Agency‐configurable period, 3. Not logged in, 4. Off‐route by a Transit Agency‐configurable distance, 5. Emergency/panic alarm activated, 6. Late pull‐out by a Transit Agency‐configurable period, and 7. Leaving a layover by a Transit Agency‐configurable period.

3004.14.5

System shall allow Transit Agency configuration of map icons (color and/or base icon), so that the following operational conditions can be easily seen on the map display:

1. All conditions from prior requirement above,

2. Layover, and/or ignition off,

3. Extra Service,

4. Special Events,

5. Non‐Revenue scheduled trips (pull In, pull out, deadhead, training, etc.), and

6. Non‐Revenue unscheduled trips (road trades, etc.).

3004.14.6

Dispatchers shall have an option to query a list of all vehicle Operators currently driving a route, including at least the following information: 1. Operator name; 2. Operator Status such as: full time, part time, regular, regular relief, extra board, vacation relief; 3. Employee number; 4. Route number; 5. Vehicle number; 6. Trip number; 7. Home Division; 8. Time vehicle departed base; 9. Time Operator due back to base; and 10. Whether the Operator is returning the vehicle to base or being relieved in the field.

3004.14.7 The CAD system shall allow dispatchers to add, delete, or temporarily replace/reassign Operators by vehicle and block. Operator assignments shall be automatically updated as Operators sign‐in/out of their vehicle’s MDTs.

3004.14.8 The CAD system shall allow dispatchers to view vehicle details such as vehicle type, make/model, Division assignment, route assignment, schedule adherence, block/trip, VID number, and run number.



83

3000


3004.14.9

Schedule adherence shall be visible to the dispatcher system wide (by geographic area, by route, or by severity of schedule deviation) via a minimum of these methods: 1. Color or style of vehicle icons displayed in the map display, 2. List or table of vehicles noting schedule adherence, 3. List or route diagram noting schedule adherence by vehicle on that route, 4. System wide summary of schedule adherence by route, 5. Block list of schedule adherence in tabular format, and 6. Route that is flagged in the message queue that is having overall schedule adherence problems.

3004.14.10 Dispatchers shall have the option to see a list of routes and/or vehicles that are currently affected by a detour in time order by the next affected vehicle in one (1) or both directions.

3004.14.11 Based on data reported by vehicles to central, a tabular list of vehicles and causes for late arrivals at time points will be displayed. This data shall also be stored to the central system database for reporting purposes.

3004.14.12 When a dispatcher selects a block, CAD system shall provide quick access (pull down menu, quick keys, etc.) to other information, including: paddle (block schedule), headways, relief points, Operator status (regular relief, extra board, mini‐run, etc.).

3004.15 Dispatch Service Adjustment Functions

3004.15.1

The CAD system shall include functionality for adjustments to service including as a minimum: 1. Modifications to time points to support service adjustments such as detours, alternate routes, etc.; 2. Cancel or add blocks/trips; 3. Adjust for temporary detours; and 4. Reassign or remove vehicles from certain routes or blocks (e.g. may be required by a mechanical issue or bus bridge).

3004.15.2

The system shall include management for a series of standard service restoration/correction functions including:

1. Detour: Activate predefined detours for service routes.

2. Ad‐hoc Detour: Create short term detours for accidents/incidents and events.

3. Delete/Add a Trip: Delete or add trip to a block to adjust service levels.

4. Replace a Vehicle/Operator: Assign a replacement vehicle and/or Operator to take over service from a scheduled block that cannot continue for any reason.

5. Skip Stop: Notify an Operator to bypass a series of stops to restore headways, with the ability to identify and log the starting and stopping point for the skip stop measure.

6. Initiate headway management instead of schedules. The headway mode will automatically evenly distribute the vehicles on the route. This function shall communicate the revised “schedule adherence” to all affected vehicles.



84

3000


3004.15.3 The CAD system shall be capable of displaying adjusted timed transfer points, RDTs, vehicles, and routes/trips. Adjusted information will be available for real‐time data feed.

3004.15.4 Dispatch shall be able to transmit detour directions/instructions for buses to any vehicle/resource in the field.

3004.15.5 All dispatch service adjustments shall be logged and disseminated to the Transit Agency Customer Service and other staff. Information dissemination triggers, timing, and staff to be contacted will be configurable by Transit Agency.

3004.15.6 For all dispatcher service adjustments, lost service miles and hours shall be calculated and stored by CAD for later reporting. Lost service and miles shall be displayed to dispatch.

3004.15.7 The CAD system shall include functionality for the display of multiple screens from multiple dispatch workstations on a large screen or video wall display.

3004.15.8 System shall store all detours for future use. These may be deleted by the System Administrator, if the detour is determined to be undesirable.

3004.15.9 CAD shall be able to suggest the number of vehicles necessary to maintain a given headway identified by Dispatchers.

3004.15.10

CAD shall highlight detours and allow dispatchers to highlight and save a graphic/map view of the detour to be forwarded to: 1. MDTs 2. Customer service and other users via e‐mail and fax.

3005 AUTOMATED STOP ANNUNCIATION (ASA)

3005.1 ASA Functional Requirements

3005.1.1 All current ASA central management functions and capabilities shall be maintained, and no functions shall be removed or rescinded without the prior consent of the Transit Agency.

3005.1.2 Contractor shall supply the latest and highest functionality ASA management systems and software they have developed to date.

3005.1.3 The central processing system shall be used to generate and manage next stop, customer and other announcements, manage device configuration, generate reports, and manage device fault reporting and logs. The ASA system will meet or exceed the requirements of the United States Access Board.

3005.1.4 The system shall include functionality to import route and stop data from an external system via Transit Agency file(s) (e.g. Comma Separated Value, tab delimited, etc.).

3005.1.5 The ASA central processing system shall include tools to manage announcements in batch (e.g. change header data in the messages) without a user having to change each message individually.



85

3000


3005.1.6

The ASA shall include the capability of announcing all stops, or selectively announcing stops (e.g., major intersections, landmarks, transfer points, etc.). Distance, time or geographic triggers for announcements will be completely configurable by Transit Agency for any announcement. Stops to be announced shall be set through configuration data managed by Transit Agency at the central system.

3005.1.7 The ASA central processing system shall include the ability to add announcements for any intersection, location or landmark desired.

3005.1.8 Only one (1) next stop message per stop shall be required. However the system must support the activation of time‐based messages (e.g. public service announcements) that will be played/displayed at a lower priority.

3005.1.9

The content of audio and visual next stop announcement messages shall be Transit Agency configurable from the central system, and shall include the ability to announce message types including, but not limited to: 1. Cross‐street only, 2. Current street and cross‐street (e.g. “<EXAMPLE CURRENT STREET AND CROSS‐STREET>”), 3. Landmark, 4. Transfer opportunities, 5. Bus Stop Name, and 6. Service announcements.

3005.1.10 The system shall include the ability for Transit Agency to independently configure audio and text messages associated with a specific stop.

3005.1.11 The system shall provide a minimum of two languages. English shall be the primary language, with the secondary language to be determined by the Transit Agency.

3005.1.12

Through configuration data, it shall be possible for the system to make, on a route by route basis, audio announcements as follows: 1. Language 1 (English) only. 2. Language 2 only. 3. Both languages 1 and 2 (first one, then the other in sequence).

3005.1.13 Audio messages shall be either synthesized or recorded voice. Recorded voice files shall be exchanged (import and export) with other central systems in either .MP3 or .WAV format.

3005.1.14 The ASA system shall be able to mix synthesized and recorded segments, for future audio messages.

3005.1.15 The ASA system speech engine shall be a modular component that will allow the Transit Agency to replace it at a later date without changes to the central CAD system.

3005.1.16 The system shall provide for any combination of male and female voice announcements, settable through configuration data or voice recording.

3005.1.17 Synthesized voices (if used) shall have a natural tone, timbre and cadence comparable to human spoken sentences.



86

3000


3005.1.18 The system shall allow designations such as “Southwest,” “South,” and “street” to be truncated in the configuration data (e.g. “W Jefferson St” instead of “West Jefferson Street”), but annunciated as complete words.

3005.1.19 The system shall be Transit Agency configurable so that external announcements may be set for activation any route.

3005.1.20

The content of the external announcements shall be configurable by Transit Agency to include some or all of the following: 1. Route number. 2. Route name. 3. Destination. 4. Direction. 5. Branch. 6. Route Type (e.g. Express, Limited)

3005.1.21 Dispatchers shall be able to assign pre‐determined or ad‐hoc modes of operation (e.g. drop off only or skip stop), which will modify the announcement to be made, such as; “This bus is full and only available for drop off. Please wait for the next available bus.”

3005.1.22 The system shall be Transit Agency configurable so that external announcements can be made less frequently, only at specified stops or not at all. In addition, the system must allow specific volume levels to be determined for individual stops, times of day and/or sections of routes.

3005.1.23 The system shall be able to repeat external announcements at any or all stops by a time configurable by Transit Agency without Operator interaction. Intervals shall be a minimum of 30 seconds.

3005.1.24

The database of announcement messages shall associate a table of stops and message data for each Transit Agency route.

1. The system shall accept incremental updates of on‐board message data on an as‐needed basis.

2. The user interface for entry/deletion/modification of messages shall be easy to use, and shall associate all messages with a route.

3. The system shall accept the addition, deletion, or movement (from one route to another) of stop data.

4. The database shall support direct SQL interfaces.

5. Each message shall have a unique identifier, defined by the Transit Agency.

6. The central system shall include look‐up tables to associate data or messages entered through the workstation with the message identifier.

7. Creation or deletion of a message shall not change the identifiers of the other messages.

8. Provisions shall be included to rebuild the message database and identifiers on a periodic basis (e.g. after there have been a significant number of message additions and deletions).

3005.1.25 The system shall provide an easy‐to‐use means to record and/or generate announcement audio and to define route‐stop structures.



87

3000


3005.1.26 The system shall use a commercial off‐the‐shelf reporting utility capable of producing standardized or regular reports, as well as custom reports. The utility shall include ASCII and XML export capabilities.

3005.1.27 The system shall be installed on a desktop PC and/or server supplied by the Transit Agency, accessible by multiple clients or workstations, and configured with required hardware and operating system software.

3006 DESKTOP DISPLAY WEB APPLICATION

3006.1.1 The CAD system shall include a desktop display system that allows any authorized user within Transit Agency to have read/view/query/report access to the fixed route dispatch displays, using a system allowing web browser based accessed.

3006.1.2 The number of users accessing the desktop display shall not be restricted by software or application licenses related to the CAD/AVL software or Contractor.

3006.1.3

The read/view/query functions shall operate the same as, or materially similar to, those features on the dispatch workstations. Users shall have the capability to select routes, groups of routes, route patterns, specific trips and geographic areas to directly view the operation and performance of vehicles on those routes.

3006.1.4 The desktop display web application shall allow users with appropriate permissions to create and/or edit incidents. All incident modifications or creations shall be logged by the central server and available to all users (CAD, RDT and Desktop application users).

3006.1.5 The Desktop Display web application shall include the following functionality: 1. AVL Playback (includes location reports and schedule adherence data). 2. Ability to access real‐time data such as performance data, incidents, etc.

3006.1.6 Filters shall be provided to filter out certain information (e.g. Operator information) from specific users, based on their level of access. A minimum five (5) Transit Agency‐configurable levels of access shall be provided.

3006.1.7 The desktop display system shall also include “dashboard” presentation of route or system performance including schedule and headway performance.

3006.1.8

Contractor shall provide the following two (2) levels of licenses for the CAD web‐based desktop display application: 1. Almost complete CAD functionality, except for radio call setup (individual licensing); and 2. AVL playback, reporting, and incident entry (unlimited or group licensing).

3006.1.9 All licenses shall be transferrable between computers and/or Transit Agency staff.

3006.1.10 During design review, Contractor shall identify whether the functionality can be provided on existing Transit Agencies’ desktop computers (on the Transit Agency corporate LAN), or whether separate workstations are required.

3006.1.11 Contractor shall use Transit Agency’s authentication database for login, to minimize the need for additional user names or passwords.



88

3000


3006.1.12 The CAD system shall allow for integration of the web based functionality into a Transit Agency website through a web frame.

3006.1.13 The CAD web‐based view shall allow for personalization through a Transit Agency‐customized look and feel.

3006.1.14 The CAD web‐based view shall allow for personalization of the web menus based on user authenticated credentials.

3007 PORTABLE RADIO TRACKING

3007.1.1 The CAD system shall be configured to allow customized filtering of portable radios by preconfigured groups (e.g. customer service, fare technicians, supervisors, etc.) tracked by real‐time GPS coordinates.

3007.1.2 The CAD system shall allow tracking of RDTs based on GPS positions provided from those devices to the central system over commercial cellular.

3008 REAL‐TIME PASSENGER INFORMATION (RTPI)

3008.1.1

The system shall include the capability to generate and disseminate real‐time transit traveler information via Transit Agency‐owned infrastructure, web and mobile services, and third‐party applications through a standard interface. The system shall include the capability to accept unique trip IDs per schedule.

3008.1.2

The system shall support real‐time traveler information dissemination through the following platforms and technologies: 1. Information Display Signs at the major terminals, and other future high‐ridership locations such as Park and Ride lots and shelters 2. Website Application, integrated into Transit Agency’s existing website 3. Mobile Web Application, accessible through a mobile internet browser and tailored for display in a mobile format 4. Telephone Traveler Information using keypad and Interactive Voice Response technology to provide both scheduled and real‐time information 5. SMS Text Messaging pushed out of the CAD/AVL system 6. Subscription Rider Alerts pushed out of the CAD/AVL system using RSS 7. Trip Planner Integration – Provision of real‐time arrival information for trips requested by the customer, through a new trip planning application or integration with Transit Agency’s existing trip planning system. 8. Third‐Party Development Portal/Application Support – Including Google Transit™ schedule and real‐time data feeds and customer web/mobile applications, via data replication to a third‐party development portal.

3008.1.3

The system shall update real‐time arrival predictions and generate service alerts based upon real time service adjustments and measures implemented by dispatch, including: 1. Cancelled Service, 2. Detours (planned and ad hoc), 3. Weather/Conditions‐based reroutes (resulting in curtailed service or un‐served stops), and 4. Additional of supplemental service (‘trippers’) in addition to scheduled trips.



89

3000


3008.1.4

The system shall automatically generate and implement real‐time arrival information adjustmentsand service alerts based on real‐time service conditions and dispatch measures. At no time shall information presented through the real‐time passenger information system contradict actual expected service based on real‐time conditions.

3008.1.5

Under no circumstances shall the system display real‐time arrival information for a service that will not serve the location of the customer (stop ID requested or sign location) due to real‐time service adjustment, detour, cancelled trip, or other real‐time conditions or dispatch service measures.

3008.1.6 Real‐time arrival predictions for services operated under headway management mode shall report predicted arrival times based on actual arrivals rather than scheduled arrivals.

3008.1.7 When real‐time arrival information is displayed at a specific stop, or requested for a specific stop ID, any active service measures affecting that location, or a route serving that location (detours, skipped stop, etc.) shall be provided to the rider.

3008.1.8 The system shall provide stop‐level information to customers via web applications and mobile applications when a customer enters a stop’s unique stop ID.

3008.1.9

The system shall include the ability to generate automated and ad hoc data feeds disseminated using Transit Agency’s existing RSS subscription service. The system shall allow for message dissemination based on Transit Agency‐defined groups, including at a minimum stop ID, route, and system‐wide service alerts.

3008.1.10

The system shall include the ability to export real‐time stop information to third‐party traveler information systems through a web‐based development portal. The development portal shall be hosted on the Transit Agency Enterprise network, accepting real‐time information from the CAD/AVL database on a continuous basis.

3008.1.11 The system shall support export of real‐time traveler information to Google™ Transit using the General Transit Real‐Time Feed Specification.

3008.1.12

The system shall include the capability to link and display service status messages to real‐time bus arrival information requests. Service status messages may include: 1. Real‐time service alerts (detours, cancellations, special service routes, etc.). 2. Pre‐scheduled event information or notices.

3008.1.13 All traveler information systems shall be compliant with ADA requirements, including but not limited to audible announcements, web accessibility, and text to speech capability, as applicable to the application in question.



90

3000


3008.1.14

Real‐time vehicle arrival information shall include the ability to configure and display stop‐level real‐time information in the following states: 1. Estimated bus arrival countdown time in minutes, for vehicles within a threshold arrival time (e.g. 15 minutes). 2. Estimated bus arrival time (HH:MM format) for bus arrivals over the threshold arrival time. 3. Display of a “Due” message for vehicles within a configurable threshold of estimated arrival (e.g. “Due”). 4. Scheduled bus arrival time for vehicles that are not yet in service or for which real‐time location/arrival information is not available. 5. “Delayed” or similar if a vehicle in revenue service has remained stationary for a configurable period of time. 6. Display of “Unavailable” or similar message when the location and/or arrival of a service cannot be confirmed. The system shall include an additional field that compares bus schedule to real‐time information and displays if bus is on time, late, or no information is available.

3008.1.15

The system shall support Information Display Signs at Transit Agency facilities shall support the following formats: 1. Schedule Display: LED‐screen display of vehicle arrivals at major terminals including route number, route name/destination, estimated/scheduled departure time, and status indications of routes (delayed, cancelled, etc.). These displays shall also support the ability to display general service alerts, e.g. through a scrolling text band. 2. Departure Boards: Curbside display of departure information for next departures within a configurable timeframe (e.g. 30 minutes) at major terminals. Information on the signs shall include but may not be limited to route number, route name/destination, estimated or scheduled departure time, and departure location (loading bay number). 3. Loading Bay Identifiers: Curbside display at each loading bay indicating the next departure at that location. Signs shall include route number, route name/destination, and estimated or scheduled departure time specific to that loading bay. 4. Bus Shelter Displays: Exterior‐type display suitable for mounting in a bus shelter or similar location. Signs shall include route number, route name/destination, and estimated or scheduled departure time.

3008.1.16

The System shall support the following real‐time information conditions at major terminals, and similarly configured passenger facilities:

1. Display of real‐time estimated and scheduled departure for vehicles approaching the facility, when the inbound vehicle is operating on or ahead of schedule

2. Display of real‐time estimated departure times based on the estimated arrival times of the inbound vehicle, when the inbound vehicle is operating behind schedule.

3008.1.17

To avoid customer confusion when arriving vehicles continue as a different, interlined route or are existing revenue service, the System shall support the automatic update of on‐board passenger information signs and the deck sign at a configurable trigger point prior to arrival at the passenger facility. When this trigger point is reached, the system shall display information for the continuing service, or the appropriate out of service message.



91

3000


3008.1.18 Information Display Signs shall be designed for interior or exterior use depending upon conditions at the installation location.

3008.1.19 Arrival information shall be displayed for all services in route (i.e. not cancelled or detoured).

3008.1.20

The system shall not display real‐time bus arrival information under the following conditions: 1. When the service has been cancelled, and 2. When the requested location will not serve the stop/location in question due to service adjustment, detour, or stop closure.

3008.1.21 The system shall be configurable to display real‐time arrival or departure information, depending on location context (e.g. intermodal center, end of route, mid‐line stop), schedule dwell time, and/or real‐time service status).

3008.1.22 When scheduled rather than real‐time information is displayed, the system shall have the capability to indicate that the display time is scheduled time rather than estimated time (e.g. through the use of an asterisk after the arrival time).

3008.1.23 Service status messages shall be configurable by stop, route/service, or system wide.

3008.1.24 The system shall have the ability to implement ad hoc or pre‐planned stop closure service status messages when a customer requests information for a stop that is currently or scheduled to be out of service due to detours, construction, etc.

3008.1.25 The system shall include the ability to select from a library of pre‐planned service alert messages, and/or create ad‐hoc messages. Ad hoc message generation shall take into consideration the display capabilities limitations of traveler information media.

3008.1.26 The system shall include the ability to set event start and end times (effective time) for service alerts through Transit Agency central dispatch.

3008.1.27

Real‐time arrival information and scheduled, effective, and historical service alerts shall be accessible to all Transit Agency system users (including but not limited to dispatch, field supervisors, customer service, planning, and administrative staff) through a common interface platform.

3008.1.28 The system shall have the ability to assign permissions to create, edit, or delete scheduled service alerts based upon user type or unique user ID.

3008.1.29

The system shall provide a web services‐based mechanism to publish Transit Agency real‐time passenger information, for current fixed route schedules as well as real‐time dispatch actions and status data, as the data becomes available to the central system. The real‐time status data provided shall include location and schedule adherence for all vehicles, as well as predicted arrival/departure times for each vehicle at each downstream stop for its block. Latency between data becoming available to the central system and being published to the web service shall not exceed five (5) seconds.

3009 SUMMARY KPI AND PERFORMANCE TOOLS DISPLAYS

3009.1.1 The CAD system shall provide a summary BI tool with a series of displays to be developed through a series of two workshop meetings between Contractor and the Transit Agency.



92

3000


3009.1.2

There shall be up to five standard displays that are developed through the following process:

1. Contractor meets with Transit Agency to assess data types, capabilities of the BI tools, and desired KPIs to be displayed.

2. Contractor develops mock‐ups of BI displays for review and comment.

3. Contractor finalizes BI displays for testing.

4. Transit Agency provides final comments following pilot fleet data.

5. Contractor finalizes BI displays for operations.

3009.1.3 BI displays shall be available through web/Internet access to any authorized user with up to 35 simultaneous users.

3009.1.4

BI displays shall summary data and statistics on: 1. Day‐snapshots by Transit Agency and garage: ‐ Late and missed trips with causes. ‐ On‐time performance with causes for delays beyond a certain threshold. ‐ Service miles lost and total service miles. ‐ Hours lost and total service hours. 2. Monthly‐snapshots by Transit Agency and garage: ‐ Late and missed trips with causes. ‐ On‐time performance with causes for delays beyond a certain threshold, as well as trends month over month. ‐ Service miles lost and total service miles, as well as trends month over month. ‐ Hours lost and total service hours, as well as trends month over month. ‐ Average daily boardings per APC.

3009.1.5 BI displays shall be provided in a flexible tool that can be amended and updated by the Transit Agency.

3009.1.6 BI display may also contain additional summaries of contracted Operator metrics.

4000

DATA REQUIREMENTS AND REPORTING

4001 REQUIRED CONTRACTOR‐PROVIDED REPORTS

4001.1.1 Contractor shall allow parameters to be dynamic and configurable by the Transit Agency system administrator.

4001.1.2

System shall be able to support the Transit Agency with maintaining standard FTA and management level reporting during cutover or system replacement (i.e. moving from one system to the other system) that are configurable, manageable and executable by the Transit Agency and doesn't require Contractor interaction.



93

4000


4001.1.3 The System software suite shall include reporting capabilities to generate both standard reports based on pre‐established criteria, as well as customized reports based on user‐definable set of search criteria. Drawing upon data contained within the systems databases.

4001.1.4

At a minimum, the CAD system shall provide the following reporting capabilities and reports shall be exportable per Transit Agency requirements: 1. Daily Operations Summary Report, 2. Daily Pull‐Out Performance Report, 3. Nightly Pull‐In Service Report, 4. Schedule Adherence Report, 5. Ridership and Passenger Loading, 6. Detours and Service Corrections, 7. Incident Reports (all incident types, with filters), 8. Incident Reports (specific incident), 9. Automated Event Logs, 10. System Maintenance and Health Status Reports, and 11. System Configuration Logs.

4001.1.5

Reports shall be configurable and filterable based upon common criteria in the transit industry, including: 1. System wide service reports, 2. Temporal (time window, day, week, month, quarter, year, multiple years), 3. By Service (route, run, block, stop), 4. By Operator ID, 5. By VID, 6. By agency, 7. By Controller (dispatcher), 8. By workstation, 9. By hour, 10. By transit day versus calendar day, 11. By garage, 12. By provider, and 13. By Facility.

4001.1.6 Reports shall be configured to reflect common Transit Agency‐defined reporting requirements and NTD reporting requirements.

4001.1.7 Reports shall be formatted and tailored to the requirements and data resolution of the targeted system user (e.g. planning, system administration, operations, maintenance, etc.). The system shall provide options for summary, detail, graphs, and detailed data.

4001.1.8

The CAD system shall track basic dispatch/supervisor performance statistics by dispatch workstation, dispatcher work assignment, and user log‐in, including:

1. Individual and average time from RTT or PRTT to dispatcher initiated communications, 2. Service measures implemented by type of measure, 3. Incidents created, duration the incident was open, and number of incidents closed, 4. Number of average vehicles and routes active, and 5. Duration of log‐on.



94

4000


4001.1.9 Dispatch performance statistics shall be automatically reported by the system and made available to the Dispatch Supervisor as summary reports by day of week, week of month and month of year.

4001.1.10 Within the standard reports, functionality shall be included to generate reports based on user specified start date and end dates and event information, as well as fault and maintenance reports.

4001.1.11 Use of the reporting functions shall be via a user interface supplied by Contractor and shall not require prior knowledge of databases and query methods.

4001.1.12 Reports shall include the date generated and the system user ID of the report generator.

4001.1.13 The System‐generated reports shall be formatted and print‐ready.

4001.1.14 The System‐generated reports shall be exportable to standard, non‐proprietary formats (e.g. Portable Document Format (.PDF), MS Word (.DOC or .DOCX), Rich Text Formal (.RTF), Extensible Mark‐up Language (XML), and comma‐separated value file format).

4001.1.15

For Contractor reports, parameters defining data shall be configurable by Transit Agency personnel each time the report is generated and report parameter configuration shall be able to be saved by Transit Agency personnel, for future reports. Transit Agency shall be able to develop new reports without the aid of Contractor.

4001.1.16 The CAD/AVL system shall partition large tables to allow faster reporting and improved reporting performance.

4001.1.17 The CAD/AVL system shall offer telematics canned reporting (e.g. idle time, fuel level, fluid levels, J1939 components). The CAD/AVL system shall offer subsystem canned reporting to include in‐vehicle components such as: Radio, Exterior Heads, GPS, Wheelchair, Internal Sign, and Headset.

4001.1.18 All Contractor‐provided reports shall be fully modifiable including SQL source‐code editing with ability to revert to original.

4001.1.19 All reports shall be modifiable and show full source code. They shall not be dependent upon the CAD/AVL application (e.g. parameters from CAD/AVL passed into reports).

4002 CENTRAL SYSTEM DATA FOR TRANSIT AGENCY‐GENERATED REPORTS

4002.1.1

Transit Agency shall be the owner of all system data. Transit Agency and third parties designated by Transit Agency in the future shall have the right to perpetual and royalty‐free access to all data views and web service published data. This access shall be for internal use by Transit Agency (e.g., importing the data into Transit Agency historical databases) as well as for integration with future external parties designated by Transit Agency (e.g., to enable the dissemination of real‐time information for Transit Agency customers, using Dynamic Message Signs (DMS) at selected locations and other methods, sharing data with other public agencies). To enable Transit Agency data queries, Contractor shall provide a Data dictionary and Entity Relationship Diagram (ERD) for all data views as well as the format and structure for data made available via a web service (e.g., XML feed schema).



95

4000


4002.1.2

The CAD/AVL system shall provide sufficient data as approved by Transit Agency in the design review process – which Transit Agency will own and have access to – to enable the following required Transit Agency reporting:

1. Trip Stop Summary;

2. Run Trip Analysis;

3. Performance Studies;

4. Service Supplied Statistics;

5. Scheduled vehicle revenue hours and revenue miles;

6. Actual vehicle revenue hours and revenue miles;

7. Lost vehicle revenue hours and revenue miles;

8. Actual vehicle hours and miles, for all revenue and non‐revenue trips, the latter of which includes pull‐in, pull‐out and deadhead trips;

9. Service Consumed Statistics;

10. Passenger‐miles (for vehicles with APC);

11. Unlinked passenger trips;

12. Deadheads;

13. Pull‐out/Pull‐in & Interlining deadheads;

14. Branch: several branches of one schedule, a collection of patterns;

15. Non‐typical vs. typical day. Transit Agency does not want to use non‐typical days (particularly snow days) for performance reporting. So non‐typical days can flagged;

16. Free running time (stored as "special points" in each route.); and

17. The system shall provide access to Transit Agency to update parameters for password aging and include in admin audit report a filter for time frame configurable by any value, (30 , 45, 60, 90 days, etc.).

4002.1.3

The system shall also provide data to run the following reports including, but not limited to: 1. Stop‐, trip‐, pattern‐, branch‐ and route‐level boardings and alightings by location, specifying timestamp, trip number, and latitude/longitude for stop‐level boardings; 2. Run times and stop‐ and segment‐level load counts by trip; 3. Schedule performance exceptions; 4. Headway exceptions; 5. Transfer coordination performance (including between bus and rail modes); 6. Stops passed with no passenger activity on each trip; 7. Time vehicle is not moving between scheduled stops (e.g. stop lights); 8. Missed trips, including: time of missed trip, in‐service miles and hours lost, and the cause of the missed trip; 9. Vehicles operating off‐route in the absence of a prescribed detour; 10. Accidents, incidents, and mechanical failures;



96

4000


11. Platform hours, including in‐service, loading, and layover hours;12. In‐service hours, including revenue hours, loading, and layover hours; 13. Trip‐level passenger‐miles, schedule recovery time, and schedule deviation (on‐time performance); and 14. Cumulative stop‐to‐stop and total trip‐level mileage for revenue trips.

4002.1.4

The parameters defining an “exception” (minutes early or late, minimum and maximum interval between vehicles) shall be configurable by Transit Agency personnel each time the report is generated and report parameter configuration shall be able to be saved by Transit Agency personnel, for future reports. The system shall be able to save multiple configuration sets. Transit Agency shall be able to develop new reports without the aid of Contractor.

4002.1.5

Off‐route exception data shall include, at minimum: 1. VID, Operator ID, and Block ID; 2. Data for both the off‐route‐begin and off‐route‐end locations shall include: Date/Time, Coordinates, Nearest scheduled stop ID, Block trip number, Route number, Route Pattern; 3. Route mileage missed while off‐route; and 4. Bus stop locations missed while off‐route.

4002.1.6 Transit Agency shall have the ability to identify specific streets to query if a bus was off route on that street.

4002.1.7 Transit Agency shall have the ability to query off‐route exception data by ranges of dates/times, day of week, route, route pattern and trip number, vehicle Operator, etc.

4002.1.8 The System shall provide all users with the ability to generate standard pre‐formatted reports on accidents, incidents, and mechanical failures. The details of these reports shall be approved by Transit Agency as part of the design review process.

4002.1.9

Accident, incident, and mechanical failure data shall include at a minimum: 1. Route, route pattern number and, linegroup and block number; 2. Location (nearest stop or intersection); 3. Service (weekend, Saturday, Sunday, holiday, etc.); 4. Date and time of incident; 5. Type of incident; 6. Vehicle Operator ID; 7. Vehicle number; 8. Original Dispatcher ID; 9. Subsequent Dispatcher ID; 10. Original trip; and 11.Active maintenance codes at the time of the incident (on the J1939/J1708).

4002.1.10

The System shall include the ability to record actual vehicle pull out times compared to the block scheduled pull out time, and actual vehicle pull in time (at the end of the block) compared to the block scheduled pull in time. The System shall also document and be able to query by vehicle number, assigned route/route pattern number, linegroup and block number, and vehicle Operator name and run linked to the record of pull out and pull in times.



97

4000


4002.1.11

The CAD system shall provide Operator data (set by start/end dates) to summarize: 1. Operator assignments, 2. Vehicle assignments, 3. Block/route/route pattern and trip assignments, 4. Any incidents and incident types, and 5. On time schedule performance.

4002.1.12

The CAD system shall provide individual vehicle data (set by start/end dates) to summarize: 1. Vehicle assignment, 2. Mechanical failures, 3. Block/run/route/route pattern/trip assignments, 4. Any incidents and incident types, and 5. Linegroup and block number within a time period or date range or both.

4002.1.13

The CAD system shall provide performance data that summarize on time performance by: 1. Block, route, branch, route pattern and trip; 2. Operator; 3. Geographic sub area; 4. Time of day, day of week, month of year, service or calendar day, and schedule type (e.g. weekday, Saturday, Sunday, holiday); and 5. Stop, transit center, or other specific locations, including time points not located at stops or transit centers.

4002.1.14

The CAD system shall log and summarize communications activities and interruptions between the CAD system and the vehicles for reporting purposes. Statistics shall be sufficiently disaggregated to calculate for every CAD defined vehicle, even if the vehicle was powered off, and include but not be limited to: 1. Hourly vehicle data, Total transmitted messages to vehicle, Total retransmitted messages to vehicle (due to no vehicle acknowledgement or vehicle request for re‐transmit), Total received messages from vehicle, Time of first received message from vehicle per operational day, time of last received message from vehicle per operational day; 2. Hourly system data, Total transmitted messages to vehicles, Total retransmitted messages to vehicles (due to no vehicle acknowledgement or vehicle request for retransmit), Total received messages from vehicles; and 3. Log every occurrence of fallback (vehicle data radio not communicating with dispatch). This data shall include: VID, begin date/time, last known location before fallback begin, end date/time, end location.

4002.1.15

The System shall provide the ability for all CAD users with Workstations, RDA or Desktop Web Application to “replay” stored CAD/AVL data. Replay shall include ability to select and replay multiple vehicles, groups of GPS‐enabled devices, single or multiple routes simultaneously and shall provide all status, incident reports, and location data associated with the vehicles and GPS‐enabled devices for the replay period.

4002.1.16 The system shall record the departure and arrival times, difference between scheduled and actual arrival/departure, of all trips departing or arriving at divisions and layover points.



98

4000


4002.1.17 Information (data) that is entered into the system shall be easily queried. Data shall be available for query for a minimum of 365 days, without loading archived data.

4002.1.18 Contractor shall develop a Database query performance test which will be reviewed and approved by Transit Agency.

4002.1.19

CAD shall track basic performance statistics by dispatch workstation, dispatcher work assignment, and user log‐in, including: 1. Individual and average time from RTT or PRTT to dispatcher initiated communications; 2. Number of service measures implemented by type of measure; 3. Number of incidents created, duration the incident was open, and number of incidents closed; 4. Number of average vehicles and routes active; and 5. Duration of log‐in.

4002.1.20 Dispatch performance statistics shall be automatically reported by the system and made available to the Transit Agency personnel as summary reports by runboard, day of week, week of month, and month of year.

4002.1.21 The System shall provide real‐time access to location and schedule adherence data. This data shall be continuously updated whenever updated data is received from the fleet. Contractor shall provide a data dictionary and Entity Relationship Diagram for this data.

4002.1.22 The CAD/AVL system shall provide on‐board components software status to include data specified by Transit Agency. This data should be available on demand.

4002.1.23 The central system shall store all of the APC data uploaded from vehicles, to enable Transit Agency to continue its current practice of generating APC data analysis reports.

4003 DATA INTEGRATION REQUIREMENTS

4003.1.1 All data interfaces will be retained, replaced, or improved by coordinated cooperative efforts with Public Transit IT and using ICDs prepared and approved in advance.

4003.1.2 The System shall provide for the import of stop and route mapping data using common or industry standard file formats and Transit Agency standard formats.

4003.1.3 The system shall accept schedule, stop, and Operator information through integration with Transit Agency's scheduling system.

4003.1.4

Geographic Information System (GIS) design shall be designed with ease of configuration and maintenance in mind, e.g. ease of updating the base map to reflect roadway configuration changes. System shall use current versions of any third‐party GIS application used for map viewing or updating.

4003.1.5 The system shall accept Transit Agency‐defined restrictions or parameters on GIS mapping data (e.g. roadway segments not suited for vehicle detours).

4003.1.6 The system shall support export of vehicle pull‐in and pull‐out information, for purposes of updating yard management parking status in real time during the service day.

4003.1.7 The system shall support export of actual service performed (as opposed to scheduled service), by Operator ID to scheduling for purposes of payroll reconciliation.



99

4000


4003.1.8 This system shall not require multiple GIS files or layers including redundant information to support the CAD/AVL system or other priced options (e.g. stop/timepoint IDs schema shall support all CAD applications including ASA, TSP, etc.).

4003.1.9 The system shall be able to export CAD/AVL database information to a Transit Agency Enterprise database for business intelligence, data analysis, and reporting using third‐party applications (e.g. Crystal Reports, BI applications) that combine data from multiple enterprise applications.

4003.1.10 To the fullest extent possible, the system shall utilize open standards and industry protocols to enable data export or integration with future Transit Agency‐developed or third‐party applications (e.g. mobile phone or social media applications).

4003.1.11

The CAD system shall provide the following reporting capabilities and be exportable per Transit Agency requirements: ability to export system health/fault notifications and vehicle health/diagnostic data integrated with the VLU to the Transit Agency Enterprise database for purposes of generating work orders in a third‐party maintenance management system.

4003.1.12

System shall include functionality to import and utilize HASTUS scheduling information dynamically (and in accordance with requirement 4002.2.3, incrementally) as needed to update schedule on a daily basis from HASTUS. The system shall be able to read the logic of the .OIG and retrieve the information based on selected booking id then import this information into VMS after a validation has occurred.

4003.1.13

The System shall include a scheduling 'pre‐validation' tool similar to Google Transit Feed‐Validator. The HASTUS Feed‐Validator shall check for sufficient routes, headsigns, descriptions, routes‐to‐stop associations, violation of duplicates, unique trips, and lines. This validator shall run prior to actual schedule loads into Test/Production database to preclude reloads due to errors and warning.

4003.1.14 The CAD/AVL system shall provide stop level data (not just at timing points) for dwell, scheduled arrival, actual arrival and passenger counts that will be imported into Hastus to improve scheduling.

4004 CENTRAL PROCESSING SYSTEM

4004.1 Central Processing System Functional Requirements

4004.1.1 System shall be able to accept location data from GPS enabled sources including, but not limited to, non‐revenue vehicles, mobile and portable radios, and display all resources as distinct layers and icons on the CAD/AVL maps.

4004.1.2 System shall be able to display different GPS‐enabled device subgroups as unique icons and filter which of these subgroups are displayed.

4004.1.3 The system shall include central application software and hardware as required to process AVL data, manage configuration data, manage and log incidents and events, and report diagnostic information.



100

4000


4004.1.4

The central processing system shall use data provided by Transit Agency from existing Transit Agency databases in a Contractor‐specified format, if a comprehensive format exists within Contractor software, or in a mutually agreed upon format (or database views providing access to the data from these existing databases), including the databases for Ellipse, Hastus and the General Transit Data Feed. Transit Agency will provide the CAD data feeds on a schedule, which is mutually agreed upon by Contractor and Transit Agency. The following list of data types are presented as examples and are not meant to be all inclusive: 1. Basic fleet data and information including vehicle type, ID number, make, model, year, license plate number, VIN, and configuration. 2. Other vehicle fleet information such as vehicles currently in revenue service, in for maintenance, in the yard on stand‐by, fleet held in contingency not part of the day to day fleet, and fleet that is in for long term maintenance issues or are no longer usable. 3. Fixed route schedule information, including: routes, route description and variations, stop patterns/sequences, blocks, trips, transfer protection, etc. 4. Schedules and variations for weekdays, Saturday, Sunday, special schedule days, etc. 5. Stop data including: stop name, GPS coordinates, serving routes, transfer points, etc. 6. Operator information, including employee number, name, seniority, status (full time, part time, regular, regular relief, extra board, vacation relief) and date of hire.

4004.1.5 Imports of the data as per the above requirement shall occur as part of an automated procedure with the central processing system checking for files or views in a predetermined directory, or database table, or as a real‐time service (service oriented architecture).

4004.1.6 The ability to force a manual data import shall be provided which can be activated based on permissions.

4004.1.7

The CAD central processing system shall perform a series of internal consistency checks on imported data and shall generate logs and alarms should errors be found or scheduled import is missing with automated e‐mails and warnings to Transit Agency System Administrators. Internal consistency checks will be performed on imported data prior to using the data in active or production modes for the system.

4004.1.8

The central processing system shall provide the following functionality: 1. Manage the communications with all AVL equipped, radios and MGR devices. 2. Import vehicle, schedule and Operator data from existing Transit Agency databases. 3. Create and manage all AVL configuration data. 4. Create diagnostic and system performance reports. 5. Provide a real‐time AVL interface to external systems to provide the location of all AVL equipped vehicles. 6. Process and provide real‐time location and mapping for GPS‐enabled radios/MGR and other devices.

4004.1.9

The AVL map system shall be based on standard digital GIS data provided by the Transit Agency in ESRI‐based GIS map layers. Digital data may include Transit Agency bus routes, other agency bus routes, route‐stop‐sequences, bus stop points, park and ride/transit center locations, park and pool locations, landmarks, depots, LRT/HRT/Commuter Rail and fixed route facilities, street network lines (with attributes), transportation stops and available sand lots for winter conditions. This list is provided as an example and is not intended to be comprehensive.



101

4000


4004.1.10 The AVL shall include functionality to import Transit Agency GIS data at intervals specified and configurable by Transit Agency. Import shall be possible without Contractor assistance

4004.1.11

The AVL stop database shall use Transit Agency’s existing stop identification numbering system as assigned by Transit Agency (at a minimum of six [6] numeric characters per stop). The AVL database shall use Transit Agency’s existing Station database that positions stops (vehicle bays) within a station.

4004.1.12 The central processing system shall be used to generate and manage device configuration, generate reports, and manage device fault reporting and logs.

4004.1.13 The central processing system shall maintain an inventory of all on‐board devices in use, and shall identify devices that have not reported in after a specific time configurable by the Transit Agency.

4004.1.14 The system shall allow for extracting data via standard SQL queries, including ASCII, delimited text file, XML, and RSS.

4004.1.15 The system shall integrate on a real‐time basis with Transit Agency’s maintenance management system to provide service performance and vehicle data, using a view to existing maintenance management databases or direct access to these databases supplied by Transit Agency.

4004.1.16 The system shall allow imports of stop and route mapping data using common or industry standard file formats and Transit Agency standard formats.

4004.1.17 The system shall allow migration to updated versions of hardware and software and operating systems. Contractor shall provide information regarding its plans or policies regarding future software operation system migrations.

4004.1.18 Disk mirroring and other techniques shall be used to minimize loss of data in the event of a storage device failure. Failure of a storage device shall not result in loss of current configuration data.

4004.1.19

The system shall provide a web services‐based mechanism to publish Transit Agency real‐time passenger information, for current fixed route schedules as well as real‐time dispatch actions and status data, as the data becomes available to the central system. The real‐time status data provided shall include location and schedule adherence for all vehicles, as well as predicted arrival/departure times for each vehicle at each downstream stop for its block. Latency between data becoming available to the central system and being published to the web service shall not exceed five (5) seconds.

4004.1.20 The system shall provide API access of fixed route schedules, dispatch actions and real‐time status data for integration with current and future external systems. The intent is to be able to intercept and disseminate communications from the central system to all other processes.

4004.1.21

Any faults or errors that occur during the automatic conversion or transfer of data either within internal subcomponents of the central system, or from external data sources to internal subcomponents, shall be logged and critical operational items automatically emailed to an Transit Agency‐configurable email distribution list.

4004.1.22 The system shall allow for the creation and configuration by Transit Agency of “dummy” vehicle logon IDs by Transit Agency for special and non‐revenue services (e.g. Bus Bridges, extra service, maintenance, and training buses).



102

4000


4004.2 Schedule Data Transfer

4004.2.1 Transit Agency currently uses Hastus as its scheduling software. The CAD/AVL system shall integrate seamlessly with Hastus to allow frequent schedule updates.

4004.2.2

The system shall import schedule data from Hastus. Contractor shall specify file formats necessary to import the schedule into the CAD system. Transit Agency will provide the files in Contractor specified format. Alternatively, Contractor shall develop database views to import data from these systems. Exports shall meet the following requirements:

1. Contractor shall specify and configure the import software into the system. 2. The system shall allow for full or partial updates of schedule information. 3. The system shall only activate schedule transfers when manually initiated or scheduled by a System Administrator, or during Transit Agency‐defined off‐peak hours. 4. Contractor shall be responsible for ensuring all data required by the system for employees, schedules, maps, vehicle maintenance, etc. is properly imported. 5. Contractor shall be responsible for ensuring all necessary network configurations are in place to allow for schedule data transfers to take place. 6. Contractor shall provide the Transit Agency with the ability to test imported data to ensure accuracy before being placed in production. 7. Any failure or translation errors during automatic data transfers shall be immediately and automatically reported via email to a predefined Transit Agency‐configurable email distribution list of Transit Agency staff. In the event of a failure the system shall revert back to the last known good schedule.

4004.2.3 The system shall recognize and support multiple concurrent schedule types per day.

4002.2.4 The system shall accept incremental updates of schedule data on an as‐needed basis.

4004.2.5 Updated and/or new schedules shall be automatically pushed to the fleet on a regular basis, to be configured by Transit Agency.

4002.2.6 System shall allow for both an initial set of scheduling (map, route, stops, schedules) data each quarter (Operator sign‐up), as well subsequent mid‐sign up changes. This may or may not require replacing the initial set of data if exception based data imports are allowed.

4004.2.7 The System shall have the ability to import and utilize both schedule and headway based schedule operational as pre‐defined in the Hastus scheduling system software.

4004.3 Interface Documents

4004.3.1 Contractor shall supply a Data and Message Format Interface Control Document with details of the format and structure of the data and message formats for integration with other systems. Transit Agency shall have full rights to release this information to 3rd party suppliers.

4004.3.2

Contractor shall also supply updated Interface Control Documents for all external interfaces with the CAD system, including: 1. All current and proposed interfaces and integration with Transit Agency’s systems. 2. Interfaces between all integrated vehicle systems. 3. All proposed or required interfaces with existing reporting and management systems. 4. Interface Control Documents (ICDs) for network monitoring and voice radio control.



103

4000


4004.3.3 Contractor shall provide full documentation to importing static schedule, map data, as well as map update processes and procedures for Transit Agency review. Upon content approval, Contractor shall provide one (1) bound hardcopy and one (1) electronic copy.

4004.4 Data Maintenance

4004.4.1

The CAD/AVL System shall provide Transit Agency configurable data management processes such as archival and purging of data from the real‐time or historical database. For example, the retention period for Stop Event data might be defined as 12 months, after which data related to Stop Events, whether in a single table or a group of parent‐child related tables, will then be exported from the historical database, the exported files compressed and stored with their logs in an archive directory. After a successful export and storage, the associated rows will then be deleted from the database tables. Configurable data management processes may include: 1. Variable retention periods dependent upon the category or usage of the data. 2. Scheduled purge routines. 3. Archival of purged data into compressed files or Transit Agency approved database backup.

4004.5 GTFS and GTFS Real Time

4004.5.1 The system shall supply GTFS data and feeds per the current published GTFS and GTFS‐Real Time standards.

4004.5.2 GTFS Real Time feeds shall provide vehicle location, schedule status, and service adjustment information at a minimum of 30 second intervals.

4005 PARATRANSIT INTERFACES

4005.1.1 Data interfaces will be retained, replaced, or improved by coordinated cooperative efforts with CITY’s IT team and using ICDs prepared and approved in advance.

4005.1.2 The system shall interface with the currently deployed version of PASS‐MON to enable paratransit functionality on the paratransit fleet (deployed with the current CAD/AVL system).

4006 TRAPEZE INFO INTERFACES

4006.1.1 Data interfaces will be retained, replaced, or improved by coordinated cooperative efforts with CITY’s IT team and using ICDs prepared and approved in advance.

4006.1.2 The CAD system shall interface with the currently deployed version of TrapezeInfo to enable customer service functions.

4006.1.3 Updates on vehicle status and locations for the TrapezeInfo interface shall be enhanced to every 10 seconds.

5000

GARAGE & YARD COMMUNICATIONS REQUIREMENTS

5000.1.1 Contractor shall meet with the Transit Agency to assess Wi‐Fi coverage for CAD/AVL requirements at the four yards operated by City of Phoenix and two yards operated by RPTA/Tempe.



104

5000


5000.1.2 Contractor shall make recommendations to Transit Agency on necessary adjustments to provide full yard coverage of common areas where buses are parked as part of normal operations.

5000.1.3 Contractor recommendations shall be driven by the requirements stated in this section.

5000.1.4 For consistency of terminology, the term "upload" refers to data from the vehicle to the central system, and "download" refers to data from central to the vehicle. The WLAN equipment will be supplied, installed and configured by Transit Agency.

5000.1.5 Wi‐Fi data transfers on onboard vehicles equipment will occur through the new onboard Mobile Gateway Router (MGR)

5000.1.6 The Mobile Gateway Router (MGR) and Vehicle Logic Unit (VLU) shall include any additional components and software needed to support the garage WLAN bulk data transfer capability defined in this specification.

5000.1.7 Contractor shall recommend wireless AP coverage requirements at all Transit Agency’s garages to enable WLAN connectivity for data exchange between the on‐board VLUs and the central system via bulk data transfer. Contractor will work with Transit Agency’s existing network equipment to the extent possible.

5000.1.8

The WLAN coverage area available for bulk data transfer at the garages shall include the shed/maintenance area where the vehicles are to be parked. Contractor shall review the plans for each garage and design the optimal locations for the APs (including the orientation of antennas) to satisfy all bulk data requirements. The APs shall be located such that the wireless link capacity is an average 54Mbps between each vehicle parked in the coverage area and the central system. Actual data transfer capacity experienced by individual MGRs may be lower dependent on system load and external conditions, but the full average 54Mbps capacity should be available if only a single OBC is connected and there is no WLAN interference. Contractor’s APs shall be capable of 802.11ac.

5000.1.9 The MGR/VLU shall be able to authenticate automatically when the vehicle has entered the WLAN accessible zone and connect via WLAN without manual intervention. The time to detect the data path shall be configurable between 30 seconds and 5 minutes.

5000.1.10 Contractor’s system shall support WLAN IEEE 802.11n and 802.11AC compliant wireless network protocols.

5000.1.11

Contractor’s system shall support strong encryption for wireless authentication and transmission by supporting industry best practices. The current industry standard for wireless encryption protocol is Wi‐Fi Protected Access (WPA) and Wi‐Fi Protected Access II (WPA2). An industry equivalent or better security protocol to (WPA) and (WPA2) is acceptable as long it meets all other Wi‐Fi requirements specified in this Contract.

5000.1.12

The APs supplied by Transit Agency support 5.0 GHz frequencies. The APs are capable of supporting multiple Service Set IDs (SSIDs) and assign separate SSIDs to separate Virtual LANs. The APs are able to support Wi‐Fi multimedia. Contractor’s system shall allow segregation of Transit Agency‐owned data (e.g., CCTV/DVR) to a separate WLAN network infrastructure.



105

5000


5000.1.13

Contractor’s system shall allow for WLAN controller communication technology in each garage. The WLAN controller and wireless APs support the following functions: * The WLAN controller automatically detect and configure the wireless Aps. * The WLAN controller provide full control of the wireless Aps. * Wireless APs monitor radio frequency characteristics including received signal strength, noise, and interference (from other 802.11 radios) on all channels in its operational frequency band. The data shall be collected and analyzed by the WLAN controller. * The WLAN controller shall assign radio channels to each Wireless AP to avoid interference and channel conflicts. Contractor’s system shall utilize existing Transit Agency’s WLAN controllers and APs devices.

5000.1.14 Contractor shall provide bulk data exchange management software for the Transit Agency network.

5000.1.15 The bulk data exchange management software shall undertake bi‐directional bulk data file transfers with each vehicle while connected with the WLAN garage data communications system as initiated by the MGR/VLU during startup and shutdown.

5000.1.16

The bulk data transfer system shall be capable of the following tasks:

* Download software updates/patches and configuration data to VLUs; * Download to VLUs all updated schedule and trigger locations data required for operation of the VLU firmware; * Upload vehicle components monitoring configuration data from the VLUs; * Download updated trigger locations and announcement sign audio and text message files to enable automated annunciation system on‐board announcements.

5000.1.17 Once communication is established with the VLU, the bulk data transfer system shall automatically determine which required file transfers remain to be completed and initiate them.

5000.1.18 A validation process shall ensure multiple attempts are made to complete all required file transfers until acknowledgement has been received that the file transfer was successfully completed.

5000.1.19 When within WLAN coverage, the system shall provide the ability to automatically assign a vehicle to an inside facility (e.g. garage).

5000.1.20

Contractor system shall support a WLAN based on commercial, off‐the‐shelf WLAN technology using 802.11n (802.11b is not acceptable). The System shall meet the following WLAN minimum standards: 1. Clients must support EAP. 2. Clients must support remote antennas. 3. Clients must support WPA2 security. 4. Clients must support 802.11n/ac. 5. Clients must utilize Active communication. 6. Clients must support external antennas. 7. Transit Agency will provide the Wireless network at each site. 8. The vendor must provide bandwidth and traffic requirement for Transit Agency to ensure proper coverage and speed of the wireless network to support the application.

5000.1.21 Transit Agency will supply and be responsible for the supply and installation of all garage and yard WLAN equipment including network infrastructure, access points, antennae, and cabling.



106

5000


5000.1.22 Communications from the central site to the Access Points shall be over Transit Agency's existing local area network. Transit Agency will supply the communications network. Configuration (e.g. IP addresses) shall be per Transit Agency directive.

5000.1.23 The WLAN shall concurrently manage communications to multiple Transit Agency vehicles at each Access Point.

5000.1.24

The WLAN shall have sufficient throughput to meet requirements of ensuring complete fleet downloads and uploads within a six hour window at each garage for vehicles located at that garage. Contractor shall evaluate existing network hardware and validate system optimization meets system requirement per this solicitation.



107

SECTION 3 – INSTRUCTIONS TO PROPOSERS 3.1 INQUIRIES

Proposers are encouraged to send relevant questions to the CITY immediately upon receipt of the RFP. This will enable the CITY to prepare more comprehensive responses. Any questions that arise relating to this RFP must be directed, in writing, to the Contracts Specialist II:

Elizabeth Kellim City of Phoenix Public Transit Dept. 302 N. 1st Avenue, Suite 900 Phoenix, AZ 85003 Fax 602-495-2002 [email protected]

Questions must be received at the above address by the due date and time indicated in paragraph 1.5, Schedule of Events. Questions may be mailed, e-mailed or faxed. By the same date and time, Proposers must also notify the CITY of questions to “Attachment C - Draft Contract” of the RFP. All changes to the RFP will be in the form of a written addendum, which will be available at the CITY website: https://www.phoenix.gov/solicitations

Proposers shall acknowledge receipt of all addenda by completing the Addenda Certification form, located in Section 8.4 of the RFP, and submitting the form with their technical proposal. Only written responses provided in an addendum will be official and binding on the CITY. Proposers may not rely on oral communications with CITY employees, and no oral communication is binding on the CITY.

3.2. CITY’S VENDOR SELF-REGISTRATION AND NOTIFICATION Vendors must be registered in the City’s e-Procurement Self-Registration System at https://www.phoenix.gov/financesite/Pages/EProc-help.aspx. Such registration is intended to facilitate issuance of solicitation notices, responses to solicitations and access of procurement information. The City may, at its sole discretion, reject any offer from an Offeror who has not registered in the City’s e-Procurement system.

3.3. PROPOSAL SUBMITTAL INSTRUCTIONS 3.3.1. Due Date and Address

Proposals must be received by the date and time indicated in Paragraph 1.3, Schedule of Events. A Proposer mailing its proposal must allow sufficient mail delivery time to ensure that the CITY receives the proposal by the time and date specified. Late proposals will not be considered and will be returned unopened to the Proposer. Neither the CITY nor any CITY official or employee is responsible for proposals not properly addressed, identified and submitted. Proposals must be sealed and clearly marked with Proposer’s name, RFP number, and title on the outside of the package.

Proposals must be received at or sent by mail to:



108

Elizabeth Kellim, Contracts Specialist II City of Phoenix Public Transit Department 302 North 1st Avenue, Suite 900 Phoenix, AZ 85003

3.3.2. Number of Proposal Submittals Each Proposer shall submit ONE (1) original, FIVE (5) printed copies and SIX (6) electronic copies searchable PDF format on CD or flash drive) of its technical proposal. The Proposer’s price proposal and financial information (see Section 8.1) must be submitted in a separate sealed envelope within the proposal package. This envelope must be clearly marked “Price Proposal and Financial Information.” Each Proposer shall submit ONE (1) original, TWO (2) printed copies, and ONE (1) electronic copy (PDF format on CD or flash drive) of this information. The Proposer shall submit all required Small Business and DBE forms and documentation in a separate sealed envelope within the proposal package, marked to identify it as such. Each Proposer shall submit ONE (1) original, ONE (1) printed copy, and ONE (1) electronic copy (PDF format on CD or flash drive) of this information. The submitted CDs and/or flash drives must contain electronic file copies of all proposal text, spread-sheets, and diagrams included in the original printed proposals.

3.3.3. Proposal Content Each proposal package submitted must contain: Technical Proposal (Response Forms 1-4) Attachment A - Outreach Efforts (DBE Form) and supporting documentation (provide in a

separate sealed envelope in the Technical Proposal) Completed Forms in Section 8.2 - 8.7 of this RFP Price Proposal and Financial Information (Section 8.1, provide in a separate sealed

envelope) Letter from Surety Company (refer to Section 8.1) Statement of Ability to obtain the levels of insurance required (refer to Section 8.1)

3.4. PROPOSER RESPONSIBILITY

By submitting a proposal, each Proposer represents that it has thoroughly examined and familiarized itself with the work required under this RFP and that the Proposer is capable of performing quality work to achieve the CITY’s objectives. A Proposer’s failure to read and/or understand any part of the RFP will not affect any provision of the RFP or of the Contract. Each Proposer is responsible to consider applicable laws and FTA regulations that may affect cost, progress, performance, or furnishing the work. Proposer is liable for every item in the RFP and the Contract. Only those firms that seek and accept a demanding level of accountability should respond to this RFP.



109

3.5. PROPOSAL GUIDELINES The following guidelines are intended to promote equitable evaluation of competitive sealed proposals. 3.5.1. Proposals must be prepared in accordance with the instructions outlined in this section and

must include all of the information requested in this RFP. Noncompliance with RFP requirements may constitute a ground to eliminate the proposal from consideration of the Contract award.

3.5.2. Each Proposer shall define the capability of his/her organization to meet the intended objectives of this RFP. Each Proposal must be specific and complete in every detail, prepared in a simple straightforward manner, with concise information on the Proposer’s capability to provide all services satisfactorily. The Proposer should emphasize completeness and clarity of content, and the proposal should enable the CITY to determine whether or not the Proposer can meet the CITY’s requirements without the need for any additional information or discussion. Cursory responses or responses that merely reiterate the contents of the RFP will be deemed nonresponsive. Do not include marketing and sales-type information.

3.5.3. Each proposal must be signed by an individual authorized to bind the Proposer. 3.5.4. Each proposal must provide the name, title, address, e-mail address, and telephone number of

each person with authority to bind the Proposer contractually and the person who may be contacted during the proposal evaluation process.

3.5.5. The “Certification Form” (Section 8.2) must be completed and submitted with the Technical

Proposal.

3.6. PROPOSAL FORMAT Each proposal must be typewritten in a clear typeface with a minimum font size of 12. The proposal must be bound in a loose-leaf three-ring binder. The use of double-sided pages is encouraged. Technical Proposal The Technical Proposal in response to this solicitation shall be submitted on the forms and in the format specified below:

Response Form 1. Software: Functionality, Scalability, Modules and Interfaces Response Form 2. Hardware Response Form 3. Experience and Approach The Proposer should have seven (7) years of proven experience:

in CAD/AVL technology and deployments; in supporting CAD/AVL hardware and software for both fixed route fleet and paratransit

operations; and working with third-party data/voice communications offering and supporting CAD/AVL

hardware/software maintenance contracts.



110

The Proposer should have recent (within the last three (3) years) deployment of the proposed CAD/AVL technology on a scale similar in size, scope and complexity to those currently in place for Transit Agency in regards to:

Revenue vehicles; Number of annual service hours; and Service area.

Response Form 4. Proposer’s Understanding of Scope of Work DBE Forms. Attachment A – Outreach Efforts, supporting documentation (submitted in separate sealed envelope in the Technical Proposal) Section 8 Forms (located in Section 8 of the RFP) Certification Form (8.2) Addenda Certification (8.4) Debarment and Suspension Certificate (8.5) Lobbying Certification (8.6) Buy America Certification (8.7) DBE Form “Attachment A – Outreach Efforts” (in a separate envelope) Price Proposal The Proposer must complete the Price Proposal Excel forms according to the instructions in Section 8.1 of this RFP and Payment Terms (Section 8.3) and submit them in a separate sealed envelope within the price proposal package, along with the required documents listed under “Financial Information.”

3.7. FINANCIAL RESPONSIBILITY – SUBMITTED WITH PRICE PROPOSAL The CITY Auditor or other designated personnel will independently review the Financial Information category of Section 8.1. This category will not be scored but will be reviewed to determine Proposer’s financial responsibility. Unless a Proposer’s financial responsibility is satisfactory and can be fully verified and documented, the CITY will deem its proposal nonresponsible.

3.8. PROPOSER EXCEPTIONS The Proposer shall identify and list all exceptions to this RFP by referring to the page number and the specific section or paragraph to which Proposer takes exception and stating the exception clearly and specifically. The Proposer shall provide a complete explanation of why the exception was taken, proposed alternate language, and what benefit would accrue to the CITY if it considered the exception. The Proposer shall list all exceptions, including those to “Draft Contract” (Attachment C), in its technical proposal under the heading “Table of Exceptions to the RFP.” Exceptions that appear elsewhere in the Proposal are invalid and will not be considered.

3.9. ADDENDA The CITY is not liable for any oral instructions or communications by CITY employees, including by the Contracts Specialist II and/or Contracting Officer, irrespective whether the instructions or comments constitute or relate to proposal instructions, specifications, or proposal documents. Any changes to the RFP will be in the form of one or more written addenda, which will be available to all Proposers on the City’s website: https://www.phoenix.gov/solicitations. It is the Proposer’s responsibility to check the website and verify all required information is submitted with their offer.



111

All addenda are part of the RFP and the resulting Contract. Proposers shall acknowledge the receipt of all addenda by submitting a signed copy of the “Addenda Certification” (Section 8.4) with their Technical Proposal.

3.10. PROPOSER RIGHTS All materials submitted in response to this RFP will become the CITY’s property and, at the appropriate time, a matter of public record available for review pursuant to A.R.S. 39-121, et seq. If a Proposer believes that a specific section of its proposal is confidential, the Proposer shall mark the section “CONFIDENTIAL” and segregate it in a specific and clearly labeled section of the proposal. The Proposer shall state the basis for considering the marked section confidential, including the specific harm or prejudice that may result from disclosure. Once the procurement file becomes available for public inspection, the Procurement Officer will not make any information identified by the Proposer as “confidential" available to the public unless such information is necessary to support the evaluation process or is specifically requested in accordance with applicable public records law. When a public records request for such information is received, the CITY will promptly notify the party that provided the documents that a request or requirement to produce the documents has been received. Notice will be given as soon as practicable, and may include facsimile transmission, electronic mail and/or regular mail. Immediately upon notification, the document provider shall identify the documents that it desires to remain confidential. The document provider may then take such measures as it deems necessary, at the document provider’s sole cost and expense, to protect the documents against disclosure. If the document provider fails to obtain and provide to the CITY a court order prohibiting disclosure of the requested documents within seven (7) days after receiving notice of the request for disclosure, the CITY will deem the document provider to have consented to the disclosure, and the requested documents or information may be disclosed by the CITY.

3.11. CITY RESERVATION OF RIGHTS The CITY reserves the right to cancel the RFP in whole or in part, in its sole discretion, at any time before the Contract is approved and fully executed on the CITY’s behalf. In addition, this RFP and any resulting Contract are subject to cancellation in accordance with A.R.S. 38-511. Any such cancellation is without cost to the CITY. The CITY reserves the right to reject any or all proposals, to undertake discussions with one or more Proposers, and to accept that proposal which, in its judgment, will be the best value and most advantageous to the CITY, considering all of the evaluation criteria.

3.12. LATE PROPOSALS NOT CONSIDERED Proposals received after the stipulated opening date and time will not be considered. Unopened proposal(s) will be returned to the Proposer.

3.13. RFP INCONSISTENCIES OR ERRORS If a Proposer discovers any ambiguity, inconsistency or error in the RFP, the Proposer shall promptly notify the CITY in writing. If the Proposer fails to notify the CITY by the last date for submission of written inquiries indicated in Paragraph 1.5, Schedule of Events, this failure waives all claims of ambiguity, inconsistency or error, and the CITY’s interpretation of the RFP will govern.



112

3.14. PROPOSER ERRORS OR OMISSIONS

The CITY is not responsible for any Proposer errors or omissions.

3.15. PROPOSER INCURRED COSTS The Proposer assumes and shall pay and discharge all costs incurred in preparing or responding to this RFP. All materials and documents submitted in response to this RFP become the property of the CITY and will not be returned after the proposal submission deadline.

3.16. MODIFICATION OR WITHDRAWAL OF PROPOSAL A proposal may not be modified, withdrawn or canceled by a Proposer for two hundred forty (240) calendar days following the proposal submission deadline and, by submitting a proposal, each Proposer agrees to keep the proposal firm for that period of time. Proposals may be withdrawn, altered and/or resubmitted at any time before the submission deadline. Notice of withdrawal must be in writing and signed by the Proposer’s authorized representative. Written notice of withdrawal must be received before the proposal due date and time. Withdrawn proposal(s) may be resubmitted before the submittal due date and time.

3.17. PROPOSER CERTIFICATION By submission of a proposal, the Proposer certifies that it has not paid or agreed to pay any fee, commission, or other item of value contingent on the award of a contract to any employee, official or current consultant of the CITY.

3.18. DISCOUNTS Each Proposer shall specify payment terms in its proposal. If applicable, payment discounts will be computed from date of receiving acceptable services or a correct invoice, whichever is later, to date payment is mailed by the CITY.

3.19. CITY’S RIGHT TO DISQUALIFY FOR CONFLICT OF INTEREST In its sole discretion, the CITY reserves the right to disqualify any Proposer on the basis of any real or apparent conflict of interest disclosed before Contract award. Any Proposer submitting a proposal waives all objections to the CITY’s exercise of this right, now or at any future time, before any body or agency, including but not limited to, the City Council of the City of Phoenix and any court.

3.20. COVENANT AGAINST CONTINGENT FEES The Proposer warrants that no person or selling agent has been employed or retained to solicit or secure the Contract upon an agreement or understanding for a commission, percentage, brokerage, or contingent fee, excepting bona fide employees or bona fide established commercial or selling agencies maintained by the Proposer for the purpose of securing business. For breach or violation of this warranty, the CITY may cancel the Contract without liability; in its discretion, the CITY may deduct from the Contract price the consideration paid; or the CITY may otherwise recover the full amount of the commission, brokerage or contingent fee.

3.21. EXECUTION OF AGREEMENT The “Draft Contract” included in the RFP as Attachment C will form the basis of any Contract between the CITY and the successful Proposer. The successful Proposer will be liable to perform all duties and obligations in the “Draft Contract” and any changes to the Contract.



113

Within fifteen (15) calendar days of transmission of the Contract from the CITY, the successful Proposer shall sign and deliver the Contract to the CITY.



114

SECTION 4 – EVALUATION AND AWARD 4.1 PROPOSAL EVALUATION, NEGOTIATION AND SELECTION

The CITY will evaluate and negotiate Proposals, select the Proposer whose proposal represents the best value to the CITY, and award any Contract in accordance with the criteria and procedures described in this RFP, including this section. The RFP’s approach contemplates that proposals will first be evaluated to determine which ones are in the Competitive Range. The CITY may then discuss with Proposers and negotiate proposals in the Competitive Range, after which the CITY may request BAFOs. But the CITY may select a proposal for award without discussions or negotiations and without requesting BAFOs.

4.2 EVALUATION COMMITTEE The CITY will appoint an Evaluation Committee. The Evaluation Committee may consist of CITY staff, staff from other transit agencies, and other persons. The Contracts Specialist II will chair the Evaluation Committee, serving in a non-voting capacity. The Evaluation Committee will evaluate proposals, establish the Competitive Range, and select the Proposer, if any, to receive the contract award. The CITY may appoint a Technical Advisory Team to provide technical assistance to the Evaluation Committee. The Technical Advisory Team may consist of CITY staff, staff from other transit agencies, and other persons. The Technical Advisory Team will evaluate the technical portion of each proposal for compliance with the RFP specifications. The Technical Advisory Team will provide a summary of their technical review to the Evaluation Committee.

4.3 EVALUATION OF COMPETITIVE PROPOSALS This section describes the process by which proposals will be reviewed and evaluated and the Proposer selected for a potential award. Evaluations will be made in strict accordance with all of the responsiveness, responsibility and evaluation criteria specified below. The Evaluation Committee will recommend the Proposal that constitutes the best value and is the most advantageous to the CITY. 4.3.1 Clarifications

Upon receipt and opening of offers submitted in response to this Solicitation, the City may request written clarifications for such purposes as information gathering or eliminating minor informalities in proposals. Clarifications shall not otherwise afford the Offerors the opportunity to alter or change their offers.

4.3.2 Exceptions and Determining Responsiveness

The RFP states criterion that determine responsiveness. By submitting a proposal, the Proposer accepts all of the contract documents, except the conditions, exceptions, reservations or understandings that are explicitly, fully and separately stated and submitted in accordance with Section 3.8 “Proposer Exceptions.” The Contracts Specialist II, in consultation with legal counsel, will review only exceptions, conditions, reservations or understandings that are explicitly, fully and separately stated in a proposal to determine if one or more are acceptable. Exceptions, conditions, reservations, or understandings are presumed to be unacceptable, unless explicitly accepted by the CITY. The Contracts Specialist II, in consultation with legal counsel, will review and analyze all Proposer exceptions, conditions, reservations or



115

understandings, if any, stated in each proposal. A Proposal that includes unacceptable exceptions, conditions, reservations, or understandings may be rejected as nonresponsive. Alternatively, the City in its sole discretion may instruct in writing that any Proposer remove the conditions, exceptions, reservations or understandings. If the Proposer fails to do so in writing, the City may determine the Proposal to be nonresponsive.

4.3.3 Qualification of Responsible Proposers

A review of responsibility may occur up to contract award. This determination will be made based on the initial information in the Proposal, any information at the CITY’s request, information in any best and final offer (BAFO), and information received from Proposer’s references, including information about Proposer’s past history. To be found responsible, at a minimum, Proposers must meet all of the requirements set forth below. The final determination of a Proposer’s responsibility will be based upon all information received during the evaluation process. The CITY reserves the right to make additional inquiries as it deems necessary to establish the competence and financial stability of any Proposer submitting a proposal. Responsibility Requirements Any Proposer whose proposal does not meet these requirements, as determined by the Evaluation Committee, is not responsible, and the Proposer’s proposal will not be considered further in the evaluation process. The requirements, not listed in order of importance, are as follows. A. The Proposer shall possess and demonstrate the financial strength, resources and

capability to perform the Work and to complete the contract in a satisfactory manner. This shall be demonstrated, in part, by documents required in Section 8.1(A).

B. The Proposer shall reasonably demonstrate evidence that its human and physical resources are sufficient to meet the requirements of the contract, including but not limited to possession of all necessary licenses, skills, experience and equipment to complete the contract as required.

C. The Proposer shall demonstrate evidence of satisfactory past performance of contracts of similar size, scope and complexity as evidenced by client references.

4.3.4 Detailed Evaluation of Proposals and Determination of Competitive Range

The Evaluation Committee will perform and document its evaluation. During deliberations, the Evaluation Committee will reach a consensus score for each evaluation criterion except price, which the Contracts Specialist II will score. The consensus scores will determine the Proposers’ rankings and which Proposals are within the Competitive Range. Proposal Evaluation Criteria The following constitute the criteria by which the CITY will evaluate and rank Proposals for purposes of determining the Competitive Range and selecting a Proposal for a potential award. The Contracts Specialist II will review and score Price Proposals. The Proposer offering the lowest total CAD/AVL system cost per vehicle including all new software and hardware required to attain a fully functional CAD/AVL system as required per this solicitation, as well as lowest



116

pricing for all years for extended maintenance Price Proposal 1 (REM) and Price Proposal 2 (FM) will receive the maximum points allocated for price. Evaluation Criteria (Max 1000 points) Points

A. Software: Functionality, Scalability, Modules and Interfaces: 1. Radio Integration 2. Dispatch and Scheduling 3. Ad·hoc Reporting and SQL reporting tool 4. Traffic Signal Prioritization 5. Automated Vehicle Telematics Solution 6. Garage / Maintenance Facility Mapping 7. Mobile Application Solution 8. Paratransit Interface 9. Driver Vehicle Inspection 10. Data Exchange 11. Vehicle Single Logon 12. Incident Management 13. Exterior Digital Destination Sign 14. Interior Digital Readerboard 15. GPS 16. Voice Annunciation 17. Automatic Passenger Counter (APC) 18. Onboard Component Asset Management Solution 19. Map displays

0-300 Pts

B. Hardware: Functionality and Scalability: 1. Mobile Devices 2. IVU peripheral component self-diagnostic (i.e. assist in new vehicle installs) 3. Data transfer via Wi-Fi, mobile router, radio 4. CAD/AVL Controller Consoles 5. Onboard hardware component

0-200 Pts

C. Experience and Approach: 1. Proposer's relevant system integration experience, qualifications and past performance. 2. Overall Project Plan 3. Relevant experience and qualifications and other vital information about all key personnel, including subcontractors, who will be assigned to this project. 4. Customer references of recent and similar projects. 5. Proposer's approach to planning, start-up system implementation, testing, integration, and installation. 6. Solution Testing Approach 7. Proposer's approach to technical and system user training 8. Proposer’s approach to quality control 9. Proposer’s approach to minimize vehicle downtime 10. Proposed Project Management plan

0-200 Pts



117

11. Proposed Project Schedule 12. Progress Payment Schedule

E. Proposer’s Total Price: The price evaluation will be based on the estimated total price. The Proposer offering the lowest estimated total cost per vehicle including all software and hardware will receive the maximum points allocated for price. All other Proposers will receive points based on the mathematical relationship between their proposed prices and the lowest Proposer’s price.

0-200 Pts

D. Proposer’s Understanding of Scope of Work: 1. Understanding of work scope and complexity of fixed-route services contemplated in this RFP. 2. Understanding of work scope and complexity of paratransit services contemplated in this RFP. 3. Understanding of work scope and complexity of Light-Rail services contemplated in this RFP.

0-100 Pts

4.3.5 Proposals not within the Competitive Range

In accordance with CITY policies, the CITY will notify Proposers of any proposals that the CITY has determined are not in the Competitive Range.

4.3.6 Discussions/Demonstrations with Proposers in the Competitive Range

The CITY will notify each Proposer whose proposal is in the Competitive Range and provide in writing any questions or requests for clarification to the Proposer. For each Proposer so notified, the City may request demonstrations of the Proposers’ offered solution. Additionally, such notified Proposers may be interviewed by the CITY and asked to discuss answers to written or oral questions or provide clarifications to any facet of its proposal. To the fullest extent permitted by law, during the evaluation process, the CITY will not provide any information, financial or otherwise, to any Proposer about other proposals received in response to this RFP. During discussions with Proposers in the Competitive Range, the CITY will not give Proposers specific prices or specific financial requirements that Proposers must meet to qualify for further consideration. But the CITY may state that proposed prices are too high with respect to the marketplace or otherwise unacceptable. Proposers will not be told of their relative rankings before contract award.

Demonstrations. If demonstrations are requested, the CITY will communicate the assigned date and time to the Proposer along with any other instructions. Demonstrations will be conducted in-person at the CITY’s designated location; participation by telephone is not permitted. Required Proposer attendees will include but may not be limited to: the proposed project manager, project engineer, and the training lead. Proposers are notified that the CITY will video record the demonstrations and the CITY may photograph any equipment presented.

Treatment of Conditions, Exceptions, Reservations or Understandings. If a proposal in the Competitive Range contains conditions, exceptions, reservations or understandings to or about any contract requirement as provided in Section 3.8 “Proposer Exceptions,”



118

the CITY may discuss or negotiate the conditions, exceptions, reservations or understandings during these meetings. But the CITY in its sole discretion may reject any and all conditions, exceptions, reservations and understandings, and the CITY may instruct any Proposer to remove the conditions, exceptions, reservations or understandings. If the Proposer fails to do so, the CITY may determine the Proposal is nonresponsive, and the CITY may revoke its determination that the proposal is in the Competitive Range.

4.3.7 Site Visits

The CITY reserves the right to inspect the Proposer’s facilities and/or other transit systems where the Proposer has supplied the same or similar services.

4.3.8 Best and Final Offers (BAFO) Each Proposer in the Competitive Range may be afforded the opportunity to amend its proposal and submit one BAFO. The request for BAFOs will include the following: 1. Notice that discussions/negotiations are concluded. 2. Notice that this is the opportunity to submit a written BAFO. 3. A common date and time for submission of a BAFO by each Proposer in the Competitive

Range, allowing a reasonable opportunity to prepare BAFOs. 4. Notice that if any modification to a BAFO is submitted, it must be received by the date and

time specified for receipt of BAFOs. 5. Notice to Proposers that do not submit a notice of withdrawal or a BAFO that their

immediately previous proposal will be construed as their BAFO. If a Proposer’s BAFO modifies its initial Proposal, the BAFO must include a “Change Log” identifying all modifications made to the Proposal. The CITY will evaluate BAFOs based on the same requirements and criteria applicable to initial Proposals. The CITY will adjust appropriately the initial scores for criteria that have been affected by Proposal modifications made by a BAFO. Based on the criteria defined in Section 4.3. as weighted, the CITY will then perform final scoring and prepare final rankings. The Evaluation Committee will recommend the proposal that is the best value and most advantageous to the CITY based on the evaluation criteria. The results of the evaluation and the selection of a Proposer for any award will be documented in the solicitation file.

4.3.9 Award Recommendation

The CITY reserves the right to make an award to a Proposer whose proposal it judges to be the best value and most advantageous to the CITY based on the evaluation criteria, and to do so without conducting written or oral discussions with any Proposer and without soliciting BAFOs.

4.3.10 Debriefing

After contract award, unsuccessful Proposers will be notified and may request a debriefing. 4.4 PROTEST PROCEDURE

A disappointed Proposer that intends to protest the award must comply with the CITY’s protest procedure.

Staff’s recommendation to award a Contract to a particular Proposer will be posted on the CITY



119

website. An unsuccessful Proposer may file a protest no later than seven (7) calendar days after the recommendation is posted on the website. All protests must be in writing, filed with the Contracting Officer, Kimberly Hayden (email: kimberly.hayden @phoenix.gov) and include the following: Identification of the RFP; The name, address and telephone number of the protester; A detailed statement describing the legal and factual grounds for the protest, including copies of

relevant documents; The form of relief requested; and The signature of the protester or its authorized representative.

The Contracting Officer will render a written decision within a reasonable period of time after the protest is filed. The CITY will not request City Council authorization to award the Contract until the protest process is completed. The Contracting Officer’s decision on a protest is final and binding. But the protester may appeal the decision as permitted in the CITY’s protest procedure and may appeal further to the FTA for procurements funded in whole or in part with FTA funds in accordance with FTA requirements. The protester must exhaust its administrative remedies by pursuing the CITY’s protest procedure to completion before appealing the CITY’s decision to FTA. FTA’s review of protests is limited to: The CITY’s failure to follow its protest procedures or its failure to review a complaint or protest; or Violations of federal law or regulations. An appeal to FTA must be received by the appropriate FTA Regional Office or FTA Headquarters within five (5) working days of the date the protestor learned or should have learned of an adverse decision by the CITY or any other basis of appeal to FTA.



120

SECTION 5 – SPECIAL TERMS AND CONDITIONS 5.1 METHOD OF PAYMENT AND INVOICING

The CITY will compensate Contractor for satisfactory and complete performance of work under the Contract at the prices set forth in the Contract. The CITY shall make every effort to process payment for the purchase of services within thirty (30) calendar days after receipt and approval of a correct invoice. Any prompt payment terms offered must be clearly noted by Contractor on all invoices submitted to the CITY. Payment of invoice(s) will be delayed if an invoice or supporting documentation submitted is incorrect or incomplete. Monthly invoices must be sent to:

City of Phoenix/Public Transit Department Attn: Deputy Public Transit Director - Support Services 302 North First Avenue, Suite 900 Phoenix, Arizona 85003 INITIAL PROJECT. Contractor shall be paid on a milestone basis. Contractor shall submit one (1) invoice to the CITY after each milestone is approved and signed off by Transit Agency. The amount invoiced shall be based on the milestone invoice table listed below. Invoices should be submitted to the CITY by the 10th day of the month following the period in which the services/product were delivered and must contain date, contract number, supporting documentation, and invoice amount. Advance payments are not authorized. Payment will be made only for actual milestones that have been completed and approved by Transit Agency:

Milestone Progress Payments The payment schedule will form part of the Contract. Upon each milestone completed and approved Transit Agency payment will be released as a percentage of the total cost of the contract as follows: 1. System Design Documentation ..................................... 10% 2. Completion of acceptance and mini fleet test ................ 10% 3. Training and Documentation ......................................... 10% 4. Completion of Vehicle Installations ............................... 30% 5. Substantial Acceptance ................................................. 25% 6. Final Acceptance (end of 3 year warranty period) ......... 15%* * in equal annual payments

MAINTENANCE AND SUPPORT SERVICES. Payment shall be made in accordance with Attachment E, Extended Maintenance.

5.2 PRICE Prices of initial purchase and installation must be firm and fixed.

5.3 ALTERATION IN CHARACTER OF WORK

5.3.1 Whenever an alteration in the character of work results in a substantial change in the nature of services, thereby materially increasing or decreasing the cost of the performance, the work will



121

be performed in accordance with this Agreement. Before any additional work is started, a contract change order or supplemental agreement will be executed by CITY and CONTRACTOR. CITY and CONTRACTOR agree to negotiate and resolve contract change orders in good faith.

5.3.2 No changes in the scope, character, or complexity of work may be made by CONTRACTOR without first receiving approval properly defining and limiting the change. CITY will not pay any claim for extra work done or materials furnished by CONTRACTOR except as provided in this Agreement, and CONTRACTOR may not do any work or furnish any materials not covered by this Agreement unless first approved in writing by CITY. Any such work or materials furnished by CONTRACTOR without prior written approval is Contractor’s sole risk, cost and expense, and CONTRACTOR may not make any claim for compensation for any such work or materials.

5.4 UNSATISFACTORY PERFORMANCE The Transit Agency shall decide all questions as to the quality and acceptability of any work performed under the Contract as monitored and documented by the CITY’s. If, in the opinion of the CITY, performance becomes unsatisfactory, the CITY shall notify Contractor. Contractor shall have a reasonable time to cure the unsatisfactory performance. See Exhibit C – Draft Contract, Section 11.D. If the unsatisfactory performance is not cured within the time specified, the CITY may withhold milestone payments until the Work is completed to the CITY’s satisfaction or the CITY is able to complete the Work with inside or other outside forces. Contractor will be liable for difference between cost to the CITY to complete the Work with other forces and the cost to the CITY for completion of the Work by Contractor per the contract. Repeated incidences of unsatisfactory performance may result in cancellation of the Contract for default. See Exhibit C – Draft Contract, Section 11.B.

5.5 PERFORMANCE SURETY Performance surety in the amount of $2,500,000 must be provided by Contractor immediately upon

receiving notice of Contract award. The performance surety must be renewed annually at the beginning of each contract year. The CITY will not give notice to proceed in any form until the performance surety has been received by the CITY. The performance surety must be in the form of a bond, cashier’s check, certified check or money order. Personal or company checks are not acceptable unless certified. If the performance surety is in the form of a bond, the company issuing the surety must be authorized by the Arizona Department of Insurance to transact surety business in the state of Arizona or be named on the approved listing of surplus-lines companies. A certificate of deposit (CD) issued by a local Phoenix bank may also be used as a form of surety provided the CD is issued jointly in the name of the City of Phoenix and Contractor and Contractor endorses the CD to the CITY at the beginning of the Contract. Interest earned on the CD may be retained by Contractor but only if Contractor is not in default under the Contract.

5.6 INDEMNIFICATION OF CITY AGAINST LIABILITY Contractor (“Indemnitor”) must indemnify, defend, save and hold harmless the City of Phoenix and its officers, officials, agents, and employees ( “Indemnitee”) from and against any and all claims, actions, liabilities, damages, losses, or expenses (including court costs, attorneys’ fees, and costs of claim processing, investigation and litigation) ( “Claims”) caused, or alleged to be caused, in whole or in part, by the negligent or willful acts or omissions of Contractor or any of its owners, officers, directors, agents, employees or subcontractors in connection with this Contract. This indemnity includes any Claims arising out of or recovered under the Workers’ Compensation Law or arising out of the failure of Contractor to conform to any federal, state or local law, statute, ordinance, rule, regulation or court



122

decree. It is the specific intention of the parties that Indemnitee will, in all instances, except for Claims arising solely from the negligent or willful acts or omissions of Indemnitee, be indemnified by Contractor from and against any and all Claims. Contractor will be responsible for primary loss investigation, defense and judgment costs where this indemnification applies. In consideration of the award of this Contract, Contractor waives all rights of subrogation against Indemnitee for losses arising from the work performed by Contractor for the City. The obligations of Contractor under this provision survive the termination or expiration of this Contract.

5.7 INSURANCE REQUIREMENTS Contractor and subcontractors must procure and maintain until all of their obligations have been discharged, including any warranty periods under this Contract are satisfied, insurance against claims which may arise from or in connection with the performance of the work hereunder by Contractor, his agents, representatives, employees or subcontractors. These insurance requirements are minimum requirements for this Contract and in no way limit the indemnity covenants contained in this Contract. The City in no way warrants that the minimum limits stated in this section are sufficient to protect Contractor from liabilities that might arise out of the performance of the work under this contract by Contractor, his agents, representatives, employees or subcontractors and Contractor is free to purchase additional insurance as may be determined necessary. 5.7.1 MINIMUM SCOPE AND LIMITS OF INSURANCE: Contractor must provide coverage with

limits of liability not less than those stated below. An excess liability policy or umbrella liability policy may be used to meet the minimum liability requirements provided that the coverage is written on a “following form” basis.

5.7.1.1. Commercial General Liability – Occurrence Form

Policy must include bodily injury, property damage and broad form contractual liability coverage.

General Aggregate $2,000,000 Products – Completed Operations Aggregate $1,000,000 Personal and Advertising Injury $1,000,000 Each Occurrence $1,000,000

The policy must be endorsed to include the following additional insured language: "The City of Phoenix is named as an additional insured with respect to liability arising out of the activities performed by, or on behalf of the Contractor".

5.7.1.2. Worker's Compensation and Employers' Liability Workers' Compensation Statutory Employers' Liability Each Accident $100,000 Disease – Each Employee $100,000 Disease – Policy Limit $500,000 Policy must contain a waiver of subrogation against the City of Phoenix.



123

This requirement does not apply when a contractor or subcontractor is exempt under A.R.S. 23-901, AND when such contractor or subcontractor executes the appropriate sole proprietor waiver form.

5.7.1.3. Technology Errors and Omissions Liability The policy must cover errors and omissions or negligent acts in the delivery of products, services, and/or licensed programs for those services as defined in the Scope of Services of this contract.

Each Claim $1,000,000 Annual Aggregate $1,000,000

In the event that the professional liability insurance required by this Contract is written on a claims-made basis, Contractor warrants that any retroactive date under the policy must precede the effective date of this Contract; and that either continuous coverage will be maintained or an extended discovery period will be exercised for a period of two (2) years beginning at the time work under this Contract is completed.

5.7.2 ADDITIONAL INSURANCE REQUIREMENTS: The policies must include, or be endorsed to

include, the following provisions: 5.7.2.1 On insurance policies where the City of Phoenix is named as an additional insured, the

City of Phoenix is an additional insured to the full limits of liability purchased by Contractor even if those limits of liability are in excess of those required by this Contract.

5.7.2.2 Contractor's insurance coverage must be primary insurance and non-contributory with respect to all other available sources.

5.7.3 NOTICE OF CANCELLATION: For each insurance policy required by the insurance provisions

of this Contract, Contractor must provide to the City, within 2 business days of receipt, a notice if a policy is suspended, voided or cancelled for any reason. Such notice must be mailed, emailed, hand delivered or sent by facsimile transmission to (City of Phoenix Public Transit Department, Attn: Christine Adrian, 302 N. 1st Avenue, Suite 900, Phoenix, AZ 85003).

5.7.4 ACCEPTABILITY OF INSURERS: Insurance is to be placed with insurers duly licensed or

authorized to do business in the state of Arizona and with an “A.M. Best” rating of not less than B+ VI. The City in no way warrants that the above-required minimum insurer rating is sufficient to protect the Contractor from potential insurer insolvency.

5.7.5 VERIFICATION OF COVERAGE: Contractor must furnish the City with certificates of insurance

(ACORD form or equivalent approved by the City) as required by this Contract. The certificates for each insurance policy are to be signed by a person authorized by that insurer to bind coverage on its behalf. All certificates and any required endorsements are to be received and approved by the City before work commences. Each insurance policy required by this Contract must be in effect at or prior to commencement of work under this Contract and remain in effect for the duration of the project.



124

Failure to maintain the insurance policies as required by this Contract or to provide evidence of renewal is a material breach of contract. All certificates required by this Contract must be sent directly to (City of Phoenix Public Transit Department, Attn: Christine Adrian, 302 N. 1st Avenue, Suite 900, Phoenix, AZ 85003). The City project/contract number and project description must be noted on the certificate of insurance. The City reserves the right to require complete, certified copies of all insurance policies required by this Contract at any time. DO NOT SEND CERTIFICATES OF INSURANCE TO THE CITY'S RISK MANAGEMENT DIVISION.

5.7.6 SUBCONTRACTORS: Contractors’ certificate(s) must include all subcontractors as additional insureds under its policies or Contractor must furnish to the City separate certificates and endorsements for each subcontractor. All coverages for subcontractors must be subject to the minimum requirements identified above.

5.7.7 APPROVAL: Any modification or variation from the insurance requirements in this Contract

must be made by the Law Department, whose decision is final. Such action will not require a formal Contract amendment, but may be made by administrative action.

5.8 INTELLECTUAL PROPERTY AND SPECIAL TERMS AND CONDITIONS

5.8.1 Definitions

5.8.1.1 “Deliverables” means all software, equipment, systems, work to be delivered, or other work products provided within the scope of this Agreement.

5.8.1.2 “Intellectual Property Rights” or “IPR” mean all intellectual property rights, including with limitation, any rights in any invention, patent, discovery, improvement, know-how, utility model, trade-mark, copyright, industrial design or mask work, integrated circuit topography, trade secret and all rights of whatsoever nature in computer software and data, Confidential Information, and all intangible rights or privileges of a nature similar to any of the foregoing, including in every case in any part of the world and whether or not registered, and shall include all rights in any applications and granted registrations for any of the foregoing.

5.8.1.3 “Joint IPR” means the Intellectual Property Rights conceived, created, developed, or reduced to practice in a Project pursuant to this Agreement.

5.8.1.4 “Licensed Patents” shall mean all patents throughout the world (including patents of importation, improvement patents, patents and certificates of addition and utility models, as well as divisions, reissues, continuations, renewals, and extensions of the foregoing) applications therefore, and patents which may issue upon such applications, as to which patents or applications Contractor has at any time during the Term of this Agreement the right to grant licenses of.



125

5.8.1.5 “Licensed Products” shall mean any and all products which employ or are produced by the practice of inventions claimed in the Licensed Patents.

5.8.2 Intellectual Property Indemnification. In addition to the indemnification in paragraph 5.6. above, Contractor agrees to defend, at its own expense, and to indemnify and hold harmless the City and its officers, agents, and employees from and against all judgments, claims, damages, suits, liabilities, settlements, costs and demands, including reasonable attorneys’ fees, suffered or incurred by the City as a result of any claim that the Deliverables infringe the patents, copyrights, or other intellectual property rights of third parties, provided that Contractor is notified in writing of such claim. Contractor will have the sole right to control the defense of all such infringement claims, lawsuits and other proceedings including the right to settle the same. In no event will the City settle any such claim, lawsuit, or proceeding without Contractor’s prior written approval. The City will cooperate with Contractor, at Contractor’s expense, in a reasonable way to facilitate the settlement or defense of such claim. If, as a result of any claim of infringement by Contractor, the City is enjoined from using the Deliverables provided under this Agreement, or if Contractor reasonably believes that the Deliverables are likely to become the subject of a claim of infringement, Contractor may, at Contractor’s option and expense, (1) procure the right for the City to continue to use the Deliverables, or (2) replace or modify the Deliverables so as to make them non-infringing and of equal or superior functional and capability for the purpose for which the Deliverable was provided.

5.8.3 Document Delivery. All documents, together with all unused materials supplied by the City,

are to be delivered to the City upon completion or termination of this Agreement before the final payment is made to Contractor. All documents prepared by Contractor shall be prepared in a format and at a quality approved by the City. Contractor shall review all documents provided by the City related to the performance of the Services and shall promptly notify the City of any defects or deficiencies discovered in such review. Contractor shall provide timely and periodic submittals of all documents required of Contractor, including sub-agreements, if any, as such become available to the City for review.

5.8.4 Reservation. Nothing in this Agreement shall be interpreted to give either party any rights whatsoever to any Intellectual Property of the other not conceived, created, developed, or reduced to practice pursuant to this Agreement.

5.8.5 Warranty Against Infringement. Contractor warrants that the Deliverables will be free of the rightful claim of any third party by way of infringement or misappropriation of patent, copyright, trade secret, trademark or other rights arising under the laws of the United States. Contractor further warrants that no act or omission of Contractor will result in a third party holding a claim (other than infringement) that interferes with the City’s enjoyment of the Deliverables. Contractor warrants that it owns or possesses the necessary rights, title and licenses necessary to perform its obligations hereunder.



126

Contractor warrants that, as of the Effective Date and throughout the Term, Contractor has not conveyed any rights or licenses to any third party regarding the Deliverables.

5.8.6 Warranty on Deliverables. Contractor warrants the Deliverables (including hardware, electrical, electronic, mechanical, and all other system components, including installation), for a period of 3 year period starting with the date of final system acceptance (the “Warranty Period”), to be substantially free of any condition which would make the system fail to perform other than in material accordance with the requirements set forth in Section II, Scope of Work, (each such condition to be considered an “Error”). If the City reports to Contractor any Errors (any condition which could make it fail to perform other than in material accordance with the specifications) in the system during the Warranty Period, then Contractor shall, at its expense, use reasonable commercial efforts to modify or replace the faulty hardware, software, electrical component or other system feature as quickly as reasonably practicable. Where possible, both parties shall attempt to resolve Errors through telephone instruction, issuance of updated documentation, corrective code, or hardware replacement or modification.

5.8.7 Acceptance of Deliverables. Final acceptance of Deliverables shall be provided only after successful completion of testing of the Deliverables. Final acceptance shall not occur until all phases of implementation have been successfully performed. Acceptance test criteria will be identified during the Design and Review process.

5.8.8 Supervision of Others. Contractor shall take all reasonable precautions to prevent any other person with whom Contractor is or may become associated (whether as supervisor, employee, owner or otherwise) from acquiring confidential information from or through Contractor and/or using or divulging such confidential information at any time; provided, however, Contractor shall not be responsible or liable, nor shall he be in breach of this Subsection, if any other person shall acquire, use, or divulge such confidential information as a result of a forcible entry into the office or file of City.

5.8.9 Software License. Services provided under this Agreement may be in support of City’s license to use computer software programs, owned or distributed by Contractor, under a separate software license agreement. The software license agreement shall govern all use by City of such programs. Neither this Agreement nor any ordering document includes the grant of any license or any other rights for such programs.

5.9 CONTRACTOR AND SUBCONTRACTOR WORKER BACKGROUND SCREENING

Contractor agrees that all contract workers and subcontractors (collectively “contract worker(s)”) that Contractor provides pursuant to this Contract shall be subject to background and security checks and screening (collectively “Background Screening”) as set forth in this RFP. Contractor shall perform at its sole cost and expense all such Background Screening pursuant to the provisions in this RFP. The provider of the Background Screening shall comply with all applicable laws, rules and regulations. Contractor further agrees that the Background Screening required in this RFP is necessary to preserve and protect public health, safety and welfare. The Background Screening requirements set forth in these provisions are the minimum requirements for this Contract. The CITY in no way warrants that these minimum requirements are sufficient to protect Contractor from any liabilities that may arise out of Contractor’s services under this Contract. Therefore, in addition to the specific measures set forth



127

below, Contractor and its contract workers shall take such other reasonable, prudent and necessary measures to further preserve and protect public health, safety and welfare when providing services under this Contract. Contractor shall be responsible and shall warrant that all Background Screening information furnished to the CITY is accurate and current through the date of hire of the proposed contract worker. Background Screening Requirements and Criteria. Because of the varied types of services performed, the CITY has established three levels of risk and associated Background Screening. The risk level and Background Screening required for this Agreement is Maximum Risk. A. Minimum Risk and Background Screening (“Minimum Risk”).

A minimum risk Background Screening shall be performed when the contract worker: (i) will not have direct access to CITY facilities or information systems; or (ii) will not work with vulnerable adults or children; or (iii) when access to CITY facilities is escorted by a City workers. The Background Screening for minimum risk shall consist of the screening required by A.R.S. § 41-4401 to verify legal Arizona worker status.

B. Standard Risk and Background Screening (“Standard Risk”). A standard risk Background Screening shall be performed when the contract worker’s work assignment will: (i) require a badge or key for access for City facilities; or (ii) allow any access to sensitive, confidential records, personal identifying information or restricted City information; or (iii) allow unescorted access to City facilities during normal and non-business hours. The Background Screening for this standard risk level shall include the Background Screening required for the Minimum Risk level and a background check for real identity/ legal name, and shall include felony and misdemeanor records from any county in the United States, the state of Arizona, plus any other jurisdiction where the contract worker has lived at any time in the preceding seven (7) years from the contract worker’s proposed date of hire.

C. Maximum Risk and Background Screening (“Maximum Risk”). A maximum risk Background Screening shall be performed when the contract worker’s work assignment will: (i) have any contact with vulnerable people such as children, youth, elderly, or individuals with disabilities; or (ii) have any responsibility for the receipt or payment of the CITY funds or control or inventories, assets, or records that are at risk of misappropriation; or (iii) have unescorted access to the CITY data centers, money rooms, or high-value equipment rooms; or (iv) have access to private residences; or (v) have access to Homeland Defense Bureau identified critical infrastructure sites/facilities. The Background Screening for this maximum risk level shall include the Background Screening required for the Standard Risk level, plus a sexual offender search, a credit check, and driving record search for the preceding seven (7) years from the contract worker’s proposed date of hire. Contract workers who work directly with children or vulnerable adults are also subject to fingerprint verification through the Arizona Department of public Safety as mandated by Phoenix City Code, § 2-45.6.

Contractor Certification; City Approval of Maximum Background Screening. By executing this Contract, Contractor certifies and warrants that Contractor has read the Background Screening requirements and criteria set forth above, understands them and that Contractor has satisfied all such Background Screening requirements for the Minimum Risk Background Screenings. In addition, for Maximum Risk Background Screening, Contractor shall provide for the CITY’s review and approval such Background Screenings for any contract worker considered for performing services under this Contract where human safety or facility security is classified as a Maximum Risk level. The CITY may, in its sole discretion, accept or reject any or all of the contract workers proposed by Contractor for performing work under this Contract. A contract worker rejected for work at a Maximum Risk level under this



128

Contract shall not be proposed to perform work under other CITY contracts or engagements without CITY’s prior written approval. Terms of This Provision Applicable to all of Contractor’s Contracts and Subcontracts. Contractor shall include the terms of this provision for contract worker Background Screening in all contracts and subcontracts for work performed under this Contract, including supervision and oversight. Materiality of Background Screening Provisions; Indemnity. The Background Screening provisions of this Contract, as set forth above, are material to CITY’s entry into this Contract and any breach thereof by Contractor may, at CITY’s option, sole and unfettered discretion, be considered to be a material breach of this Contract. In addition to the indemnity provisions set forth in Section 5.6 of this RFP, Contractor shall defend, indemnify and hold harmless the CITY for any and all Claims (as defined in Section 5.6) arising out of these Background Screening provisions including, but not limited to, the disqualification of a contract worker by Contractor or the CITY for failure to satisfy these provisions. Continuing Duty; Audit. Contractor’s obligations that Contractor’s workers satisfy the Background Screening requirements in these provisions shall continue throughout the entire term of this Contract. Contractor shall notify the CITY immediately of any change to a Maximum Risk Background Screening of a contract worker previously approved by the CITY. Contractor shall maintain all records and documents related to all Background Screenings and the CITY reserves the right to audit Contractor’s compliance with these provisions pursuant to Section 7.3.

5.10 ACCESS CONTROLS, BADGE AND KEY ACCESS PROCEDURES A contract worker shall not be allowed to begin work in any CITY facility without: (1) the prior completion and CITY’s acceptance of the required background screening; and (2) when required, the contract worker’s receipt of a CITY issued badge. A badge will be issued to a contract worker solely for access to the CITY facility(s) to which the contract worker is assigned. Each contract worker who enters a CITY facility must use the badge issued to the contract worker. Badge Access Procedures. An authorized City of Phoenix badge application form is available at the City of Phoenix Badging Office, 251 W. Washington, 2nd Floor, Phoenix, AZ 85003-1611. Each contract worker (as defined herein) who is furnishing Standard Risk (as defined herein) or Maximum Risk (as defined herein) services under the Contract shall submit to the City of Phoenix Banking & Cashiering Division, 251 W. Washington, 3rd Floor, Phoenix, AZ 85003-1611: (i) a fully completed and authorized City of Phoenix badge application form; (ii) a check in the initial badge fee amount listed below made payable to the “City of Phoenix”; (iii) two forms of identification. One form of identification must be a government issued credential with an accompanying photograph. The second form of identification must be a valid passport; military issued identification card; immigration and naturalized services identification card; social security card; or an original birth certificate. After receipt of the badge application and payment, the contract worker will proceed to the badging office for processing of the badge application and issuance of the badge. The CITY will not process the badge application until the contract worker satisfies the required Background Screening (as defined in Section 5.9). The contract worker shall comply with all requirements and furnish all requested information within five (5) business days from initial submission of the badge application or the subject contract worker’s badge application shall be rejected. Key Access Procedures. If the contract worker’s services require keyed access to enter a CITY facility(s), a separate key issue/return form must be completed and submitted by Contractor for each key issued. The key issue/return form is available at and the completed form shall be submitted to the



129

badging office at the address above. Stolen or Lost Badges or Keys. Contractor shall report lost or stolen badges or keys to their local police department and must obtain a police department report (PDR) prior to re-issuance of any lost or stolen badge or key. A new badge application or key issue form shall be completed and submitted along with payment of the applicable fees listed below prior to issuance of a new badge or key. Return of Badges or Keys. All badges and keys are the property of the CITY and must be returned to the CITY at the badging office within one (1) business day of when the contract worker’s access to a CITY facility is no longer required to furnish the services under the Contract. Contractor shall collect a contract worker’s badge and key(s) upon the termination of the contract worker’s employment; when the contract worker’s services are no longer required at the particular CITY facility(s); or upon termination, cancellation or expiration of this contract. Contractor’s Default; Liquidated Damages; Reservation of Remedies for Material Breach. Contractor’s default under this section shall include, but is not limited to the following: (i) Contract Worker gains access to a CITY facility(s) without the proper badge or key; (ii) contract worker uses a badge or key of another to gain access to a CITY facility; (iii) contract worker commences services under this Contract without the proper badge, key or Background Screening; (iv) contract worker or Contractor submits false information or negligently submits wrong information to the CITY to obtain a badge, key or applicable Background Screening; or (v) Contractor fails to collect and timely return contract worker’s badge or key upon termination of contract worker’s employment, reassignment of contract worker to another CITY facility or upon the expiration, cancellation or termination of the Contract. Contractor acknowledges and agrees that the access control, badge and key requirements in this section are necessary to preserve and protect public health, safety and welfare. Accordingly, Contractor agrees to properly cure any default under this section within three (3) business days from the date notice of default is sent by the CITY. The parties agree that Contractor failure to properly cure any default under this section shall constitute a breach of this section. In addition to any other remedy available to the CITY at law or in equity, Contractor shall be liable for and shall pay to the CITY the sum of one thousand dollars ($1,000.00) for each breach by Contractor of this section. The parties further agree that the sum fixed above is reasonable and approximates the actual or anticipated loss to the CITY at the time and making of the Contract in the event that Contractor breaches this section. Further, the parties expressly acknowledge and agree to the fixed sum set forth above because of the difficulty of proving the CITY’s actual damages in event that Contractor breaches this section. The parties further agree that three (3) breaches by Contractor of this section arising out of any default within a consecutive period of three (3) months or three (3) breaches by Contractor of this section arising out of the default within a period of twelve (12) consecutive months shall constitute a material breach of this contract by Contractor and the CITY expressly reserves all of its rights, remedies and interests under the contract by Contractor and the CITY expressly reserves all of its rights, remedies and interests under the Contract, at law and in equity including, but not limited to, termination of the Contract. Badge, Intrusion Breach and Key Fees. The following constitute the badge and key fees under this contract. The CITY reserves the right to amend these fees upon thirty (30) days prior written notice to Contractor. Initial Badge Fee: $ 55.00 per applicant Replacement Badge Fee: $ 55.00 per badge Lost / Stolen Badge Fee: $ 55.00 per badge Replacement Key Fee: $ 55.00 per key Additional/Lost /Stolen Key Fee: $ 55.00 per key



130

Additional/Replacement Locks $ 55.00 per lock Intrusion Alarm Breach $75.00 per occurrence and failing to notify Central Monitoring System (CMS) at time of breach causing a False Alarm Charge.



131

SECTION 6 – GENERAL TERMS AND CONDITIONS Contractor agrees that the CITY will prepare any Contract awarded. Contractor will not insist on or use its standard contract, terms and conditions, or other documents or forms. Under the Phoenix City Charter, the City Attorney must draft the Contract to be executed. The Contract form is Attachment C. Contractor has carefully read the draft Contract and agrees to be bound as written except for those exceptions clearly and specifically indicated as required in Section 3.8 and agreed to by the CITY. 6.1 EQUAL EMPLOYMENT OPPORTUNITY

CONTRACTOR shall not discriminate against any worker, employee or applicant, or any member of the public, because of race, color, religion, sex, national origin, age, or disability nor otherwise commit an unfair employment practice. CONTRACTOR shall ensure that applicants are employed, and employees are dealt with during employment without regard to their race, color, religion, sex, national origin, age, or disability. Such action shall include but not be limited to the following: employment, promotion, demotion or transfer; recruitment or recruitment advertising; layoff or termination; rate of pay or other forms of compensation; and selection for training; including apprenticeship. This clause must be incorporated in all subcontracts with all labor organizations furnishing skilled, unskilled and union labor, or who may perform any such labor or services in connection with this Agreement. CONTRACTOR further agrees that this clause will be incorporated in all subcontracts, job-consultant agreements or subleases of this Agreement.

6.2 NON-WAIVER OF LIABILITY In execution of the public trust, the CITY (as a public entity supported by tax revenues) cannot agree to waive any lawful right to recover amounts due it. Therefore, Contractor may not insist upon or demand any agreement by which the CITY limits in advance or waives any right the CITY might have to recover damages in any court under applicable Arizona law. Contractor may not take exception to this Section, and any attempt to do so during the solicitation phase will render the CITY’s proposal nonresponsive.

6.3 CONTRACT OVERSIGHT The CITY shall assign staff to provide day-to-day oversight of the Contract. Contract monitoring and on-site inspections will be conducted routinely to ensure compliance with the Contract’s terms and conditions.

6.4 LICENSES AND PERMITS Contractor must be and remain current with all federal, state, and local licenses and permits required to perform Contractor’s work under this Contract.

6.5 LEGAL WORKER REQUIREMENTS The CITY is prohibited by A.R.S. § 41-4401 from awarding a Contract to any Contractor who fails, or whose subcontractors fail, to comply with A.R.S. § 23-214(A). Therefore, Contractor agrees that: A. Contractor and each subcontractor it uses warrants their compliance with all federal immigration

laws and regulations that relate to their employees and their compliance with A.R.S. § 23-214, subsection A.

B. A breach of a warranty under paragraph A shall be deemed a material breach of the Contract that

is subject to penalties up to and including termination of the Contract.



132

C. The CITY retains the legal right to inspect the records and any other documents of any Contractor or subcontractor employee who works on the Contract to ensure that Contractor or subcontractor is complying with the warranty under paragraph A.

6.6 DAMAGE TO CITY PROPERTY Contractor shall perform all work so that no damage to the City building or grounds results. Contractor shall repair any damage caused to the CITY’s satisfaction at no cost to the CITY. Contractor shall exercise care to avoid damage to adjacent finished materials that are to remain. If finished materials are damaged, Contractor shall repair and finish to match existing materials as approved by the CITY at Contractor’s expense.

6.7 CONTRACTOR INCURRED RISKS The CITY does not assume any responsibility or liability, at any time, for the protection or loss of materials from the time Contract operations commence until Contract expiration. Any such loss, injury or destruction will not release Contractor from any obligations under the Contract.

6.8 FAILURE TO COMPLY If any services performed or equipment provided under the Contract are not in conformity with all Contract requirements, the CITY may require Contractor to immediately take all necessary steps to ensure that future services performed will conform to the Contract. The CITY may reduce the Contract price to reflect the actual value of the equipment provided or services performed. If Contractor fails to promptly take necessary steps to ensure that future equipment provided or services performed conform to the requirements of the Contract, the CITY may terminate the Contract for default.

6.9 CONTRACT CLOSEOUT At the end of the Contract, the CITY shall review the Contract to ensure all required deliverables have been met. This includes, but is not limited to, an audit of Contractor’s financial and operational records and an inspection of all CITY equipment provided to Contractor. Any outstanding issues must be resolved within thirty (30) days of Contract completion, at which time a Notice of Contract Closure must be sent by the CITY to finalize the Contract closure between the parties. Contractor shall keep all Contract-related records for a minimum of five (5) years after Contract completion, expiration or termination. Upon twenty-four (24) hour notice, Contractor shall make available all records to the CITY or its agents for audit during normal business hours. In the event of litigation or claims related to the Contract, Contractor shall maintain all records until the litigation or claim is concluded or five (5) years after the end of the Contract, whichever last occurs.

6.10 TRANSITION COOPERATION AGREEMENT Upon the expiration, termination or other conclusion of this Agreement and of Contractor’s rights and obligations under the Agreement, the parties anticipate that City will select a successor provider to perform the same or similar work. The parties further acknowledge that the successor provider may be Contractor or another individual, firm or entity. If the successor provider is an individual, firm or entity other than Contractor, then Contractor shall cooperate fully with the successor provider to effect a smooth and seamless transition. This cooperation must include, but is not limited to, the following.



133

1) Contractor shall share and permit the copying of all books and records necessary or convenient for the successor provider to undertake its work. These records include, but are not limited to, maintenance records, inventory records, supplier contracts, and support Agreements.

2) If original records are necessary for the successor provider to properly perform its legal obligations, Contractor shall provide the originals to the successor, and Contractor shall keep copies of them.

3) Contractor shall execute documents necessary to effect a transfer of all contracts, goods, and services.

4) Contractor shall not sell, transfer, convey or encumber any City assets or any of the assets to be transferred to the successor provider.

5) Contractor shall maintain all inventory levels necessary for the successor provider to continue to perform the work.

6) As City may direct, Contractor shall surrender to the successor provider or to CITY all CITY-owned real, personal and/or intellectual property.

7) Contractor shall inventory all property (real, personal or mixed) purchased or leased with City funds and all property in which City has an ownership or possessory interest. Contractor shall include a description of the property and its location in sufficient detail to permit easy identification.

Until the date that the successor provider assumes its position, Contractor shall fully and conscientiously perform its obligations under this Agreement in a professional and workmanlike manner. If City elects to perform the same or similar work using City forces, Contractor’s duty of cooperation, as described above, shall extend to City as the successor provider.

6.11 HAZARDOUS MATERIALS REQUIREMENTS – SDS Contractor shall comply with the following: A. SAFETY DATA SHEETS – Contractor shall furnish to the CITY copies of the Safety Data

Sheets (SDS), for all products used, prior to beginning service. Contractor must update copies of the SDS on an annual basis. In addition, each time a new chemical or cleaning product is introduced, any copy of that product’s MSDS must be provided to the CITY prior to product use. The Safety Data Sheets must be in compliance with OSHA Regulation 1910.1200, paragraph g.

B. LABELING of HAZARDOUS MATERIALS – Contractor must comply with the OSHA Regulation 1919.1200 paragraph f, concerning the labeling of all chemical containers.

C. CAUTION SIGNS – Contractor shall use caution signs as required by OSHA Regulation 1910.144 and 1910.145 at no cost to the CITY. Caution signs must be on-site during each scheduled cleaning.

D. OSHA GUIDELINES BLOOD PATHOGENS – Contractor shall comply with OSHA Standard 29CFR 1910.1030 Blood Borne Pathogens as it pertains to the training, safety, and equipment needed for all employees engaged in contracted service. Contractor shall be responsible for compliance on the Contract start date and shall provide proof to the CITY’s Public Transit Department.



134

Proof of compliance with OSHA regulation 1920.1200, Hazard Communication, shall be provided to the CITY’s Public Transit Department upon commencement of this Contract. Failure of Contractor or its employees to comply with all applicable laws and rules may result in Contract termination without liability.

E. SDS Notebooks Contractor shall maintain on the site or provide to the CITY a notebook containing current (dated within the past three years or verified as most current by manufacturer) SDS for all materials being used on-site, whether or not they are defined as a Hazardous Material. The notebook shall be kept in the CITY’s on-site storage area. The notebook must be kept up-to-date as materials are brought onto and removed from the site. A complete copy of the SDS notebook shall be provided to the CITY. New products must be approved for use by the CITY by providing a copy of the product’s SDS for review and approval.

F. Emergency Spill Response Plan Contractor shall prepare an emergency spill response plan for all hazardous material used. A plan for directing employees in proper response procedures must be submitted. At a minimum, the response plan must address the following: 1) Description of equipment on site available to contain and/or respond to an

emergency/spill of the material. 2) Notification procedures. 3) The response coordination procedures between Contractor and the CITY. 4) A site plan showing the location of stored hazardous materials and location of spill

containment/response equipment. 5) Description of the training provided to Contractor’s employees. 6) Hazardous Materials Storage and Labeling Specifications. 7) Contractor shall, to the satisfaction of the CITY’s environmental representative, properly

and safely store all hazardous materials, which shall include the following: a) Have a designated storage site for hazardous material, which includes secondary

containment. b) Provide CITY approved signage which clearly identifies the hazardous materials

storage site. Signage must be in a language understood by Contractor’s on-site employees.

c) Label all hazardous materials containers according to OSHA requirements, and bear applicable NFPA or HMIS labels.

8) Non Hazardous Materials Labeling Specifications 9) Contractor shall clearly label all packaged products, whether or not they are classified as

Hazardous Materials under this section. Any containers that are filled from larger containers must also be labeled.

10) Offsite Storage of Hazardous Materials The CITY encourages storage of hazardous materials off-site until the materials are needed.

11) Hazardous Materials Management Program Documentation Contractor shall make all required documentation available immediately upon request of the CITY’s environmental representative. Contractor shall also provide the CITY’s environmental representative with copies of all permits obtained from environmental regulatory agencies.



135

12) Contractor Training Requirements Contractor shall provide requested copies of the company’s written Hazardous Communications Program to the CITY that satisfies requirements listed under sections e.,f.,g.,and h. of 29 CFR 1910.1200, Hazard Communications. Contractor must demonstrate how employees are trained in the proper use, storage, and disposal of chemical products and wastes in a language understood by Contractor’s on-site employees.

6.12 COMPLIANCE WITH HAZARDOUS MATERIALS MANAGEMENT, POLLUTION PREVENTION, AND

SPILL PREVENTION, RESPONSE AND REPORTING POLICIES Contractor must incorporate the intent and applicable aspects of the CITY hazardous materials management program, pollution prevention policy, and spill prevention, response and reporting program. Areas of responsibility will include, but are not limited to, environmental health and safety, hazardous materials management, air quality management and permitting, wastewater management, storm water management, and pollution prevention. Contractor must obtain all required regulatory environmental permits, including permit fees, necessary for conducting facilities maintenance operations at the facility. Contractor shall prepare all annual reports and other routinely required documentation required to maintain facility compliance. Contractor will work closely with facility staff to ensure that daily operations comply with environmental requirements. CITY staff may conduct periodic on-site inspections to ensure work procedures and record keeping, equipment/product labeling, signage, and personal protective equipment meet the regulatory requirements. Contractor shall be responsible for maintaining an updated facility chemical inventory, developing an environmental record keeping system, and ensuring employee environmental training.



136

SECTION 7 - FEDERAL TRANSIT ADMINISTRATION REQUIRED CLAUSES This procurement is being funded, in whole or in part, with federal funds through Federal Transit Administration (FTA). As consequence of that funding, the following FTA mandated provisions are included in this RFP. 7.1 NO OBLIGATION BY THE FEDERAL GOVERNMENT

The CITY and Contractor acknowledge and agree that:

A. Notwithstanding any concurrence by the Federal Government in or approval of the solicitation or award of this Contract, absent the express written consent by the Federal Government, the Federal Government is not a party to the Contract and shall not be subject to any obligations or liabilities to the CITY, Contractor, or any other party (whether or not a party to that contract) pertaining to any matter resulting from this Contract.

B. The Contractor shall include the above clause in each subcontract financed in whole or in part with Federal assistance provided by FTA. It is further agreed that the clause shall not be modified, except to identify the sub-Contractor who will be subject to its provisions.

7.2 PROGRAM FRAUD AND FALSE OR FRAUDULENT STATEMENTS OR RELATED ACTS The Contractor acknowledges and agrees that:

A. The provisions of the Program Fraud Civil Remedies Act of 1986, as amended, 31 U.S.C. §§

3801 et seq., and U.S. DOT regulations,” Program Fraud Civil Remedies,” 49 C.F.R. Part 31, apply to its actions pertaining to this project. Upon execution of the Contract, the Contractor certifies or affirms the truthfulness and accuracy of any statement it has made, it makes, it may make, or causes to be made, pertaining to this Contract or the FTA assisted project for which work under this Contract is being performed. In addition to other penalties that may be applicable, the Contractor further acknowledges that if it makes, or causes to be made, a false, fictitious, or fraudulent claim, statement, submission, or certification, the Federal Government reserves the right to impose the penalties of the Program Fraud Civil Remedies Act of 1986 on the Contractor to the extent the Federal Government deems appropriate.

B. If the Contractor makes, or causes to be made, a false, fictitious, or fraudulent claim, statement, submission, or certification to the Federal Government under a contract connected with a project that is financed in whole or in part with federal assistance originally awarded by FTA under the authority of 49 U.S.C. § 5307, the Federal Government reserves the right to impose the penalties of 18 U.S,C, § 1001 and 49 U.S.C. § 5307(n)(1) on the Contractor, to the extent the Federal Government deems appropriate.

C. The Contractor shall include the above two (2) clauses in each subcontract financed in whole or in part with federal assistance provided by FTA and each such clause shall not be modified, except to identify the subcontractor who will be subject to the provisions.

7.3 ACCESS TO RECORDS

A. In accordance with 49 C.F,R, 18,36(i), the Contractor shall provide the CITY, the FTA

Administrator, the Comptroller General of the United States or any of their authorized representatives access to any books, documents, papers and records of the Contractor which are directly pertinent to this Contract for the purposes of making audits, examinations, excerpts



137

and transcriptions. Pursuant to 49 C.F.R. 633.17, the Contractor shall provide the FTA Administrator or his authorized representatives including any PMO contractor access to Contractor’s records and construction sites pertaining to a major capital project, defined at 49 U.S.C. 5302(a)1, which is receiving federal financial assistance through the programs described at 49 U.S.C. 5307, 5309 or 5311.

B. Contractor shall permit any of the foregoing parties to reproduce by any means whatsoever or to copy such excerpts and transcriptions as are reasonably needed.

C. Contractor shall maintain all books, records, accounts and reports required under this Contract for a period of not less than three years after the date of termination or expiration of this Contract, except in the event of litigation or settlement of claims arising from the performance of this Contract, in which case the Contractor agrees to maintain same until the CITY, the FTA Administrator, the Comptroller General, or any of their duly authorized representatives, have disposed of all such litigation, appeals, claims or exceptions related thereto. Reference 49 CFR 18.39(i)(11).

D. FTA does not require the inclusion of these requirements in subcontracts.

7.4 FEDERAL CHANGES The Contractor shall at all times comply with all applicable FTA regulations, policies, procedures and directives, including without limitation those listed directly or by reference in the Master Agreement between the CITY and the FTA, as they may be amended or promulgated from time to time during the term of the Contract. Contractor’s failure to so comply shall constitute a material breach of the Contract.

7.5 CIVIL RIGHTS The following requirements apply to this Contract:

A. Nondiscrimination - In accordance with Title VI of the Civil Rights Act, as amended, 42 U.S.C. §

2000d, section 303 of the Age Discrimination Act of 1975, as amended, 42 U.S.C. § 6102, section 202 of the Americans with Disabilities Act of 1990, 42 U.S.C. § 12132, and Federal transit law at 49 U.S.C. § 5332, the Contractor shall not discriminate against any employee or applicant for employment because of race, color, creed, national origin, sex, age, or disability. In addition, the Contractor shall comply with applicable Federal implementing regulations and such other implementing requirements FTA may issue.

B. Equal Employment Opportunity - The following equal employment opportunity requirements apply to the underlying contract: Race, Color, Creed, National Origin, Sex - In accordance with Title VII of the Civil Rights Act, as amended, 42 U.S.C. § 2000e, and Federal transit laws at 49 U.S.C. § 5332, the Contractor agrees to comply with all applicable equal employment opportunity requirements of U.S. Department of Labor (U.S. DOL) regulations, "Office of Federal Contract Compliance Programs, Equal Employment Opportunity, Department of Labor," 41 C.F.R. Parts 60 et seq ., (which implement Executive Order No. 11246, "Equal Employment Opportunity," as amended by Executive Order No. 11375, "Amending Executive Order 11246 Relating to Equal Employment Opportunity," 42 U.S.C. § 2000e note), and with any applicable federal statutes, executive orders, regulations, and federal policies that may in the future affect construction activities



138

undertaken in the course of the project. The Contractor agrees to take affirmative action to ensure that applicants are employed, and that employees are treated during employment, without regard to their race, color, creed, national origin, sex, or age. Such action shall include, but not be limited to, the following: employment, upgrading, demotion or transfer, recruitment or recruitment advertising, layoff or termination; rates of pay or other forms of compensation; and selection for training, including apprenticeship. In addition, the Contractor shall comply with any implementing requirements FTA may issue. Age - In accordance with section 4 of the Age Discrimination in Employment Act of 1967, as amended, 29 U.S.C. § § 623 and federal transit law at 49 U.S.C. § 5332, the Contractor agrees to refrain from discrimination against present and prospective employees for reason of age. In addition, the Contractor shall comply with any implementing requirements FTA may issue. Disabilities - In accordance with section 102 of the Americans with Disabilities Act, as amended, 42 U.S.C. § 12112, the Contractor agrees that it will comply with the requirements of U.S. Equal Employment Opportunity Commission, "Regulations to Implement the Equal Employment Provisions of the Americans with Disabilities Act," 29 C.F.R. Part 1630, pertaining to employment of persons with disabilities. In addition, the Contractor shall comply with any implementing requirements FTA may issue.

C. The Contractor shall include these requirements in each subcontract financed in whole or in part with federal assistance provided by FTA, modified only if necessary to identify the affected parties.

D. For assistance with a contract clause incorporating the requirements of the new DBE rule in 49 CFR Part 26, contact the FTA HelpLine at www.ftahelpline.com.

7.6 TERMINATION

A. Termination for Convenience. CITY may terminate this contract in whole or in part, at any time by written notice to Contractor when, in CITY’s sole and unfettered opinion, it is in CITY’s best interest to do so. Contractor shall be paid its costs, including contract close-out costs, and profit on work performed up to the date of termination. Contractor shall promptly submit its termination claim to CITY for payment together with such supporting documentation as CITY may require. If Contractor has any property in its possession belonging to CITY, Contractor shall account for same, and dispose of it in such manner as CITY may direct. When the Notice of Termination is received, Contractor shall immediately consult with CITY as to the goods and materials then on order or that are in place and as to its plan to further the work had the contract not been terminated. After such consultation, Contractor shall take whatever action CITY may direct with regard to goods and materials, e.g., cancel orders; retain, sell or otherwise dispose of the goods and materials; begin winding up work or continue to prosecute it.

B. Termination for Cause. Subject to Contractor’s right to cure pursuant to the provisions of

paragraph (D) below, if Contractor: (a) fails to provide any of the deliverables as specified herein within the time specified in this contract or any extension thereof; or, (b) fails to perform any of the other material provisions of this contract, CITY may terminate this contract for cause. Failure to perform includes, but is not limited to: in the opinion of CITY, Contractor attempts to impose on CITY personnel or materials, products or workmanship that is of an unacceptable quality; and, Contractor fails to furnish the required service and/or product within the time set



139

forth in this contract. If, after termination for failure to fulfill contract obligations, it is determined that Contractor was not in default, or that the delay was excusable, the rights and obligations of the parties will be the same as if the termination had been one for convenience. Provided, however, that if it is determined that Contractor was not in default, or that the delay was excusable, then, and in that event, CITY may, at its sole and unfettered discretion, require Contractor to continue its performance to completion and shall, if appropriate under the circumstances, allow additional time for such performance to be completed and shall pay Contractor its costs of delay, demobilization and remobilization if appropriate.

C. Notice of Termination. Termination, whether for Convenience in accordance with paragraph (A)

above, or for Default, Breach, or Cause in accordance with paragraph (B) above, shall be upon no less than thirty (30) calendar days prior written notice. Such termination shall be effected by CITY delivering a Notice of Termination to Contractor specifying: (a) the nature of the default, if any; (b) the extent of the termination, i.e., whether in whole or in part and, if in part, the part being terminated; and, (c) the date upon which the termination is to take effect.

D. Opportunity to Cure. Prior to termination for Default, Breach, or Cause and CITY’s right to

terminate, the CITY, after consultation with Contractor, will deliver to Contractor a Notice to Cure and allow Contractor thirty (30) calendar days (or such other period agreed upon between Contractor and CITY) within which Contractor shall proceed to correct and cure the defect; thereafter, Contractor shall diligently pursue such cure to completion. The Notice to Cure will state the time period within which cure is permitted together with other appropriate reasonable conditions. If Contractor fails to proceed to correct and cure the breach or default of any of the terms, covenants, or conditions of this contract within thirty (30) calendar days (or such other period agreed upon between Contractor and CITY) after receipt by Contractor of written Notice to Cure from CITY setting forth the nature of said breach or default, then, and in that event, CITY shall have the right to terminate this contract by delivering a Notice of Termination for Default, Breach or Cause in accordance with paragraph (B) above. Any such termination for cause shall not operate in any way to preclude CITY from also pursuing all of its other available remedies against Contractor and its sureties for said breach or default.

7.7 INCORPORATION OF FTA TERMS

The preceding provisions include, in part, certain Standard Terms and Conditions required by the U.S. Department of Transportation (DOT), whether or not expressly set forth in the preceding contract provisions. All contractual provisions required by DOT, as set forth in FTA Circular 4220.1F, dated November 1, 2008, are hereby incorporated by reference. Anything to the contrary herein notwithstanding, all FTA mandated terms shall be deemed to control in the event of a conflict with other provisions contained in the contract. The Contractor shall not perform any act, fail to perform any act, or refuse to comply with any requests of the CITY that would cause the CITY to be in violation of the FTA terms and conditions.



140

7.8 CERTIFICATION REGARDING DEBARMENT AND SUSPENSION

In accordance with the U.S. Office of Management and Budget (OMB) “Guidelines to Agencies on Governmentwide Debarment and Suspension (Nonprocurement)” 2 C.F.R. Part 180 and U.S. DOT regulations, “Nonprocurement Suspension and Debarment,” 2 C.F.R. Part 1200, Contractor must provide certification that neither it nor its “principals” are presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from covered transactions by a federal department or agency. Contractor, as a condition of responsiveness, shall submit with their bid submittal a completed “Debarment and Suspension” form, which is located in Section 8.5 of this RFP. Contractor shall also include these requirements in each subcontract exceeding $25,000 financed in whole or part with federal assistance provided by FTA.

7.9 BUY AMERICA The Contractor shall comply with 49 U.S.C. 5323(j) and 49 CFR Part 661, which provide that Federal funds may not be obligated unless steel, iron, and manufactured products used in FTA funded projects are produced in the United States, unless a waiver has been granted by FTA or the product is subject to a general waiver. General waivers are listed in 49 CFR 661.7, and include final assembly in the United States for 15 passenger vans and 15 passenger wagons produced by Chrysler Corporation, microcomputer equipment, software, and small purchase (currently less than $100,000) made with capital, operating, or planning funds. Contractor, as a condition of responsiveness, shall complete and submit the “Buy America” certification form with their bid. The form to complete is in Section 8.7 of this RFP.

7.10 DISPUTES

Disputes arising in the performance of this Contract that are not resolved by agreement of the parties shall be decided in writing by the Contract Specialist (Lead) or his designee. This decision shall be final and conclusive unless within ten (10) calendar days from the date of receipt of its copy, the Contractor mails or otherwise furnishes a written appeal to the Public Transit Director or the Director’s designee. In connection with any such appeal, the Contractor shall be afforded an opportunity to be heard and to offer evidence in support of its position. The decision of the Public Transit Director or the Director’s designee shall be binding upon the Contractor and the Contractor shall abide by the decision. Performance During Dispute: Unless otherwise directed by the CITY, the Contractor shall continue performance under the Contract while matters in dispute are being resolved unless such performance is refused by CITY or is enjoined or prohibited by an Arizona court of competent jurisdiction. Claims for Damages: Should either party to this Contract suffer injury or damage to person or property because of any act or omission of the other party or of any of his employees, agents or others for whose act it is legally liable, a claim for damages therefore shall be made in writing to such other party within five (5) calendar days after the first observance of such injury of damage. Remedies: Unless this Contract provides otherwise, all claims, counterclaims, disputes and other matters in question between the CITY and the Contractor arising out of or relating to this Contract or its breach will be decided by arbitration.



141

Rights and Remedies: The duties and obligations imposed by the Contract documents and the rights and remedies available thereunder shall be in addition to and not a limitation of any duties, obligations, rights and remedies otherwise imposed or available by law. No action or failure to act by the CITY or the Contractor shall constitute a waiver of any right or duty afforded any of them under this Contract, nor shall any such action or failure to act constitute an approval of or acquiescence in any breach thereunder, except as may be specifically agreed upon in writing.

7.11 LOBBYING Byrd Anti-Lobbying Amendment, 31 U.S.C. 1352, as amended by the Lobbying Disclosure Act of 1995, P.L. 104-65 [to be codified at 2 U.S.C. § 1601, et seq.] - Contractors who apply or bid for an award of $100,000 or more shall file the certification required by 49 CFR part 20, "New Restrictions on Lobbying." Each tier certifies to the tier above that it will not and has not used Federal appropriated funds to pay any person or organization for influencing or attempting to influence an officer or employee of any agency, a member of Congress, officer or employee of Congress, or an employee of a member of Congress in connection with obtaining any Federal contract, grant or any other award covered by 31 U.S.C. 1352. Each tier shall also disclose the name of any registrant under the Lobbying Disclosure Act of 1995 who has made lobbying contacts on its behalf with non-Federal funds with respect to that Federal contract, grant or award covered by 31 U.S.C. 1352. Such disclosures are forwarded from tier to tier up to the recipient. The "Lobbying Certification" form, Section 8.6 of this RFP, must be completed, signed and submitted with Contractor’s bid.

7.12 CLEAN AIR The Contractor shall comply with all applicable standards, orders or regulations issued pursuant to the Clean Air Act, as amended, 42 U.S.C. §§ 7401 et seq. The Contractor shall report each violation to the CITY and understands and agrees that the CITY will, in turn, report each violation as required to assure notification to FTA and the appropriate EPA Regional Office. The Contractor shall also include these requirements in each subcontract exceeding $100,000 financed in whole or part with federal assistance provided by FTA.

7.13 CLEAN WATER The Contractor shall comply with all applicable standards, orders or regulations issued pursuant to the

Federal Water Pollution Control Act, as amended, 33 U.S.C. 1251 et seq. Contractor shall report each violation to the CITY and understands and agrees that the CITY will, in turn, report each violation as required to assure notification to FTA and the appropriate EPA Regional Office.

The Contractor shall also include these requirements in each subcontract exceeding $100,000 financed in whole or in part with Federal assistance provided by FTA.

7.14 CARGO PREFERENCE – USE OF UNITED STATES-FLAG VESSELS

Contractor shall: (a) use privately owned United States flag commercial vessels to ship at least 50 percent of the gross tonnage (computed separately for dry bulk carriers, dry cargo liners and tankers) involved, whenever shipping any equipment, material or commodities pursuant to the Contract, to the extent such vessels are available at fair and reasonable rates for United States - Flag commercial vessels; (b) furnish within twenty (20) working days following the date of loading for shipments originating within the United States or within thirty (30) working days following the date of loading for shipments originating outside the United States, a legible copy of a rated, “onboard” commercial ocean bill-of-lading in English for each shipment of cargo described in the preceding paragraph to the Division



142

of National Cargo, Office of Market Development, Maritime Administration, Washington, D.C. 20590, and to the CITY, the FTA recipient (through the Contractor in the case of a subcontractor’s bill-of-lading); and, (c) include these requirements in all subcontracts issued pursuant to this Contract when the subcontract may involve the transport of equipment, material, or commodities by ocean vessel.

7.15 FLY AMERICA

Contractor shall comply with 49 U.S.C. 40118 (the "Fly America" Act) in accordance with the General Services Administration's regulations at 41 CFR Part 301-10, which provide that recipients and subrecipients of federal funds and their contractors are required to use U.S. Flag air carriers for U.S Government-financed international air travel and transportation of their personal effects or property, to the extent such service is available, unless travel by foreign air carrier is a matter of necessity, as defined by the Fly America Act. If a foreign air carrier was used, Contractor shall submit an appropriate certification or memorandum adequately explaining why service by a U.S. flag air carrier was not available or why it was necessary to use a foreign air carrier and shall, in any event, provide a certificate of compliance with the Fly America requirements. Contractor shall include the requirements of this section in all subcontracts that may involve international air transportation.

7.16 PRIVACY ACT Contracts Involving Federal Privacy Act Requirements - The following requirements apply to the Contractor and its employees that administer any system of records on behalf of the Federal Government under any contract: A. Contractor agrees to comply with, and assures the compliance of its employees with, the

information restrictions and other applicable requirements of the Privacy Act of 1974, 5 U.S.C. § 552a. Among other things, the Contractor agrees to obtain the express consent of the Federal Government before the Contractor or its employees operate a system of records on behalf of the Federal Government. The Contractor understands that the requirements of the Privacy Act, including the civil and criminal penalties for violation of that Act, apply to those individuals involved, and that failure to comply with the terms of the Privacy Act may result in termination of the underlying contract.

B. Contractor also agrees to include these requirements in each subcontract to administer any system of records on behalf of the Federal Government financed in whole or in part with Federal assistance provided by FTA.

7.17 ENERGY CONSERVATION Contractor shall comply with mandatory standards and policies relating to energy efficiency that are contained in the State of Arizona Energy Conservation plan issued in compliance with the Energy Policy and Conservation Act (P.L. 94-163).

7.18 RECYCLED PRODUCTS

Contractor agrees to comply with all the requirements of §6002 of the resource Conservation and Recovery Act, as amended (42 U.S.C. 6962), including but not limited to the regulatory provisions of 40 CFR Part 247, and Executive Order 12873, as they apply to the procurement of the items designated in Subpart B of 40 CFR Part 247.



143

7.19 ACCESS REQUIREMENTS FOR PERSONS WITH DISABILITIES (ADA)

Contractor agrees to comply with the requirements of 49 U.S.C. § 5301(d) which expresses the federal policy that the elderly and persons with disabilities have the same right as other persons to use mass transportation services and facilities, and that special efforts shall be made in planning and designing those services and facilities to implement those policies. Contractor also agrees to comply with all applicable requirements of section 504 of the Rehabilitation Act of 1973, as amended, 29 U.S.C. § 794, which prohibits discrimination on the basis of handicaps, and with the Americans with Disabilities Act of 1990 (ADA), as amended, 42 U.S.C. §§ 12101 et seq., which requires the provision of accessible facilities and services, and all other federal regulations.

7.20 NATIONAL TRANSPORTATION COMMUNICATIONS FOR ITS PROTOCOL

Contractor shall comply with relevant National Transportation Communications for ITS Protocol (NTCIP) specifications, including those found in service package APTS and comply with all physical and logical architecture requirements associated thereto. Reference: 49CFR, Part 940. Contractor shall provide all hardware and software to provide fully integrated ITS and Communications Systems that perform the functions as specified in this specification and all other equipment specifications for the ITS and Communications Systems. Contractor is herein notified that this project is listed as an element of the Maricopa Association of Governments (MAG) Regional ITS Architecture which was last updated June 2013. The MAG Regional ITS Architecture is available online at http://azmag.gov/ITS/.

7.21 DISADVANTAGED BUSINESS ENTERPRISE (DBE) PROGRAM

SECTION I. DEFINITIONS Agency means the City of Phoenix for purposes of this Contract. Arizona Unified Certification Program (AZUCP) means a consortium of government agencies organized to provide reciprocal DBE certification within Arizona pursuant to 49 Code of Federal Regulations (CFR) Part 26. The official DBE database containing eligible DBE firms certified by AZUCP can be accessed at: https://adot.dbesystem.com. The certification system is called the Arizona Unified Transportation Registration and Certification System (AZ UTRACS). Commercially Useful Function means that a DBE is responsible for executing the work of the contract and is carrying out its responsibilities by actually performing, managing, and supervising the work involved. If a DBE does not perform or exercise responsibility for at least 30% of the total cost of its contract with its own work force, or if the DBE subcontracts a greater portion of the work of a contract than would be expected on the basis of normal industry practice for the type of work involved, the DBE is presumed not to be performing a Commercially Useful Function. Contract means a legally binding relationship obligating a seller to furnish supplies or services (including construction and professional services) and the buyer to pay for them. DBE stands for disadvantaged business enterprise. In this context, DBE means a Small Business Concern that has successfully completed the DBE certification process and has been granted DBE status by the City of Phoenix or another AZUCP member pursuant to the criteria contained in 49 CFR Part 26.



144

DBE Compliance Specialist means an Agency employee responsible for compliance with this DBE Contract Clause. EOD means the City of Phoenix Equal Opportunity Department. Joint Venture (JV) means an association between two or more persons, partnerships, corporations, or any combination thereof, formed to carry on a single business activity. One participant in the JV arrangement must be a certified DBE with the City of Phoenix or AZUCP. The JV is limited in scope and duration to this Contract. The resources, assets, and labor of the participants must be combined in an effort to accrue profit. Outreach Efforts means the diligent and good-faith efforts demonstrated by a Submitter to solicit participation from interested and qualified DBEs and other Small Businesses. Submitter shall identify and document potential business opportunities for DBEs and other Small Businesses, describe what efforts were undertaken to solicit DBE and Small Business participation, disclose results of negotiations with DBEs and Small Businesses, communicate and record Submitter’s selection decisions relating to DBE and Small Business participants. Race- and Gender-Neutral (RGN) Measures means a measure or program that is, or can be, used to assist all Small Businesses. Small Business means, with respect to firms seeking to participate as DBEs in contracts funded by the U.S. Department of Transportation (US DOT), a Small Business Concern as defined in section 3 of the Small Business Act and Small Business Administration regulations implementing the Act (13 CFR part 121), which Small Business Concern does not exceed the cap on average annual gross receipts specified in 49 CFR § 26.65(b). “Small Business” and “Small Business Concern” are used interchangeably in this DBE Contract Clause. Subcontract means a contract at any tier below the prime contract, including a purchase order. Subcontractor means an individual, partnership, JV, corporation or firm that holds a contract at any tier below the prime contract, including a vendor under a purchase order. Submitter means an individual, partnership, JV, corporation or firm that tenders a submittal to the Agency to perform services requested by a solicitation or procurement. The submittal may be direct or through an authorized representative. Successful Submitter means a firm that has been selected by the Agency to perform services or furnish supplies requested by a solicitation or procurement. SECTION II. GENERAL REQUIREMENTS

A. DBE Participation. For this solicitation, the Agency has not established a race- or gender-conscious DBE participation goal. The Agency extends to each individual, firm, vendor, supplier, contractor, and subcontractor an equal economic opportunity to compete for business. The Agency uses race- and gender-neutral measures to facilitate participation by DBEs and Small Businesses. The Agency encourages each Submitter to voluntarily subcontract with DBEs and Small Businesses to perform part of the work—a Commercially Useful Function—that Submitter might otherwise perform with its own forces.



145

B. Applicable Federal Regulations. This Contract is subject to DBE requirements issued by USDOT in 49 CFR Part 26. Despite the lack of a race- and gender-conscious DBE participation goal for this Contract, the Agency must track and report DBE participation that occurs as a result of any subcontract, procurement, JV, or other arrangement involving a DBE. For this reason, the Successful Submitter shall provide all relevant information to enable the required reporting.

C. Counting DBE Participation. The Agency will count DBE participation as authorized by federal regulations. A summary of these regulations can be found at phoenix.gov/eod.

D. DBE Certification. Only firms (1) certified by the Agency or another AZUCP member, and (2) contracted to perform a Commercially Useful Function on scopes of work for which they are certified, may be considered to determine DBE participation resulting from RGN measures on this Contract. This DBE determination affects the Agency’s tracking and reporting obligations to USDOT.

E. Civil Rights Assurances. As a recipient of USDOT funding, the Agency has agreed to abide by the assurances found in 49 CFR Parts 21 and 26. Each Contract signed by the Agency and the Successful Submitter, and each Subcontract signed by the Successful Submitter and a Subcontractor, must include the following assurance verbatim:

“The contractor, subrecipient, or subcontractor shall not discriminate on the basis of race, color, national origin, sex, or creed in the performance of this contract. The contractor shall carry out applicable requirements of 49 CFR Parts 21 and 26 in the award and administration of USDOT-assisted contracts. Failure by the contractor to carry out these requirements is a material breach of this contract, which may result in the termination of this contract or such other remedy as the City of Phoenix deems appropriate.”

Note: For purposes of the required Contract and Subcontract language above, the Successful Submitter is the “contractor.”

SECTION III. REQUIRED OUTREACH EFFORTS The Agency has implemented outreach requirements for this Contract. Specifically, each Submitter will, prior to submission: (1) identify DBE and Small Business participation opportunities, including Commercially Useful Functions; (2) actively solicit proposals from DBEs and Small Businesses; (3) evaluate DBE and Small Business proposals; and (4) communicate selection decisions to DBEs and Small Businesses, including each rejection of a DBE or Small Business proposal. If a Submitter fails to conduct these Outreach Efforts or fails to submit the required documentation of Submitter's Outreach Efforts as indicated in Section IV below, including that pertaining to communicating selection decisions, the Agency may determine that the Submitter’s submittal is nonresponsive. A determination of nonresponsiveness disqualifies Submitter from further consideration for the Contract award.



146

SECTION IV. SUBMITTAL REQUIREMENTS

A. Outreach-Efforts documentation due with initial qualifications-based submittal. 1. Attachment A. Each Submitter will complete and submit Attachment A documenting its diligent, good-faith Outreach Efforts. Attachment A must be submitted with the initial qualifications-based submittal. a. Each Submitter will list in Attachment A all DBEs and Small Businesses contacted by Submitter in preparing its submittal. Each Submitter shall also provide the following minimum information to document its Outreach Efforts. The DBE Compliance Specialist will consider this information to determine whether Submitter has demonstrated the required Outreach Efforts:

1) Each business’s full legal name and contact information; 2) Business status (DBE, Small Business, SBE, or unknown); 3) Scope of work solicited (brief description, percentage of contract value); 4) Solicitation method (personal contact, telephone, fax, e-mail, other); 5) Selection process; and 6) Communication of selection outcome to each participant.*

*Submitter will provide supporting documentation that shows Submitter has communicated its final selection decisions and outcomes to all DBEs and Small Businesses, including those not chosen to participate in this Contract. b. Each Submitter shall complete Attachment A in accordance with the following instructions.

1) Each Submitter shall actively contact DBEs or Small Businesses for each scope of work or business opportunity selected for Outreach Efforts (Columns A and C).

2) Submitter’s contacts with DBEs and Small Businesses should occur well before the deadline for the initial qualifications-based submittal to afford the firms contacted a reasonable opportunity to prepare a proposal and participate in the Contract. 3) Submitter shall ask each firm to indicate the number of its employees (Column A). 4) For each DBE’s or Small Business’s annual gross receipts, Submitter shall ask the firm to indicate the gross-receipts bracket into which it fits (e.g., less than $500,000; $500,000 – $1 million; $1 – 2 million; $2 – 5 million; etc.) rather than requesting an exact figure from the firm (Column A). 5) If Submitter does not select a DBE or Small Business to participate in the Contract, Submitter shall explain the reason why (Column E). 6) Submitter shall notify each DBE or Small Business contacted whether or not Submitter selected the firm (Column E). Submitter shall notify all firms not selected, and Submitter shall state when (date) and how (method) the selection outcome was communicated to Each firm (Column F).

2. Attachment A Supporting Documentation. Each Submitter shall complete and submit supporting documentation of its Outreach Efforts related to Attachment A.



147

a. Submitter shall submit with Attachment A—on the due date for Attachment A—all supporting documentation of Submitter’s contacts with DBEs or Small Businesses for each scope of work or business opportunity selected for Outreach Efforts. b. This documentation must include (1) descriptions of scopes of work and business opportunities identified for DBE and Small Business participation, and (2) a copy of the actual solicitation sent to interested DBEs and Small Businesses. The solicitation may be in the form of a letter, attachment to an e-mail, advertisements in newspapers and trade papers, or written communications with chambers of commerce. c. Submitter shall submit documentation that establishes how Submitter communicated its selection decisions and outcomes to each DBE and Small Businesses not selected for this Contract. This documentation may be in the form of a letter, e-mail, or telephone log, whichever is applicable to the selection communication. The documentation must show the name of the person contacted and the date. d. For all of the above documentation, if Submitter uses a blast e-mail or fax format, the documentation submitted must include a copy of the e-mail or fax, and Submitter must disclose all e-mail addresses and fax numbers to which the solicitation or outcome notification was sent and the date and time of transmission. For telephone contacts, Submitter shall document the date and time of the call and the names of the respective persons representing Submitter and the DBE or Small Business.

B. Outreach-Efforts documentation due within seven days after final negotiations.

1. Attachments B-1 And B-2. Within seven days after final negotiations with the Agency, the Submitter selected for negotiations shall complete and submit Attachments B-1 and B-2. Submitter must show diligent, good-faith Outreach Efforts and provide information regarding its DBE and Small Business selection decisions and outcomes for all negotiations with DBEs and Small Businesses. Attachment B-1 must contain the names of all DBEs and Small Businesses reported as “selected” on Attachment A, Column E, and all supporting documentation (if applicable). 2. Instructions for completing Attachments B-1 and B-2.

a. Attachment B-1 Negotiations with Small Businesses. The Submitter shall provide the following information in Attachment B-1, which the DBE Compliance Specialist will evaluate to determine whether Submitter negotiated diligently and in good faith with the DBEs and Small Businesses identified in Attachment A, Column E, as potential participants in the Contract’s business opportunities:

1) Each business’s full legal name and contact information; 2) Business status (DBE, Small Business, SBE, or unknown); 3) Scope of work to be performed (brief description, percentage of contract value); 4) Type of agreement; 5) Agreement amount; and 6) Communication of final selection outcomes to participants.*

*The Successful Submitter shall provide supporting documentation that shows Submitter has communicated its final selection decisions and outcomes to all DBEs and Small Businesses, including those not chosen to participate in this Contract.



148

The Successful Submitter shall complete all appropriate boxes in Attachment B-1 and shall indicate the firms with which Submitter has negotiated, including firms that Submitter proposes will participate in and perform part of the Contract. Supporting documentation may include copies of e-mails, letters, faxes, or contact logs stating the name of the firm, date and time of communication, and the identity of the person contacted.

b. Attachment B-2 Small Business Utilization Commitment. The Successful Submitter shall sign and submit Attachment B-2, which commits the Successful Submitter to the Agency as follows:

1) The firms indicated as selected in Attachment B-1 will participate in the Contract; 2) The Successful Submitter will comply with the Race- and Gender-Neutral post-award

requirements as stated in Sections V and VI below; 3) Any and all changes or substitutions must first be authorized by the DBE Compliance Specialist

before implementation; and 4) The proposed total DBE and Small Business participation percentage is true and correct.

Submitter shall ensure that the percentages proposed for Small Business participation on Attachment B-1 equal the total percentage proposed in Attachment B-2. If the Successful Submitter fails to timely submit a completed copy of Attachment B-1 or Attachment B-2, or fails to provide the required supporting documentation for Attachment B-1, the Agency may determine that Submitter’s proposal is nonresponsive. A determination of nonresponsiveness disqualifies Submitter from further consideration for the Contract award.

C. Failure To Meet Outreach Requirements. The DBE Compliance Specialist will determine, in writing, whether Submitter has satisfied all outreach requirements. If the DBE Compliance Specialist determines that Submitter has failed to satisfy the outreach requirements (specified in Sections III and IV, Parts A & B), then the DBE Compliance Specialist may determine that the submittal is nonresponsive. A determination of nonresponsiveness disqualifies Submitter from further consideration for the Contract award. The Agency shall send written notice to Submitter stating the basis for DBE Compliance Specialist’s decision.

D.

Administrative Reconsideration. If the DBE Compliance Specialist determines that Submitter did not properly complete Attachment A or Submitter failed to demonstrate sufficient Outreach Efforts or failed to submit required documentation, then the Agency will permit Submitter to request EOD to reconsider this determination. In its request for reconsideration, Submitter may clarify its submittal. But Submitter may not submit or refer to new or revised documents or information. EOD will only reconsider the original submittal as clarified in the request for reconsideration.

If Submitter requests EOD to reconsider the DBE Compliance Specialist’s determination of nonresponsiveness based on insufficient Outreach Efforts or insufficient documentation, then Submitter must provide written notice to the Agency and EOD within three business days of the Agency’s notice of disqualification to Submitter. The request for reconsideration should be addressed to: City of Phoenix Equal Opportunity Department



149

Business Relations Division-Contract Compliance Section 251 West Washington Street, Seventh Floor Phoenix, AZ 85003 with a copy e-mailed to the Procurement Officer and the DBE Compliance Specialist.

SECTION V. POST-AWARD COMPLIANCE REQUIREMENTS A. Subcontracting Commitment. Promptly after Contract award, the Successful Submitter shall

submit to the Agency a list of all subcontractors and copies of all executed contracts, purchase orders, subleases, JV agreements, and other arrangements formalizing agreements between the Successful Submitter and any DBE or Small Business.

The Successful Submitter shall not terminate any DBE or Small Business Subcontracts, and the

Successful Submitter shall not alter the scope of work or reduce the Subcontract amount, without the DBE Compliance Specialist’s prior written approval. Any request to alter a DBE or Small Business Subcontract must be submitted in writing to the DBE Compliance Specialist before any change is made. If the Successful Submitter fails to do so, the Agency may declare Submitter in breach of contract.

B. Relief From Proposed DBE Utilization. After Contract award, the Agency will not grant relief

from the proposed DBE or Small Business utilization except in extraordinary circumstances. The Successful Submitter’s request to modify DBE or Small Business participation must be in writing to the DBE Compliance Specialist. The DBE Compliance Specialist has final discretion and authority to determine if the request should be granted.

Submitter’s written request must set forth the amount of relief sought, evidence that demonstrates why relief is necessary, and any additional relevant information that the DBE Compliance Specialist should consider. The Successful Submitter shall include with the request all documentation of Submitter’s attempts to subcontract with the DBE or Small Business and any other action taken to locate and solicit a replacement DBE or Small Business.

If an approved DBE allows its DBE certification to expire, or the certification is revoked during

the course of the Subcontract, the Agency will consider all work performed by the DBE under the original contract to count as DBE participation. No increased scope of work negotiated after expiration or revocation of the DBE’s certification may be counted. Likewise, any work performed under a Contract extension granted by the Agency may not be counted as DBE participation.

C. DBE Substitutions. If the DBE or Small Business was approved by the Agency, but the firm

subsequently loses its DBE or Small Business status before execution of a contract, the DBE Compliance Specialist will consider whether or not the Successful Submitter has exercised diligent and good-faith efforts to find another DBE or Small Business as a replacement. The Successful Submitter shall notify the DBE Compliance Specialist in writing of the necessity to substitute a DBE or Small Business and provide specific reason(s) for the substitution or replacement. Actual substitution or replacement of a DBE or Small Business may not occur before the DBE Compliance Specialist’s written approval has been obtained.



150

D. Prompt Payment Of Subcontractors. Within seven days of the Successful Submitter’s receipt

of an Agency progress payment that includes amounts for the Submitter’s Subcontractors, suppliers, or subconsultants, the Submitter shall pay the Subcontractors, suppliers, and subconsultants the respective amounts allowed for satisfactory performance of their work. If the Agency reduces the Successful Submitter’s retention, the Submitter shall correspondingly reduce the retentions of Subcontractors and suppliers that have performed satisfactory work. Under the prompt-payment provisions of 49 CFR Part 26, the Successful Submitter must ensure prompt and full payment of retentions to Subcontractors and suppliers when their work is complete, the Agency has accepted the work, and the Agency has paid the Successful Submitter for the work. The Successful Submitter shall pay each Subcontractor’s and supplier’s retention no later than 30 days after the Agency pays Submitter. If the Successful Submitter diverts any payment received for a DBE’s, Small Business’s, or other Subcontractor’s work performed on the Contract or fails to reasonably account for the application or use of the payment, the Agency may declare the Successful Submitter in breach of contract. If the Successful Submitter fails to make payments under these provisions, the Agency may take any one or more of the following actions: 1. Declare the Successful Submitter in breach of contract; 2. Withhold future payments, including retention, until proper payment has been made to all

Subcontractors and suppliers; 3. Reject the Successful Submitter’s future bids on Agency contracts for a period not to exceed

one year from the substantial-completion date of this Contract; and/or 4. Terminate the Contract. Nothing in this section prevents the Successful Submitter from enforcing its Subcontract with a Subcontractor or supplier for defective work, late performance, or other claims arising under the Subcontract.

SECTION VI. RECORDS & REPORTING REQUIREMENTS

A. Records. During performance of the Contract, the Successful Submitter shall keep all records necessary to document DBE and Small Business participation. The Successful Submitter shall provide the records to the Agency within 72 hours of the Agency’s request and at final completion of the Contract. The Agency will prescribe the form, manner, and content of reports. The required records include:

1. A complete listing of all Subcontractors and suppliers on the project; 2. Each Subcontractor’s and supplier’s scope of work performed; 3. The dollar value of all subcontracting work, services, and procurement; 4. Copies of all executed Subcontracts, purchase orders, and invoices; and 5. Copies of all payment documentation.

B. Reports. At the beginning of each month, the Successful Submitter must enter the following documentation and payment information into the Agency’s web-based certification and



151

compliance system. The system can be found at http://phoenix.diversitycompliance.com:

1. The total of all payments received from the Agency during the previous month. 2. All payments made to DBEs or Small Businesses during the previous month. 3. Copies of all Subcontractors’ subcontracts executed with DBEs or Small Businesses utilized

during the previous month.

This information will document DBE and Small Business participation that occurred during each payment-request period throughout the Contract’s duration. Copies of all DBEs’ and Small Businesses’ payment requests and invoices must be submitted for each report period.

Before the Agency processes the Successful Submitter’s final payment, the Successful Submitter shall submit to the Agency a final certification of full and final payment to each Subcontractor in the form prescribed by the Agency. The form must be completed and certified by the Successful Submitter’s and each Subcontractor’s duly authorized agents.

CITY OF PHOENIX PUBLIC TRANSIT DEPARTMENT: RFP PTD16-002 - COMPUTER AIDED DISPATCH / AUTOMATIC VEHICLE LOCATOR (CAD/AVL) SYSTEM

152

ATTACHMENT A ‐ OUTREACH EFFORTS Project Title:

Project NO:

Submitter’s Name:

Phone #: Point of Contact:

Mailing Address: City:

State: Zip:

E-mail:

Each submitter must conduct outreach efforts and submit documentation of those outreach efforts as described in Sections III and IV of the Disadvantaged Business Enterprise (DBE) Program Race‐ and Gender‐Neutral Contract Clause (Contract Clause). Detailed instructions for this form are included in Section IV of the Contract Clause. Supporting documentation is required for columns D and F. Submitters should make additional copies of this form as needed.

(A)

Small Business Name and Contact Information (B)

Business Status

(C)

Scope of Work Solicited

(D)

Solicitation Method (E)

Small Business Selection Decision

(F)

Communication of Selection Outcomes

Name:

DBE

SBC ‐ Small

Business Concern

SBE ‐ City of

Phoenix Certified

Unknown

_____________

Estimated

Percentage of total

contract

value: %

Newspapers or Websites

Trade and/or Professional

Listing

Business Outreach Events

E‐mail blast

Other

Firm was selected

Firm was not selected

Explain why this firm was not

selected as a proposed participant

Date:

Methods of Communication

Address:

City, State, Zip:

Number of Employees:

Phone Number:

E‐Mail or Fax:

Range of Annual Gross Receipts:

Number of Years in Business:

Name:

DBE

SBC ‐ Small

Business Concern

SBE ‐ City of

Phoenix Certified

Unknown

_____________

Estimated

Percentage

of total contract

value: %



Listing


E‐mail blast

Other

Firm was selected




Date:


Address:

City, State, Zip:


Phone Number:

E‐Mail or Fax:



Name:

DBE

SBC ‐ Small

Business Concern

SBE ‐ City of

Phoenix Certified

Unknown

_____________

Estimated

Percentage of total

contract

value: %



Listing


E‐mail blast

Other

Firm was selected




Date:


Address:

City, State, Zip:


Phone Number:

E‐Mail or Fax:



CITY OF PHOENIX PUBLIC TRANSIT DEPARTMENT: RFP PTD16-002 - COMPUTER AIDED DISPATCH / AUTOMATIC VEHICLE LOCATOR (CAD/AVL) SYSTEM

153

ATTACHMENT B‐1 NEGOTIATIONS WITH SMALL BUSINESSES

Project Title:

Project NO:

Submitter’s Name:

Phone #: Point of Contact:

Mailing Address: City:

State: Zip:

E-mail:

This form is due from the Successful Submitter within 7 days of final contract negotiations with the see. Make additional copies of this sheet as needed. Detailed instructions for this form are included in Section IV of the Contract Clause.

(A)

Small Business Contact Information (B)

Business Status

(C)

Scope of Work/Services to be Performed

(D)

Type of Agreement (E)

Agreement Amount

(F)

Communication of Final Selection Outcomes

Name:

DBE

SBC ‐ Small

Business Concern

SBE ‐ City of

Phoenix Certified

Unknown

Subcontract

Joint Venture

Purchase Order

Service Agreement

Firm was not Selected

$

As a Percent of Total Contract Award:

%

Other:

Firm Selected

Date:

Method of Communication:

Address:

City, State, Zip:


Phone Number:

E‐Mail or Fax:

Range of annual Gross Receipts:


Name:

DBE

SBC ‐ Small

Business Concern

SBE ‐ City of

Phoenix Certified

Unknown

Subcontract

Joint Venture

Purchase Order

Service Agreement


$


%

Other:

Firm Selected

Date:


Address:

City, State, Zip:


Phone Number:

E‐Mail or Fax:



Name:

DBE

SBC ‐ Small

Business Concern

SBE ‐ City of

Phoenix Certified

Unknown

Subcontract

Joint Venture

Purchase Order

Service Agreement


$


%

Other:

Firm Selected

Date:


Address:

City, State, Zip:


Phone Number:

E‐Mail or Fax:





154

ATTACHMENT B-2

SMALL BUSINESS UTILIZATION COMMITMENT

(NEGOTIATED CONTRACTS)

On behalf of the Successful Submitter, I certify under penalty of perjury that the following information is true and correct.

1) The firms indicated as selected in Attachment B-1, Negotiations with Small Businesses, will participate in this contract.

2) The Successful Submitter will comply with the Race- and Gender-Neutral post-award requirements stated in Sections V and VI of the DBE contract clause.

3) The Successful Submitter understands and agrees that any and all changes or substitutions must be authorized by the Equal Opportunity Department before implementation.

4) The following statement is true and correct: The proposed total participation of DBE, SBC, and SBE firms in this contract will be: %

Signed:

Print Name:

Title:

Name of Company:

Date:



155

SECTION 8

PROPOSAL SUBMITTALS

Proposers shall complete Section 8.1 and submit with their Price Proposal

Proposers shall complete Sections 8.2 – 8.7 and submit with their Technical Proposal



156

8.1 PRICE PROPOSAL AND FINANCIAL INFORMATION A. FINANCIAL INFORMATION

Each of the items below is required to be submitted with this portion of the proposal. Check off the boxes below to indicate their inclusion.

Proposer’s audited financial statements for the last three (3) years, which must be prepared in accordance with generally accepted accounting principles of the jurisdiction in which the Proposer is domiciled and which statements must be audited by an independent, certified public accountant. If Proposer is a partnership, submit audited financial statements for each partner. If audited statements are not available, the CITY will require Proposer to submit reliable financial information satisfactory to the CITY. The City Auditor, or other designated personnel, will independently review the financial responsibility of Proposers.

Disclose Proposer’s available operating capital for this project and its source, and provide the amount of any financing proposed for the project, its source, and the repayment terms.

State whether any participant in the proposal has ever filed bankruptcy proceedings. If so, state the date, jurisdiction, amount of liabilities, and amount of assets. Provide this information on a separate statement with the heading "BANKRUPTCY INFORMATION.”

Provide detailed information regarding litigation, liens, or claims that as alleged exceed $10,000 and have resulted or may result in litigation against any participant.

A letter of commitment from a surety authorized to write surety business in Arizona confirming that the Proposer can qualify for and procure the performance surety bond required OR a statement signed by an authorized officer of Proposer in which Proposer certifies that the cash is immediately available, identifying the location and immediate availability of the cash, and that the cash will be provided when and as required in Section 5.5.

Provide a minimum of two bank credit references. Include the bank officer’s name, title, and current telephone number.

Provide evidence of Proposer’s ability to obtain the specified amounts of insurance from an insurance company with an “A.M. Best” rating of not less than B+ VI authorized to do business in Arizona. Disclose intended deductible levels, if any. Disclose the number and amount of all claims paid by Proposer or its insurers in the last five (5) years. Demonstrate that Proposer’s financial capability is commensurate with required insurance limits and the proposed deductible levels. See Section 5.7.



157

B. PRICE PROPOSAL Proposers shall use the instructions below to complete all 5 tables in the Excel Pricing sheet. The prices quoted include all costs necessary to fully complete the required services pursuant to a contract. Any items omitted from a proposal which are clearly necessary for the services and their intended use shall be considered a portion of such services although not directly specified or called for in this RFP. No advantage shall be taken by the Proposer in the omission of any part or detail which makes the services incomplete. Proposers shall not include cost associated with Transit Agency supplied equipment and services. Transit Agency will supply all network infrastructure equipment and communication service between sites, subscription to wireless carrier service, including backend equipment such as dispatch workstations, central radio communication system, and server equipment as detailed in functional requirement. Proposer shall include in their pricing proposal all costs associated with the maintenance warranty for the first three years. The pricing for the Extended Maintenance shall be provided separately as prescribed within Attachment E. Contractor shall include all costs for the 3 year on-site Contractor as a part of the initial CAD/AVL system procurement. All costs for an on-site Contractor during the Extended Maintenance shall be provided separately as prescribed within Attachment E. The Proposer shall provide a per vehicle unit cost (503 COP bus, 327 RPTA bus, COP 126 paratransit, 50 Valley Metro Rail) that takes into account all CAD/AVL specific hardware and software required to have a fully functional CAD/AVL system that meets the functional requirements as identified in this solicitation. Although there may be a minority of vehicles on which Transit Agency may choose not to replace all System vehicle components, it is currently the intent of the Transit Agency to fully replace all CAD/AVL components on the majority of existing vehicles. Therefore, the allocation of Price points will be based on Total CAD/AVL System Solution Cost.

TABLE 1 - HARDWARE COSTS The hardware pricing table shall include, but not be limited to, all CAD/AVL onboard (fixed end) components such as IVU, Radio, GPS, MDT Display, wire harnesses, APC system, and component tray equipment or equivalent onboard technology, central system components, and proprietary hardware interface components that cannot be supplied by the Transit Agency. Proposers are required to include itemized cost per component. Proposers shall identify, on the CAD/AVL Hardware Pricing Proposal table, major system components make and model information such as, but not limited to; onboard equipment, specialized central system equipment, and hardware interface equipment that cannot be provided by Transit Agency. Proposers shall add lines as directed and necessary for components to make the System functional as per contract requirements; otherwise, such components are deemed to be included in the cost and shall not be charged additionally to the Transit Agency. Proposers shall provide a total hardware cost per



158

vehicle type. The hardware vehicle costs will be multiplied by the number of total vehicles targeted for CAD/AVL upgrade to determine total system hardware costs. TABLE 2 - SOFTWARE PRICING The software pricing table shall include all base CAD/AVL specific software necessary to supply a working CAD/AVL system per functional system requirement in this solicitation. The Proposer shall include all software licensing information such as perpetual license, processor license, recurring licensing fees, etc., relevant in calculation for the total system software cost of ownership. The software shall include but not be limited to all dispatch consoles, fixed-end, central server, and maintaining existing external interfaces as detailed in section 2.3 Interface Requirements. Proposers are required to include an itemized cost per software module. Proposers shall identify software components and third party system software components required for a fully functional system as required by the functional requirements in this solicitation. Proposers shall add lines as directed and necessary for components to make the System functional as per contract requirements; otherwise, such components are deemed to be included in the cost and shall not be charged additionally to the Transit Agency. Proposers shall provide a total software cost per vehicle type. The software cost per vehicle type will be multiplied by the number of total vehicles targeted for CAD/AVL upgrade to determine total system software costs. TABLE 3 - OPTIONS PRICING The Options pricing table shall include additional vehicle enhanced functionality such as equipment/software/installation not required in this functional system requirement solicitation. Proposers are encouraged to propose additional pertinent transit-specific hardware/software technologies that would be of value to the Transit Agency for review. All fixed end hardware/software configurations and installation proposed in the options list shall be coordinated to be implemented at the same time new vehicle CAD/AVL equipment is installed. The Transit Agency, at its sole discretion, will have the option to select none or any option that is deems as added value to the organization. The optional pricing request is as follows:

1. Onboard Surveillance System Transit Agency is looking to upgrade and standardize all surveillance systems throughout the fleet. Transit Agency standardizes on Apollo brand onboard surveillance system. Proposers are encouraged to evaluate the existing fleet and propose a surveillance system solution that will leverage the existing Apollo-based onboard surveillance technology with the new CAD/AVL system architecture.

2. Exterior Head Signs

Transit Agency is looking to upgrade all external headsigns that are not capable of J1708/J1939 communications. Transit Agency standardizes on Luminator brand headsigns and Proposers are encourage to evaluate the existing fixed route fleet and propose a headsign solution that will meet the functional requirements as prescribed in this solicitation.

3. Wheelchair Sensors

Transit Agency is seeking technology to provide system “over-the-air’ status of wheelchair seating capacity. Proposers are encouraged to evaluate the existing fleet and propose a Wheelchair notification system to leverage the existing Transit Agency’s in-house digital sign



159

passenger information system. The desire is to display Wheelchair Capacity Status to passengers at designated sites where digital signs are available.

4. Bike Rack Sensors

Transit Agency is seeking technology to provide system “over-the-air’ status of bike rack capacity. Proposers are encourage to evaluate the existing fleet and propose a bike rack notification system to leverage the existing Transit Agency’s in-house digital sign passenger information system. The desire it to display bike rack capacity Status to passengers at designated sites where digital signs are available.

TABLES 4 AND 5 – EXTENDED MAINTENANCE Proposers shall provide two distinct pricing proposals specifically to identify if Transit Agency can leverage economies-of-scale pricing by using a payment arrangement where the CITY will act as the single point of contact for regional maintenance and support payment.



160

8.2 CERTIFICATION FORM Proposer certifies it is a: sole proprietorship____; partnership____; corporation____; joint venture____ Arizona Sales Tax No.____________________________ Use Tax No. for Out-of-State Suppliers_______________ City of Phoenix Sales Tax No.______________________ Taxpayer’s Federal Identification No._________________ Proposer certifies that he has read, understands, and will fully and faithfully comply with this Request for Proposal, its attachments and any referenced documents. Proposer also certifies that the prices offered were independently developed without consultation with any of the other Proposers or potential Proposers. Company’s Legal Name ______________________________________________ Address ______________________________________________ City, State and Zip Code ______________________________________________ Telephone Number ______________________________________________ Company’s Fax No. ______________________________________________ Company’s Toll Free No. ______________________________________________ E-mail Address ______________________________________________ Authorized Signature ______________________________________________ Printed Name and Title ______________________________________________ MAILING ADDRESSES Purchase Order Address: (If different from above) Name __________________________ Address __________________________ City, State and Zip Code __________________________ Payment Address: (If different from above) NOTE: Any assignment of proceeds must go through the City of Phoenix, Division of Accounts, formal assignment procedure. Please refer to the Assignment – Delegation in the RFP. Name __________________________ Address __________________________ City, State and Zip Code __________________________



161

8.3 PAYMENT TERMS

Proposer shall indicate the payment terms in their proposal submittal. Prompt payment terms offering twenty (20) calendar days or more will be considered in the proposal evaluation process. If no payment term is indicated, the CITY shall apply net thirty (30) days as Proposer’s payment terms. Proposer offers a prompt payment discount of ____% ____calendar days to apply after receipt of accurate invoice. FEDERAL PROMPT PAYMENT REQUIREMENTS This prompt payment clause is applicable to every CITY Contract or subcontract on projects funded either in whole or in part by USDOT.

1. Contractor shall pay to its Subcontractors or material suppliers and each

Subcontractor shall pay to its Subcontractors or material supplier, within seven (7) days of receipt of each progress payment, the amounts attributable to the Contractor, Subcontractors or material supplier for work performed or materials supplied. In addition, any reduction of retainage to the Contractor must also result in a like reduction to Subcontractors for their work successfully completed within fourteen (14) days of the reduction of the retainage to the Contractor. No contract between Contractor and its Contractors, Subcontractors and material suppliers may materially alter the rights of any Contractor, Subcontractor or material supplier to receive prompt and timely payment as provided herein. Any diversion by Contractor, or any Subcontractor, of payments received for work performed on a contract, or failure to reasonably account for the application or use of such payments, constitutes sufficient grounds for CITY to take any one or more of the following actions: (1) withhold future payments including retainage until proper disbursement has been made; (2) refusal of all future bids or offers from the Contractor for a period not to exceed one year; or, 3) cancellation of the Contract.

2. Alternate Dispute Resolution. If entitlement to the payment is in dispute, the parties

to the dispute shall submit the matter to either: a) binding arbitration; b) to some other form of binding alternative dispute resolution (ADR); or, c) a City of Phoenix facilitated mediation process. The ADR process shall commence within a reasonable period of time, not to exceed fourteen (14) calendar days of receipt of a Notice to Proceed to an ADR process issued by the CITY once an ADR determination has been made on any disputed claim, the determination shall be implemented by the disputing parties within seven (7) calendar days of that determination.

3. Inspection and Audit. The provisions of A.R.S. Section 35-214 shall apply to the

resultant contract. CITY shall perform the inspection and audit function specified therein and such inspection and audit may include, at CITY’s option, sole and unfettered discretion, the prompt payment requirements contained in Paragraph 1



162

above. 4. Non-waiver. Should the CITY fail or delay in exercising or enforcing any right, power,

privilege or remedy under this section, such failure or delay shall not be deemed a waiver, release or modification of the requirements of this section or of any of the terms or provisions thereof.

5. Inclusion of this provision in subcontracts. Contractors shall include the provisions of

these paragraphs in every subcontract, including procurement of materials and leases of equipment. Further, as a means of enforcing such provisions subcontract or procurement as CITY may direct; provided, however, that, in the event Contractor becomes involved in, or is threatened with, litigation with a subcontractor or supplier as a result of such direction, Contractor may request to enter into such litigation to protect the interests thereof.

6. No Subcontractor Claim. Nothing contained in this section shall provide a basis for

any subcontractor to assert any claim against the CITY for its administration, enforcement or waiver of the provisions of this Prompt Payment provision.



163

8.4 ADDENDA CERTIFICATION The undersigned acknowledges receipt of the following addenda to RFP PTD16-002: Addendum Number _________, dated Addendum Number _________, dated Addendum Number _________, dated Addendum Number _________, dated Addendum Number _________, dated Addendum Number _________, dated Failure to acknowledge receipt of all addenda may cause the proposal to be considered not responsive to the RFP. Include the acknowledged receipt of each addendum with the technical proposal. Authorized Official:________________________________ Title of Authorized Official: _________________________ Company Name:__________________________________



164

8.5 DEBARMENT AND SUSPENSION CERTIFICATION

Choose one alternative:

□ The Contractor certifies to the best of its knowledge and belief that it and its principals:

1. Are not presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from covered transactions by any federal department or agency;

2. Have not within a three-year period preceding this Contract been convicted of or had a civil judgment rendered against them for commission of fraud or a criminal offense in connection with obtaining, attempting to obtain, or performing a public (federal, state or local) transaction or Contract under a public transaction; violation of federal or state antitrust statutes or commission or embezzlement, theft, forgery, bribery, falsification or destruction of records, making false statements, or receiving stolen property;

3. Are not presently indicted for or otherwise criminally or civilly charged by a governmental entity (federal, state, or local) with commission of any of the offenses enumerated in Paragraph 2 of this certification; and

4. Have not within a three-year period preceding this Contract had one or more public transactions (federal, state or local) terminated for cause or default.

OR

□ The Contractor is unable to certify to all of the statements in this certification, and attaches its explanation to this certification. (In explanation, certify to those statements that can be certified to and explain those that cannot.)

The Contractor certifies or affirms the truthfulness and accuracy of the contents of the statements submitted on or with this certification and understands that the provisions of Title 31 USC § Sections 3801 are applicable thereto.

Executed in [insert city and state].

Name:

________________________________________________________________________ Authorized signature Date



165

8.6 LOBBYING CERTIFICATION The Contractor certifies, to the best of its knowledge and belief, that: 1. No federal appropriated funds have been paid or will be paid, by or on behalf of the undersigned,

to any person for influencing or attempting to influence an officer or employee of a federal department or agency, a member of the U.S. Congress, an officer or employee of the U.S. Congress, or an employee of a member of the U.S. Congress in connection with the awarding of any federal Contract, the making of any federal grant, the making of any federal loan, the entering into of any cooperative agreement, and the extension, continuation, renewal, amendment or modification thereof.

2. If any funds other than federal appropriated funds have been paid or will be paid to any person

for making lobbying contacts to an officer or employee of any agency, a member of Congress, an officer or employee of Congress, or an employee of a member of Congress in connection with this federal Contract, grant, loan or cooperative agreement, the undersigned shall complete and submit Standard Form LLL, “Disclosure Form to Report Lobbying,” in accordance with its instruction, as amended by “Government-wide Guidance for New Restrictions on Lobbying,” 61 Fed. Reg. 1413 (1/19/96).

3. The undersigned shall require that the language of this certification be included in the award

documents for all subawards at all tiers (including subcontracts, subgrants and contracts under grants, loans and cooperative agreements) and that all subrecipients shall certify and disclose accordingly. This certification is a material representation of fact upon which reliance was placed when this transaction was made or entered into. Submission of this certification is a prerequisite for making or entering into this transaction imposed by 31, USC § 1352 (as amended by the Lobbying Disclosure Act of 1995). Any person who fails to file the required certification shall be subject to a civil penalty of not less than $10,000 and not more than $100,000 for each such failure.

THE CONTRACTOR, _____________________________________________, CERTIFIES OR AFFIRMS THE TRUTHFULNESS AND ACCURACY OF EACH STATEMENT OF ITS CERTIFICATION AND DISCLOSURE, IF ANY. IN ADDITION, THE CONTRACTOR UNDERSTANDS AND AGREES THAT THE PROVISIONS OF 31 USC §§ 3801 ET SEQ. APPLY TO THIS CERTIFICATION AND DISCLOSURE, IF ANY.

Name of the Contractor’s authorized official: _______________________________________

Title: _______________________________________________________________________________________________

______________________________________________________________________________________________________

Signature Date



166

8.7 Buy America Certification

Certificate of Compliance

The Contractor hereby certifies that it will comply with the requirements of 49 USC Section 5323(j)(2)(C), Section 165(b)(3) of the Surface Transportation Assistance Act of 1982, as amended, and the regulations of 49 CFR 661.11:

Name and title:

Company:

________________________________________________________________________ _______________________

Authorized signature Date

Certificate of Non-Compliance

The Contractor hereby certifies that it cannot comply with the requirements of 49 USC Section 5323(j)(2)(C) and Section 165(b)(3) of the Surface Transportation Assistance Act of 1982, as amended, but may qualify for an exception to the requirements consistent with 49 USC Sections 5323(j)(2)(B) or (j)(2)(D), Sections 165(b)(2) or (b)(4) of the Surface Transportation Assistance Act, as amended, and regulations in 49 CFR 661.7.

Name and title:

Company:

________________________________________________________________________ _______________________

Authorized signature Date

C-1

ATTACHMENT C – DRAFT CONTRACT

AGREEMENT NO. ___________

BETWEEN

THE CITY OF PHOENIX

AND

_______________________

FOR THE COMPUTER AIDED DISPATCH / AUTOMATIC VEHICLE LOCATOR (CAD/AVL) SYSTEM

THIS AGREEMENT is made and entered into this _____day of ___, 2016, by and between the

City of Phoenix, a municipal corporation duly organized and existing under the laws of the state of Arizona acting by and through its Public Transit Department (hereinafter referred to as “CITY”) and ______________ (hereinafter referred to as “CONTRACTOR”).

RECITALS

WHEREAS, the City Manager of the City of Phoenix is authorized and empowered by

provisions of City Charter to execute contracts; and,

WHEREAS, public transit plays an important role in transporting large numbers of people to

and from work places, social service organizations, public events and activity centers in an energy

conscious manner; and,

WHEREAS, public transit systems are of particular and special help, aid, assistance, and

benefit to the general public, students, school children, and persons who are disadvantaged, infirm,

aged, blind and persons with disabilities; and,

WHEREAS, CITY desires that public transportation be available to the citizens, residents and

visitors of Phoenix; and,

WHEREAS, Chapter 2, Section 2, Subsections (c), (i) and (I), Charter of the City of Phoenix,

1969, authorize CITY to establish, maintain, equip, own, and operate transportation services of any

kind and to install, maintain, and operate all systems, proper or convenient, or which may be

C-2

conducive to the welfare, safety, and health or convenience of the City of Phoenix and to the

inhabitants thereof; and,

WHEREAS, by this Agreement, CITY intends to establish arrangements for such transit

system; and,

WHEREAS, CONTRACTOR is a public service corporation with the experience and the

capability to provide transit services; and,

WHEREAS, CONTRACTOR desires to furnish the required equipment and personnel; and,

WHEREAS, the CITY has issued its solicitation document, Request for Proposals (RFP)

PTD16-002 for Computer Aided Dispatch / Automatic Vehicle Locator (CAD/AVL) System; and,

WHEREAS, the Proposal of __________and the subsequent terms and conditions were

authorized by Formal Action of the City Council dated ________;

NOW, THEREFORE, it is agreed by and between the parties as follows:

SECTION 1. TERM OF AGREEMENT. A. The sixteen (16) year Agreement will include an initial design and installation period of up to

two (2) years, a three (3) year warranty and seven (7) years extended maintenance with optional extensions of four (4) years on a two-year increment bases. The option(s) to extend may be exercised by the CITY, acting at its sole discretion, at any time prior to the expiration of the term then existing. The contract will commence on July 1, 2016, or upon full execution by both parties, whichever occurs last.

B. This Agreement terminates upon the earliest occurrence of any of the following:

1) reaching the end of the term as set forth in 1(A); 2) completing the services set forth in the Scope of Work attached as CONTRACT

EXHIBIT A (the “Services”); 3) payment of the maximum compensation under Section 2(A) of this Agreement, unless it

is amended to allow additional compensation; or 4) termination pursuant to the provisions of this Agreement.

SECTION 2. COMPENSATION.

A. Under this Agreement, CITY will pay for satisfactory and complete performance of work at the rate(s) specified in the Price Proposal (CONTRACT EXHIBIT B), with no additional charges for equipment, supplies, overhead, travel or administrative support. Total amount to be remitted by the CITY to CONTRACTOR for all services satisfactorily performed under this Agreement may not exceed $___________ for the sixteen (16) year term of the Agreement.

B. For the initial project, Contractor shall be paid on a milestone basis. Contractor shall submit one (1) invoice to the CITY after each milestone is approved and signed off by CITY. The

C-3

amount invoiced shall be based on the milestone invoice table listed below. Invoices should be submitted to the CITY by the 10th day of the month following the period in which the services/product were delivered and must contain date, contract number, supporting documentation, and invoice amount. Advance payments are not authorized. Payment will be made only for actual milestones that have been completed and approved by TRANSIT AGENCY:

Milestone Progress Payments The payment schedule shall form part of the Contract. Upon each milestone completed and approved TRANSIT AGENCY payment will be released as a percentage of the total cost of the contract as follows: 1. System Design Documentation ..................................... 10% 2. Completion of acceptance and mini fleet test ............... 10% 3. Training and Documentation ......................................... 10% 4. Completion of Vehicle Installations ............................... 30% 5. Substantial Acceptance ................................................ 25% 6. Final Acceptance (end of 3 year warranty period) ........ 15%

C. For the maintenance and support services agreement, CONTRACTOR to review Maintenance

and Support Services for payment information as detailed in Exhibit C. CONTRACTOR shall be paid on a fiscal basis in arrears. CONTRACTOR shall submit invoices to the CITY 45 days before payment is due. CONTRACTOR shall submit one (1) invoice to the CITY for services provided during the previous fiscal period. The CITY shall have an option to request itemized billing as required by the TRANSIT AGENCY. Payment will be made within forty-five (45) calendar days of receipt and approval of CONTRACTOR’S correct invoice. No payment will be made in the absence of the required supporting documentation and/or explicitly identified work required under this hardware/software maintenance and support contract.

D. Payments by TRANSIT AGENCY, or the receipt thereof by CONTRACTOR, shall in no way lessen the liability of CONTRACTOR to replace unsatisfactory Work or material whether or not the unsatisfactory character of such Work or material may have been apparent or detected at the time the payment was made. Materials, components, or workmanship that do not conform to the requirements of the Agreement and the final design of the TRANSIT AGENCY-accepted System shall be rejected and shall be replaced by CONTRACTOR without delay.

E. CONTRACTOR shall submit invoices free of mathematical errors and/or missing supporting documentation. Upon finding an error and/or missing documentation, the CITY will return the invoice to CONTRACTOR. CONTRACTOR shall promptly resubmit the revised invoice to the CITY. Failure to identify an error does not waive any of the CITY’s rights.

F. In accordance with the requirements of Chapter 19, § 2, Charter of the City of Phoenix, no more than ninety (90%) percent of the total contract price may be paid before completion of all work to be performed under this Agreement and its acceptance by CITY. Invoices shall be submitted to:

City of Phoenix/Public Transit Department Attn: Deputy Public Transit Director - Support Services

C-4

302 North First Avenue, Suite 900 Phoenix, Arizona 85003

SECTION 3. SCOPE OF WORK. CONTRACTOR shall provide the Computer Aided Dispatch / Automatic Vehicle Locator (CAD/AVL) System to the CITY in accordance with the Scope of Work set forth in CONTRACT EXHIBIT A. The Scope of Work may be supplemented with additional detail from time to time during the term of the Agreement if and as satisfactory to the CITY.

SECTION 4. INDEMNIFICATION OF CITY AGAINST LIABILITY. CONTRACTOR shall defend, indemnify, save and hold harmless the CITY and its officers, officials, agents, and employees (hereinafter referred to as "Indemnitee") from and against any and all claims, actions, liabilities, damages, losses, or expenses (including court costs, attorneys' fees, and costs of claim processing, investigation and litigation) (hereinafter referred to as "Claims") for bodily injury or personal injury (including death), or loss of or damage to tangible or intangible property caused, or alleged to be caused, in whole or in part, by the negligent or willful acts or omissions of CONTRACTOR or any of its owners, officers, directors, agents, employees or subcontractors. This indemnity includes any claim or amount arising out of or recovered under the Workers' Compensation Law or arising out of CONTRACTOR's failure to conform to any federal, state or local law, statute, ordinance, rule, regulation or court decree. It is the specific intention of the parties that the Indemnitee must, in all instances, except for Claims arising solely from the negligent or willful acts or omissions of the Indemnitee, be indemnified by CONTRACTOR from and against any and all claims. But CONTRACTOR has no duty to indemnify the CITY for the cost to repair collision and comprehensive damage to CITY vehicles operated by CONTRACTOR in excess of the deductible specified in CONTRACT EXHIBIT D (Insurance Requirements). It is agreed that CONTRACTOR is responsible for primary loss investigation, defense and judgment costs where this indemnification is applicable. In consideration of the award of the contract, CONTRACTOR agrees to waive all rights of subrogation against the CITY, its officers, officials, agents and employees for losses arising from the work performed by CONTRACTOR for the CITY.

SECTION 5. INSURANCE REQUIREMENTS. CONTRACTOR and its subcontractors shall

deliver to the CITY, before commencement of the Services provided under this Agreement, a certificate of insurance acceptable to the CITY in the amounts and form specified in CONTRACT EXHIBIT D. Failure of CONTRACTOR and its subcontractors to maintain insurance during the term of the Agreement, including renewal options, is a material breach and may result in immediate termination of this Agreement without notice. Insurance requirements are subject to periodic review and adjustment by the CITY.

SECTION 6. PERFORMANCE SURETY REQUIREMENTS. Performance surety in the amount of $2,500,000 must be provided by CONTRACTOR immediately upon receiving notice of contract award. CITY will not give Notice to Proceed in any form until the performance surety has been received by CITY. Performance surety must be in the form of a bond, cashier’s check, certified check or money order. Personal or company checks are not acceptable unless certified. If performance surety is in the form of a bond, the company issuing the surety bond must be authorized by the Insurance Department of Arizona to transact surety business in the state of Arizona or be named on the approved listing of surplus-lines companies. A certificate of deposit (CD) issued by a local Phoenix bank may also be used as a form of surety provided the CD is issued jointly in the name of the City of Phoenix and CONTRACTOR and CONTRACTOR endorses the CD to CITY at the beginning of the contract period. Interest earned on the CD may be retained by CONTRACTOR, but only if CONTRACTOR is not in default under this Agreement.

C-5

SECTION 7. LIQUIDATED DAMAGES. For each and every missed milestone, Transit Agency may deduct the sum per milestone shown in Table 7.1 below, unless otherwise specified and agreed to in Contractor’s proposal, from monies due to or to become due to Contractor, not as a forfeit or penalty but as liquidated damages. Permitting Contractor to continue and finish the milestone or any part of it after the time fixed for its completion, or after the date to which the time fixed for its completion may have been extended, will in no way operate as a waiver on the part of the Transit Agency of any of its rights under the contract.

Table 7.1 Milestone Liquidated Damages

System Design Documentation $172,632.00 Completion of acceptance and mini fleet test $172,632.00 Training and Documentation $172,632.00 Completion of Vehicle Installations $172,632.00 Substantial Acceptance $172,632.00

For failure to perform technical services, Transit Agency may calculate, and deduct as shown in Table 7.2 below, unless otherwise specified and agreed to in Contractor’s proposal, from monies due to or to become due to Contractor, not as a forfeit or penalty but as liquidated damages. During the initial three-year warranty period, the basis for liquidated damages will be based on a percentage of the annual amount due towards Final Acceptance. During the extended maintenance and support period, the basis for liquidated damages will be based on a percentage of the extended maintenance annual price.

Table 7.2 Request Level Request Type IMPACT Liquidated Damages

% assessed (increments per CITY discretion, but not to

exceed) 1-2 Day-to-Day Minimal-Minor .001 - .005 3 Day-to-Day Server .001 - .006 4 Project Minor .001 - .007 5 Project Severe .001 - .008 Deliverables Reports Minor .001 - .002

These sums in Tables 7.1 and 7.2 are fixed and agreed upon between the parties because the actual loss to the Transit Agency and to the public caused by delay in completion or failure to perform technical services will be impractical and extremely difficult to ascertain and determine.

SECTION 8. LEGAL WORKER REQUIREMENTS

CITY is prohibited by A.R.S. § 41-4401 from awarding a contract to any CONTRACTOR who fails, or whose subcontractors fail, to comply with A.R.S. § 23-214. Therefore, CONTRACTOR agrees that:

A. CONTRACTOR and each subcontractor it uses warrant their compliance with all federal

immigration laws and regulations that relate to their employees and their compliance with § 23-214.

B. A breach of a warranty under paragraph A constitutes a material breach of the Agreement that is subject to penalties up to and including termination of the Agreement.

C-6

C. The CITY retains the legal right to inspect the papers of any CONTRACTOR or subcontractor employee who works on the Agreement to ensure that CONTRACTOR or subcontractor is complying with the warranty under paragraph A. SECTION 9. RESPONSIBILITY FOR COMPLIANCE WITH LEGAL REQUIREMENTS.

CONTRACTOR’s products, service, and facilities must be in full compliance with all applicable federal, state and local health, environmental, and safety laws, regulations, standards, codes and ordinances, regardless of whether or not they are referred to by CITY. At the request of CITY representatives, CONTRACTOR shall provide CITY:

1) Environmental, safety and health regulatory compliance documents (written safety programs, training records, permits, etc.) applicable to services provided by CONTRACTOR under this Agreement.

2) A list of all federal, state, or local (EPA, OSHA, Maricopa County, etc.) citations or notice of violations issued against CONTRACTOR’s firm or its subcontractors including work performed, dates, reasons, dispositions, and resolutions.

CITY shall have the right, but not the obligation, to inspect the facilities, transportation vehicles or vessels, containers and disposal facilities provided by CONTRACTOR or subcontractor. CITY may also inspect operations conducted by CONTRACTOR or subcontractor in the performance of this Agreement.

SECTION 10. GENERAL CONDITIONS. The following general conditions are material to CITY’s entry into this Agreement, and CONTRACTOR’s beach of any one or more of them constitute a material breach of contract: A. Records

CITY, FTA, the Comptroller General of the United States, or any designee may inspect and copy, as the case may be, any facilities, books, documents, papers, computerized media and records of CONTRACTOR that are pertinent to this Agreement for any purpose, including an audit, related to the Agreement. CONTRACTOR shall maintain all books, records, data, and documents according to generally accepted accounting principles as required by the uniform system of accounts and records. All required records must be maintained for a minimum of five (5) years after CITY makes the final payment and all other pending matters are closed. Parties providing documents to the CITY or to CITY employees are hereby advised that notwithstanding anything to the contrary in such party’s form of nondisclosure agreement, the CITY intends to comply with all laws relating to preservation and disclosure of public records, and will consider itself to have satisfied the requirements of any nondisclosure agreement by following the procedures described in the RFP, Section 3.10, Proposer Rights.

B. Covenant Against Contingent Fees Both parties warrant that no person has been employed or retained to solicit or secure this Agreement upon an agreement or understanding for a commission, percentage, brokerage or contingent fee; and that no member of Congress, no member of the Phoenix City Council, and no officer, agent, or employee of CITY has any interest, financially or otherwise, in this Agreement.

C. CITY’s Right to Assign and Novation The parties agree that if another publicly funded transportation agency desires to provide the service described in this Agreement, CITY may, after consultation with CONTRACTOR, assign

C-7

all of its rights and obligations under the Agreement to that agency.

D. Lobbying Prohibition CONTRACTOR shall comply with all requirements of Title 31 U.S.C. Section 1352 and 54 Federal Register 52305, and CONTRACTOR warrants that its activities and those of its officers, agents, employees and contractors comply, and will continue to comply, with this prohibition against spending federal funds for lobbying. CONTRACTOR shall certify compliance with this prohibition and disclose the activities of all lobbyists paid to influence or attempt to influence government officials for federal grants or contracts.

E. Alteration in Character of Work 1. Whenever an alteration in the character of work results in a substantial change in the

nature of services, thereby materially increasing or decreasing the cost of the performance, the work will be performed in accordance with this Agreement. Before any additional work is started, a contract change order or supplemental agreement will be executed by CITY and CONTRACTOR. CITY and CONTRACTOR agree to negotiate and resolve contract change orders in good faith.

2. No changes in the scope, character, or complexity of work may be made by

CONTRACTOR without first receiving approval properly defining and limiting the change. CITY will not pay any claim for extra work done or materials furnished by CONTRACTOR except as provided in this Agreement, and CONTRACTOR may not do any work or furnish any materials not covered by this Agreement unless first approved in writing by CITY. Any such work or materials furnished by CONTRACTOR without prior written approval is Contractor’s sole risk, cost and expense, and CONTRACTOR may not make any claim for compensation for any such work or materials.

F. Assignability; Successors and Assigns Except as provided in Section 10(C), this Agreement is not be assignable without the prior written consent of the parties, and any attempt to assign the Agreement without prior written consent is void. This Agreement extends to and is binding upon the parties’ respective heirs, successors, legal representatives and assigns.

G. Fiscal Year Clause. The continuation of this Agreement after the end of each fiscal year of CITY is subject to the City of Phoenix appropriating funds for the Agreement in subsequent fiscal years. CITY does not represent that funding will be approximated because such a budgetary determination is solely within the City Council’s discretion at the time the subsequent budget is adopted. CITY’s fiscal years end on June 30 each year.

H. Fiscal Year Time for Payment. Under the provisions of A.R.S. § 42-17108, CITY may pay for services rendered or costs incurred only during a fiscal year in which the services and costs are budgeted and for a period of sixty (60) days thereafter. CONTRACTOR must submit its invoices for services performed or costs incurred, together with any required reports, before the close of a fiscal year allowing sufficient time for the processing of payment within the 60-day period.

I. Contract Administration and Dispute Resolution 1. Disputes related to this Agreement’s interpretation or performance, if not resolved by the

parties, must be decided in writing by Contracts Specialist Lead or his designee. The decision of the Contracts Specialist Lead is final and conclusive unless within ten (10)

C-8

calendar days from the date of receipt of the decision, CONTRACTOR appeals in writing to the CITY’s Public Transit Director. On appeal, CONTRACTOR will be afforded an opportunity to be heard and to offer evidence in support of its position. The decision of the Public Transit Director or designee is binding on CONTRACTOR, and CONTRACTOR shall abide by the decision.

2. Performance During Dispute: CONTRACTOR shall continue performance under this

Agreement during all disputes unless CONTRACTOR’s performance is refused by CITY or is enjoined or prohibited by court of competent jurisdiction.

3. Claims for Damages: If either party to the contact suffers injury or damage to person or

property because of any act or omission of the other party or of any of its employees, agents or others for whose acts it is legally liable, the injured [arty shall make a claim for damages in writing to the other party within five (5) calendar days after the first observance of the injury of damage.

4. Remedies: Unless the Agreement provides otherwise, all claims, counterclaims, disputes

and other matters in question between CITY and CONTRACTOR arising out of or relating to this Agreement or its breach must be decided by arbitration.

5. Rights and Remedies: The parties’ rights and remedies and their duties and obligations

under this Agreement do not limit or exclude any rights, remedies, duties or obligations otherwise recognized or imposed by law. No action or failure to act by CITY or CONTRACTOR constitutes a waiver of any right or duty afforded either of them under the Agreement, and any such action or failure to act does not constitute approval of or acquiescence in any breach of the Agreement, except as may later be specifically agreed in writing.

J. Contract Order of Precedence If a conflict appears between this Agreement’s provisions and other incorporated documents,

the following take precedent in the order set forth below to resolve the conflict:

1) Federal conditions; 2) This Agreement; 3) City terms and conditions; 4) Appendices and exhibits; 5) The RFP and Contractor’s Proposal; 6) Other documents referenced or included in the RFP.

Unless otherwise specifically provided, in resolving any conflict or inconsistency among the foregoing documents, the most recent in time prevails over older documents or provisions covering the same issue, and provisions most favorable to CITY prevail over less favorable conflicting or inconsistent provisions wherever they may be found.

K. Notices Any notice, consent of other communication (“Notice”) required or permitted under this Agreement must be in writing and either delivered in person, sent by facsimile transmission, deposited in the United States mail, postage prepaid, registered or certified mail, return receipt requested, or deposited with any commercial air courier or express service addressed as follows:

C-9

If to CONTRACTOR:

If to CITY: Maria Hyatt, Public Transit Director City of Phoenix Public Transit Department 302 North 1st Avenue, Suite 900 Phoenix, AZ 85003 Telephone: (602) 262-7242 FAX (602) 495-2002

Notices will be deemed received at the time they are personally served or sent by facsimile transmission, on the second day after deposit with any commercial air courier or express service, or if mailed, ten (10) days after the Notice is deposited in the United States mail. Any time period stated in a Notice must be computed from the time the Notice is deemed received. Either party may change its mailing address or the person to receive Notice by notifying the other party as provided in this paragraph. Notices sent by facsimile transmission must also be sent by regular mail to the recipient at the above address. This requirement for duplicate notice does not change the effective date of a notice sent by facsimile transmission.

L. Attorneys’ Fees If suit is brought by either party to enforce the terms of this Agreement, to collect any monies due, or to collect money damages for breach, the prevailing party is entitled to recover, in addition to any other remedy, reimbursement for reasonable attorneys’ fees, court costs, costs of investigation and other related expenses incurred in connection therewith.

M. Federal, State and Local Laws CONTRACTOR warrants that it shall comply with all federal, state and local laws and ordinances and all lawful orders, rules and regulations applicable to this Agreement.

N. Waiver CITY’s failure at any time to require performance of any provision of this Agreement in no way affects the right of CITY to enforce the provision later or to enforce any other provision of this Agreement.

O. Non-Waiver of Right. The omission by either party at any time to enforce any default or right reserved to it, or to require performance of any of the terms, covenants, or provisions hereof by the other party at the time designated, shall not be a waiver of any default or right to which the party is entitled, nor does it in any way affect the right of the party to enforce such provisions thereafter.

P. Implied Contract Terms Each and every provision of law and any clause required by law to be in this Agreement must be read and enforced as though it were included in the Agreement, and if any such provision is not inserted or is not correctly inserted, then upon either party’s request the Agreement must be promptly amended to insert the correct provision.

Q. Severability This Agreement’s provisions are severable, and if any provision is deemed invalid by a forum of competent jurisdiction, all other provisions of the Agreement remain in effect without the

C-10

invalid provision.

R. Organization Disclaimer This Agreement is not intended to constitute, create, give rise to or otherwise recognize a joint venture agreement or partnership between the parties or any other formal business organization, and the parties have only the rights and obligations set forth in the Agreement. No person, employee, subcontractor, or supplier of Contractor may be considered a CITY employee, and no CITY civil service, retirement or personnel rights or privileges accrue to such persons. Contractor assumes all liability for all salaries, wages, bonuses, retirement, withholdings, worker’s compensation, occupational disease compensation, unemployment compensation, other employee benefits and all related taxes and premiums for such persons. CONTRACTOR shall defend and indemnify CITY against all of these liabilities. SECTION 11. TERMINATION OF SERVICES.

A. Termination for Convenience. At any time, CITY may terminate this Agreement for convenience by written notice to CONTRACTOR. Under this provision, CITY may terminate the Agreement for any reason or for no reason. CONTRACTOR shall be paid its costs, including contract close-out costs, and profit on work performed up to the date of termination. CONTRACTOR shall promptly submit these costs to CITY for payment together with such supporting documentation as CITY may require. If CONTRACTOR has any property in its possession belonging to CITY, CONTRACTOR shall account for and return or dispose of the property as CITY directs. When Notice of Termination is received, CONTRACTOR shall immediately consult with CITY about the goods and materials on order then or that are in place and about CONTRACTOR’s plan to proceed with the work had the Agreement not been terminated. After this consultation, CONTRACTOR shall take whatever action CITY may direct related to the Agreement, including cancelling orders; retaining, selling or otherwise disposing of goods and materials; and winding up work or continuing to prosecute it.

B. Termination for Cause. Subject to CONTRACTOR’s right to cure under the provisions of

11(D). below, if CONTRACTOR: (a) fails to provide any of the deliverables specified in this Agreement within the time specified or any extension; or (b) fails to perform any other material provision of this Agreement, CITY may terminate the Agreement for cause. Failure to perform includes any attempt by CONTRACTOR to use unacceptable personnel or supply materials, defective products or workmanship or to furnish the required service and/or product later than the time set forth in the Agreement. If, after termination for cause, it is determined that CONTRACTOR was not in default or that a delay was excusable, then the termination shall be deemed a termination for convenience, and CITY may, in its sole discretion, require CONTRACTOR to continue performance of this Agreement and, if appropriate under the circumstances, allow additional time for performance to be completed, and pay CONTRACTOR its costs of delay, demobilization and remobilization, if appropriate.

C. Notice of Termination. CITY shall give CONTRACTOR thirty (30) days’ written notice before

terminating CONTRACTOR for convenience or for cause. To effect either termination, CITY shall deliver a Notice of Termination to CONTRACTOR specifying: (a) the nature of the default, if any; (b) the nature of the termination, i.e., whether for convenience or cause; (c) the date upon which the termination takes effect.

C-11

D. Opportunity to Cure. Before termination for cause, the Contract Administrator, after consultation with CONTRACTOR, will deliver to CONTRACTOR a notice to cure and allow CONTRACTOR thirty (30) calendar days (or such other period agreed to between CONTRACTOR and CITY) within which CONTRACTOR correct and cure the defect. Upon receiving the cure notice, CONTRACTOR shall diligently pursue the cure to completion. The notice will state the time period within which cure is permitted together with other reasonable conditions. If CONTRACTOR fails to correct and cure the breach or default of any of the terms, covenants, or conditions of this Agreement within thirty (30) calendar days (or such other period agreed to between CONTRACTOR and CITY) after CONTRACTOR’s receipt of the notice to cure specifying the nature of the default or breach, then CITY may terminate this Agreement by delivering a notice of termination for cause in accordance with 12(B) above. Any termination for cause will not preclude CITY from also pursuing all other available remedies against CONTRACTOR and its sureties for the default or breach.

SECTION 12. CONFIDENTIALITY AND DATA SECURITY

A. All data, regardless of form, including originals, images and reproductions, prepared by, obtained by, or transmitted to CONTRACTOR in connection with this Agreement are confidential, proprietary information owned by CITY. Except as specifically provided in this Agreement, CONTRACTOR shall not disclose data generated in performing any service to any third person without the prior written consent of the City Manager or his/her designee.

B. Personal identifying in information, financial account information, or restricted CITY information, whether electronic format or hard copy, must be secured and protected at all times to avoid unauthorized access. At a minimum, CONTRACTOR must encrypt and/or password-protect electronic files. This includes data saved to laptop computers, computerized devices or removable storage devices. When personal identifying information, financial account information, or restricted CITY information, regardless of its format, is no longer necessary, the information must be redacted or destroyed through appropriate and secure methods that ensure the information cannot be viewed, accessed or reconstructed.

C. If data collected or obtained by CONTRACTOR in connection with this Agreement is believed to have been compromised, CONTRACTOR shall notify the City Privacy Officer immediately. CONTRACTOR agrees to reimburse CITY for any costs incurred by CITY to investigate potential breaches of the data and if applicable, the cost of notifying individuals who may be impacted by the breach.

D. CONTRACTOR shall incorporate the requirements of this section into all subcontractor agreements entered into by CONTRACTOR. Any violation of this section will be deemed to cause irreparable harm that justifies injunctive relief in court, notwithstanding the parties have agreed to arbitrate other disputes under the Agreement. A violation of this section may result in immediate termination of Agreement without notice.

E. CONTRACTOR shall defend, indemnify, and hold harmless the CITY and its officers, officials, agents, and employees from and against any and all claims, actions, liabilities, damages, losses, or expenses (including court costs, attorney’s and experts’ fees, and cost of claims-processing, investigation and litigation) for any loss caused, or alleged to be caused, in whole or in part, by CONTRACTOR’s or any of its owners’, officers’, directors’, agents’ or employees’

C-12

failure to comply with the requirements of this section. This indemnity includes any claim arising out of CONTRACTOR’s failure to conform to any federal, state or local law, statute, ordinance, rule, regulation or court decree.

F. CONTRACTOR’s obligations under this section survive termination of this Agreement. SECTION 13. INTELLECTUAL PROPERTY AND SPECIAL TERMS AND CONDITIONS

A. Definitions

1. “Deliverables” means all software, equipment, systems, work to be delivered, or other work products provided within the scope of this Agreement.

2. “Intellectual Property Rights” or “IPR” mean all intellectual property rights, including with

limitation, any rights in any invention, patent, discovery, improvement, know-how, utility model, trade-mark, copyright, industrial design or mask work, integrated circuit topography, trade secret and all rights of whatsoever nature in computer software and data, Confidential Information, and all intangible rights or privileges of a nature similar to any of the foregoing, including in every case in any part of the world and whether or not registered, and shall include all rights in any applications and granted registrations for any of the foregoing.

3. “Joint IPR” means the Intellectual Property Rights conceived, created, developed, or

reduced to practice in a Project pursuant to this Agreement.

4. “Licensed Patents” shall mean all patents throughout the world (including patents of importation, improvement patents, patents and certificates of addition and utility models, as well as divisions, reissues, continuations, renewals, and extensions of the foregoing) applications therefore, and patents which may issue upon such applications, as to which patents or applications CONTRACTOR has at any time during the Term of this Agreement the right to grant licenses of.

5. “Licensed Products” shall mean any and all products which employ or are produced by the

practice of inventions claimed in the Licensed Patents.

B. Intellectual Property Indemnification. In addition to the indemnification in paragraph 5.6. above, CONTRACTOR agrees to defend, at its own expense, and to indemnify and hold harmless the CITY and its officers, agents, and employees from and against all judgments, claims, damages, suits, liabilities, settlements, costs and demands, including reasonable attorneys’ fees, suffered or incurred by the CITY as a result of any claim that the Deliverables infringe the patents, copyrights, or other intellectual property rights of third parties, provided that CONTRACTOR is notified in writing of such claim. CONTRACTOR will have the sole right to control the defense of all such infringement claims, lawsuits and other proceedings including the right to settle the same. In no event will the CITY settle any such claim, lawsuit, or proceeding without CONTRACTOR’s prior written approval. The CITY will cooperate with CONTRACTOR, at CONTRACTOR’s expense, in a reasonable way to facilitate the settlement or defense of such claim. If, as a result of any claim of infringement by CONTRACTOR, the CITY is enjoined from using the Deliverables provided under this Agreement, or if CONTRACTOR reasonably believes that the Deliverables are likely to become the subject of a claim of infringement, CONTRACTOR may, at CONTRACTOR’s option and expense, (1) procure the right for the CITY to continue to use the Deliverables, or (2) replace or modify the

C-13

Deliverables so as to make them non-infringing and of equal or superior functional and capability for the purpose for which the Deliverable was provided.

C. Document Delivery. All documents, together with all unused materials supplied by the CITY,

are to be delivered to the CITY upon completion or termination of this Agreement before the final payment is made to CONTRACTOR. All documents prepared by CONTRACTOR shall be prepared in a format and at a quality approved by the CITY. CONTRACTOR shall review all documents provided by the CITY related to the performance of the Services and shall promptly notify the CITY of any defects or deficiencies discovered in such review. CONTRACTOR shall provide timely and periodic submittals of all documents required of CONTRACTOR, including sub-agreements, if any, as such become available to the CITY for review.

D. Reservation. Nothing in this Agreement shall be interpreted to give either party any rights whatsoever to any Intellectual Property of the other not conceived, created, developed, or reduced to practice pursuant to this Agreement.

E. Warranty Against Infringement. CONTRACTOR warrants that the Deliverables will be free of the rightful claim of any third party by way of infringement or misappropriation of patent, copyright, trade secret, trademark or other rights arising under the laws of the United States. CONTRACTOR further warrants that no act or omission of CONTRACTOR will result in a third party holding a claim (other than infringement) that interferes with the CITY’s enjoyment of the Deliverables. CONTRACTOR warrants that it owns or possesses the necessary rights, title and licenses necessary to perform its obligations hereunder. CONTRACTOR warrants that, as of the Effective Date and throughout the Term, CONTRACTOR has not conveyed any rights or licenses to any third party regarding the Deliverables.

F. Warranty on Deliverables. CONTRACTOR warrants the Deliverables (including hardware, electrical, electronic, mechanical, and all other system components, including installation), for a period of 3 year period starting with the date of final system acceptance (the “Warranty Period”), to be substantially free of any condition which would make the system fail to perform other than in material accordance with the requirements set forth in Section II, Scope of Work, (each such condition to be considered an “Error”). If the CITY reports to CONTRACTOR any Errors (any condition which could make it fail to perform other than in material accordance with the specifications) in the system during the Warranty Period, then CONTRACTOR shall, at its expense, use reasonable commercial efforts to modify or replace the faulty hardware, software, electrical component or other system feature as quickly as reasonably practicable. Where possible, both parties shall attempt to resolve Errors through telephone instruction, issuance of updated documentation, corrective code, or hardware replacement or modification.

C-14

G. Acceptance of Deliverables. Final acceptance of Deliverables shall be provided only after successful completion of testing of the Deliverables. Final acceptance shall not occur until all phases of implementation have been successfully performed. Acceptance test criteria will be identified during the Design and Review process.

H. Supervision of Others. CONTRACTOR shall take all reasonable precautions to prevent any other person with whom CONTRACTOR is or may become associated (whether as supervisor, employee, owner or otherwise) from acquiring confidential information from or through CONTRACTOR and/or using or divulging such confidential information at any time; provided, however, CONTRACTOR shall not be responsible or liable, nor shall he be in breach of this Subsection, if any other person shall acquire, use, or divulge such confidential information as a result of a forcible entry into the office or file of CITY.

I. Software License. Services provided under this Agreement may be in support of CITY’s license to use computer software programs, owned or distributed by CONTRACTOR, under a separate software license agreement. The software license agreement shall govern all use by CITY of such programs. Neither this Agreement nor any ordering document includes the grant of any license or any other rights for such programs. SECTION 14. CONTACTS WITH THIRD PARTIES. CONTRACTOR or its subcontractors

shall not contact third parties to provide any information in connection with the Deliverables provided under this Agreement without the prior written consent of the CITY. Should CONTRACTOR or its subcontractors be contacted by any person requesting information or requiring testimony relative to the Services provided under this Agreement or any other prior or existing Agreement with the CITY, CONTRACTOR or its subcontractors shall promptly inform the CITY giving the particulars of the information sought and shall not disclose such information or give such testimony without the written consent of the CITY or court order. The obligations of CONTRACTOR and its subcontractors under this Section shall survive the termination of this Agreement.

CONTRACTOR agrees that the requirements of this Section shall be incorporated into all

subcontractor agreements entered into by CONTRACTOR. It is further agreed that a violation of this Section shall be deemed to cause irreparable harm that justifies injunctive relief in court. A violation of this Section may result in immediate termination of this Agreement without notice.

SECTION 15. NON-DISCLOSURE. In addition to the confidentiality and data security

requirements in Section 12, CONTRACTOR shall not disclose, without the CITY’s prior written consent, any information in the performance of the Services under this Agreement to any person, firm, corporation, association, or other entity other than persons in the CITY’s organization qualified to receive such information, for any reason or purpose whatsoever, nor shall CONTRACTOR make use of any such confidential or proprietary information for its own purposes or for the benefit of any person, firm, corporation or other entity, except the CITY.

CONTRACTOR agrees to act as a trustee of the foregoing information and as trustee of any other confidential information learned in connection by CONTRACTOR’s relationship with the CITY. CONTRACTOR further represents to the CITY that, as an inducement to enter this Agreement, CONTRACTOR will hold this information in trust and confidence for the CITY’s sole benefit and use.

C-15

Further, there shall be no dissemination or publication of any information gathered, or documents prepared in the course of the performance of the Services without the prior written consent of the CITY.

Should the CITY, upon advice of counsel, deem it necessary, due to existing or anticipated litigation, to assert a legal privilege of protection and non-disclosure with regard to the subject matter of this Agreement, then, and in that event, upon written demand, CONTRACTOR shall relinquish to the possession and control of the CITY its entire file related to this Agreement and only those portions of said file deemed by the CITY to be not privileged shall be returned to Contractor pending the resolution of the existing or anticipated litigation.

CONTRACTOR agrees that the requirements of this Section shall be incorporated into any subcontractor agreements entered into by CONTRACTOR. It is further agreed that a violation of this Section shall be deemed to cause irreparable harm that justifies injunctive relief in court. A violation of this Section may result in immediate termination of this Agreement without notice. The obligations of CONTRACTOR under this Section shall survive the termination of this Agreement.

SECTION 16. EQUAL EMPLOYMENT OPPORTUNITY. CONTRACTOR shall not

discriminate against any worker, employee or applicant, or any member of the public, because of race, color, religion, sex, national origin, age, or disability nor otherwise commit an unfair employment practice. CONTRACTOR shall ensure that applicants are employed and employees are dealt with during employment without regard to their race, color, religion, sex, national origin, age, or disability. Such action shall include but not be limited to the following: employment, promotion, demotion or transfer; recruitment or recruitment advertising; layoff or termination; rate of pay or other forms of compensation; and selection for training; including apprenticeship. This clause must be incorporated in all subcontracts with all labor organizations furnishing skilled, unskilled and union labor, or who may perform any such labor or services in connection with this Agreement. CONTRACTOR further agrees that this clause will be incorporated in all subcontracts, job-consultant agreements or subleases of this Agreement.

SECTION 17. INTEGRATION. This Agreement constitutes the full and complete understanding and agreement of the parties and supersedes all prior understandings, agreements, discussion, proposals, bids, negotiations, communications, and correspondence, whether oral or written. Neither party has made any representation, promise, inducement or statement of intention that is not embodied in this Agreement and neither party is bound by or liable for any matter not in the Agreement.

SECTION 18. GOVERNING LAW; FORUM; VENUE. This Agreement is executed and delivered in the state of Arizona, and the substantive laws of Arizona (without reference to choice-of-law principles) govern the Agreement’s interpretation and enforcement. Any action to interpret or enforce this Agreement must be commenced and maintained in the state or federal courts of the state of Arizona, Maricopa County. SECTION 19. FORCE MAJEURE. Except for payment of all amounts due, neither party shall be liable to the other nor deemed in default under this contract if and to the extent that the party's performance of this Agreement is prevented by a force majeure, which means an occurrence beyond the control and without the fault of the party affected. But a force majeure does not include late performance by a subcontractor unless the delay was beyond the control and without the fault of the subcontractor.

C-16

If either party is delayed in the progress of the work by a force majeure, the delayed party shall notify the other party, in writing and as soon as is practical, of the commencement of the delay and the specific causes of delay. The notice must be hand-delivered or mailed certified-mail return-receipt requested and must make a specific reference to and invoke this provision. The delayed party shall endeavor to end the delay as soon as practicable and shall notify the other party in writing when it has done so. The time of completion will be extended by contract modification for the time the delay prevented the delayed party from performing this Agreement.

SECTION 20. REPORTING REQUIREMENTS. CONTRACTOR shall collect data as required and provide periodic reports comparing the transit system's past and present performance and discussing various management goals and objectives as described in CONTRACT EXHIBIT A and CONTRACTOR’s proposal. Monthly and quarterly reports are due on or before the tenth day of the following month. Reports and required submissions may be revised, reorganized, deleted or changed as directed by CITY.

SECTION 21. CONFLICTS OF INTEREST.

A. CONTRACTOR acknowledges that, to the best of its knowledge, information and belief, no person has been employed or retained to solicit or secure this Agreement upon a promise of a commission, percentage, brokerage, or contingent fee, and that no member of the Phoenix City Council or any employee of the CITY has any financial interest in the contracting firm. For breach of violation of this warranty, CITY shall have the right to annul this Agreement without liability, including any such commission, percentage, brokerage or contingent fee.

B. CITY reserves the right to disqualify CONTRACTOR in the event the CITY determines CONTRACTOR has an actual or apparent conflict of interest with the purposes of this Agreement, and the provisions and procedures set for in Section 9 shall apply.

C. If CITY finds that CONTRACTOR or anyone acting on its behalf offered or gave gratuities in the form of entertainment, gifts or inducements to any CITY officer or employee for the purpose of securing this Agreement, or securing favorable treatment with respect to the awarding, amending, or making of any determination with respect to the performance of this Agreement, CITY may, on one (1) calendar day written notice to CONTRACTOR, terminate CONTRACTOR’s right to perform this Agreement; provided that and the issue may be litigated in an Arizona court of competent jurisdiction. In the event of such termination, the CITY is entitled to the same remedies against CONTRACTOR as could be pursued for CONTRACTOR’s default or breach.

D. This Agreement is subject to cancellation by CITY pursuant to the provisions of Arizona Revised Statutes § 38-511. SECTION 22. CLAIMS OR DEMANDS AGAINST THE CITY. CONTRACTOR shall comply

with the provisions of Chapter 18, Section 14 of the Charter of the City of Phoenix, pertaining to claims or demands against the CITY, including provisions therein for set-off of indebtedness to the CITY against demands on the CITY. CONTRACTOR shall follow the prescribed procedure for presentation of claims and demands. In addition, CONTRACTOR shall comply with the claim statutes, A.R.S. §§ 12-821 and 12-821.01, pertaining to claims against CITY. Nothing in this Agreement constitutes a dispute resolution process, an administrative claims process, or contractual term as used in A.R.S § 12-821.01(C) to affect the date on which a claim accrues under A.R.S § 12-821.01(A) and (B).

C-17

SECTION 23. RELEASE OF INFORMATION – ADVERTISING AND PROMOTION. CONTRACTOR shall not publish, release, disclose or announce to any member of the public, press, official body, or any other third party: (1) any information concerning this Agreement or the services provided under it, or (2) any Agreement-related documents or their contents without the prior written consent of CITY, except as required by law. The name of any site on which services are performed shall not be used in any advertising or other promotional context by CONTRACTOR without CITY’s prior written consent.

SECTION 24. TRANSITION COOPERATION AGREEMENT. Upon the expiration, termination or other conclusion of this Agreement and of CONTRACTOR’s rights and obligations under the Agreement, the parties anticipate that CITY will select a successor provider to perform the same or similar work. The parties further acknowledge that the successor provider may be CONTRACTOR or another individual, firm or entity. If the successor provider is an individual, firm or entity other than CONTRACTOR, then CONTRACTOR shall cooperate fully with the successor provider to effect a smooth and seamless transition. This cooperation must include, but is not limited to, the following.

8) CONTRACTOR shall share and permit the copying of all books and records necessary or convenient for the successor provider to undertake its work. These records include, but are not limited to, maintenance records, inventory records, supplier contracts, and support Agreements.

9) If original records are necessary for the successor provider to properly perform its legal obligations, CONTRACTOR shall provide the originals to the successor, and CONTRACTOR shall keep copies of them.

10) CONTRACTOR shall execute documents necessary to effect a transfer of all contracts, goods, and services.

11) CONTRACTOR shall not sell, transfer, convey or encumber any CITY assets or any of the assets to be transferred to the successor provider.

12) CONTRACTOR shall maintain all inventory levels necessary for the successor provider to continue to perform the work.

13) As CITY may direct, CONTRACTOR shall surrender to the successor provider or to CITY all CITY-owned real, personal and/or intellectual property.

14) CONTRACTOR shall inventory all property (real, personal or mixed) purchased or leased with CITY funds and all property in which CITY has an ownership or possessory interest. CONTRACTOR shall include a description of the property and its location in sufficient detail to permit easy identification.

Until the date that the successor provider assumes its position, CONTRACTOR shall fully and conscientiously perform its obligations under this Agreement in a professional and workmanlike manner. If CITY elects to perform the same or similar work using CITY forces, CONTRACTOR’s duty of cooperation, as described above, shall extend to CITY as the successor provider.

SECTION 25. COMPLIANCE WITH ENVIRONMENTAL LAWS. CONTRACTOR shall comply with all provisions of CONTRACT EXHIBIT E.

SECTION 26. EFFECTIVE DATE. This Agreement will be in full force and effect only when it has been approved by the City Council of the City of Phoenix, Arizona, executed by the duly authorized officials of the respective parties, and filed with the Phoenix City Clerk.

C-18

SECTION 27. EXHIBITS; INCORPORATION BY REFERENCE. The RFP, addenda and CONTRACTOR’s Proposal are incorporated into this Agreement by reference. The following attached Exhibits are each by this reference also incorporated into this Agreement.

Exhibit “A” Scope of Work Exhibit “B” Price Proposal Exhibit “C” Maintenance and Support Scope of Work Exhibit “D” Insurance Requirements Exhibit “E” FTA Required Clauses Exhibit “F” Compliance with Environmental Laws

C-19

IN WITNESS WHEREOF, the parties herein have caused this Agreement to be executed in triplicate originals.

CITY OF PHOENIX, ARIZONA ED ZUERCHER, CITY MANAGER By________________________ Maria Hyatt Public Transit Director

ATTEST: __________________________________

City Clerk APPROVED AS TO FORM: __________________________________

Acting City Attorney APPROVED BY CITY COUNCIL ORDINANCE NO. _________on ____________

By ________________________

ATTEST: ___________________________________

C-20

CONTRACT EXHIBIT A SCOPE OF WORK

(Scope of Work to be completed based upon the proposal accepted and awarded by the City)

C-21

CONTRACT EXHIBIT B PRICE PROPOSAL

(Price Proposal to be completed based upon the proposal accepted and awarded by the City)

C-22

CONTRACT EXHIBIT C MAINTENANCE AND SUPPORT SCOPE OF WORK

(Maintenance and Support as stated in Attachment E of RFP PTD16-002 and based upon the

proposal accepted and awarded by the City)

C-23

CONTRACT EXHIBIT D INSURANCE REQUIREMENTS

(Insurance requirements as stated in Section 5.7 of RFP PTD16-002)

C-21

CONTRACT EXHIBIT E FEDERAL TRANSIT ADMINISTRATION (FTA) REQUIRED CLAUSES

This Agreement is being funded, in whole or in part, with federal funds through the Federal Transit Administration (FTA). As a consequence of that funding, the FTA mandated provisions, listed below by title, are incorporated into this Agreement. The clauses are fully stated in Section 7 of RFP PTD16-002. 1. NO OBLIGATION BY THE FEDERAL GOVERNMENT 2. PROGRAM FRAUD AND FALSE OR FRAUDULENT STATEMENTS OR RELATED ACTS 3. ACCESS TO RECORDS 4. FEDERAL CHANGES 5. CIVIL RIGHTS 6. TERMINATION 7. INCORPORATION OF FTA TERMS 8. CERTIFICATION REGARDING DEBARMENT AND SUSPENSION 9. BUY AMERICA 10. DISPUTES 11. LOBBYING 12. CLEAN AIR 13. CLEAN WATER 14. CARGO PREFERENCE – USE OF UNITED STATES-FLAG VESSELS 15. FLY AMERICA 16. PRIVACY ACT 17. ENERGY CONSERVATION 18. RECYCLED PRODUCTS 19. ACCESS REQUIREMENTS FOR PERSONS WITH DISABILITIES (ADA) 20. NATIONAL TRANSPORTATION COMMUNICATIONS FOR ITS PROTOCOL 21. DISADVANTAGED BUSINESS ENTERPRISE (DBE) PROGRAM

C-22

CONTRACT EXHIBIT F COMPLIANCE WITH ENVIRONMENTAL LAWS

Contractor shall, at Contractor’s own expense, comply with all present and subsequently enacted Environmental Laws and any amendments thereto, affecting Contractor’s occupation and use of the Premises. A. DEFINITIONS 1. “Environmental Laws” means those laws promulgated for the protection of human health or

the environment, including but not limited to, the following as the same are amended from time to time: the Comprehensive Environmental Response, Compensation, and Liability Act of 1980 [CERCLA], 42 U.S.C. Sections 9601 et seq., as amended by the Superfund Amendment and Reauthorization Act [SARA]; the Solid Waste Disposal Act [SWDA], 42 U.S.C. Sections 6901 et seq., as amended by the Resource Conservation and Recovery Act [RCRA] including Subtitle I, Underground Storage Tanks; the Toxic Substances Control Act [TSCA], 15 U.S.C. Sections 2601 et seq.; the Public Health Service Act (Title XIV) [PHSA] a.k.a. the Safe Drinking Water Act [SDWA] and SDWA Amendments of 1996, 42 U.S.C. Sections 300f et seq.; the Federal Water Pollution Control Act [FWPCA], as amended by the Clean Water Act, 33 U.S.C. Sections 1251 et seq.; the Clean Air Act, 42 U.S.C. Sections 7401 et seq.; Title 49 of the Arizona Revised Statutes, including the Arizona Environmental Quality Act, A.R.S. Sections 49-201 et seq.; the Arizona Hazardous Waste Management Act, A.R.S. Sections 49-921 et seq.; the Arizona Underground Storage Tank Regulation Act, A.R.S. Sections 49-1001 et seq.; the Arizona Solid Waste Management Act, A.R.S. Section 49-701 et seq.; the Occupational Safety and Health Act of 1970 as amended, 29 U.S.C. Sections 651-678 and the regulations promulgated thereunder, and, any other laws, regulations and ordinances (whether enacted by local, state or federal government) now in effect or hereafter enacted, that provide for the regulation or protection of human health or the environment, including the ambient air, ground water, surface water, and land use, including substrata soils.

2. In this Contract, the term “regulated substances” means: a. Those substances identified or listed as a hazardous substance, pollutant, hazardous

material, and, petroleum, in CERCLA/SARA; the Hazardous Materials Transportation Act, 49 U.S.C. Sections 5101 et seq.; RCRA, Subtitle I, Regulation of Underground Storage Tanks, 42 U.S.C. Sections 6991 through 6991i; Clean Air Act, 42 U.S.C. Section 7412 et seq.; and in any rule or regulation adopted to implement said statutes.

b. Those substances identified or listed as a hazardous substance, pollutant, toxic pollutant, petroleum, or as a hazardous, special, or solid waste in the Arizona Environmental Quality Act, A.R.S. Sections 49-201 et seq., including but not limited to, the Water Quality Assurance Revolving Fund Act [WQARF], A.R.S. Sections 49-281 et seq.; the Solid Waste Management Act, A.R.S. Sections 49-701 et seq.; the Underground Storage Tank Regulation Act, A.R.S. Sections 49-1001 et seq.; A.R.S. Sections 49-851 through 49-868 pertaining to Management of Special Waste; the Hazardous Waste Management Act, A.R.S. Sections 49-921 et seq.; and in any rule or regulation adopted to implement said statutes.

c. All substances, materials and wastes that are, or that become, regulated, or that otherwise are classified as hazardous or toxic, under any Environmental Law during the term of this Contract.

3. The term “release” means any releasing, spilling, leaking, pumping, pouring, emitting, emptying, discharging, injecting, escaping, leaching, disposing or dumping.

C-23

4. As used herein, the term “Premises” means Contractor’s leasehold and/or any part or portion of Transit facility or City owned property where Contractor or its employees or agents causes to occur a release of a regulated substance.

5. As used herein, the term “Contractor” means every consultant, lessee, sublessee, licensee, permittee, concessionaire, tenant or other person, firm or corporation occupying or using the Premises pursuant to an agreement and includes Contractor’s heirs, personal representatives, successors-in-interest and assigns.

B. COMPLIANCE 1. Contractor shall not cause or permit any regulated substance to be used, generated,

manufactured, produced, stored, brought upon, or released on, or under the Premises, or transported to or from the Premises, by Contractor, its agents, employees, Contractor’s invitees or a third party in a manner that would constitute or result in a violation of any Environmental Law or that would give rise to liability under an Environmental Law. Contractor may provide for the treatment of certain discharges regulated under the City of Phoenix pretreatment ordinances pursuant to Chapter 28 of the Phoenix City Code or such other ordinances as may be promulgated and the Federal Clean Water Act, 33 U.S.C. Section 1251 et seq. Contractor shall indemnify, defend and hold harmless, on demand, City of Phoenix (“City”), its successors and assigns, its elected and appointed officials, employees, agents, boards, commissions, representatives, and attorneys, for, from and against any and all liabilities, obligations, damages, charges and expenses, penalties, suits, fines, claims, legal and investigation fees or costs, arising from or related to any claim or action for injury, liability, breach of warranty or representation, or damage to persons, the environment or Premises and any and all claims or actions brought by any person, entity or governmental body, alleging or arising in connection with contamination of, or adverse effects on, human health or the environment pursuant to any Environmental Law, the common law, or other statute, ordinance, rule, regulation, judgment or order of any governmental agency or judicial entity, which are incurred or assessed as a result, whether in part or in whole, of Contractor’s occupancy or use of the Premises during the term of this Contract or any previous contract or uses of the Premises by Contractor or its owners or affiliated entities, agents, employees, invitees, visitors or licensees. Regardless of the date of termination of this Contract, Contractor’s obligations and liabilities under this Section shall continue so long as City bears any liability or responsibility under the Environmental Laws arising from Contractor’s occupancy or use of the Premises during the term of this Contract. This indemnification of City by Contractor includes, without limitation, costs incurred in connection with any investigation of site conditions or any cleanup, remedial actions, removal or restoration work required or conducted by any federal, state or local governmental agency or political subdivision because of regulated substances caused by Contractor to be present on or under the Premises or present in the soil or ground water on or under the Premises or present in surface waters on or adjacent to the Premises.

2. Without limiting the foregoing, if the release by Contractor of any regulated substance on or under the Premises, or in surface waters on or adjacent to the Premises results in any contamination of the Premises or surface waters, Contractor shall promptly take all actions at its sole cost and expense that are necessary to mitigate any immediate threat to human health or the environment. Contractor shall then undertake any further action necessary to return the contaminated site to the condition existing prior to the introduction by Contractor of any regulated substance; provided that City’s approval of such actions shall first be obtained. Contractor shall undertake such actions without regard to the potential legal liability of any other person; however, any remedial activities by Contractor shall not be

C-24

construed to impair Contractor’s rights, if any, to seek contribution or indemnity from another person.

3. Contractor shall, at Contractor’s own cost and expense, make all tests, reports, studies and provide all information to any appropriate governmental agency as may be required pursuant to the Environmental Laws pertaining to Contractor’s occupancy or use of the Premises. This obligation includes but is not limited to any requirements for a site characterization, site assessment and/or remediation plan that may be necessary due to any actual or potential spills or discharges of regulated substances on, under or from the Premises, or in surface waters on or adjacent to the Premises during the term of this Contract. At no cost or expense to City, Contractor shall promptly provide all information requested by City pertaining to the applicability of the Environmental Laws to the Premises, to respond to any governmental investigation, or to respond to any claim of liability by third parties which is related to environmental contamination. In addition, City shall have the right to inspect, within ten (10) days of Contractor’s receipt of written request, and copy any and all records, test results, studies and/or other documentation, other than trade secrets and legally privileged documents, regarding environmental conditions relating to the use, storage, or treatment of regulated substances by Contractor on, under or from the Premises or in surface waters on or adjacent to the Premises.

4. Contractor shall notify the Public Transit Director within twenty-four (24) hours upon learning of the following: a. Any correspondence or communication from any governmental agency regarding the

application of Environmental Laws to the Premises or Contractor’s occupancy or use of the Premises;

b. Any change in Contractor’s activities on the Premises that will change or have the potential to change Contractor’s or City’s obligations or liabilities under Environmental Laws;

c. Any assertion of a claim or other occurrence for which Contractor may incur an obligation under this Section.

5. Contractor shall at its own expense obtain and comply with any permits or approvals that are required or may become required as result of any occupancy or use of the Premises by Contractor, its agents, employees, invitees and assigns.

6. Contractor shall insert the provisions of this Contract Exhibit E in any agreement or contract by which it grants a right or privilege to any person, firm or corporation under this Contract.

7. Contractor shall obtain and maintain compliance with any applicable financial responsibility requirements of federal, state and/or local law regarding the ownership or operation of any underground storage tank(s) or any device used for the treatment or storage of a regulated substance and present evidence thereof to the City, as may be applicable.

8. Contractor shall take reasonable precautions to prevent other persons not acting under Contractor’s authority from conducting any activity that would result in the release of a regulated substance on, under or from the Premises or in surface waters on or adjacent to the Premises. Contractor shall also exercise due care with respect to any regulated substance that may come to be located on the Premises as a result of the actions of third parties who are not under Contractor’s authority.

9. Contractor shall make its best efforts to minimize its production of a waste stream that includes regulated substances, and shall minimize the storage of regulated substances on, in and around the Premises.

C-25

C. TERMINATION OF AGREEMENT Contractor’s failure or the failure of its agents, employees, contractors, invitees or of a third party to comply with any of the requirements and obligations of this Contract Exhibit or applicable Environmental Law shall constitute a material breach of this Contract and shall permit the City to pursue the following remedies, in addition to all other rights and remedies provided by law or otherwise provided for in this Contract, to which the City may resort cumulatively, or in the alternative: 1. The City of Phoenix may, at the City’s election, keep this Contract in effect and enforce all of

its rights and remedies under the Contract, including (1) the right to recover rent and other sums as they become due by appropriate legal action and/or (2) the right, upon ten (10) day’s written notice to Contractor, to make payments required of Contractor or perform Contractor’s obligations and be reimbursed by Contractor for the cost thereof, unless such payment is made or obligation performed by Contractor within such ten (10) day period.

2. The City of Phoenix may, at the City’s election, terminate this Contract upon written notice to Contractor.

3. Notwithstanding any other provision in this Contract to the contrary, the City shall have the right of “self-help” or similar remedy in order to minimize any damages, expenses, penalties and related fees or costs, arising from or related to a violation of Environmental Laws on, under or from the Premises or in surface waters on or adjacent to the Premises, without waiving any of its rights under this Contract.

4. The exercise by the City of any of its rights under Section C of this Contract Exhibit shall not release Contractor from any obligation it would otherwise have under this Contract Exhibit.

5. The covenants of this Contract Exhibit shall survive the termination of this Contract.