EZ Data and NEOTech: A Comprehensive Approach to Managing and Utilizing Multi-Agency/Multi-State Real-Time And Archived Mobility Data Exchange Entity Eligible Applying to Recieve Federal Funding: NEORide Prepared for USDOT ATTAIN Program (NOFO#: 693JJ324NF00005)

Volume I: Technical Application (Submitted: Feb 2, 2024) Project Name EZData and NEOTech: a comprehensive approach to managing and utilizing multi-agency/multi-state real-time and archived mobility data exchange Eligible Entity NEORide Total Project Cost $2,000,000 Advanced Transportation Technology and Innovation Program Request

$1,600,000

Are matching funds restricted to a specific project component? If so, which one?

No

State(s) in which the project is located Ohio and Indiana Is the project currently programmed in the:

• Transportation Improvement Program

• Statewide Transportation Improvement

Program

• MPO Long Range Transportation Plan

• State Long Range Transportation Plan

Yes, use of quality data to support mobility services is referenced in 1) SARTA -SCATS Coordinated Public Transit-Human Services Transportation Plan; 2) WRTA and Trumbull’s 2050 Metropolitan Transportation Plan; 3) BCRTA- OKI Coordinated Public Transit-Human Services Transportation Plan; and 4) CARTS – OMEGA District Regional Plan

Technologies Proposed to Be Deployed (briefly list)

• Cloud-based multi agency/multi-state and vendor-agnostic data exchange for real-time and archived data for initially 7 agencies in OH and IN;

potentially expand to ~30 NEORide members in OH, KY, IN, MI, AK, WV, PA

• Implementation of standard formats: general transit feed specification (GTFS), operational data spec (ODS), transactional data specification (TDS) and transit ITS exchange specification (TIDES) for data fusion

• Real-time trip clearinghouse for interagency coordination on paratransit/DRT/on-demand trips

• Single data source for multimodal real-time customer information dissemination.

• One-stop data and reporting source for various planning, operations and maintenance business needs of agencies

Will the project use connected vehicle technologies? If so, which technologies will be used

EZData will ingest CAD/AVL, APC, AFC and DRT trip data generated by other systems that use vehicle-to-center connectivity. This infrastructure could be used to deploy V2X technologies to support the following traveler-centric applications:

• Outdoor wayfinding to locate and board transit vehicles (using BLE or

V2P);

• Priority for transit vehicles (using V2I));

• Transfer connection protection for trips spanning multiple modes (using

V2P, V2C and V2I).

Will the project use automated driving system technologies?

No

Rural Considerations: a) Is the project serving a rural area(s)? A rural area is an area with a population of less than 50,000 residents according to the 2020 Census population estimates. b) If yes, how much ATTAIN funding is being requested to be put toward serving the rural area(s)?

Yes, most of the agencies serve rural areas, Please see the map included in the project narrative.

EZ Data and NEOTech: A Comprehensive Approach to Managing and Utilizing Multi- Agency/Multi-State Real-Time and Archived Mobility Data Exchange Submitted by NEORide Prepared for USDOT ATTAIN Program (NOFO#: 693JJ324NF00005) i

Table of Contents

1 SECTION II PROJECT NARRATIVE

1.1 PROJECT OVERVIEW

1.2 INTRODUCTION

1.2.1 Motivation

1.2.2 Background

1.2.3 Innovation

1.2.4 Scalablity and Replicability

1.2.5 High-level System Details

1.2.6 Future Vision

1.3 SERVICE AREA OVERVIEW

1.4 ISSUES AND CHALLENGES

1.4.1 Addressing Real-time Responsive Mobility Challenges for Rural and Underserved Populations through Data/Service Interoperability

1.4.2 Data Silos Limiting Service Design and Coordination

1.4.3 Data Quality Challenges

1.4.4 Vendor Dependencies Caused by Proprietary Data Exchange Formats

1.4.5 High Cost of Data Acquisition, Management and Utilization

1.4.6 Digital Divide Among Agencies of Various Size

1.5 CURRENT SYSTEM ENVIRONMENT

1.6 PROPOSED SYSTEM VISION, GOALS AND DESCRIPTION

1.6.1 Vision

1.6.2 Goals

1.6.3 System Components

1.7 DEPLOYMENT PLAN

1.7.1 Procurement and Implementation

1.7.2 Operations and Maintenance (O&M)

1.8 IMPLEMENTATION CHALLENGES

1.9 DEPLOYMENT SCHEDULE

1.9.1 Task 1A- Program Management

1.9.2 Task 1B- Program Reporting

1.9.3 Task 2- Planning

1.9.4 Task 2- Design

Submitted by NEORide ii

1.9.5 Task 3- Implementation

1.9.6 Task 4- Evaluation

1.9.7 Final Report

1.10 PERFORMANCE MANAGEMENT

1.11 LEVERAGING DOT’S ITS RESOURCES

1.12 FMVSS / FMCSR EXCEPTION

1.13 BUY AMERICA

1.14 LEVERING OTHER LOCAL AND REGIONAL APPLICATIONS

2 SECTION III- MANAGEMENT STRUCTURE

2.1 APPLICANT: NEORIDE

2.2 PARTNERSHIPS

2.3 ORG CHART

2.4 NEORIDE’S COORDINATION WITH MEMBER AGENCIES

3 SECTION IV - STAFFING DESCRIPTION

3.1 PROPOSED KEY STAFF, ROLE AND COMMITMENT

3.2 PROPOSED STAFF BIOS

3.3 POINT OF CONTACT

4 EXHIBITS AND ATTACHMENTS

EXHIBIT A: INPUT ON TECHNOLOGIES, GOALS, PRIORITIES

EXHIBIT B -RESUMES

Submitted by NEORide iii

List of Figures

Figure 1. Source Datasets and Key Use Cases for EZData Figure 2. Geographies Served by Partner Agencies (partner agencies serve highlighted county boundaries) Figure 3 Ohio Developmental Disability Council Survey 2017 Figure 4. System Overview Diagram Figure 5. EZData and NEOTech Program Org Chart

List of Tables

Table 1. Current Providers of Data at Transit Agencies Table 2. Phasing of Proposed Components Table 3. Proposed Schedule Table 4. Key Staff

Submitted by NEORide

1 Section II Project Narrative

1.1 Project Overview

EZData will be deployed as a vendor-agnostic Data Exchange for small-urban/rural agencies in OH and IN, as a unified system for fusion, management, and consumption of transit system data.

EZData will use standards-based replicable approach to implement a cloud-based system to enable design, delivery, and monitoring of high-quality mobility services for ALL travelers.

Further, NEOTech, a new department within NEORide, will leverage EZData to help agencies with data-driven decision making.

1.2 Introduction

1.2.1 Motivation

Although EZData and NEOTech appear on paper to be extremely complex, they were developed by NEORide and its partners for reasons that are straightforward and easy to understand, beginning with the fact that the wide-spread, efficient use of transit-related data has the potential to drive the sustained growth of public transportation.

Unfortunately, several seemingly insurmountable roadblocks have made it difficult, and in some cases impossible, to unleash that potential. Some systems, particularly those operating in rural areas simply do not have access to data that will enable them to analyze and improve service.

On the other hand, larger agencies, including the Stark Area Regional Transit Authority, are deluged with too much information. “We receive more than three terabytes of data every day from a variety of sources,” SARTA CEO Kirt Conrad said. “But we can’t really take advantage of it because we don’t have the staff or the computing power required to properly assess the billions of data points that pour in.”

The type of data systems receive from vendors is also becoming increasingly problematic. Many now employ “walled garden” technology platforms that severely limit the scope, type, and utility of the information they provide—information that should, ideally, enable transit managers to accurately evaluate both their system’s and the vendor’s performance.

While these and other data-specific problems are serious, the lack of an efficient and effective way to store and share information is clearly the most difficult challenge transit agencies now

Submitted by NEORide face because the resultant lack of communication hinders the collaboration that is essential to improving service and increasing ridership.

EZData and NEOTech were specifically conceived to remove the roadblocks that are impeding progress. Once implemented, the EZData system will facilitate the acquisition, compilation, and storage of real-time and historic data from participating systems. NEOTech will serve as a highly proficient “geek squad” that will thoroughly analyze the data which will then be made accessible to transit professionals who will use it to:

• Monitor and modify fixed routes to meet evolving community needs.

• Ensure that drivers and vehicles are available to provide paratransit and other on-demand rides during peak hours.

• Make traveling across system and geographic boundaries easy, seamless, and affordable.

• Support business development and job growth by connecting employers with job seeking workers.

• Operate more cost effectively by identifying and eliminating waste.

• Evaluate fare payment, GPS, and other products supplied by vendors.

• Share fuel efficiency, emissions, vehicle performance, and other operation data.

• Maximize the use of human resources.

• Other potential uses limited only by the imaginations of the dedicated transit professionals who utilize the system.

We are confident that by fulling unleashing the power of data, transit systems will significantly improve service, enhance the riders experience, and make traveling to the thousands of destinations served by public transit each and every day more convenient, and affordable than ever before.

1.2.2 Background

NEORide is in the process of deploying EZConnect platform (https://www.ezconnect.org/) funded by the USDOT-ATCMTD grant, which will serve as the unified information gateway for agencies and customers alike. This is being deployed using regional mobility center (RMC) model to support service coordination among agencies that are co-located in a larger geographic region but don’t have the resources or mandate individually to meet traveler needs. Currently, there are two such hubs- 1) Northeast Ohio Hub that involves 5 agencies; and 2) Southwest Ohio Hub that includes 3 agencies. Through this digital and physical mobility hub infrastructure, customers will be able to use an omni-channel platform for plan, book, pay and connect. Also, agencies will have access to tools such as an Integrated Mobility Platform, EZfare and customer relationship management (CRM) software to help their customers using real-time information relevant to their trips for the entire trip-chain.

We are also implementing a proof-of-concept centralized trip clearinghouse using transactional data spec (TDS), funded by the FTA-EMI grant so EZConnect platform can exchange data with legacy paratransit/DRT platforms in real-time and help EZConnect customer https://www.ezconnect.org/

Submitted by NEORide service representatives (CSRs) answer queries related to all para/DRT trips, even if those are not managed within the Integrated Mobility Platform, available at regional hubs.

Further, there has been an ongoing implementation of EZfare system (https://www.ezfare.us/) using FTA-IMI grant, now used by 15 agencies across 5 states and enables the integrated payment vision of EZConnect platform.

In addition, agencies use various systems for managing fixed route services and maintaining their fleet, independent of the EZConnect project. Agencies also provide micromobility services through separate contracts with those vendors.

Through the course of these projects, we have realized the following key gaps:

• Lack of a common repository of data and information for all modes (fixed route, paratransit/DRT, microtransit, micromobilty) to enable intermodal planning and connectivity (e.g., enabling transfers between modes) through 3rd party applications. For example, SARTA should be able provide a microtransit connectivity to a fixed-route express bus service from Canton to Cleveland, followed by a bikeshare booking, managed by GCRTA, all part of the same transaction using EZfare. In current situation, multiple integrations with individual vendors are needed to enable this functionality. This repository will also provide multimodal information to customer service agents (CSRs) to address customer queries or to other information dissemination channels.

• Lack of access to real time demand and capacity information across all agencies for better service coordination for paratransit/demand response trips. We are developing a proof-of-concept application using TDS with one vendor but integrations with additional vendors are needed for seamless operations.

• Lack of a consolidated repository of all historical data on performed services along with fleet and operator performances so that we can provide one-click reporting to funding entities, including the National Transit Database (NTD).

• Lack of data needed to analyze multimodal O-D patterns across a broader region so first/last mile services, microtransit zones, DRT service areas and fixed route adjustments can be planned to provide appropriate services to rural/underserved areas and transit deserts.

• Lack of skilled resources at NEORide member agencies who can manage the data pipelines and address ad-hoc analytics/reporting requests without relying on expensive vendors that provide or understand the data.

1.2.3 Innovation

Based on initial stakeholder discussions as part of ongoing implementations, NEORide has concluded that these gaps demand a comprehensive approach that involves people, process and technology. This effort will result in an industry-first implementation of such kind where agencies across multiple states are able to pool their digital and human resources for addressing the mobility needs of their communities by making data-driven decisions both in real-time and for service planning purposes.

https://www.ezfare.us/

Submitted by NEORide Prepared for USDOT ATTAIN Program (NOFO#: 693JJ324NF00005)

The proposed concept includes the following innovative components:

• A cloud-based data exchange infrastructure, referred as EZData in this application. This infrastructure will be enabled with real-time and after-the-fact access to required multimodal data from a single repository. Such access will require eventually managing data pipelines of more than a dozen individual products that are used by 30+ agencies across 7 states, requiring a scalable and replicable approach.

• Given canned reports from vendor products don’t meet agency needs, adding to redundant staffing or consulting expenses at individual agencies, a common pool of resources, managed by NEORide is needed. NEORide plans to start a new division of its COG called NEOTech to assist member agencies with all data and technology assistance needs.

NEOTech will develop and implement data management processes and policies to keep EZData current and support the use cases discussed in this application.

• NEORide will launch an Open Data Platform for providing data access to 3rd party developers and researchers.

• Additionally, NEORide is proposing to organize Annual Industry Data Summits in coordination with an existing Regional or National Conference (e.g., OPTA in Ohio) to foster collaboration and knowledge sharing with industry on open data access.

1.2.4 Scalablity and Replicability

NEORide is planning the initial implementation for 7 agencies, located in the state of OH and IN.

However, given other NEORide agencies use products being targeted for EZData, we intend to scale the infrastructure to all NEORide member agencies. This list currently includes ~30 agencies across the states of OH, IN, WV, KY, MI, AK and PA. Given successful deployment of EZfare used by 15 states across 5 states we understand the institutional, technical and financial challenges to be overcome for such large-scale and joint-deployment projects. We are really excited about the potential for such scale as reduction in such resource needs at agencies will result in significant cost savings in long term, while helping them design, deliver and manage mobility services efficiently.

Further, while this approach will initially benefit NEORide agencies, we will be using standards/specifications for transit datasets to build the centralized data repository so it can be replicated by other agencies/regions. These specifications are:

• GTFS and GTFS-RT: widely adopted by transit agencies worldwide, GTFS (schedule) and GTFS-RT (real-time performance) are standard formats used by developers to build open data- based customer-facing applications for fixed route services.

• Operational Data Specification (ODS): being developed by Cal-ITP and Mobility Data, ODS promises to address the limitations within GTFS data format by adding driver and vehicle schedule information (e.g., runs and blocks). NEORide team will verify the applicability of ODS format in EZData context and will adopt if it meets our objectives.

Also, we intend to add details related to workforce management to this specification for correlation of schedule data with operator performance data.

Submitted by NEORide

• Transactional Data Specification (TDS): developed as part of TCRP 210, TDS is being explored by various agencies in the US for paratransit/demand response transit (DRT) service interoperability. NEORide has already been implementing a TDS-based data exchange project through an effort funded by the FTA-EMI grant (to support EZConnect project) to enhance service interoperability between agencies. However, we are also aware that Minnesota DOT and MTC-Bay are implementing customer-focused use cases of TDS and several others are interested and are coordinating with Shared Use Mobility Center (SUMC) for a DRT-focused community practice.

• Transit ITS Data Specification: originally developed as part of TCRP Report 235, TIDES provides standard formats for exchanging computer aided dispatch/ automatic vehicle location (CAD/AVL), automated passenger counters (APC) and automated fare collection (AFC) data. NEORide is aware that different agencies and regional groups across the country are planning to adopt TIDES.

1.2.5 High-level System Details

Figure 1 provides a high-level overview of source datasets, applicable standards and use cases for EZData. As stated earlier, EZData is being designed as cloud-based datawarehouse using Amazon Web Service (AWS) platform infrastructure. It will include the following components.

1. Real-time Data: this component will act as the aggregator of real-time information data for fixed route and paratransit/DRT services.

a) Fixed-route Real-time Data Manager: This component will validate and publish

GTFS-RT to be used by 3rd party developers for all NEORide member agencies. This will also enable NEORide’s Open Data Portal for fixed route data.

b) TDS Manager: This component is proposed as an enhancement to the ongoing TDS implementation as part of the project funded by FTA-EMI grant. It will expand to build integration with other paratransit/DRT vendors and provide real-time access to trip requests, vehicle locations and vehicle capacity from a central repository.

2. Archived Data

a) Extract-Transform-Load (ETL)

i. Data Validation: We will conduct automated validation of datasets obtained from vendors for sufficiency and accuracy per a defined set of operational parameters to detect anomalies (e.g., missing timepoints or stops in CAD/AVL record)

ii. Conformance with Specifications: We will provide utilities to comply with data structure per GTFS, ODS, TIDES and TDS formats.

iii. Data Ingestion: We will provide utilities to insert data into the cloud-based data store.

b) Data Storage: refers to the data storage infrastructure built using AWS cloud storage technologies.

EZ Data and NEOTech: A Comprehensive Approach to Managing and Utilizing Multi-Agency/Multi-State Real-Time and Archived Mobility Data Exchange Submitted by NEORide Prepared for USDOT ATTAIN Program (NOFO#: 693JJ324NF00005)

Figure 1. Source Datasets and Key Use Cases for EZData

Submitted by NEORide Prepared for USDOT ATTAIN Program (NOFO#: 693JJ324NF00005)

a) Data Access: refers to utilities provided to access fixed route and paratransit/DRT data for operations and payments in a format compliant with TIDES and TDS.

3. Business Intelligence Platform and Applications refers to a 3rd party cloud-based platform for data analytics and visualization. NEORide has currently not selected a platform but intends to use a commonly used BI platform such as Tableau or Power BI.

4. Helpdesk: refers to a cloud-based helpdesk application facilitated by NEORide for requesting help from NEOTech.

1.2.6 Future Vision

Eventual goal for the EZData infrastructure is to serve as the unified data exchange for all business needs of NEORide member agencies. While the proposed concept will be capable of ingesting real-time and archived micromoblity (e.g., bikeshare, sccotershare) data where available, it is not included in the scope to manage the cost. Proposed concept will also be enhanced further to enable API-based data access for third-party developers for building transit-focused applications.

Also, focus of the proposed concept is only on standard data formats for data ingestion to ensure scalability and replicability. In the future, this could be enhanced to support specific needs of agencies (e.g., track circuitry data for rail operations) and customer incident data.

Further, we have submitted a separate application under SMART grant for Coordinating Resources for Enhanced Availability, Training and Efficiency (CREATE) initiative that will enable predictive vehicle diagnostics and regional coordination on maintenance through resource pooling. We will link CREATE and EZData initiatives so EZData can serve as the unified data exchange for all NEORide needs.

1.3 Service Area Overview

This application is being submitted by NEORide. NEORide is a Council of Governments (COG), including membership from 30 agencies across 7 states, primarily serving rural populations.

NEORide is also designated as the grantee of federal and state grants to support public transit.

NEORide is submitting this application along with member agencies from 1) Six (6) counties in Ohio that include Stark County Regional Transit Authority (SARTA), Western Reserve Transit Authority (WRTA), Columbiana Action Agency of Columbiana County (CARTS), Trumbull County, Butler County RTA, and Dayton RTA Transit; and 2) CityBus serving Lafayette, IN.

Most of the area served by these agencies is rural as shown in Figure 3.

NEORide and its member agencies have a strong track record of innovation. NEORide recently completed a successful implementation of the largest multi-agency/multi-state mobile ticketing platform, EZfare. Also, member agencies such as SARTA have demonstrated various innovative technologies such as hydrogen fuel cell -powered vehicles. Further, WRTA has been working on an autonomous shuttle project funded by the FTA-AIM grant. Also, SARTA, WRTA, BCRTA, CARTS and Trumbull County are part of ATCMTD-funded EZConnect project.

Submitted by NEORide Prepared for USDOT ATTAIN Program (NOFO#: 693JJ324NF00005)

Figure 2. Geographies Served by Partner Agencies (partner agencies serve highlighted county boundaries; yellow indicates rural )

1.4 Issues and Challenges

1.4.1 Addressing Real-time Responsive Mobility Challenges for Rural and Underserved Populations through Data/Service Interoperability

As most of the service area is rural, transit options are limited, and residents must rely on personal automobiles for their mobility needs. This limitation presents enormous challenges for underserved populations. Approximately 20% population in each county is over 65 and roughly 10% population has some disability condition. Also, median household income in all the participating counties is less than the national median income as reported in 2019. The number of people under poverty is also higher than the national average in all counties. When transportation is the second largest expense after housing undeserved population groups are forced to make tough decisions and thus influencing their access to income, education, or health outcomes. Most underserved populations that don’t live near a fixed route service have to rely on paratransit or demand responsive services that have to be booked 24-48 hours in advance. EZConnect has been accelerating deployment of on-demand microtransit services, however, footprint is still small. Also, currently there is limited coordination among providers in a region for cross-county services due to a common repository for managing coordinated services.

Figure 3 Ohio Developmental Disability Council Survey 2017

Submitted by NEORide Prepared for USDOT ATTAIN Program (NOFO#: 693JJ324NF00005)

1.4.2 Data Silos Limiting Service Design and Coordination

Agencies proposing this concept use close to a dozen vendors (see Figure 1) for managing a variety of services that include fixed route, paratransit, demand response, microtransit, human service transportation (HST)/ non-emergency medical transportation (NEMT), veteran services.

Through EZConnect initiative, agencies in the Northeast and Southwest Ohio have initiated regional service coordination efforts such as “One Seat Ride,” however, there is a lack of a common repository of historical origin-destination patterns served by agencies to apply data-driven decision making in designing new zones and services.

1.4.3 Data Quality Challenges

Transit data systems are data-driven. Data generated by these systems depends on the quality of upstream data (e.g., driver/vehicle schedule, route/stop database) consumed by systems, human input during operations (e.g., operator entry on driver terminals), faulty hardware/sensors, unaddressed operational anomalies, level of sophistication in data post-processing logic and several other factors. Unless these issues are addressed by vendors or agency in-house staff, reports generated by agencies may require a lot of verification before those are ready for submission to funding entities or presentation to stakeholders.

1.4.4 Vendor Dependencies Caused by Proprietary Data Exchange Formats

Transit systems have historically been deployed as closed/proprietary systems due to lack of any industry data standards. While advancements have been made in datasets for customer-facing applications due to interest from private sector and developers (e.g., GTFS, GTFS-RT, GBFS, MDS etc), other datasets are available only in proprietary data formats. Therefore, a significant investment is needed in developing enterprise datawarehouse or similar data-focused applications independent of a system providers. Most agencies rely on their vendors to provide the reports or analyses needed which is often expensive and adds to the cost of operations and maintenance of these systems.

1.4.5 High Cost of Data Acquisition, Management and Utilization

Given challenges in managing transit data quality and proprietary nature of data formats, it is very expensive to design, develop and maintain enterprise data systems. Most agencies do not have in-house resources to take on projects of such magnitude. At the same time, external developers cannot replicate existing solutions as they have to interface with proprietary systems while addressing unique business needs of an agency.

1.4.6 Digital Divide Among Agencies of Various Size

NEORide membership includes agencies with fleet size ranging from 20 to 500+. Resources available at agencies to manage technology and associated data infrastructure also varies accordingly. While larger agencies have established departments to address technology and data needs, for other agencies technology services are contracted out or are performed by in-house staff as part-time effort. This limits the utilization of technology platforms

Submitted by NEORide deployed by those agencies, even if the platforms provide the same capabilities as those available at larger agencies.

1.5 Current System Environment

NEORide member agencies that are currently part of the EZData project contract with a range of vendors for their various needs, as shown in Table 1. As mentioned earlier, data access and reporting require significant reliance on vendor resources, even if the same vendor is providing the system for different agencies.

It is noteworthy that there is an additional pool of vendors being used by other NEORide member agencies. Therefore, EZData provides an opportunity to create a data management infrastructure that can eventually support data ingestion from all major mainstream vendors active nationwide in the transit industry.

Table 1. Current Providers of Data at Transit Agencies

Agency Fixed Route Operations

Paratransit/DRT/Microtransit Operations

Payments

BCRTA GMV Via Masabi Dayton RTA Clever Devices Trapeze Masabi, SPX CityBus Trapeze Trapeze Masabi, SPX CARTS N/A Via, CTS Masabi SARTA Avail Trapeze Masabi, SPX Trumbull County N/A Ecolane, Non-electronic N/A WRTA Avail TripSpark Masabi, SPX

1.6 Proposed System Vision, Goals and Description

1.6.1 Vision

EZData and NEOTech will help NEORide facilitate one-stop access to all data as required to meet the business needs of member agencies in delivering digitally-enabled and equitable mobility services to ALL travelers, while creating a workforce skilled in providing technology and data services to help the member agencies.

1.6.2 Goals

NEORide has set out the following goals for this project:

• Enhanced access to destinations with quality services for underserved customers.

• Reduce digital divide among agencies with pooling of skilled resources.

• Enhance customer satisfaction with improved Complete Trip Experience.

• Reduce congestion and improve air quality with high-quality non-single occupancy vehicle (SOV) services.

• Enhance access to data and information for member agencies and their stakeholders.

Submitted by NEORide

1.6.3 System Components

There are 3 key aspects of the proposed concept, as a comprehensive approach to data ingestion, management and consumption is needed addressing the people, process, and technology aspects as follows:

1. EZData: A cloud-based data infrastructure that is scalable to meet the needs of all member agencies that use a variety of vendors.

2. Data Pipeline Management: tools and associated quality control processes to manage standards-based data input/output (I/O) pipelines that are replicable to handle data from all mainstream vendors.

3. NEOTech: skilled human resources managed by NEORide to assist agencies with technology and data services.

1.6.3.1 EZData

EZData is being designed as cloud-based datawarehouse using Amazon Web Service (AWS) platform infrastructure. It will be designed as a centralized repository for ingesting, storing and accessing data, primarily from operations and payment systems.

EZData will contain both real-time and archived data. Use cases for applications both datasets will be different, as discussed further in this section.

EZData will include the following components:

1. Real-time Data: this component refers to management of data on vehicle location, trip status, current load/capacity, and other updates about the service as discussed below:

• Fixed-route Real-time Data Manager: Most vendors provide real-time information on fixed route service in GTFS-real time format as that is widely adopted as the standard for building real-time information application by 3rd party developers. However, feed is often not validated for accuracy. Also, feed is not often fully compliant with the standard as vendors often skip optional fields. In some cases (e.g., rail operations or for small agencies), GTFS-RT is not even available, and agencies need to work with a partner to develop those. The Fixed-route Real-time Data Manager will automatically collect GTFS-RT feed offered by partner agencies, validate, and publish those for consumption by third party developers through an Open Data Portal, managed by NEORide. NEORide already has partners such as Transit, Moovit and Uber that provide customer-facing applications and will benefit from having access to quality GTFS-RT information from a single location.

• TDS Manager: This component is being proposed as an enhancement to the ongoing implementation. It will expand to build integration with 2 other paratransit/DRT vendors and will provide real-time access to trip requests, vehicle locations and vehicle capacity from a central repository. This will enable NEORide to extend and enhance the TDS-enabled functionality of EZConnect and achieve a higher level of service integration, technology inter-operability, and system level intelligence. We anticipate that the ATTAIN project will result in proposals to both extend and refine TDS within the NEORide eco-system of agencies, as well as from other interested public transit agencies

Submitted by NEORide who are interested in using this specification to facilitate DRT inter-operability. The letter of support from the SUMC-led TDS oversight group submitted with this grant proposal is indicative of the positive relationship expected between this proposed ATTAIN project and the advancement of the formal adoption of TDS for demand responsive transportation in the public transportation sector.

2. Archived Data The following components are involved for managing archived data:

• Extract-Transform-Load (ETL): ETL has been a standard practice in data engineering to build large scale datawarehouse and data lake applications. Modern cloud-based systems refer to it as ELT where data can be ingested prior to transformation given the compute and storage resources available in the cloud.

While there is a limited deployments of such applications in the transit industry, we will follow industry best practices and lessons learned as available to build ETL/ ELT data pipelines. As stated earlier, the focus of initial deployment is limited to schedule data, CAD/AVL data, APC data and AFC data. Workforce data to supplement driver/vehicle schedule data will also be included, where available from agencies, to provide additional analytical context to performance data. In addition, trip performance data as collected by TDS Data Manager will also be archived.

AWS will be used to manage the scripts for ETL data pipelines for ease of development, maintenance and scalability. The following steps will be involved:

i. Extraction and Data Validation: The initial step will involve extracting data from individual vendor databases. Table 1 provides a list of vendors. While several agencies use same the vendor, they could be using different versions of the same product which could complicate how data is structured in the product. We will consult with vendor partners for identifying required dataset to extract.

We will also conduct automated validation of datasets obtained from vendors for sufficiency and accuracy per a defined set of operational parameters to detect anomalies (e.g., missing timepoints or stops in CAD/AVL record). A list of such parameters will be developed during the design stage of the project.

ii. Middleware Tools for Transformation: As listed in Section 1.2.4, we are planning to use GTFS, ODS, TIDES and TDS formats for transforming data obtained from vendors. We will be developing utilities in a common language tech-stack to transform data in these formats prior to ingestion in the EZData datawarehouse/data lake. Please see section 1.6.3.2 for discussion related to the process.

iii. Data Ingestion: We will build utilities to insert data into the cloud-based data store.

We intend to use capabilities built into the AWS platform for managing ingestion of large-scale data.

• Data Storage: We will be using out of the box microservices built into the AWS platform-as-a-service to store and manage the ingested data.

Submitted by NEORide

• Data Access: refers to utilities provided to access fixed route and paratransit/DRT data for operations and payments in a format compliant with TIDES and TDS. As part of the proposed scope, our plan is to offer utilities for automatically exporting data and making it available for 3rd parties for specific use cases.

1.6.3.2 Data Pipeline Management

To ensure replicability across a broader vendor pool serving agencies within NEORide membership, and for replicability by other entities in the transit industry, we are planning to use industry standard specifications. While some have been formally adopted as standards, there are various efforts underway across the industry to advance other specifications into standards. As mentioned earlier, applicable standards/ specifications include:

• GTFS and GTFS-RT: Agencies have been using GTFS and GTFS-RT for over 10 years.

There are open-source tools available to validate, manage and utilize such data. We will be starting from those tools and will be applying the best practices developed and maintained by the GTFS community of practice.

• ODS: A recently developed specification by Cal-ITP and Mobility Data, ODS, is intended to enhance GTFS to add operations-focused datasets (e.g., runs, blocks and driver workpiece) to create a common format for importing schedule data from vendors. The standard is still under development with very limited adoption so we will validate its applicability during design phase of the project.

• TDS: As mentioned earlier, TDS was developed in a TCRP project that culminated with the publication of TCRP Report 210 in 2019. NEORide was awarded the EMI grant by the FTA for enhancing interoperability among DRT services for public transportation as part of EZConnect project. EZConnect uses TDS as a core element of its technology stack and implements TDS compliant data exchanges between DRT services via its middleware solution. The translation broker technology being developed for this middleware is intended to shield native technology platforms from TDS data requirements at this early stage of TDS implementation in the USA. Implementation is currently underway to enable interoperability among 3 vendors as part of the EZConnect project, being led by the author of the TCRP Report 210, who also has experience with FlexDenmark platform. FlexDenmark, a national DRT trip coordination platform in Denmark, uses SUTI standard, which was used as the basis for developing the TDS.

• TIDES: It is a relatively new concept. While there have been efforts in the industry to organize and implement this specification as a follow-up to the work published in TCRP Report 235, limited work has been completed so far. It requires significant cooperation from the transit vendor community. NEORide partner, Arcadis, was co-lead for the TCRP 235 project and has been working with all mainstream vendors for decades and will be leading this effort. One of the major vendors, Avail Technologies, has also provided us the letter of support.

Additionally, we realize that some vendors may not be able to comply with these specifications/ standards and we will discuss the process to ingest those datasets using vendor-provided APIs or custom ETL routines. These details will be determined as part of the design stage.

Submitted by NEORide

Further, we will develop standard operating procedures (SOPs) and best practices for managing the data pipelines. Key considerations include:

• Management of Privacy Data: given some data will have customers’ personally identifiable information (PII) and payment information, we will apply industry best practices into ETL design to create safeguards for PII protection.

• Cybersecurity: Information security is a paramount concern for cloud-based data applications. We have selected AWS as the vendor partner to leverage their industry leading tools for data ingestion, management and access. Also, we will be cautious about filtering out any privacy sensitive information prior to storage.

• Disaster Recovery: While most of the data planned for this project is not contributing to mission critical applications, lack of access will impact continuity of business. We will be using AWS services to setup data infrastructure in redundant configurations to ensure failsafe operations in event of unexpected failures.

• Data Access: NEORide will setup a process to make data accessible to end-users. For third party developers, data will be made available through an Open Data Portal. For agencies, a process will be setup to request and facilitate data access (see Section 1.6.3.3). It will be the first Open Data Portal of such kind involving multiple agencies across many states, and vendors for multimodal services.

• Terms of Use: Given PII considerations and other sensitives around data access, NEORide will draft the terms of data utilization by agencies and third parties.

As an outcome of the project, NEORide will also develop a framework for Data Governance document to manage all-things data which will cover the about key considerations as well.

1.6.3.3 NEOTech

Through the course of various joint technology deployment projects managed by NEORide, we have realized the need to have a centralized pool of technology resources. NEORide is taking this opportunity to setup a new division, NEOTech. This is consistent with one of the key goals of the administration as workforce building for the future with advanced skillsets. These resources will be trained in helping transit agencies with technology and data services. The following tools will be used by NEOTech

1. Business Intelligence Platform and Applications: We will utilize a commercial off-the-shelf (COTS) software (also cloud-based) for data analytics and visualization. These platforms will be used by NEOTech staff to provide analyses and reports, not available within vendor platforms or to meet the day-to-day needs of agencies. Key use cases to be implemented as part of proposed budget include:

a. Serve as multimodal data exchange for customer-facing applications, already live as part of EZfare project.

b. Readily available reports for National Transit Database reporting.

c. Readily available reports for key performance indicators for up to 30 metrics.

2. Helpdesk: refers to a cloud-based helpdesk application facilitated by NEORide for requesting services from NEOTech.

Figure 4 provides a visual illustration of the proposed concept..

EZ Data and NEOTech: A Comprehensive Approach to Managing and Utilizing Multi-Agency/Multi-State Real-Time and Archived Mobility Data Exchange Submitted by NEORide

Figure 4. System Overview Diagram

Submitted by NEORide

1.7 Deployment Plan

1.7.1 Procurement and Implementation

NEORide is proposing a consortium of partners from public and private sector and academia. We may need to procure COTS products for helpdesk and BI platform. If awarded, we will follow the Code of Federal Regular (CFR) guidelines as listed in 2 CFR, part 200, and clarified in the NOFO, to engage with partners already part of the proposed team or new vendors.

As shown in Table 2, Year 1 will primarily be dedicated to finalizing Concept of Operations, Requirements and Design. Later half of Year 1 and Year 2 will involve development and launch activities. Implementation will involve the 5 overlapping phases as follows:

• Phase 1: will involve ingesting data from fixed route sources. It will include implementing GTFS-RT, GTFS and TIDES standards/specifications.

• Phase 2: will involve ingesting 1) paratransit/DRT data using TDS; and 2) payment data using TIDES or custom ETL scripts, as applicable.

• Phase 3: will involve ingesting supporting schedule data such as driver/vehicle schedule and workpiece, using ODS or custom ETL scripts, as applicable.

• Phase 4: will start building analytics and visualization layer using ingested data infrastructure.

• Phase 5: NEOTech implementation will start, after planning phase is complete. We will start this phase early in the process as it involves establishing the department, developing policies and procedures, hiring, and training. We anticipate the process to take up to 12 months. This phase will launch an Open Data Portal to make data accessible to 3rd parties.

While we anticipate we will go live by the end of Year 2, Year 3 may involve refinements as data products require constant adjustments to meet the stakeholder needs.

Table 2. Phasing of Proposed Components

Submitted by NEORide

1.7.2 Operations and Maintenance (O&M)

EZData and NEOTech are expected to move into O&M phase starting Year 3. At this point, agencies will be able to request their specific data/analytics needs through NEORide helpdesk portal. These requests will be addressed by NEOTech staff.

All system components will be deployed in the cloud-hosted environment to minimize maintenance needs for agency staff. The vendor support contract will include a service level agreement (SLA) to guarantee a desired level of service for EZData.

NEORide member agencies have already identified funding needed for long term operations and maintenance as explained under cost-sharing information in Volume 2. Also, as part of ConOps development during the initial 6 months, the team will develop operational policies and procedures for long-term sustainable system operations.

Through ongoing EZfare and EZConnect projects, NEORide has developed a standard process of collaboratively working with member agencies in developing long term operations and maintenance planning and budgeting. We will develop a similar process in coordination with a new EZData Committee (see stakeholder engagement in Section 1.8 for further information on EZData Committee).

1.8 Implementation Challenges

Deployment of a complex system at this scale will be a difficult task requiring extensive stakeholder engagement, detailed design, verification. The project team has identified the following challenges which might impact the project timeline and/or budget.

• Stakeholder Engagement: Data projects are highly complex and require extensive stakeholder coordination early in the process to ensure stakeholder needs are met by the end-product. We will launch EZData Committee, involving members of all participating transit agencies, which will guide us during the planning and implementation stages of the project. EZData Committee will also coordinate with NEORide for EZData O&M and for planning strategic direction for NEOTech department.

• Open data and APIs: EZData is planned as an open system that will build ETL pipelines using open data standards/specifications or open APIs. As stated earlier, while some the standards have been in practice for a while, new specifications do not have vendor adoption yet. We plan to work with vendors directly to address these challenges and have planned to engage them during the design stage. We have obtained letters of support from major CAD/AVL, para/DRT and payment vendors as an indication of their commitment to this project.

• Data Quality: Transit systems are very data-sensitive. Quality of upstream (e.g., schedule, route/stop) and downstream (e.g., performance) can suffer due to a lot of technical (e.g., integration between vendors) and human factors (e.g., driver logon or other driver input on terminals). Also, data quality can suffer if systems are not designed to address operational anomalies. We will be documenting such challenges during design process and will account for into the ETL framework.

Submitted by NEORide

• Staffing and Training: Given NEOTech is planned as the dedicated technology/data service provider, NEORide will hire and train staff to build those capabilities.

• Regulatory Compliance: Given the focus on data, we will ensure that we are compliant with any applicate legal considerations. As mentioned earlier, PII, PCI or HIPAA will be biggest concerns. Also, we will make sure any cybersecurity compliance needs are addressed.

1.9 Deployment Schedule

Deployment schedule with expected due dates for deliverables is provided in Table 3. Main work will be completed within the first couple years but the evaluation task will be completed by Year

4. With dates not known, the schedule begins from Notice to Proceed (NTP) day. Also, effective date is assumed as the day when the Agreement will be executed.

Table 3. Proposed Schedule

Task Start Date End Date

Task 1A: Project Management

Kickoff NTP + 6 Weeks Draft cooperative agreement with Project Management Plan NTP + 2 Weeks NTP + 8 weeks

Final Agreement NTP+ 8 Weeks NTP + 12 Weeks

Bi-weekly and Monthly Meetings NTP + 2 Weeks NTP + 4 Years

Task 1B: Program Reporting

Quarterly progress reports NTP + 3 Months NTP + 4 Years

Annual report to the Secretary NTP + 1 Year NTP + 4 Years Annual Budget Review and Program Plan Reporting NTP + 1 Year NTP + 4 Years

Task 2: Planning

Concept of Operations NTP + 4 Months NTP + 6 Months

Systems Engineering Management Plan NTP + 6 Months NTP + 9 Months

Task 3: Design

System Design Document NTP + 6 Months NTP + 9 Months

As-Built Documents NTP + 18 Months NTP + 24 Months

Task 4 - System Implementation

Development NTP + 9 Months NTP + 18 Months

Testing NTP + 15 Months NTP + 22 Months

Go-Live NTP + 22 Months NTP + 24 Months

Task 5 - Evaluation

Data Management Plan NTP + 6 Weeks NTP + 12 Weeks

Evaluation Plan NTP + 6 Weeks NTP + 12 Weeks

Submitted by NEORide

Task Start Date End Date

Data Management and Analysis NTP + 12 Weeks NTP + 4 Years

Draft Evaluation Report NTP + 24 Months NTP + 3 Years

Final Evaluation Report NTP + 36 Months NTP + 4 Years

Task 6 - Final Report

Final Report (Draft) NTP + 45 Months NTP + 46 Months

Final Report (Final) NTP + 46 Months NTP + 4 Years

We will follow the systems engineering process for effective execution of our deployment plan.

The deployment will be conducted under the following tasks.

1.9.1 Task 1A- Program Management

As required, we will participate in the kickoff meeting and support any necessary activities as required (e.g., presentation). Further, as part of Task 1, we will develop a detailed Project Management Plan (PMP) that will outline the detailed activities to be performed under each task;

start and end dates for those activities; any milestones attached; detailed budget; staffing resources necessary to complete activities; human resource management approach;

communication management; cost management and cost control; quality assurance and quality control procedures; and risk management approach. This PMP will be included in the Draft Cooperative Agreement. Once the PMP and Agreement language are finalized, we understand that the fully executed Agreement will be provided by the USDOT, and the Agreement will become effective.