METRO_Concept_of_Operations.pdf

CONCEPT OF

OPERATIONS

INTELLIGENT

TRANSPORTATION

SOFTWARE

PROJECT MANAGER

METRO REGIONAL

TRANSIT

AUTHORITY

SEPTEMBER 2, 2025

PRODUCED BY:

BURGESS & NIPLE

WITH FORWARD

MOMENTUM AND

LEVERDE

METRO | Table of Contents

Concept of Operations ii

TABLE OF CONTENTS

1 Executive Summary

1.1 Project Purpose and Goals

1.2 Summary of Proposed Systems and Key Changes

1.3 Document Overview

2 Introduction

2.1 Project Background and Context

2.2 The Role of the Concept of Operations (ConOps)

2.3 Approach and Methodology

2.4 Referenced Documents

3 Overarching System Vision and Guiding Principles

3.1 METRO’s Strategic Goals for Technology Modernization

3.2 Future State Guiding Principles

3.3 High-Level Conceptual Future System Architecture

4 CAD/AVL system

4.1 Current State Concept of Operations

4.2 Future State Concept of Operations

4.3 Objective-Based Procurement Statements

4.4 Detailed Technical Requirements

5 Finance, Payroll, and Human Resources Information System (HRIS)

5.1 Current State Concept of Operations

5.2 Future State Concept of Operations

5.3 Objective-Based Procurement Statements

5.4 Detailed Technical Requirements

6 Asset and Maintenance Management System

6.1 Current State Concept of Operations

6.2 Future State Concept of Operations

6.3 Objective-Based Procurement Statements

6.4 Detailed Technical Requirements

Concept of Operations iii

LIST OF FIGURES

Figure 1: Future State Guiding Principles

Figure 2: Future System Architecture

Figure 3: CAD/AVL Existing Scenario 1

Figure 4: CAD/AVL Existing Scenario 2

Figure 5: CAD/AVL Existing Scenario 3

Figure 6: CAD/AVL Existing Scenario 4

Figure 7: CAD/AVL Existing Scenario 5

Figure 8: CAD/AVL Existing Scenario 6

Figure 9: CAD/AVL Future Scenario 1

Figure 10: CAD/AVL Future Scenario 2

Figure 11: CAD/AVL Future Scenario 3

Figure 12: CAD/AVL Future Scenario 4

Figure 13: CAD/AVL Future Scenario 5

Figure 14: CAD/AVL Future Scenario 6

Figure 15: Finance Existing Scenario 1

Figure 16: Finance Existing Scenario 2

Figure 17: Finance Existing Scenario 3

Figure 18: Finance Existing Scenario 4

Figure 19: Finance Existing Scenario 5

Figure 20: Finance Existing Scenario 6

Figure 21: Finance Existing Scenario 7

Figure 22: Finance Existing Scenario 8

Figure 23: Finance Existing Scenario 9

Figure 24: Finance Future Scenario 1

Figure 25: Finance Future Scenario 2

Figure 26: Finance Future Scenario 3

Figure 27: Finance Future Scenario 4

Figure 28: Finance Future Scenario 5

Figure 29: Finance Future Scenario 6

Figure 30: Finance Future Scenario 7

Figure 31: Finance Future Scenario 8

Figure 32: Finance Future Scenario 9

Figure 33: Asset/Maintenance Existing Scenario 1

Figure 34: Asset/Maintenance Existing Scenario 2

Figure 35: Asset/Maintenance Existing Scenario 3

Figure 36: Asset/Maintenance Existing Scenario 4

Figure 37: Asset/Maintenance Existing Scenario 5

Concept of Operations iv

Figure 38: Asset/Maintenance Future Scenario 1

Figure 39: Asset/Maintenance Future Scenario 2

Figure 40: Asset/Maintenance Future Scenario 3

Figure 41: Asset/Maintenance Future Scenario 4

Figure 42: Asset/Maintenance Future Scenario 5

LIST OF ABBREVIATIONS

Abbreviation Definition

ADA Americans with Disabilities Act

AP Accounts Payable

APC Automated Passenger Counts

API Application Programming Interfaces

AR Accounts Receivable

CAD/AVL Computer Aided Dispatch / Automatic Vehicle Location

DVR Digital Video Recorder

EEC Employee Engagement Center

ERP Enterprise Resource Planning

FMLA Family and Medical Leave Act

GPS Global Positioning System

GTFS-RT General Transit Feed Specification – Real Time

HR Human Resource

HRIS Human Resources Information System

ITS Intelligent Transportation Software

METRO Akron METRO Regional Transit Authority

PO Purchase Order

PR Purchase Requisition

PTO Paid Time Off

RTA Regional Transit Authority

SFTP Secure File Transfer Protocol

SLA Service Level Agreement

METRO | Executive Summary

Concept of Operations 1

1 EXECUTIVE SUMMARY

This section provides a high-level overview of the Concept of Operations (ConOps) and

Technical Requirements for METRO Regional Transit Authority’s (METRO) Intelligent

Transportation Software (ITS) Modernization project. It is intended for executive leadership and key decision-makers to quickly grasp the project’s strategic goals, the rationale for change, and the envisioned future state.

1.1 Project Purpose and Goals

This document outlines a transformative initiative to modernize METRO’s core operational and administrative technology. The current ecosystem, built on aging platforms and fragmented processes, presents operational challenges and limits METRO’s ability to leverage data for strategic decision-making. This project focuses on the procurement and implementation of new, integrated Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL) and

Finance/Payroll systems, with deep consideration for their integration with existing and future

Asset and Maintenance Management functions.

The fundamental goals of this modernization effort are to:

• Enhance Data Integrity: Establish a single source of truth for operational and financial data that is accurate, reliable, consistent, and transparent.

• Unify and Automate Core Processes: Eliminate data silos and automate highly manual workflows, particularly in payroll, financial reporting, and maintenance data management.

• Improve the Employee Experience: Provide staff with modern, intuitive, and responsive tools, including a self-service portal for payroll and HR information, reducing administrative burden and frustration.

• Provide a Better Customer-Facing Experience: Deliver more reliable, timely, and accurate real-time information to passengers across all platforms.

• Streamline Workflows for Greater Efficiency: Simplify complex processes like budgeting, procurement, and service analysis to allow staff to focus on high-value activities.

1.2 Summary of Proposed Systems and Key Changes

METRO’s current operational environment is a patchwork of disparate systems characterized by a lack of integration, reliance on manual data transfers, and cumbersome workarounds. Critical processes like payroll are managed across multiple systems including Fleet-Net, TimeTrak, and extensive Excel spreadsheets, while the daily import of fuel and mileage data is a multi-step manual process. This fragmentation results in data inconsistencies, operational inefficiencies, and a significant reliance on institutional knowledge.

METRO | Executive Summary

Concept of Operations 2

This ConOps proposes a shift from the current siloed environment to a cohesive, integrated digital ecosystem. The vision is to implement modern, best-in-class systems that communicate seamlessly, automate routine tasks, and provide trustworthy data for all users.

The key changes envisioned are:

• For CAD/AVL: A new, reliable system providing accurate, low-latency vehicle location data. This system will offer a modern, intuitive interface for dispatchers and operators, support future-forward features like turn-by-turn navigation, and generate a trustworthy data feed for all passenger-facing applications.

• For Finance, Payroll, and HRIS: A unified system that automates complex payroll calculations based on union rules and shift differentials, provides a self-service portal for employees to view paystubs and paid time off (PTO), and streamlines financial reporting

(e.g. budget-to-actual), and budget and grants management. The goal is to drastically reduce reliance on manual data entry and Excel-based reconciliation.

• For Asset & Maintenance Management: Tighter integration with the CAD/AVL system to enable real-time vehicle diagnostics and automated mileage collection. This will support proactive maintenance, improve Preventative Maintenance (PM) scheduling, enhance warranty tracking, and enable a transition to paperless work orders and more efficient inventory management.

The cornerstone of this future state is integration. By procuring systems with robust, open

Application Programming Interfaces (APIs) and defining data requirements upfront, METRO can break down the silos that currently hinder efficiency and data reliability.

1.3 Document Overview

This document serves as the foundational narrative for METRO’s ITS modernization. It begins by outlining the existing processes and the pain points that justify the need for change. It then discusses the concept for future operations, key features, and user-centric scenarios that illustrate the desired state.

Finally, the document translates this vision into technical requirements for each system. These requirements will form the technical basis for a future, objective-based procurement process, ensuring that vendor proposals are evaluated against METRO’s clearly defined operational needs. This is a living document, intended to evolve as the project progresses, but it represents the comprehensive understanding of METRO’s needs at this critical pre-procurement stage.

METRO | Introduction

Concept of Operations 3

2 INTRODUCTION

This chapter establishes the framework for the Concept of Operations (ConOps) and Technical

Requirements document. It details the project’s background, defines the purpose and function of the ConOps within the system engineering lifecycle, and outlines the methodology used to gather the information presented.

2.1 Project Background and Context

METRO Regional Transit Authority (METRO) provides essential mobility services to its community, relying on a suite of Intelligent Transportation Systems (ITS) to manage its complex daily operations. However, many of the core systems – including Computer-Aided Dispatch /

Automatic Vehicle Location (CAD/AVL), Finance/Payroll/HRIS, and Asset and Maintenance

Management – are built on aging technology. These legacy systems, coupled with a history of acquisitions by the vendor and limited integration, have led to an operational environment characterized by data silos, significant manual processing, and workflow inefficiencies.

Recognizing these challenges and the opportunity to enhance service delivery, METRO has initiated a comprehensive ITS Modernization project. This initiative, guided by the findings of the 2022 Transit Technology Review, and extensive stakeholder engagement, aims to strategically replace or upgrade these critical systems. The Burgess & Niple (B&N) team has been engaged as the ITS project manager to guide METRO through the planning, procurement, and implementation phases of this critical undertaking. This document is a foundational step in that process.

2.2 The Role of the Concept of Operations (ConOps)

In the field of systems engineering, a ConOps is a crucial user-oriented document that forms the bridge between the strategic needs of an organization and the technical specifications of a system. It answers the fundamental questions:

• What will the new system(s) do?

• Who will use the new system(s)?

• Why is this change necessary?

• How will the new system(s) be used in day-to-day operations?

The ConOps developed here describes the current and envisioned future operational environment from the perspective of the METRO staff who will use, manage, and maintain the systems daily. By creating a clear narrative of operational scenarios, system goals, and user interactions, this document ensures that all subsequent technical development and procurement activities are anchored to tangible, real-world needs. It translates METRO’s

METRO | Introduction

Concept of Operations 4 strategic vision into an operational blueprint that is understandable to both technical and non-technical stakeholders.

2.3 Approach and Methodology

The information and concepts detailed in this document were developed through a structured, collaborative methodology designed to capture a comprehensive view of METRO’s operations.

The process included/includes:

1) Document Review: A thorough review of existing documentation, including the 2022 technology plan, internal meeting notes, and system documentation provided by

METRO.

2) On-Site Discovery: Intensive on-site discovery sessions conducted in February and May of 2025. These sessions involved interviews and process observation with a wide range of stakeholders from every key department, including Executive Leadership, Finance, Payroll, Procurement, Operations, Driver Training, Maintenance, IT, Planning, and

Customer Service.

3) Process Mapping: Documenting and diagramming key workflows, particularly for payroll and maintenance data management, to identify dependencies, inefficiencies, and opportunities for automation.

4) Synthesizing Needs: Consolidating feedback to identify common themes, critical pain points, and shared goals for a future system. This synthesis forms the basis for the “as-is” operational descriptions and the vision.

5) Iterative Development: This ConOps is a “living document”. The content presented herein represents the B&N team’s best understanding of METRO’s needs at this stage. It is designed to be reviewed and refined by METRO stakeholders to ensure it accurately reflects their operational reality and future aspirations before being finalized for procurement purposes.

2.4 Referenced Documents

The development of this document was informed by the analysis of several key sources, which have been leveraged to produce this report. These include:

• Akron METRO RTA Transit Technology Review, Evaluation and Acquisition Plan

• Avail Technologies ETMS System documentation

• CAD/AVL RFP 2013

• Current State Memorandum

• Industry Scan and Recommendations

• METRO Strategic Plan 2020

• Scheduling Software RFP 2018

METRO | Overarching System Vision and Guiding Principles

Concept of Operations 5

3 OVERARCHING SYSTEM VISION AND GUIDING

PRINCIPLES

The modernization of METRO’s ITS ecosystem represents more than a simple replacement of aging software and hardware. It is a strategic initiative designed to fundamentally change how technology supports the agency’s mission. This project is an opportunity to re-evaluate legacy processes, break down departmental silos, and build a cohesive, data-driven operational philosophy.

This chapter outlines the high-level vision and the set of guiding principles that will inform all subsequent decisions in this project from system design and procurement to implementation and daily use. These principles help keep the project aligned with METRO’s long-term objectives for efficiency, reliability, and service excellence.

3.1 METRO’s Strategic Goals for Technology Modernization

Based on extensive stakeholder engagement and a review of existing operational challenges, METRO has identified several key strategic goals for the ITS modernization project. These goals provide the “why” behind the specific technical requirements detailed later.

Goal 1: Achieve a Single Source of Truth for Key Data

The most persistent challenge across METRO is a lack of trust in the data produced by current systems. A primary goal is to establish an integrated environment where operational and financial data is accurate, consistent, and reliable. This involves eliminating the discrepancies between different reports, providing transparency into how data is calculated, and ensuring that all departments are working from the same validated information for planning, performance management, and mandatory reporting.

Goal 2: Automate and Streamline Manual Workflows

Significant staff time is consumed by redundant data entry, paper-based approval routing, and manual workarounds using Excel spreadsheets. A key objective is to automate these processes wherever possible. This includes streamlining the complex, multi-system payroll process, digitizing purchase requisitions (PR), creating a seamless flow for maintenance data, and simplifying budget entry and tracking. The desired objective is to free staff from low-value, repetitive tasks, to focus on analysis and service improvement.

Goal 3: Empower Employees with Modern, User-Friendly Tools

The user experience with current systems is frequently described as poor, with slow, non-intuitive interfaces, and complicated processes. This project aims to provide METRO employees with modern, responsive, and easy-to-use tools that support their work. This includes providing

Concept of Operations 6 a self-service portal for employees to access their own pay and benefits information, reducing unnecessary workflows, and delivering a system that staff can use with confidence.

Goal 4: Enhance the Customer and Rider Experience

Technology is a primary interface between METRO and its customers. A key goal is to leverage new systems to provide a more reliable, predictable, and transparent rider experience. This will be achieved by delivering accurate real-time bus location and arrival information, establishing clear and timely communication about detours and service disruptions, and ensuring a consistent experience across all public facing platforms, including mobile apps and the METRO website.

Goal 5: Establish Robust and Sustainable Technology Governance

This modernization is an investment in METRO’s future. Therefore, a strategic goal is to procure systems that are both effective today but also are flexible and sustainable for the future. This means prioritizing solutions with open, well-documented Application Programming Interfaces

(APIs) to simplify future integrations, establishing clear Service Level Agreements (SLAs) with vendors for support and accountability, and moving away from a technology architecture that locks the agency into single-vendor solutions that do not meet all of their needs effectively.

3.2 Future State Guiding Principles

To make sure the modernization project addresses METRO’s strategic goals, the following set of guiding principles will be used to evaluate system options, make design decisions, and manage the implementation process. These principles are derived directly from the challenges identified in the current operational environment and will serve as the project’s foundational pillars for success.

Concept of Operations 7

Figure 1: Future State Guiding Principles

3.2.1 Data as a Trusted Central Asset

The Problem: A recurring theme throughout discovery is a fundamental lack of trust in the data generated by current systems. For example, the Finance department avoids certain reports because they produce inconsistent results. The Planning department must perform extensive manual cleanup and analysis of Automated Passenger Counts (APC) and runtime data, and has been unable to gain an understanding on why yearly ridership totals do not match the sum of the corresponding monthly reports. This forces staff into a defensive posture of constant data validation and creates risk for federal reporting and strategic planning.

The Principle: This project will treat all operational and financial data as a core agency asset.

The primary goal is to establish an integrated environment that functions as a single source of truth. This means that all data generated by systems procured under this program must be accurate, consistent, transparently calculated, and verifiable as such. When a report is run, its results must be reliable and defensible, eliminating the need for staff to second-guess the system or build their own shadow systems in Excel to verify information.

In Practice: This will be achieved by requiring vendors to provide comprehensive data dictionaries and clear documentation of their calculation logic. The system architecture will be designed to ensure data consistency, and procurement requirements will specify the need for robust, verifiable reporting and analysis capabilities.

3.2.2 User-Centric, Intuitive Design

The Problem: The current user experience for METRO staff is often frustrating and inefficient.

Dispatchers contend with a “forest of paper” to manage daily exceptions. Finance and HR staff

Future State

Guiding Principles

Data as a Trusted

Central Asset

User-Centric, Intuitive Design

Automation of Manual

Processes

Seamless System Integration

Scalability and Future

Readiness

Concept of Operations 8 must perform dozens of clicks to navigate clunky, outdated interfaces modeled on legacy

Microsoft Access databases. The “cloud” migration resulted in a slow, unreliable remote desktop environment that frequently freezes, interrupting critical tasks like payroll processing.

The Principle: The design of all future systems must prioritize the user. Interfaces will be modern, web-based, intuitive, and responsive. The goal is to empower staff with tools that simplify their work, reduce the number of clicks required for routine tasks, and present information clearly. A system should not require a user to have a decade of institutional knowledge or a degree in computer science to perform a basic function or troubleshoot a common issue.

In Practice: This principle will be enforced by requiring vendors to provide functional, hands-on demonstrations, not just marketing presentations. The usability of a system will be a key evaluation criterion during procurement. Requirements will specify the need for features like mobile-friendly employee self-service portals and potential integration with METRO’s Active

Directory for a single sign-on experience.

3.2.3 Automation of Manual Processes

The Problem: METRO’s current operations are heavily reliant on manual processes that are both time-consuming and prone to error. The operator payroll process is a prime example, requiring the Dispatch Supervisor to manually reconcile run assignments, paper exception slips, and a 150+ page report with a master Excel spreadsheet. Similarly, the daily import of fuel and mileage data from FLEETWATCH is a manual, multi-step process. Paper-based purchase requisitions are physically routed for signatures, and PTO is tracked in handwritten ledgers and spreadsheets.

The Principle: The new ecosystem must aggressively automate these manual and paper-based workflows. The project will seek to digitize processes from end to end. An operator’s time should flow automatically from their on-bus login to the payroll system. Purchase requests should be created and approved electronically. Inventory and financial data should be updated in real-time.

In Practice: This will be achieved by defining detailed workflow requirements for key processes like payroll, procurement, and data management. We will require systems that support electronic forms, configurable approval chains, and automated alerts and notifications to replace physical paper trails.

3.2.4 Seamless System Integration

The Problem: The lack of integration between METRO’s critical systems is the root cause of many of its data integrity and efficiency problems. Data does not flow automatically between

HASTUS (scheduling), Avail (CAD/AVL, finance), NeoGov (HR), and TimeTrak. This requires

Concept of Operations 9 constant manual export and import of data using unstable formats like .TXT and .CSV files, creating data latency, introducing errors, and consuming valuable staff time.

The Principle: The future state must be built on a foundation of seamless, automated integration. Data entered once in a primary system (e.g. a new hire in HRIS) should be automatically available in all other relevant systems (e.g. Payroll, CAD/AVL operator module, etc.). The default method for data exchange must be through modern, stable, and well-documented APIs.

In Practice: Robust API capabilities will be a non-negotiable requirement for any new system procured. Vendors will be evaluated on their demonstrated ability to integrate with the other key platforms in METRO’s environment. This principle is the technical backbone that enables the goals of automation and data integrity.

3.2.5 Scalability and Future Readiness

The Problem: METRO is currently constrained by end-of-life hardware and inflexible legacy software. The inability to easily add a second budget to the finance system or the reliance on a vendor-owned short code for passenger texting are examples of a technological framework that is not built for the future. This creates a risk of vendor lock-in and limits the agency’s ability to adapt to new operational needs or technologies.

The Principle: This modernization project must deliver an ecosystem that is both scalable and future-proof. METRO will prioritize solutions built on open standards that provide flexibility and control over the agency’s data and operational workflows. The chosen systems must be able to accommodate growth in service, the addition of new technologies (e.g. new on-board peripherals), and evolving business practices without requiring cost-prohibitive custom development.

In Practice: This will be achieved by carefully scrutinizing vendor architecture, requiring clear product roadmaps, and ensuring contracts provide METRO with long-term data ownership and control. The project will favor modern, cloud-native solutions that offer greater flexibility and scalability than the current legacy applications.

3.3 High-Level Conceptual Future System Architecture

The guiding principles defined in the previous section lead to a fundamentally different approach to system architecture. METRO’s current state can be described as a complex web of disparate systems connected by brittle, manual, and often one-way data transfers. The future state envisions a clean, modern, and data-centric “hub-and-spoke” model that prioritizes seamless integration, enhances data reliability, and simplifies overall system management.

Concept of Operations 10

The conceptual architecture places a unified data repository at its core, establishing it as the definitive single source of truth for the entire organization. The “spokes” radiating from this hub represent automated, bidirectional API connections. This model ensures that data is shared efficiently and consistently, breaking down the departmental silos that currently impede

METRO’s operations.

Figure 2: Future System Architecture

This proposed architecture provides several key advantages over the current environment:

Simplified and Robust Integration: Instead of building and maintaining dozens of unique point-to-point connections between every system, this model simplifies the landscape. Each primary system only needs to develop and maintain a single, robust API connection to the central hub.

This dramatically reduces complexity and points of failure. When a system like Finance/Payroll needs operator time data, it queries the hub, which has already received that data from the

CAD/AVL system, rather than needing a direct, custom-built link between the two.

Guaranteed Data Consistency: By feeding a central data warehouse, all departments and reporting tools access the exact same underlying information. This structure eliminates the data discrepancies currently experienced, where a ridership report from one module does not match another. When the Planning department needs performance data and the Finance department needs operational cost data, both are drawing from the same validated source, ensuring organizational alignment.

Enhanced Reporting and Analytics: A centralized data repository unlocks powerful new capabilities for business intelligence. It becomes significantly easier to conduct cross-functional analysis, for example, correlating maintenance events and parts costs (from the

METRO | CAD/AVL system

Concept of Operations 11

Asset/Maintenance system) with on-time performance and vehicle mileage (from the CAD/AVL system). This allows for more sophisticated, data driven decision making without the need for manual data extraction and consolidation in Excel or similar tools.

Future Scalability and Agility: This model is developed for the future. As METRO’s needs evolve, adding a new system or replacing an existing one becomes a more manageable task. A new platform only requires a single integration with the central hub to both access the data it needs and contribute its own data to the ecosystem. This makes the entire architecture more agile, reducing the cost and complexity of future technology upgrades and preventing the re-creation of the data silos that exist today.

4 CAD/AVL SYSTEM

The CAD/AVL system is the nerve center of METRO’s daily transit operations. It is the primary tool for monitoring fleet location, managing on-street service, facilitating communication between dispatch and operators, and collecting the raw data necessary for service planning and performance analysis. The current system has served METRO for many years but is now a primary source of operational friction and data unreliability. This chapter details the current operational concept, outlines a vision for the future, and establishes the foundational requirements for a modern replacement system.

4.1 Current State Concept of Operations

The current CAD/AVL system is provided by Avail Technologies. Architecturally, it is a complex hybrid environment of on-premise, remote desktop, and cloud-hosted services. Core dispatching and reporting functions are accessed via the “cloud”, a remote desktop connection to a vendor-hosted virtual machine that uses Microsoft Access databases for some modules.

This is paired with multiple generations of aging on-board hardware across the fleet. This fractured and outdated setup creates significant daily challenges for all user groups, leading to extensive manual workarounds that have become standard operating procedures.

4.1.1 Key Functions and User Roles

Dispatchers (Operations Supervisors) serve as the primary real-time users of the system. They monitor vehicle locations on a map-based interface, communicate with operators via an integrated Motorola radio system, manage service exceptions (e.g. late pullouts, vehicle breakdowns), and are intended to manage detours. Their work is heavily supplemented by a forest of paper-based logs, run sheets, binders, and frequent radio/phone calls due to system limitations.

Operators interact with the system via an in-vehicle MDT (Mobile Data Terminal). Their core functions are to log in to their assigned run, perform a pre-trip inspection using the MDT, follow

Concept of Operations 12 schedule adherence prompts, and receive text-based messages from dispatch. They often rely on paper schedules as a backup and use the radio as the primary means of communication.

Planners act as downstream consumers of the system’s data. They do not typically use the live dispatch interface but instead run historical reports on on-time performance (OTP), runtimes, and passenger counts to inform service adjustments and fulfill National Transit Database (NTD) reporting requirements. This process is marked by data extraction into Excel and manual analysis due to the system’s poor reporting capabilities.

Maintenance Staff (Foremen & Technicians) are primarily reactive users. They receive alerts from the system for critical vehicle faults (e.g. “Stop Engine” light) and may use this information to initiate work orders. They do not receive detailed, real-time diagnostic codes through the system, relying instead on radio calls from dispatch.

IT/System Administrators provide technical support for the system. Their role is significantly complicated by the remote-hosted environment, which severely limits their ability to perform administrative tasks like creating new user accounts, troubleshooting database issues, or applying fixes without submitting a ticket to the vendor and waiting for a response.

Customer Service Representatives use system-derived information to answer passenger inquiries. They primarily rely on third-party apps like Transit App (fed by METRO’s Swiftly system) because Avail’s myStop app and real-time data are considered less reliable and slower.

4.1.2 Existing Operational Scenarios and Workflows

The following scenarios illustrate how the current CAD/AVL system and its surrounding manual processes function in practice, highlighting the inefficiencies and operational challenges experienced by METRO.

Concept of Operations 13

4.1.2.1 Scenario 1: Daily Operator Sign-in and Pull-Out

An operator begins their shift by physically going to the dispatch window. A dispatcher gives them a checkmark on a paper pull-out sheet to confirm the operator is present. The operator then receives their bus assignment from a separate sheet of paper created by the yard coordinator. The operator proceeds to the assigned bus and manually keys their Operator ID and Run Number into the MDT. The login process is often slow and can fail if the aging MDT /

Integrated Vehicle Logic Unit (IVLU) freezes. Once logged in, the system initiates a multi-step pre-trip inspection on the touchscreen. If a safety critical fault is found (e.g., a non-functional wheelchair ramp), the operator’s primary action is to use the radio to call dispatch, as the electronic report is not trusted for immediate action. If the login process fails entirely, the operator is instructed to continue their run without a working MDT, relying on the radio and their paper schedule. Dispatch is now blind to this vehicle’s location and status within Avail, creating a data gap for the entire trip.

Figure 3: CAD/AVL Existing Scenario 1

Concept of Operations 14

4.1.2.2 Scenario 2: Handling a Call-Off and Extra Board Assignment

An operator calls dispatch to report that they will be absent. The dispatcher on duty takes the call and notes the absence and reason (e.g., FMLA) on a paper log. They then enter the absence into a separate Microsoft Access database (the “Dispatch Log”). Simultaneously, another dispatcher takes a physical folder containing the daily extra board assignment sheets, crosses off the now-absent operator, and consults a handwritten rotation list to identify the next available extra board operator. This assignment is written by hand onto the extra board sheet.

The information is then passed to the payroll supervisor, who manually enters the exception into Avail’s Fleet-Net payroll module. If the absence is for FMLA, the information must also be entered into a separate Google Form and the JJ Keller system for tracking. This single event requires actions across five different systems, four of which are manual or paper based.

Figure 4: CAD/AVL Existing Scenario 2

Concept of Operations 15

4.1.2.3 Scenario 3: Road Call for a Mechanical Failure

An operator experiences a “stop engine” light on the road. They immediately use the radio to call dispatch. The dispatcher receives the call and can see a generic “stop engine” fault and a

Suspect Parameter Number (SPN) in the Avail interface, but no specific diagnostic information.

The dispatcher creates a road call work order using a form within Avail. This action automatically prints a paper copy of the work order on a printer in the maintenance foreman’s office. Simultaneously, the dispatcher communicates verbally via radio to the maintenance foreman, who then assigns a mechanic. There is no automated alert or digital assignment. If the printer is jammed or the foreman is away from their desk, the process relies entirely on the radio call. The original paper work order becomes the primary tracking document for the repair.

Figure 5: CAD/AVL Existing Scenario 3

Concept of Operations 16

4.1.2.4 Scenario 4: Managing a Detour

A water main break closes a major road. A road supervisor draws a polygon around the affected area in Avail, which flags the associated stops as closed within the dispatch interface. However, this action does not automatically generate a new path for operators or alert passengers.

Dispatch must then broadcast verbal turn-by-turn instructions over the open-channel radio to all affected operators. They may also type a text message that is sent to the operator’s MDT, which operators must read while driving. The detour information is not passed to Swiftly or any other passenger-facing application. Customer Service is notified via an internal e-mail group and staff must manually update the METRO website. Customers at the closed stops have no real-time notification of the service change.

Figure 6: CAD/AVL Existing Scenario 4

Concept of Operations 17

4.1.2.5 Scenario 5: Generating a Service Performance Report

A planner needs to analyze the on-time performance and passenger loads for a specific route.

They log onto the Avail system and navigate to the reporting module. After selecting the route and date range, they wait several minutes for the system to generate the report. They export the data to Excel. The resulting file contains inconsistent and unreliable data; for example, ridership counts at the transit center are often inflated because the system fails to properly account for ridership (e.g. reset the APCs to zero or transfer counts to new route) between interlined trips. The planner must manually identify and scrub this bad data. They then find that running a separate runtime report produces slightly different trip counts than the APC report for the same period. Unable to reconcile the discrepancies, they must choose the “least incorrect” dataset, and proceed with their analysis in Excel, acknowledging the data’s inherent flaws. This process is time-consuming and undermines confidence in any strategic decisions based on the data.

Figure 7: CAD/AVL Existing Scenario 5

Concept of Operations 18

4.1.2.6 Scenario 6: Updating On-Board Announcements

The Planning department wants to add a new audio announcement to the buses. If the change is small and METRO has the audio to edit, the Sr. Planner can make the adjustment. If a new recording is required, then the Sr. Planner must submit a ticket to Avail to have a new audio file created. This task, which used to be managed internally, now requires a vendor intervention due to the cloud migration that occurred in late 2024. Avail then prepares the file and pushes it to the fleet. This process is time-consuming and any custom changes to the on-board system have a high likelihood of introducing errors that require further vendor support to resolve. If the memory card on the IVLU is full, a member of the IT team needs to go out to the affected bus and empty the memory card manually before new audio can be stored.

Figure 8: CAD/AVL Existing Scenario 6

The current CAD/AVL system suffers from pervasive operational deficiencies:

• Data and Reporting: Data is frequently inaccurate, inconsistent across reports, and lacks vendor transparency. Reports are difficult and time-consuming to generate and require manual cleaning in Excel. The system cannot accurately track lost service time or reconcile monthly vs annual data.

• System Performance and User Experience: The user interface is outdated, slow, and prone to freezing, particularly after the cloud migration. The remote desktop architecture is cumbersome and unreliable. The onboard hardware is slow and unresponsive.

• Integration: The system has poor or non-existent integration with critical platforms like

HASTUS (scheduling) and Swiftly (passenger information). The lack of a direct link to payroll prevents automated timekeeping. Manual processes are required to connect with maintenance, dispatch logs, and FMLA tracking.

Concept of Operations 19

• Hardware: The onboard hardware is a mix of multiple aging generations, with some units past the end of their life. This causes frequent failures, operational disruptions, and an inability to obtain replacement parts.

• Workflow Inefficiencies: Nearly every core operational process, from call-offs and detours to reporting and pre-trip inspections relies on a series of manual, paper-based steps that exist outside of the system. This creates duplicate data entry, risk of information loss, and significant staff inefficiency.

• Vendor Support: Vendor support is often slow and inconsistent. Support tickets are frequently downgraded or closed without adequate resolution, and proposed solutions are often workarounds rather than permanent fixes to core problems. Administrative control is limited, requiring vendor tickets for simple tasks like user creation.

4.2 Future State Concept of Operations

4.2.1 Vision and Key Improvements

The vision for the new CAD/AVL system is to move from a set of isolated tools, to a reliable, integrated, and data-rich operational hub. The new system will be the trusted source of real-time information for all departments and for METRO’s passengers, enabling proactive management and data-driven decisions. The new CAD/AVL will be characterized by automation, intuitive design, and seamless connectivity.

A Trusted Source of Operational Truth: The new system will provide accurate, consistent, and verifiable data. Reports will be generated quickly and reliably, and the underlying data will be transparent and well-documented. System logic for metrics like on-time performance and passenger counting will be clear and auditable.

An Intuitive and Responsive User Experience: Staff will interact with a modern, web-based interface that is fast, stable, and easy to navigate. Operators will use durable, responsive onboard hardware that simplifies their workflow and minimizes distractions.

A Seamlessly Integrated Communications Hub: The system will serve as the central point for operational data, sharing information automatically with Finance, Payroll, Maintenance, Scheduling, and Passenger Information systems through robust, well-documented APIs.

Automated Workflows for Efficiency: The new system will eliminate paper-based processes and automate manual tasks. This includes flagging pre-trip defects, initiating maintenance work orders, communicating detours, and most critically, capturing operator time for payroll.

Reliable and Modern On-Board Technology: The entire fleet will be outfitted with a single generation of modern, reliable, and vendor-supported on-board computers and peripherals, ensuring consistent performance and simplifying maintenance.

Concept of Operations 20

4.2.2 Future Operational Scenarios and Workflows

The following scenarios illustrate how a modern CAD/AVL system will transform METRO’s daily operations, eliminating inefficiencies and empowering staff with better tools:

4.2.2.1 Scenario 1: Daily Operator Sign-in and Pull-out

An operator arrives at the depot and taps their employee badge on a digital crew display, which confirms their check-in and shows their run and vehicle assignment for the day. The system also sends them a mobile alert with the same information. They proceed to their assigned bus and tap their same badge on the new MDT. The system instantly authenticates them, logs them into their run, and automatically loads the correct schedule and destination sign information. The operator completes a pre-trip inspection on the responsive touchscreen in minutes. A critical defect (e.g. a non-functional wheelchair ramp) is noted, and this action automatically flags the vehicle as “not ready for service” in the system. This sends an immediate electronic alert to both Dispatch and the Maintenance Foreman’s dashboard creating a preliminary work order for assessment and completion. The operator’s login time is automatically captured and sent to the payroll system, establishing the start of their paid shift. The dispatcher on duty assigns a replacement bus to the operator, and the operator repeats the process from tapping onto the

MDT, through to the inspection. This time, the inspection passes, and the operator begins their work for the day.

Figure 9: CAD/AVL Future Scenario 1

Concept of Operations 21

4.2.2.2 Scenario 2: Handling a Call-Off and Extra Board Assignment

An operator reports their absence for the day through an automated call-in line or an employee self-service portal. The system automatically logs the absence and cross-references it with their available PTO or FMLA balance in the integrated HRIS/Payroll system, sending a confirmation message to the operator of the time being approved or to contact dispatch if there is an issue.

The system then flags the operator’s assigned run as “Open” on the dispatcher’s screen in real-time. The system consults the electronic extra board roster and based on pre-defined union rules for seniority and rotation, suggests the next eligible operator to cover the run. The dispatcher reviews and confirms the assignment with a single click, for the dispatcher the process is cohesive and simple. The new operator is notified of their assignment via public address system, digital screen, or a push to their mobile device, or all three. All timekeeping and payroll systems are updated automatically with the change. This single event is managed electronically from start to finish, with a clear digital audit trail and no manual data entry.

Figure 10: CAD/AVL Future Scenario 2

Concept of Operations 22

4.2.2.3 Scenario 3: Road Call for a Mechanical Failure

An operator’s vehicle displays a warning on the MDT (e.g., “Check Engine, Dispatch has been alerted, Please Continue”) and in parallel, automatically sends a high-priority message to dispatch confirming the issue. Simultaneously, the system creates a high-priority incident, flagging the vehicle’s precise location on the dispatch map and pushing the specific fault code directly into the Maintenance system’s work order queue. The maintenance foreman receives a notification and can immediately assess the severity and dispatch a mobile technician if needed. Dispatch sees the same detailed alert and can proactively arrange a bus swap at the next major timepoint, minimizing service disruption. The system allows for a seamless sign-in for the replacement bus and/or operator. The creation of the digital work order and the capture of initial diagnostic data occur automatically and instantaneously. Dispatch has the ability to check the status of the work order.

Figure 11: CAD/AVL Future Scenario 3

Concept of Operations 23

4.2.2.4 Scenario 4: Managing a Detour

A water main break closes a major road. A road supervisor, from their vehicle’s laptop or tablet, draws the detour path on a map-based tool within the dispatch software. The software allows for expiration dates to be added to the new detour. Upon saving, the system automatically:

• Publishes the new route with real-time, turn-by-turn navigation directly to the MDTs of all affected operators.

• Generates and disseminates a GTFS-RT Service Alert, which instantly updates all passenger-facing applications (e.g. Transit App, Google Maps) to display the detour on the map, mark affected stops as closed, and provide clear instructions on where to catch the bus; and

• Sends a pre-formatted electronic notification to Communications and other internal stakeholders. The entire process is managed from a single interface and communicated to all stakeholders instantly and electronically, ensuring everyone has consistent and accurate information.

• If expiration was included, the system will revoke the detour at the appropriate time and restore navigation and mapping to the default status and routes.

Figure 12: CAD/AVL Future Scenario 4

Concept of Operations 24

4.2.2.5 Scenario 5: Generating a Service Performance Report

A planner logs into a web-based analytics portal and accesses a performance dashboard. They filter for a specific route and date range. The system instantly generates an accurate, easy-to-read OTP and ridership report, complete with visualizations. The data is trustworthy, as the system automatically resets APCs at the end of each trip and properly accounts for interlining and partial trips, flagging them for review rather than discarding them. The planner can share this report directly, or export a clean, presentation-ready report in their preferred format (.pdf or .xlsx) without any need for manual data scrubbing or external calculations.

Figure 13: CAD/AVL Future Scenario 5

4.2.2.6 Scenario 6: Updating On-Board Announcements

The Planning department wants to add a new audio announcement to the buses. An authorized staff member logs into the web-based administrative portal for the CAD/AVL system. They navigate to the announcement management module, upload the new audio file using text-to-speech or AI, and use a map interface to geofence the area where the announcement should play. After previewing and saving, they can schedule the update to be pushed wirelessly to the entire fleet during a designated off-peak window. Old files are automatically purged from the

IVLU to make room for the new audio files and any temporary files will be deleted when the expiration date is met. The process is self-service, takes only a few minutes, and does not require submitting a ticket to the vendor, giving METRO direct and immediate control over its on-board messaging.

Figure 14: CAD/AVL Future Scenario 6

Concept of Operations 25

4.3 Objective-Based Procurement Statements

The following objectives represent the core operational and functional outcomes METRO expects to achieve with the implementation of a new CAD/AVL system. These statements will serve as the foundation for the Request for Proposals, and responding vendors will be required to provide detailed narratives and functional demonstrations illustrating how their proposed solution, project team, and support model will meet each specific objective.

4.3.1 Overall Objectives

• Establish a Culture of Trust in Data. METRO’s primary objective is to make data an asset that is trusted and utilized across all departments. The current environment of inconsistent reports and “black box” calculations creates inefficiency and undermines confidence. The future system must serve as the single, verifiable source of truth for all operational data, ensuring that when the Planning department reports on ridership, the

Finance department analyzes costs, and the executive team reviews performance, everyone is working from the same accurate and defensible information.

• Eliminate Redundant, Manual, and Paper-Based Workflows. METRO’s objective is to reclaim the significant staff time currently lost to inefficient processes. The practice of using paper, Excel spreadsheets, and manual data re-entry to bridge gaps between siloed systems must end. The goal is a fully digital environment where information is entered once, regardless of who enters the data or where, flows automatically and accurately to every other system that needs it.

• Provide a Unified and Simplified User Experience. METRO’s objective is to provide its employees with a cohesive and intuitive technology ecosystem.