Addendum_2_-_Attachment_7_-_Proposed_Agreement.docx

ATTACHMENT 7 – PROPOSED FORM OF AGREEMENT

The proposed form of agreement is the State of California Standard Agreement (STD 213 Form) with exhibits and documents noted below and included within this Attachment.

· Exhibit A – Scope of Work

· Exhibit A.1 – Service Descriptions

· Exhibit A.2 – Key Performance Indicators and Service Credits

· Exhibit A.3 – On-Vehicle Device Requirements

· Exhibit B – Budget Detail and Payment Provisions

· Exhibit B.1 – Rate Sheet

· Exhibit B.2 – Equipment Listing

· Exhibit C – Information Technology General Provisions (GSPD- 401IT), Effective 6/21/22

· Exhibit D – Cloud Computing - Software as a Service (SaaS) General Provisions, Effective 6/21/22

· Exhibit E – Cloud Computing Services Special Provisions for Software as a Service (SaaS), Effective 3/15/18

· Exhibit F – Insurance Provisions

· Exhibit G – Federal Transportation Administration (FTA) Clauses

· Exhibit H – Definitions

· Exhibit I – Technical Proposal in response to Request for Proposal (RFP)

· RFP 0000032011 incorporated by reference and made a part of this agreement as if attached hereto.

Upon award, the following sections will be updated on the STD 213 form as noted below:

IMPORTANT NOTE: Provisions in the final agreement that may be modified by DGS to reflect contractor’s award are noted in brackets “{ }”.

Bidders may not alter information in this Attachment or the Exhibits. Do not submit this attachment with the proposal.

EXHIBIT A – SCOPE OF WORK

INTRODUCTION

The Department of General Services (hereinafter referred to as “DGS” or "State”), on behalf of Department of Transportation, California Integrated Travel Project (Cal-ITP) is contracting with {CONTRACTOR NAME} (hereinafter referred to as “Contractor”) for General Transit Feed Specification-Realtime (GTFS-Realtime) Services solely for use by local transit providers that provide public transportation services (hereinafter referred to as “Transit Provider”).

The Contractor shall provide the GTFS-Realtime Services to Transit Providers in accordance with the terms and conditions of this Master Service Agreement (hereinafter referred to as “MSA” or “Agreement”).

The Contractor shall also permit Transit Providers outside of California to participate under this MSA. Each Transit Provider shall determine whether use of the MSA is consistent with its procurement policies and regulations.

AGREEMENT TERM

The term of this MSA is for a three (3) year period, with the start and end date noted on the Standard Agreement (STD 213). The DGS, at its sole discretion, may extend the agreement for two (2) additional two (2) year periods or portion thereof at the same rates, terms, and conditions.

The Contractor agrees to honor all User Agreements executed by Transit Providers at the same rates, terms, and conditions. All Transit Provider User Agreements issued against this MSA must be executed prior to MSA expiration and may be fulfilled/completed in its entirety within twelve (12) months following the MSA term end date.

CONTRACT ADMINISTRATION

a. The Contractor shall assign a Contract Manager as a single point of contact for all MSA inquiries and contractual issues. Prior to MSA execution, the Contractor shall provide its Contract Manager’s name, email, phone, and fax contact information to the State Contract Administrator.

b. DGS shall assign a State Contract Administrator for the MSA and maintain User Instructions for Transit Providers on the State’s procurement portal (Cal eProcure).

c. Should the Contractor’s Contract Manager or the State Contract Administrator change, the party will provide written notice within five (5) days of the change, without amendment to this Agreement. Contractor must also notify Transit Providers of change to the Contractor’s Contract Manager change.

d. The Contractor shall promptly notify the State Contract Administrator in writing of any unresolved issues or problems that have been outstanding for more than three (3) business days.

e. The California Integrated Travel Project (Cal-ITP) may request data and reporting, relevant to the MSA, from the Contractor to support interoperability goals and refinement of the overall program.

AUTHORIZATION TO RENDER SERVICES

Prior to rendering services, the Contractor and Transit Provider must execute an agreement (hereinafter referred to as the “User Agreement”) that incorporates all terms of this MSA by reference and may contain additional specific terms and conditions from the Transit Provider, none of which may alter, rescind, or conflict with the terms and conditions of this MSA.

The User Agreement shall also contain a Scope of Work which includes a detailed project description, project implementation plan, and services requested by the Transit Provider. The User Agreement shall be in the form of a STD 213 or an appropriate equivalent contract form as required by the Transit Provider. All User Agreements must identify the MSA number.

Transit Providers shall use the following process to execute User Agreements:

a. The Transit Provider will complete and send documentation to the Contractor that includes its desired operating objectives, intended operating environment, and any desired services.

b. The Contractor shall respond within five (5) business days to confirm receipt of the Transit Provider documentation and indicate interest in proposing pricing.

c. The Transit Provider and the Contractor will meet to discuss the documentation, after which the Contractor may propose pricing for services that the Transit Provider wishes to purchase, at or below the maximum rates identified in Exhibit B.1 – Rate Sheet.

d. The Transit Provider and the Contractor will collaboratively develop a project implementation plan with clearly defined steps and timelines, which will be included in the User Agreement Scope of Work.

e. The Transit Provider and the Contractor will execute a User Agreement, which will include the Scope of Work. The User Agreement shall bind the Contractor to all obligations and terms and conditions agreed upon.

The Contractor must not refuse to accept User Agreements from Transit Providers.

SERVICES

The Contractor shall provide services and offer products as outlined in the MSA in accordance with the following:

· Exhibit A.1 – Service Descriptions

· Exhibit A.2 – Key Performance Indicators and Service Credits

· Exhibit A.3 – On-Vehicle Device Requirements Services must be provided at or below the rates identified in Exhibit B.1 – Rate Sheet.

SUBSTITUTION/DISCONTINUED DEVICES

The devices identified in Exhibit B.1 – Rate Sheet shall be available throughout the duration of the MSA term unless a substitution is approved by the State Contract Administrator. If, during the life of the MSA, a device is discontinued, the Contractor shall notify the State Contract Administrator in writing and propose a comparable substitute device *no more than thirty (30)* [at least sixty (60)] calendar days [prior to] *following the manufacturer announcement of* device discontinuation. Notice shall include a side-by-side comparison of the proposed device to the product being replaced, its corresponding specifications, and pricing. The price of the substitute device must be at or below the price of the device being replaced. The State Contract Administrator will review the substitute device and determine acceptability.

Once the substitute device has been approved, the State Contract Administrator will provide written approval to the Contractor and reflect the changes through an amendment to the MSA.

If no substitute device is available that meets or exceeds the specifications due to fundamental technology or market change, the State may determine obsolescence of a device at its sole discretion.

The Contractor shall not substitute devices without written approval from the State Contract Administrator.

CONTRACT REQUIREMENTS

The State will consider the Contractor to be the sole point of contact with regard to contractual matters, payments, warranty issues, and maintenance of the equipment for the term of the contract and any extensions. The Contractor shall be responsible for successful performance of any and all of their subcontractors.

The Contractor will be responsible for compliance with requirements under the Agreement, even if requirements are delegated to subcontractors. All State policies, guidelines, and requirements apply to subcontractors. The Contractor and subcontractors shall not in any way represent themselves in the name of the State of California without prior written approval.

The applicable provisions are:

· Exhibit C – Information Technology General Provisions (GSPD- 401IT), Effective 6/21/22

· Exhibit D – Cloud Computing – Software as a Service (SaaS) General Provisions, Effective 6/21/2022

· Exhibit E – Cloud Computing Services Special Provisions for Software as a Service (SaaS), Effective 3/15/18 Where the applicable general provisions refer to the State, in executed User Agreements this shall be understood to include the Transit Provider.

MSA USAGE REPORT

a. The Contractor shall submit usage reports on a quarterly basis to the State Contract Administrator for all sales using the report template provided by the State Contract Administrator. Usage Report will contain the following data elements at a minimum:

· Transit Provider Name

· User Agreement Number

· Order Date

· Invoice Amount

b. In addition, the Contractor shall submit a separate report listing all new User Agreements executed within the calendar quarter.

c. The State Contract Administrator will provide the reporting templates upon award. The State Contract Administrator reserves the right to modify the reporting template and require the Contractor to provide additional order information during the term of this MSA.

d. The reports shall be Excel spreadsheets transmitted electronically to Masters@dgs.ca.gov.

e. The reports are due even when there is no activity. Any reports that do not follow the required format or that excludes information will be deemed incomplete. The Contractor will be responsible for submitting corrected reports within five (5) business days of the date of written notification from the State.

f. Tax must not be included in the reports, even if it is on the User Agreement.

g. Reports are due by the thirtieth (30th) day following a calendar quarter. Failure to meet reporting requirements and submit the reports on a timely basis shall constitute grounds for suspension of the MSA.

h. Amendments for term extensions may be approved only if all quarterly reports due have been submitted to the State Contract Administrator.

DGS INCENTIVE FEE

a. The Contractor shall remit an incentive fee to the DGS-PD equal to 1.25 percent of all invoices, excluding taxes, issued against the MSA on a calendar quarter basis. (Example: If the net Transit Provider sales invoiced for a calendar quarter is $100,000.00, the incentive fee due to DGS is $1,250.00.)

b. The incentive fee is due to DGS-PD irrespective of whether or not the Transit Provider has paid the Contractor. This Incentive Fee shall not be included in the Transit Provider’s purchase price, nor invoiced or charged to the Transit Provider. All prices quoted to Transit Providers shall reflect the pricing outlined in Exhibit B.1 – Rate Sheet.

c. Payment may be made in the form of an electronic payment or by submitting a check payable to the State of California, Department of General Services.

d. To submit incentive fees electronically, users must register on the DGS LPA Payment Portal (https://www.dgs.ca.gov/PD/Services/Page-Content/Procurement-Division-Services-List-Folder/Access-LPA-Payment-Portal). Incentive Fee payments made by check shall be submitted to the following address:

Department of General Services Attn: MAPS Payments Processing 707 3rd Street, 2nd Floor West Sacramento, CA 95605

e. Failure to meet incentive fee payment requirements on a timely basis shall constitute grounds for suspension of the MSA.

CONTRACT TERMINATION/EXPIRATION TRANSITION PLAN

The Contractor must work with the State Contract Administrator to close out the MSA upon expiration. The Contractor will ensure that an efficient and effective transition takes place.

EXECUTIVE ORDER N-6-22 – RUSSIA SANCTIONS

On March 4, 2022, Governor Gavin Newsom issued Executive Order N-6-22 (the EO) regarding Economic Sanctions against Russia and Russian entities and individuals. “Economic Sanctions” refers to sanctions imposed by the U.S. government in response to Russia’s actions in Ukraine, as well as any sanctions imposed under state law. The EO directs state agencies to terminate contracts with, and to refrain from entering any new contracts with, individuals or entities that are determined to be a target of Economic Sanctions. Accordingly, should the State determine Contractor is a target of Economic Sanctions or is conducting prohibited transactions with sanctioned individuals or entities, that shall be grounds for termination of this Agreement. The State shall provide Contractor advance written notice of such termination, allowing Contractor at least thirty (30) calendar days to provide a written response. Termination shall be at the sole discretion of the State.

GENERATIVE ARTIFICIAL INTELLIGENCE (GEN AI) TECHNOLOGY & REPORTING

*Upon request by an ordering agency, Contractor must complete a GenAI Reporting and Fact Sheet (STD 1000) to identify if their solution or service includes, or makes available, any GenAI including, GenAI from third parties or subcontractors.*

During the term of the contract, Contractor must notify the State in writing if their services or any work under this contract includes, or makes available, any previously unreported GenAI technology, including GenAI from third parties or subcontractors. Contractor shall immediately complete the GenAI Reporting and Factsheet (STD 1000) to notify the State of any new or previously unreported GenAI technology.

At the direction of the State, Contractor shall discontinue the use of any new or previously undisclosed GenAI technology that materially impacts functionality, risk or contract performance, until use of such GenAI technology has been approved by the State.

Failure to disclose GenAI use to the State and submit the GenAI Reporting and Factsheet (STD 1000) may be considered a breach of the contract by the State at its sole discretion and the State may consider such failure to disclose GenAI and/or failure to submit the GenAI Reporting and Factsheet (STD 1000) as grounds for the immediate termination of the contract. The State is entitled to seek any and all relief it may be entitled to as a result of such non-disclosure.

The State reserves the right to amend the contract, without additional cost, to incorporate GenAI Special Provisions into the contract at its sole discretion and/or terminate any contract that presents an unacceptable level of risk to the State.

*If Contractor identifies GenAI in their solution, a copy of the STD 1000 must be submitted to the State Contract Administrator.*

EXHIBIT A.1 – SERVICE DESCRIPTIONS

The Contractor shall offer General Transit Feed Specification-Realtime (GTFS-Realtime) Services, On-Vehicle Devices, and Customer Support for GTFS-Realtime Services, as described in this exhibit.

The Transit Provider is not obligated to purchase On-Vehicle Devices. Transit Providers shall be able to provide their own On-Vehicle Device(s) with which to use the Contractor’s GTFS-Realtime Services. If the Transit Provider purchases On-Vehicle Devices from this MSA, it shall do so from the same Contractor from which it purchases GTFS-Realtime Services.

1. GTFS-REALTIME SERVICES

The Contractor shall provide GTFS-Realtime Services to be used by Transit Providers to provide end-users accurate and reliable transit journey information through Journey Planning Applications. The Contractor shall ensure that the GTFS-Realtime Feeds produced as part of the GTFS-Realtime Services implement all adopted elements of the GTFS-Realtime Standard and all additional requirements outlined in this MSA. All services outlined in this section are included as part of the GTFS-Realtime Services.

Section 1.1 lists the minimum requirements for the GTFS-Realtime Feeds output and quality, Section 1.2 lists the minimum requirements for mandatory interfaces provided by the Contractor for ingestion of data required to produce compliant GTFS-Realtime Feeds, Section 1.3 describes data storage requirements, Section 1.4 outlines reporting requirements, Section 1.5 lists the requirements for project implementation, and Section 1.6 includes additional support.

GTFS-Realtime Feeds The Contractor shall provide services to create and publish GTFS-Realtime Feeds. Services shall be performed during the performance period defined in the User Agreement. GTFS-Realtime Feeds shall be produced 365 days/year and twenty-four (24) hours/day, unless otherwise specified in the User Agreement.

General Feed Requirements At a minimum, the GTFS-Realtime Feeds shall:

1. Be hosted by the Contractor at a Permalink specific to the Transit Provider. The Permalink shall:

a. Support sufficient concurrent Permalink connections to ensure that under normal operating conditions GTFS-Realtime Feeds can be delivered within one (1) second, and no more than 0.1% of connection requests are being refused or disconnected;

b. Use HTTP over TLS to ensure feed integrity and security;

c. Configure the web-server hosting GTFS-Realtime data to correctly report the file modification date so consumers can leverage the If-Modified-Since HTTP header;

d. Provide protocol buffer-encoded feed content by default when queried via an HTTP request at the given URL without requiring specially defined HTTP accept headers to receive protocol-buffer encoded content.

2. Meet the GTFS-Realtime Standard, as well as all additional requirements defined in this MSA and the User Agreement, throughout the term of the agreement.

3. Incorporate new, formally adopted required changes to the GTFS-Realtime Standard within thirty (30) calendar days of adoption.

4. Include data on trip_id, vehicle_id, route_id, and stop_id wherever applicable including in TripDescriptor and VehicleDescriptor messages. The Contractor is responsible for implementing a process to accurately ascertain the trip_id, vehicle_id and route_id.

5. Be consistent with the GTFS Schedule Feed provided by and published by the Transit Provider for the trip_id, vehicle_id, route_id, and stop_id. The Contractor is responsible for ensuring the accuracy of association between the GTFS Schedule Feed and the GTFS-Realtime Feeds.

6. Be monitored continuously by the Contractor. In case of an error, the services shall be designed to have a Graceful Exit and the GTFS-Realtime Feeds shall be designed to recover automatically.

The Contractor may implement API-key controlled access to the GTFS-Realtime Feeds hosted at the Permalink, provided the Contractor implements and makes API-keys available to the general public using automated processes for enrollment and key issuance. The Contractor may implement a fair use policy with a Rate Limit for each API-key of not less than 1,000 requests per hour, provided that this policy and any other requirements to obtain an API-key have been approved by the Transit Provider.

Feed Validation The Contractor shall use a Staging Environment to confirm that any changes to the GTFS-Realtime Services do not produce any validation errors using the Canonical GTFS-Realtime Validator prior to deploying any changes to a production environment. The Staging Environment shall utilize different servers and/or virtual environments, applications, and databases than the production environment. In addition, the Contractor shall confirm that the production environment is performing adequately by confirming that the Canonical GTFS-Realtime Validator does not produce any errors for a series of three validations, performed no less than 10-minutes apart, during peak operational hours for the following instances:

1. As a component of Service Acceptance;

2. Prior to the initiation of Feed Acceptance process;

3. With every update to the associated GTFS Schedule Feed(s);

4. With every update to the Service Change and Alerts Management Service;

5. After any change to the GTFS-Realtime Services; and

6. Within thirty (30) calendar days of publication of a new version of the Canonical GTFS-Realtime Validator.

Feed Accuracy The Contractor shall analyze its prediction accuracy in the Trip Updates Feed by hour of day for each route and each stop using the following metrics:

1. Availability of Acceptable StopTimeUpdate Messages;

2. Availability of Acceptable VehiclePosition Messages;

3. Experienced Wait Time Delay;

4. Prediction Inconsistency; and

5. Prediction Reliability.

These metrics shall be reported by the Contractor in calendar quarterly reports described in Section 1.4. Additional metrics or metric expressions may be added in the User Agreement. The Contractor may use a prediction algorithm to incorporate additional factors impacting vehicle on-time performance, such as traffic data, to improve predictive accuracy.

Vehicle Positions Feed Beyond those specified in the GTFS-Realtime Standard, the Contractor shall meet the following requirements for the Vehicle Positions Feed:

1. Update location data in the feed within 2 seconds of the backend receiving new data about a vehicle in service.

2. Include valid data in at least the following fields and messages:

a. Position;

b. Stop_id;

c. Timestamp;

d. Current_status; and

e. Current_stop_sequence.

Trip Updates Feed Beyond those specified in the GTFS-Realtime Standard, the Contractor shall meet the following requirements for the Trip Updates Feed and may use a prediction algorithm to do so:

1. Timestamp field in the TripUpdate message for a specified trip shall reflect the time the prediction(s) for this trip has been updated.

2. TripUpdate messages shall be published within 2 seconds of the backend receiving updated vehicle location and/or trip data from the vehicle.

3. TripProperties messages shall be required when start date, start time, or shapes are updated for a given trip compared to what was published in the associated GTFS Schedule Feed.

4. StopTimeUpdate messages shall:

a. Include stop_sequence, as it unambiguously resolves to a GTFS stop time in stop_times.txt unlike stop_id, which can occur more than once in a trip (e.g., loop route);

b. Have stop arrival and departure times between sequential stops that increase;

c. Have stop arrival times that are before the departure time for the same trip and stop sequence if a layover or dwell time is expected - otherwise, arrival time should be the same as departure time; and

d. Be published such that for a given trip_id, StopTimeUpdate messages shall be strictly ordered by increasing stop_sequence and no stop_sequence shall be repeated.

5. StopTimeUpdate messages shall include a predicted arrival and/or departure time in the future for each stop for each:

a. Trip currently in progress;

b. Trip that is scheduled to be in progress now (even if it has not started already because it has been delayed) or that is scheduled to start in the next sixty (60) minutes.

Service Alerts Feed Beyond those specified in the GTFS-Realtime Standard, the Contractor shall update alerts in the Service Alerts Feed within two (2) seconds of receiving a confirmed input from the Service Change and Alerts Management Service (Section 1.2.2).

Data Ingestion Data Inputs The Contractor’s GTFS-Realtime Services shall ingest:

1. The GTFS Schedule Feed provided by the Transit Provider at a Permalink on a daily basis at 11:59pm local time to the Transit Provider.

2. Data inputs from the Service Change and Alerts Management Service (Section 1.2.2).

3. Vehicle data, comprising at least latitude, longitude, and a unique vehicle or device id, and optionally comprising bearing, odometer, speed, congestion level, and occupancy status data through an Ingestion Point, as needed.

In the case vehicle data is obtained from a source other than the Contractor provided On-Vehicle Device (i.e., Transit Provider provided On-Vehicle Device, existing onboard components, the Transit Provider), the Contractor shall provide a central Ingestion Point for vehicle data for ingestion. The Contractor shall provide the specification of this Ingestion Point in OpenAPI format and shall include details for protocol (e.g., HTTPS), interface language (e.g., JSON, YAML, XML) and authentication (e.g., API key). At a minimum, the Ingestion Point shall accept position updates in the National Marine Electronics Association (NMEA) format and shall use an authentication mechanism to ensure protection and integrity of the service. The Ingestion Point shall support ingestion of all required and optional vehicle data elements specified in item #3 above as well as any additional vehicle data elements defined in the User Agreement.

Service Change and Alerts Management Service The Contractor shall provide a cloud-based service (“Service Change and Alerts Management Service”) to the Transit Provider to manage transit service changes and alerts which are integrated into the GTFS-Realtime Feeds. Inputs to the tool may include stop, trip, route, or service-wide-based alerts as well as updates to the provided transit service compared to the published GTFS Schedule Feed. The inputs created by the Transit Provider through the Service Change and Alerts Management Service shall be incorporated into the relevant GTFS-Realtime Feeds including the Trip Updates Feed and the Service Alerts Feed. These inputs may also optionally be incorporated into the Trip Modifications Feed.

The Service Change and Alerts Management Service shall be user-friendly for non-technical Transit Provider personnel. The Service Change and Alerts Management Service shall meet the following minimum requirements for accessibility:

1. Shall meet the ADA Section 508 and WCAG 2.1 accessibility requirements; and/or

2. Shall provide full functional parity for users accessing the solution with assistive technologies.

The Service Change and Alerts Management Service shall be capable of efficiently handling the input of at least the following operational situations and incorporating them into GTFS-Realtime Feeds:

1. Schedule update:

a. Cancellations or reschedules;

b. Detour (e.g., a construction re-route); and

c. Additional service added;

2. Vehicle reassignment from one trip or route to another;

3. Anticipated delay or service interruption (e.g., due to an event);

4. Notice of unplanned major schedule delay or a service interruption;

5. General service interruptions:

a. Driver unavailable before or part way through their scheduled block (e.g., sickness);

b. Vehicle unavailable before or part way through its scheduled run (e.g., break down);

c. Unplanned detour due to right-of-way unavailability (e.g., road blocked); and

d. Unscheduled turn-back.

The Service Change and Alerts Management Service shall use an authentication mechanism for accessing the service in such a way as to ensure protection and integrity of the service.

The Service Change and Alerts Management Service shall not require the configuration or use of any additional services or features beyond the scope of the GTFS Realtime Services offered through this MSA, such as fully-functional Computer-Aided Dispatch (CAD) systems.

Data Connectivity The Contractor shall anticipate and plan for areas with recurring connectivity outages (especially along routes outside of major metropolitan areas) and incorporate algorithms designed to maximize the provision of complete and accurate GTFS-Realtime Feeds.

Data Transmission The Contractor shall minimize the amount of data transmitted from and to On-Vehicle Devices. The Contractor shall only use the Transit Provider connectivity plan for transmission of data directly related to the creation, configuration, and/or maintenance of the GTFS-Realtime Services, unless otherwise agreed with the Transit Provider. The Contractor shall not connect to the Transit Provider’s WLAN except to perform actions requiring data which are outside of standard operations and exceed regular operational data transmission needs, or as specified in the User Agreement.

Long-Term Data Storage The Contractor shall store location data from the Vehicle Positions Feed in a schema that is directly compatible with the TIDES Vehicle Locations Event Data Table specification (https://tides-transit.github.io/TIDES/main/tables/ - vehicle-locations). The Contractor shall store location data from all trips, including both revenue and non-revenue trips such as dead-heads and trips to/from vehicle base/yard. The Contractor shall use an authentication mechanism to ensure protection and integrity of the Long-Term Data Storage and the data retrieval mechanism. For all stored location data, the Contractor shall make the data:

1. Available for the previous four (4) months;

2. Viewable and queryable based on, at a minimum, vehicle ID, trip, route, and desired timeframe (month, week, day), by the Transit Provider with less than five-second recall; and

3. Available for download by the Transit Provider as TIDES Vehicle Locations Event Data Table .CSV file(s) in a single compressed .ZIP file, or in the format specified in the User Agreement, for both a complete data set and a queried result.

The Contractor shall provide access to Long-Term Data Storage for third-party individuals or organizations designated by the Transit Provider.

Reporting The Contractor shall provide reports on system performance to the Transit Provider and any additional governmental entities (i.e., Caltrans, California Integrated Travel Project) authorized by the Transit Provider. The User Agreement shall specify the Contractor’s reporting obligations which must include the following:

1. Sharing Canonical GTFS-Realtime Validator results with the Transit Provider within twenty-four (24) hours of receipt.

2. Reporting all identified Service Unavailability Events and Journey Planning Application Events, including those resulting from Exclusion Events, to the Transit Provider within an hour of identification, with reference to the unique and trackable ID numbers if an associated customer support inquiry was created.

3. Providing a report within fifteen (15) calendar days of a new calendar quarter which contains content covering the previous calendar quarter (i.e., report provided in April will cover the first calendar quarter data (January – March)) and which shall contain, at a minimum, the following components:

a. Measurement of the Contractor’s actual performance relative to the Key Performance Indicators and the accrual of Service Credits, if applicable (Exhibit A.2);

b. Presentation of prediction results using specified accuracy metrics (Section 1.1.3); and

c. Summary of any Service Unavailability Events, Journey Planning Application Events, all customer support inquires made by the Transit Provider in the reporting period, and any pending customer support inquiries from previous reporting periods with reference to the unique and trackable ID number, as applicable.

4. Providing a Microsoft Excel file within fifteen (15) calendar days of the Transit Provider’s fiscal year end, for the purpose of the Federal Transit Administration (FTA) National Transit Database (NTD) reporting, with the following information:

a. Annual Vehicle Revenue Miles for each transit mode; and

b. Annual Vehicle Revenue Hours for each transit mode.

The level of detail, including the need for additional report(s), and the format of these report(s) shall be defined in the User Agreement.

Implementation The Contractor shall implement the GTFS-Realtime Services in accordance with the following requirements.

Service Acceptance Service Acceptance is the milestone upon which the GTFS-Realtime Services meet all requirements in this SOW and the User Agreement, except for the requirements directly leading to Feed Acceptance (Section 1.5.2). The User Agreement shall further detail the Contractor’s approach to achieve Service Acceptance, which at a minimum must include:

1. The name, email, and phone number of the primary point of contact for both the Contractor and Transit Provider;

2. A plan to achieve Service Acceptance which outlines in detail the Contractor’s required activities and Transit Provider’s required activities;

3. Device testing to confirm compatibility with the GTFS-Realtime Services with a minimum of one On-Vehicle Device of each make and model included in the User Agreement Scope of Work, deployed in its simulated or actual target environment, unless otherwise specified in the User Agreement. For On-Vehicle Devices purchased from the Contractor, the device testing shall be executed prior to delivery, installation, and commissioning of On-Vehicle Devices (Section 2).

4. Basic support and troubleshooting to the Transit Provider for integration with the Ingestion Point (Section 1.2), as applicable.

5. End-to-end functionality and performance testing for all vehicles and routes to validate that the service is functioning as expected, including feed validation through the Canonical GTFS-Realtime Validator (Section 1.1.2); and

6. Completion of all required training for relevant Transit Provider personnel (Section 3.1).

The Contractor shall alert the Transit Provider before testing commences. The Contractor shall resolve all identified issues, unless the Contractor and the Transit Provider reach an agreement to move the solution to production despite outstanding minor issues (so long as those minor issues have a clear, agreed upon plan and timeline for resolution). The Contractor shall compile and deliver to the Transit Provider a Service Acceptance log to show that all Service Acceptance requirements have been met. The Transit Provider shall review the Contractor’s Service Acceptance log and certify in writing that the Contractor has completed all Service Acceptance requirements. Such certification shall not be unreasonably withheld. Upon Service Acceptance, payment of ongoing monthly fees for the GTFS-Realtime Service will commence.

Within twenty-four (24) hours following Service Acceptance, the Contractor shall publish GTFS-Realtime Feeds at a Permalink, unless otherwise specified in the User Agreement. The Contractor shall notify Transit Provider at the time of Permalink publication, at which point failure to provide fully functional GTFS-Realtime Services compliant with all requirements in Section 1 may lead to the accrual of Service Credits as outlined in Exhibit A.2 (Key Performance Indicators and Service Credits). Service Acceptance shall occur prior to Feed Acceptance by Journey Planning Applications.

Feed Acceptance Following Service Acceptance (Section 1.5.1), the Contractor shall provide Feed Acceptance assistance for up to three (3) Journey Planning Applications, to be selected by the Transit Provider as a component of the User Agreement. At a minimum, the Feed Acceptance assistance shall consist of the following:

1. Communication: The Contractor shall provide the name, email, and phone number of its point of contact who shall be responsible for communication with, and/or monitoring dashboards provided by, the specified Journey Planning Application(s).

2. Feed Acceptance: The Contractor shall resolve any errors raised during the Feed Acceptance process related to GTFS-Realtime Feeds, in accordance with the Recovery Time Objectives for a Journey Planning Application Event as defined in Exhibit A.2 (Key Performance Indicators and Service Credits).

3. Referral to the Transit Provider: GTFS Schedule Feed errors and/or errors related to the Transit Provider provided On-Vehicle Device shall be referred to the Transit Provider for resolution, and therefore shall provide the Contractor with relief from its obligations to meet the Key Performance Indicators, as defined in Exhibit A.2 (Key Performance Indicators and Service Credits).

4. Confirmation of Feed Acceptance: Upon any and all adopted modifications to the GTFS-Realtime Standard, the Contractor shall ensure Feed Acceptance.

Feed Acceptance shall be considered complete upon confirmation from the Journey Planning Application of acceptance of the GTFS-Realtime Feeds for use in their respective Journey Planning Application(s).

Additional Support The Contractor shall provide support as requested by the Transit Provider to accommodate non-standard Transit Provider needs for implementation and operation of the GTFS-Realtime Services at or below the hourly rate for GTFS-Realtime Services Additional Support quoted in Exhibit B.1 – Rate Sheet.

ON-VEHICLE DEVICE SERVICES

The Contractor shall offer On-Vehicle Devices for sale to Transit Providers to generate the vehicle data inputs necessary for the GTFS-Realtime Services (Section 1.2.1). All On-Vehicle Devices must meet the requirements outlined in Exhibit A.3 – On-Vehicle Device Requirements. If the Contractor is providing On-Vehicle Devices, the User Agreement shall include the requirements outlined in this section. The Contractor may provide On-Vehicle Devices that perform additional functions beyond those listed in Exhibit A.3 – On-Vehicle Device Requirements, given that the additional functionality does not compromise the integrity and quality of the GTFS-Realtime Services required to meet the key performance indicators outlined in Exhibit A.2 – Key Performance Indicators and Service Credits.

Upon request by the Transit Provider, and at or below the pricing quoted in Exhibit B.1, Rate Sheet, the Contractor shall provide the following services:

Ordering and Delivery The Contractor shall deliver On-Vehicle Devices to the Transit Provider at the address specified by the Transit Provider at the time of the order. The Contractor shall provide the Transit Provider with the total number of On-Vehicle Devices defined in the User Agreement. The Contractor shall ensure that delivery times between the Transit Provider issuing a purchase order and delivery to the Transit Provider shall never exceed six (6) months for orders up to 250 devices, and nine (9) months for orders up to 1000 devices.

Device Testing The Contractor shall carry out device testing to confirm compatibility with the GTFS-Realtime Services with a minimum of one On-Vehicle Device of each make and model within the defined scope, deployed in its simulated or actual target environment, unless otherwise specified in the User Agreement. For On-Vehicle Devices purchased from the Contractor, the device testing shall be executed prior to delivery, installation, and commissioning of On-Vehicle Devices.

Installation and Commissioning Installation of the On-Vehicle Devices shall be completed as described in the User Agreement. The Contractor shall offer “Contractor Installation” services, as described below. Following installation, each On-Vehicle Device shall undergo commissioning testing to ensure that the quality standards agreed on in the User Agreement are met for both the installation of the On-Vehicle Device and, if applicable, the integration of the On-Vehicle Device with other onboard components. Only after each On-Vehicle Device has passed all commissioning tests agreed upon in the User Agreement shall the Contractor commission the On-Vehicle Device into service.

Installation shall fall into one of the following categories:

Transit Provider Installation The Contractor shall provide clear installation instructions to the Transit Provider in a format accessible to Transit Provider personnel, as described in the User Agreement. If installation issues arise, the Contractor shall provide up to Level 2 Support (Section 3.2, Table 1). If additional support at Level 3 is requested, the Contractor may offer such support to the Transit Provider at or below the hourly rates for Contractor Custom Installation (Exhibit B.1 – Rate Sheet).

Contractor Installation At the request of the Transit Provider, the Contractor shall professionally install On-Vehicle Devices. Professional installation includes, but is not limited to, connecting to an appropriate and dependable power supply (e.g., power-on-ignition, always-on), securing in such a way that the On-Vehicle Device remains in a stable position, and mounting of radio and Global Navigation Satellite System (GNSS) antennas (as needed), including routing, fastening, and labeling of associated cabling. Installation location(s) shall be specified in the User Agreement, where all On-Vehicle Devices shall be installed in such a way as to minimize driver obstruction. Installed devices shall conform to all applicable safety regulations. The Contractor shall provide certified and authorized personnel to perform all installation services.

Contractor installation shall either be a Standard Installation or a Custom Installation based on the installation location and conditions. The Contractor shall offer Standard Installation for vehicles which meet the following conditions:

1. Available power via a USB, automobile auxiliary power outlet, or other similar connection source.

2. Available flat surface (either vertical or horizontal) near enough to the required vehicle power supply connection as to utilize the On-Vehicle Device’s power cable or be suitable for connection via eyelets.

3. Available access to antenna mount points and ability to route antenna cabling to antenna mount points on window or roof, if needed to meet the requirements defined in the On-Vehicle Device Requirements (Exhibit A.3).

The Contractor shall be liable for repair or replacement costs for On-Vehicle Devices in the case of installation or testing actions which cause damage to the functionality of the On-Vehicle Device.

All installations performed by the Contractor on vehicles not covered by these conditions shall be Custom Installations, which shall be offered at or below the Contractor Custom Installation hourly rate quoted in Exhibit B.1 – Rate Sheet.

All installations shall include the appropriate mounting hardware and may include the provision of a ruggedizing case(s) to meet the requirements defined in the On-Vehicle Device Requirements (Exhibit A.3).

The installing party shall execute the commissioning testing requirements detailed in the User Agreement and shall share the completed results with the other party. The other party will confirm that commissioning testing has been successfully completed by the installing party. Upon confirmation, the Contractor shall commission the On-Vehicle Device into service.

Warranty The Contractor shall provide a five-year (5-year) warranty for the On-Vehicle Devices. Terms for the warranty provided shall be in full accordance with the DGS General Provisions – Information Technology, with the exception of the number of years of warranty coverage which shall be five (5) years.

Device Replacement During Warranty If any of the On-Vehicle Devices purchased from the Contractor fails to meet the functional requirements and/or technical specifications outlined in the MSA and the User Agreement, then the devices shall be subject to warranty coverage. If On-Vehicle Devices subject to the warranty coverage need to be replaced, then the Contractor shall replace the failed products at no cost to the Transit Provider, including all associated shipping expenses. The replacement product shall be delivered no later than fifteen (15) business days after the Transit Provider’s request has been received by the Contractor. Replacement On-Vehicle Device(s) cannot be used, refurbished, or recycled. If the make and model of the failed device has been discontinued, the replacement device must meet or exceed all functional requirements and technical specifications outlined in the MSA. The Contractor shall provide the Transit Provider with clear instructions on how to remove and replace On-Vehicle Devices and perform commissioning testing on the replacement devices.

Discontinuation If an On-Vehicle Device offered for sale by the Contractor will be discontinued, then the Contractor shall notify the Transit Provider [no less than six (6) months in advance of the discontinuance date.] *more than thirty (30)* [sixty (60)] *calendar days following the manufacturer announcement of device discontinuation*. If orders are pending for On-Vehicle Devices that will be discontinued within six (6) months, the Contractor shall allow for order cancellation without penalty and shall allow the Transit Provider to place a new order for On-Vehicle Devices.

Additional Support [Non-Mandatory] The Contractor may offer additional support for On-Vehicle Devices as requested by the Transit Provider to accommodate non-standard Transit Provider needs for implementation and operation of the On-Vehicle Devices at or below the hourly rate quoted in Exhibit B.1 – Rate Sheet, which shall exclude Contractor Custom Installation costs given there is a separate hourly rate for Contractor Custom Installation.

CUSTOMER SUPPORT FOR GTFS-REALTIME SERVICES

Training Fees for the GTFS-Realtime Services (Exhibit B.1 – Rate Sheet) shall include a maximum of two training sessions for Transit Provider participants which shall cover the full scope of training outlined in this section. Additional training may be offered, as requested by the Transit Provider, at or below the hourly rate for GTFS-Realtime Services Additional Support quoted in Exhibit B.1 – Rate Sheet.

The Contractor shall provide the training sessions in the format defined in the User Agreement. The training sessions shall be offered to the Transit Provider participants identified in the User Agreement. The Contractor shall provide clear instructions and training to the Transit Provider so that the Transit Provider may successfully use the purchased service(s) and perform Level 1 basic troubleshooting (Section 3.2, Table 1).

The training shall, at a minimum, cover:

1. Usage of the service(s) purchased, including Service Change and Alerts Management Service and long-term data storage;

2. Level 1 support, including but not limited to, basic operation, basic issue identification and resolution, and how to verify system functionality at any given moment;

3. If applicable, installation, replacement, and removal of On-Vehicle Devices; and

4. Usage of the customer support ticketing system.

The Contractor shall provide instructional material to the Transit Provider in an electronic format that can be accessed at any time, unless otherwise specified in the User Agreement. The Contractor shall update the instructional material as needed to ensure the successful use of the purchased service(s). The instructional material shall be geared toward Transit Provider personnel who have no knowledge of the system but are qualified for their hired function (i.e., driver, maintenance, etc.).

Support The Contractor shall provide email or web-based customer support for the GTFS-Realtime Services, as well as a customer support phone number. Regardless of whether the customer support request was made on the web or by email or phone, the Contractor’s customer support system shall issue a confirmation to the Transit Provider upon receipt of a submission. Each submission shall have a unique and trackable ID number by which the Transit Provider can see the status of its inquiry, and which shall be used in reporting, as defined in Section 1.4.

Inquiries involving Service Unavailability Events or Journey Planning Application Events shall be resolved within the associated Recovery Time Objective (RTO), as defined in Exhibit A.2 (Key Performance Indicators and Service Credits).

For inquires which do not have an RTO, the Contractor shall provide an appropriate response within ten (10) calendar days of the customer support request date. A response shall be considered appropriate if it (i) identifies the root cause of the issue and provides an estimated resolution date, (ii) applies a work around to the issue, (iii) fully resolves the issue, or (iv) provides a clear timeline and expected resolution date for the issue. Acknowledgement of the issue by itself is not considered to be an appropriate response.

If the Contractor has not fully resolved the customer support request by the end of the ten (10) day period, the Contractor shall provide the Transit Provider with an expected resolution date. The Contractor shall continue to update expected resolution dates, before the date is reached, for each request that remains unresolved.

Table 1: Levels of Support

Level 2

· The…