Customer Data Guide

Overview

The Avail system enables transit agencies to automate several important operational and maintenance functions. When used as designed, the system provides data that agencies can use for reporting and operational improvement.
This article helps users understand how data is generated by the Avail system and what that data means. It helps to ensure that the data agencies receive from the Avail system is accurate, consistent, and reliable. It will also help users understand how to use the Avail system for reporting and how the FRITS project team works to ensure data reliability.

In addition, this document answers important questions such as:

• Where does my report data come from?
• How can this data be validated?
• What data should be used for official reporting to Pennsylvania Department of
• Transportation (PennDOT) and the National Transit Database/Federal Transit Administration 
  (NTD/FTA)?
• What data should be used for internal analysis and operational improvement?

This article has grown out of common questions, concerns, and misunderstandings experienced with early FRITS implementations. It is organized to address those common concerns and serve as a reference point, not a comprehensive description of the entire Avail product.

Transit Data in myAvail

There are four main components to the data flow in myAvail:

• Schedule data that contains the details of the service that should be performed.
• Operational data that is collected by vehicles that are performing the service.
• Data validation and preparation, in which APC and Ridership operational data is prepared after a day of service.
• Reporting data that is represented through reports in the Business Intelligence (BI) reporting tool.

Together these components enable agencies to set a baseline expectation (schedule data), observe what is happening on the road (operational data), validate that the data arriving from vehicles is correct (validation and preparation), and run useful reports pulling from the reporting data. The following sections describe each in more detail.

Schedule Data

Schedule data contains the details of the service that should be performed on the street. It provides a baseline expectation to which the actual service is compared. It is the foundation of transit data in myAvail.

The user begins by creating schedule data in a scheduling application such as Optibus, HASTUS, or The Master Scheduler (TMS). The process of creating schedule data requires users to know every detail of the schedule, including the exact latitude and longitude of every stop, the direction the vehicle approaches the stop, which stops are announced, when to start the announcement, what the headsign should show, what fare should be charged, and which stops are timepoints. Running times are also an essential component of schedule data, defining stop-to-stop time and distance. The accuracy of this data determines how successful an agency will be at adhering to the scheduled service, and this will have a direct result on the agency’s on-time performance.

Once the schedule is built in the scheduling application, it is exported from the scheduling application and imported into myAvail. During the import process, myAvail checks and verifies that the schedule information is complete. If any errors are found, they must be resolved in the scheduling package, and the process is repeated.

Once the import is complete, the user must complete schedule data information via GeoTools in myAvail. GeoTools is used to verify or assign trigger boxes, route traces, and announcements. The schedule data is then ready to go live automatically on the publish date. At that point, it will be published to the entire vehicle fleet.  

• Trigger boxes are geo-fenced areas that define actions that occur when a vehicle enters a specific location, such as the playing of announcements or changing of headsigns near a specific stop.
• Route traces define the path between stops. They are often used as a visual guide to better understand the service area for a particular route.
• Publish date is the date (set in the scheduling application and verified in the Deploy tab) when a specific schedule will go live.
• Service levels are categories of data that define which service should be performed on which day. For example, an agency may have a weekday service level and a weekend service level, along with various holiday service levels. All may be active in myAvail simultaneously, assigned to different days.

Operational Data

Operational data is information collected in real time from vehicles in service. It combines schedule information and Global Positioning System (GPS) data from the vehicle. GPS information is regularly (once per second) monitored by the MDT. This location-based information is an important component of all operational data described here. By comparison with schedule data, it informs operators about their schedule adherence and on-route status. It also enables dispatchers to monitor operations. Using this data, operators and dispatchers can understand what is happening in real time and can react before minor issues become serious problems. There are several important types of operational data.

1. Automatic Vehicle Location (AVL) data is captured when the vehicle is in operation and indicates where the vehicle is (based on GPS) and what it is doing. Information includes vehicle location, speed, direction, operator, and service data (Block, Run, Route, Trip, Stop).

AVL data reports include:

Location (lat/long) [GPS]

Date/time [GPS]

Direction of travel [GPS]

Speed [GPS]

Vehicle ID [schedule data]

Operator ID [schedule data]

Route ID [schedule data]

Run ID [schedule data]

Stop ID [schedule data]

Block ID [schedule data]

Trip ID [schedule data]

Distance traveled [GPS odometer distance]

AVL reports occur when:

Ignition changes state (vehicle on/off)

Operator logs on to a specific run/block

Max time interval since last communication (default 30 seconds) can be increased to 10 seconds (typically when bus is stationary, more frequent reporting when vehicle is in motion)

Vehicle enters or exits a stop trigger box

Operator sends message to dispatch

Operator puts vehicle in “manual announcement mode”, “out of service” or “Driver off”

Operator logs off

2. Arrival reports data is captured whenever the vehicle enters the trigger box of a scheduled stop. Arrival reports contain AVL data as well as arrival time.
3. Stop reports (also called departure reports) data is captured whenever the vehicle exits the trigger box of a scheduled stop. Stop reports contain AVL data as well as arrival, departure, dwell times, boards (APC data), alights (APC data), onboard numbers, and schedule deviation (if a timepoint).
4. Events are occurrences that may be important to monitor in real time. They appear in myAvail in the Event, Communications, and Maintenance queues. Events include emergency alarms, requests to talk, late logon warnings, system error messages, and wheelchair lift events, among many others. Dispatchers should actively monitor event queues.
5. Farebox data differs depending on the fare solution used by the agency (see Section 4.1). For an agency using GFI, the following data is collected:

Driver ID

Run ID

Route/Trip ID

Fareset ID

Fareset Input

Service level

Vehicle timestamp

Ridership/Cash count

An agency using the Avail fare screen will collect the data listed above as well as Stop ID, Latitude, and Longitude.

Data Validation and Preparation

At the end of the service day, as well as other time intervals defined in the system configuration, data is transmitted from the in-vehicle system to the myAvail database. Some data is immediately available for reporting. APC and farebox data, however, go through a process that enables users to process exceptions and identify adjustments to ensure that all ridership data is assigned to the correct categories. This data is kept in a holding tank until it is reviewed and available for reporting. The two important components of data validation and preparation are exceptions and adjustments.

Exceptions

myAvail compares operational data to what was planned (schedule data). When these data checks are not passed, myAvail creates an exception. This allows users to correct and validate their data, addressing anomalies that might be caused by issues like operators not logging in or switching runs correctly. The data checks include:

• Is the Trip ID valid for the Route ID?
• Is the Route ID valid for the Block ID?
• Is the Run ID valid for the Block ID?
• Is the Block/Route/Trip combination synchronous when compared to the active schedule?
• Is the Fareset ID valid when compared to the route's setup in the ETMS Routes card?
• Is the Operator ID active in the ETMS Personnel card?
• Is the Vehicle ID active in the ETMS Asset Inventory Vehicle card?

The user validates or corrects this data through exceptions processing. 

When this process is complete, all farebox and APC data is ready for system-wide reporting. Allow roughly thirty minutes between processing exceptions and accessing that information in reporting.

Adjustments

Adjustments are not identified automatically by the Avail system like exceptions are. Users create time or distance adjustments manually when a service that was scheduled was not performed as planned. For example:

• A bus breakdown that resulted in a partial or missed trip(s) reduces mileage for the day.
• Any service that was not scheduled but was performed, such as adding a tripper vehicle, increases mileage for the day.

Adjustments are essential as they inform the Avail system that the agency needs to change the service to deviate from what was originally scheduled. If adjustments aren’t entered as needed, your NTD Actual Miles and Hours will not be accurate.

Reporting

Once data has been validated and prepared, it is available for reporting. Using Business Intelligence and DataPoint in myAvail, agencies can reference multiple pre-existing reports as well as create reports, share reports, and set reports to be delivered automatically via email. myAvail does not limit an agency’s ability to access their data, and full export capabilities enable data to be exported and shared in useful and various formats.

Reporting is important for two reasons. First, it can be used for financial/governmental reporting requirements, such as state or NTD reporting. Second, reports can be used to enhance operations by measuring Key Performance Indicators (KPI).

When evaluating the numerous reports available in myAvail, it’s important to know which reports to use for which purposes, and which data each report relies on. See tables describing the purpose and source of each report in Appendix A. For more detailed information on the most frequently used reports, see Section 6.

Technical Data Flow

Once users understand the categories of data in the myAvail system, it is possible to understand the technical flow of data between the vehicle and the backend reporting system. This understanding is helpful if you are troubleshooting the system.

Wi-Fi Download to/from Vehicle

When a vehicle in the garage or yard is turned on, it connects to an access point which provides Wi-Fi for the vehicle. The vehicle system then downloads updates including run files (schedule data), announcements, and IVU firmware or configuration updates. Large files are downloaded only over Wi-Fi (except in special circumstances) to save on cellular data.

When a vehicle returns from service and is in Wi-Fi range, video from the camera system can be automatically downloaded to the backend.

Vehicle to Cloud Backend

To ensure correct flow of data from the vehicle, the operator must log on before departing the garage. When the vehicle departs the garage:

• The vehicle transitions to cellular service.
• AVL data and operational data are captured and recorded on the vehicle (in the IVU) and sent to the backend system in real time.
• As the backend myAvail system receives updates from the vehicles, it distributes the information to myAvail Operations (for dispatchers), the myStop/Passenger Information Tool (for riders), and Business Intelligence (for reporting).

If cell communication is lost:

• The vehicle will continue operating normally (headsigns will update, boards and alights are counted, schedule adherence is monitored, etc.) if the driver is already logged in.
• Data is not shared in real time with the backend system during a cell outage, but data is stored on the vehicle’s IVU and is forwarded to the myAvail system when communication is restored.
• Stop reports and other operational messages are kept on the IVU indefinitely until they can be offloaded. AVL reports, which are responsible for reporting the GPS pings, are only kept on the IVU for 5 minutes. After that point they are no longer useful for real-time estimation.

Vehicle to Passenger Information Systems

Avail’s Traveler Information Data Service (TIDS) module provides a common source for real-time system information. This service receives changes in the state of the system, such as a vehicle leaving a stop or a notification that there is a message to display from the myAvail Service. It then packages these updates into blocks of data for distribution to all passenger information tools (myStop apps, websites, third parties, etc.). The following operational data is used by the passenger information systems:

• AVL reports
• Stop reports
• Arrival reports
• Departure reports

This data is updated in real time as the vehicle sends updates to the backend server, and the vehicles progress through their fixed route schedules. These updates get sent over the cellular network and are then processed by the Avail servers to estimate future arrival times. The Avail REST API receives these updates, and other applications connected to it pull the updates from the REST API. These updates are available every three seconds.

Data Flow Into Reporting

Reports become available at different times depending on if the data requires processing or not and whether an agency processes data promptly.  Data becomes available for reporting in one of three ways.

• Real-time or same day data is available for reporting as soon as it’s captured. These reports require no additional processing.
• Next day data requires the completion of the current service day before it is available for reporting. At the end of each service day, the Avail application moves data from the Transit Authority Database to the Data Warehouse. During the process of moving the data, it is transformed and summarized to allow for efficient aggregate reporting.
• Data that requires user action is a type of next day data only available for reporting after exceptions processing and adjustments are complete. APC and farebox data requires the user to confirm or correct data via exceptions processing to ensure ridership is allocated to the correct categories. This data is available for reporting roughly thirty minutes after exceptions are processed. Adjustment data is available for reporting immediately.

Important Data Categories

There are three important data categories that transit agencies often focus on: ridership, miles, and hours. In the Avail system, each of these categories can be measured in multiple ways. Understanding the differences between each type of measurement is essential to successfully using Avail data for reporting and operational improvement.

Ridership

There are two important ridership categories in myAvail: farebox ridership and APC ridership. These measure slightly different metrics and are used for different purposes.

• Farebox ridership measures fares that are collected and is used for reporting. This data comes into the backend system when the farebox is probed (usually at the end of service day) and is available for reporting after exceptions are processed.
• APC ridership measures boards and alights to calculate an onboard count and is used for scheduling/planning. This data comes into the backend system with stop reports and is available for reporting after exceptions are processed.

Farebox and APC ridership are expected to differ; APC ridership numbers will be higher than farebox numbers. There are many instances where APCs count multiple boards or alights for a single fare. For example, a rider may get on and off the bus repeatedly to bring on grocery bags. A parent may get on and off to bring on children and a stroller separately. And at transit centers or layovers, riders may get on and off the bus as they wait for departure. In all of these instances, APC counts may be higher than the number of fares collected.

The following sections explain ridership numbers in more detail and clarify why farebox ridership should be used for reporting while APC ridership should be used for scheduling and planning.

Farebox Ridership Data

Farebox/fare screen data can come from a farebox collection system integrated with Avail or from the Avail fare screen (which operators can use to manually tally passengers and associated fares). Both options indicate what fares have been collected. The advantage of farebox ridership data is its association with passenger/fare types such as senior, student, day pass, etc., and its importance for reporting. However, most farebox ridership cannot be counted down to the stop level. (GFI farebox data, the most common source, can be counted to the trip level. The Avail fare screen provides data to the stop level.) More detailed ridership data (from APCs) may be needed for scheduling and planning service.

Agencies use a wide variety of fare solutions, ranging from boxes like GFI and Scheidt and Bachmann to mobile ticketing applications like Masabi and Token. Avail integrates with these solutions in a variety of ways. In order for an agency to understand how/whether their fare solution integrates with Avail, and how, it is important to discuss fare solutions and impact on ridership data with an Avail representative.

Farebox data flows as follows:

• An automatic test verifies there is a connection to the farebox when the Avail Mobile Data Terminal (MDT) is powered on.
• The system validates the Operator ID, Block, Route, Trip and Date/Time (System can be configured to send Run in place of Block) when the operator logs on to myAvail.
• The farebox collects ridership using each farebox key press such as Senior, Day, Monthly Pass, Cash, and others. The fare information stays on the farebox and does not interface with the myAvail in-vehicle system.
• The Avail MDT updates schedule related information at the end of each trip.
• The operator logs off, and the farebox is logged off.

Farebox ridership that is captured in a farebox is transferred from the vehicle into backend systems by probing and then into reports by exceptions processing.

• The farebox is probed at the end of a service day. This transfers data from the vehicle into the fare system backend (e.g. GFI).
• On the next processing day, the myAvail backend runs a process that transfers the farebox data from the fare system to temporary storage in myAvail for validation and processing.
• Staff use the Exceptions tab in myAvail to validate and correct the data. Note that staff are not correcting ridership counts through the exceptions process; rather they are correcting the schedule categories that ridership may be allotted to.
• Roughly thirty minutes after staff complete exceptions processing, farebox ridership data is available for reporting.

Portions of ridership data can be undefined – that is, not connected to a run, trip, or route. For example, an adult fare may be captured but not assigned to a specific route (the route is undefined). The most common cause of this issue is when exceptions have not been accepted; it could also indicate a driver not logging in.

APC Data

APC data comes from the automatic passenger counter sensors that are installed above each vehicle door. These sensors are triggered when the doors are opened and count the number of boards and alights on the vehicle. The advantage of APC data is that it associates boards and alights to specific stops. However, APC data does not associate passengers with a particular fare type and should not be used for reporting. Since APC data associates boards and alights to specific stops, it is useful for trip sampling as well as detailed planning and scheduling.

APC data is collected and processed as follows:

• An automatic check verifies there is a connection to the APC controller when the Avail MDT is powered on.
• The operator tests the APC counters to verify that they are working correctly.
• The APC collects ridership boards and alights automatically as riders pass through the doorway. APCs send data to the myAvail backend when the vehicle departs the stop.
• On the next processing day, the myAvail backend runs a process that transfers the APC data to temporary storage in myAvail for validation and processing.
• Staff use the Exceptions tab in myAvail to validate and correct the data. Note that staff are not correcting ridership counts through the exceptions process; rather they are correcting the schedule categories that ridership may be allotted to.
• Roughly thirty minutes after staff complete exceptions processing, APC ridership data is available for reporting.

Mileage Data

Mileage is an important data metric collected in myAvail and used for reporting. There are different types of mileage data, from different sources, that are useful for different purposes.  

Scheduled and Actual Miles

There are two types of mileage data in the Avail system that are based on schedule data:

• Scheduled mileage is directly calculated by schedule data. It is defined in your scheduling package by adding stop-to-stop distances for each scheduled trip. When you import and publish your schedule data in myAvail, this scheduled mileage number is brought into the Avail system. Detours do not change scheduled miles.
• NTD actual mileage is scheduled mileage plus or minus adjustments, including detours. This value is used for top-down reporting and is Avail’s recommended approach to reporting mileage.

Both of these values are useful. Clearly, NTD actual mileage is more representative of what happened in service than the scheduled mileage, since it includes adjustments based on the service that was actually performed. NTD actual mileage will differ from scheduled mileage if (for example) a bus breaks down and service is not completed, or if a tripper is added and service is increased. Comparing scheduled and actual mileage can reveal needed schedule changes and inform planning decisions.

Vehicle Miles

Vehicle miles can be measured outside of the Avail system by odometers and hubometers or inside the Avail system by J1939 odometer data or GPS data. Each of these methods contains some degree of error (due to variables like engine brand, tire tread, GPS rounding) and can be used for different purposes. All of these measures include detours; in other words, they represent the actual distance the vehicle traveled regardless of what was scheduled.

• Odometers and hubometers measure the total elapsed distance traveled during the life of a vehicle. Values may reset to zero due to maintenance (engine or component replacements), but overall, these are the best measurements of how many total miles a bus has traveled.
• Within the Avail system, vehicle miles can be configured to use J1939 odometer data or GPS data. (If configuration is set for J1939 but that connection is unavailable on certain vehicles, the system will use GPS data for those vehicles.) J1939 mileage comes directly from the vehicle engine via the J1939 connection. GPS mileage is calculated by GPS pings once per second. These values will differ very slightly due to differences in engine function and slight rounding on GPS calculations. Both will also be very close to elapsed odometer/hubometer readings for a given service day. These values do not provide the mileage traveled throughout the life of the vehicle.

All types of vehicle miles are useful for preventative maintenance and useful life calculations. Vehicle miles in the Avail system are particularly useful to planners who may want to compare them with scheduled/actual miles. Vehicle miles are not used by the NTD because they contain maintenance, training, and other non-ridership mileage.

Hours Data

Like with mileage data, there are two broad categories of hours data: those based on the schedule and those based on actual vehicle time.

Scheduled and Actual Hours

There are two types of hour data in the Avail system that are based on schedule data:

• Scheduled hours are calculated in the scheduling package, when the user defines the time for each trip. This time is brought into myAvail when a new schedule is imported and published.
• NTD actual hours are scheduled hours plus or minus adjustments. This value is used for reporting.

Vehicle Hours

Vehicle hours are captured on the vehicle whenever an operator logs into the system. The system records the time of login and log off. Between those times, the system automatically attributes hours to the correct schedule categories (block, run, route, trip, etc.) based on the login information.

Act 44 Reporting with myAvail

The Fixed Route Performance Dashboard in Business Intelligence is a tool that agencies use to measure and ultimately improve their operations. Agencies in FRITS can use the Fixed Route Performance Dashboard to create and access reports for summarizing an agency’s Act 44 formula factors and performance measures. The features of this dashboard allow users to easily view and evaluate data, and the dashboard can be customized for reporting specific to Act 44. The Fixed Route Performance Dashboard can be found in the Statistics menu of Business Intelligence. There are three main components of the dashboard:

• The Target Definition screen is used to define metrics and goals used for calculations throughout the dashboard. The default list of metrics includes schedule adherence, ridership, APC boards, revenue miles and hours, and operating costs—metrics that most agencies track and evaluate.
• The Monthly Metrics Report includes data results for all metrics. This is also the screen where manual metric values are entered. These manual entries may involve data that is not contained anywhere in the Avail system (such as Monthly Operating Cost) and data that is available elsewhere in the Avail system but not drawn automatically into this report (such as Senior Ridership).
• The 12 Month Report (a.k.a. Fixed Route Performance) contains the data and compares the data to the goals set in Target Definitions. Both the Monthly Metrics Report and the 12 Month Report can be used for Act 44 reporting data. The difference is that the 12 Month Report can also compare the data to goals that the agency has set.

Avail has customers across the country, and each has slightly different metrics and performance measures they may use to evaluate performance. For that reason, the Fixed Route Performance dashboard is customizable to an individual agency’s needs. One-time manual setup, described in the sections below, is necessary in order to prepare this dashboard for reporting specific to Act 44. Once metrics and goals have been defined, some manual data entry is required on a monthly basis.

Definitions

Note that three of the default fields in the Monthly Metrics Report and 12 Month Report directly correlate to fields in Act 44 reporting.

Table 1. Default Fields in Monthly Metrics Report

One-time Setup

The first time an agency uses the Fixed Route Performance Dashboard for Act 44 reporting, setup is required. This setup work occurs on the Target Definition screen, which is used to define additional metrics and calculated metrics necessary for Act 44 reporting. These metrics include the Act 44 formula factors and performance measures. By setting up each of these metrics, the Dashboard will be organized to contain and calculate the necessary information for Act 44 reporting.

From the Target Definition screen, click the Add Metric button below the Target Definition table. This will pop up a window that allows you to name a metric, define its data format, and clarify your goal (e.g. “exceed target”). Use this interface to enter each metric shown in the table below. The FRITS project team or FAST representative can help ensure this setup is successful.

Table 2. Metrics to Add for One-time Report Setup

In addition to the metrics defined above, users must enter additional metrics that are calculated. For these metrics, follow the same process as above, then once information is entered in the Add Metric popup, click Create a Calculated Metric to enter the calculation.

Table 3. Calculated Metrics to Add for One-time Report Setup

Once each metric has been entered, the Fixed Route Performance Dashboard is ready to be used for Act 44 reporting.

Recurring Data Entry

Each month, data flows into the Fixed Route Performance Dashboard via the Avail system and via manual entry. Of the manually entered data, some is completely external to the Avail system, and other data comes from within myAvail but must be manually copied into this dashboard. Once this data is entered, the dashboard calculates metrics needed for Act 44 reporting.

Table 4. Monthly Data Entry Categories

Frequently Used Reports

In this section, you’ll find information about the most frequently used reports in Business Intelligence. This will help you understand some possible ways to use the tools in myAvail for data gathering and operational improvements. For more detail and an extensive description of these and all BI reports and dashboards, please the following sections in Avail’s Help Center:
Operations > Operations Business Intelligence
Planning & Scheduling > Planning & Scheduling Business Intelligence

Schedule Health Report

The Schedule Health Report provides information by route about the portion of scheduled service that was not recorded, which the report displays as a percentage of the total service. This report is used to identify routes that have the most missed stops, timepoints, and trips. It’s important to monitor schedule health to ensure that service is being performed as scheduled, and that you’re capturing data from the service that is being provided.

The report displays three agency-wide KPIs at the top:

• Stops: Indicates the number of incomplete stop segments, total scheduled stop segments, and the percentage of missed stop segments (Incomplete/Scheduled). The benchmark or acceptance percentage level is less than 5%.
• Timepoints: Indicates the number of incomplete timepoint segments, total scheduled timepoint segments, and the percentage of missed timepoint segments (Incomplete/Scheduled). The benchmark or acceptance percentage level is less than 5%.
• Trips: Indicates the number of incomplete trip segments, total scheduled trip segments, and the percentage of missed trip segments (Incomplete/Scheduled). The benchmark or acceptance percentage level is less than 5%.

Data Sources and Validation

Data for the Schedule Health Report comes from comparing scheduled stop segments to captured stop segments. Thus, it combines schedule data with operational data generated by the vehicle. If a scheduled segment was not captured, it will show as missed. Adjustments do not affect the data in the Schedule Health Report; a scheduled segment that was not captured will show as missed regardless of whether an adjustment was entered later. A high percentage of missed service can occur for a wide variety of reasons and affects various statistics including route utilization.

After identifying routes with a high missing service percentage, it is critical to investigate and determine why they are occurring. Reasons could range from operational (e.g. driver takes wrong turn), to schedule data (e.g. triggerbox too small), to hardware (e.g. bad GPS). When trying to assess whether missed data was due to operational, schedule data, or hardware reasons, evaluate similar data from different time spans to identify patterns. Rewatch the service in Replay. And when learning how to use this tool for the first time, reach out to your Avail FAST representative for guidance.

Each time a new schedule is published, this report should be used to evaluate the schedule. Users should pay close attention to routes that have changed to identify possible problems with their schedule data.

Use for Reporting

The Schedule Health Report is not used for formal state/federal reporting. Rather, it is an important internal tool used to evaluate and improve an agency’s operations as well as the agency’s successful utilization of the Avail system.

Trip Running Times

This report displays the scheduled running times for trips, their actual average running times, the minimum and maximum running times, and actual speed. This report is used to identify trips that have actual running times that differ greatly from the scheduled running times or vary widely between the minimum and maximum times. Identifying routes with large differences can help target efforts to improve scheduling and on-time performance.

Running times are collected from the vehicle drive times within stop, timepoint, and trip segments. The time between departing a stop to arriving at the next stop is calculated as drive time. Running times compare the scheduled drive time vs. the actual drive time. The data can be sorted and viewed by the average, minimum, and maximum times.

Data Sources and Validation

Data for the Trip Running Times report comes from comparing scheduled times to actual times. Thus it relies on both schedule data and operational data. In BI, all levels of the report depend on completed segments. The trip level requires the first and last stop-to-stop segment of the trip be completed. When you drill down from the trip level to the timepoint level, consecutive timepoints must be completed. Drilling down again to the stop-to-stop segments, only completed segments have running times. Hardware or operational issues can cause gaps in the data.

Use for Reporting

The Trip Running Times report is not used for state/federal reporting. It is a useful internal report, particularly for the planning and scheduling team. The agency should constantly be looking at their running times performances and try to implement improvements or changes with each new schedule bid.

On-time Analysis (by Departure/Arrival)

The On-time Analysis by Departure report provides an analysis of the departure times for a specified date range. This report can be used to identify factors that cause unacceptable on-time performance. Departure time variance is recorded at each stop and is calculated using the following information:

• Depart Time Actual: Vehicle departure times based on stop reports sent by the vehicles.
• Depart Time Schedule: Scheduled departure times.

The On-time Performance by Arrival reports follow similar calculations as above except that vehicle arrival times rather than departure times are used in the evaluations.

Data Sources and Validation

On time performance is measured at the departure of a scheduled timepoint stop. The vehicle generates a stop report with the actual departure time, and that time is compared to the scheduled time to create the minutes of deviations from the schedule. In the vehicle, operators are presented with prompts to assist them with being on time. If operators arrive to a timepoint early, the screen displays a prompt to “Wait 2 minutes” and two minutes later displays “Time to depart.” If operators are late, the screen displays how late they are.

This can be validated by reviewing in Replay or measured independently from the system by a route ride.

Use for Reporting

This report is commonly used for state and federal reporting. On time performance is an industry standard for tracking an agency’s performance. 

APC and Farebox Ridership

This report displays the APC and farebox reported ridership for a specified date range. This report is used to investigate the following:

• Differences between APC and Farebox ridership counts. (Recall that differences are normal and expected: APCs measure boards and alights, and farebox ridership measures fares.)
• Trends in ridership by time of day, time of year, or service level.
• Trends in ridership by block, run, trip, or stop.
• APC counting irregularities.

Report data includes:

• Ridership: Displays data from the designated ridership source, which is configurable.
• Farebox Valuation: Displays dollar values for the ridership.
• APC: Displays Automatic Passenger Counts.
• Non-Ridership: Displays fare types not categorized as ridership.
• Farebox vs. APC: Displays both farebox and APC boards.

Note: If your property uses only one method for collecting ridership values (defined by route, in Ridership Source), the ridership and farebox values will be the same.

Data Sources and Validation

APC data is generated from the boards and alights that occur on the vehicles. While the driver is logged in, APC data will be generated with stop reports or if a board or alight occurs outside of a stop location, an APC report is generated. The generated data will be held in the holding tank until it can go through exceptions processing and be released for reporting.

For most Pennsylvania agencies, ridership comes from a GFI farebox or the Avail MDT fare screens. This data is generated from a ticket, token, pass, or from the driver pressing a button on the screen. GFI data is captured on the vehicles and moved to the holding tank after the vehicle has been probed. Avail MDT fare screen data is sent to the holding tank in real time after the stop report occurs.

APC counts are validated manually with a route ride or an examination of video footage, not by comparison with farebox ridership. The InfoDev APC manufacturer warrants the accuracy of the APC counts at 95% or within a 5% variance/difference after more than 900 boards and 900 alights. If the numbers go beyond this threshold for a particular vehicle, then the agency’s maintenance staff should troubleshoot and resolve vehicle APC issues.

APC data should be validated on a weekly basis by comparing the boards to the alights at the vehicle level. If an agency has a fare collection system, the ridership numbers should be compared to the APC boards as a secondary source. Please note that these numbers will never match. It is common for the two data sources to have up to a 25% difference. The appropriate use of this comparison is to understand your agency’s average difference between values, and then evaluate if any specific vehicles are outside of the norm (which may point to an APC or farebox issue).  

Use for Reporting

Farebox data is frequently used for reporting at the state and federal level. APC data is not; APC data is primarily used for operational improvements. There is a nuanced exception for agencies whose APCs have been NTD certified. For those agencies, APCs can be used to automatically calculate Passenger Miles and Average Passenger Trip Length for NTD. However farebox ridership is still the preferred ridership metric, and APC data is not used for Act 44 reporting.

NTD Summary Miles and Hours

NTD reporting includes common transit metrics that the FTA requires urban transit agencies to submit every year or every three years depending on fleet size. This report helps summarize the service supplied and service used by the agency. These deviations are populated through the System Adjustments process, where users can enter additions or subtractions to the scheduled service. Metrics include Scheduled Miles and Hours, Actual Miles and Hours, Unlinked Passenger Trips, and Passenger Miles.

Data Sources and Validation

The scheduled miles and hours values come directly from the scheduling package. The Actual miles and hours come from the scheduled service plus or minus any data that is added by entering system adjustments. Users enter system adjustments when there are deviations in service (missed trip, vehicle breakdown, additional tripper service, etc.).

Unlinked passenger trips come from the ridership source setup in the system. This is typically GFI or Avail fare screens.

Passenger miles are populated from the onboard count multiplied by the scheduled distance between stops.

Use for Reporting

This report is an important data source for NTD mile and hour reporting and should be submitted as required by NTD.

Vehicle Mileage (Odometer)

Avail’s in-vehicle system can track mileage via J1939 or GPS. Where available, Avail will tie into the J1939 engine computer to pull an elapsed mileage value. On vehicles where J1939 is not available, the system will default to use GPS to calculate mileage. This mileage is captured in the system and should only be used for preventative maintenance. Note that this differs from NTD actual miles, which are calculated by an adjustment to scheduled miles. See section 4.2.

Data Sources and Validation

This data can be validated against the elapsed mileage on a hubometer or tracked distance on a GIS mapping tool. The total elapsed mileage should be close to the scheduled miles the vehicle traveled, but they will not match due to detours, deviations, maintenance miles, etc. Each agency has its own typical range of deviation between the two values, depending on the type of service area and operations. Rather than looking at the deviation as a standalone number, agencies should become familiar with their deviation over time. If the deviation becomes significantly larger after publishing a new schedule, additional investigation is needed. This data should be reviewed and validated with every major schedule publish. It can point to areas in the schedule where stop to stop distances might be incorrect.

Use for Reporting

Vehicle mileage should not be used for Federal or State reporting. Actual mileage data should be drawn from the NTD report where the system utilizes the scheduled miles plus or minus any adjustments.

Data Process for FRITS Implementation

Throughout a FRITS implementation, there are steps the project team and agency will take to ensure data quality and correctness. Each is described in detail in the sections below and summarized in the final section.

Data Discovery

When an agency’s FRITS implementation is about to begin, Avail will work with the agency to learn about their data needs. The project team will work to understand:

• What the agency is currently reporting, and how do they calculate those metrics?
• Which KPIs are important to the agency in making operational decisions and which are used in self-evaluation? How are these KPIs measured and validated?
• What areas does the agency hope to improve in the coming year?

While each agency has standard reports and KPIs, most also have specific metrics that they regularly review and use for decision-making. The more Avail understands about these data needs, the better the project team can guide the agency in using the Avail product to meet the needs. An overview of these important data categories will be captured in their Reassessment Report.

Schedule Data and Validation

Early in an agency’s FRITS implementation, it’s essential for the agency to develop their schedule data. This data captures the actual service that is planned for a certain timespan. The schedule data required by a scheduling application and the Avail system may be more detailed than what an agency has historically used to perform service.

Specifically, the transit schedule must include the following data for it to be entered and maintained in schedule data software:

• Service Level Definitions and Holiday Schedules
• Driver Paddles and Block to Run Mapping
• Route, Trip, Direction, Headsign Code information
• Route Trace, Route Patterns, Stops orders, Stop to Stop time and distances

Baseline Schedule Data Validation

This important step has two separate processes and responsibilities. It must be completed before pilot.

First, the agency must validate the data that has been entered into their scheduling application. Depending on which application is being used, this process may differ. Generally, it involves reviewing driver paddles and timetables to confirm that they give a correct representation of the planned service. During this process, the schedule data is exported and delivered to Avail.

Second, Avail must validate that the schedule data is complete and able to be used in the Avail system. This involves a series of data checks to confirm that the file can be imported and other checks to ensure completeness. It also involves work within myAvail to build out trigger boxes, announcements, etc. Avail then performs an internal route validation using a bus simulator tool to perform service, and items like announcements, headsigns, and internal LED signs can be observed and confirmed.

Once the agency and Avail have both validated the schedule data, the pilot can begin.

Ongoing Data Assessments

Data assessment is an ongoing process throughout the implementation project. It includes:

• Data assessment meetings, in which the agency and project team (generally FAST representative and/or Systems Engineer) review data that is being produced by vehicles in service and reported in BI. This gives the agency an opportunity to ask questions, and it also begins the process of instructing the agency on how their reporting and KPI needs will be met by the Avail system. Finally, it serves as a time for the agency to validate the information being produced by the system. If a certain parameter seems off, the Avail representative can support the agency in understanding whether there is an issue with the system, or whether the system is accurately measuring a service that was previously misunderstood.
• Schedule data work, which requires the agency to make changes to their schedule data if needed for changes in service and/or refinement of data. Schedule data should be continuously improved by the agency, including throughout the implementation.
• Onsite route validation, which requires a representative from the agency and someone from Avail to ride a portion of the agency’s service together, observing signage, stop announcements, and other schedule data details. This visit will result in refinements to schedule data, triggerboxes, announcements, etc. Additionally, manual counts are taken and compared to APC counts to evaluate accuracy.

Final Data Assessment

After rollout is complete, Avail and the agency will have a final data assessment meeting. During this meeting, Avail will organize some of the agency’s data into a typical FAST report. This format will enable the agency to review their data to see if it indicates areas of operational improvement. Importantly, by the end of this meeting, the agency should understand both how their data will be used for reporting, and how it can be used to inform their operations.

Ongoing Daily Maintenance

Data maintenance is never over. An agency must continue to update schedule data and perform other maintenance activities to maintain accuracy of data for reporting and operations. These activities are detailed in Avail’s Standard Operating Procedures and include:

• Daily processing of exceptions.
• Daily entry and maintenance of adjustments.
• Changes to schedule data every major schedule change.
• Review of schedule health periodically and after every change.
• Regular review of APC health and on-time performance.

Table 5. DataPoint Reports, Sources, and Timing

Table 6. Business Intelligence – Operations Tab Reports, Sources, and Timing

Table 7. Business Intelligence – Planning Tab Reports, Sources, and Timing

Table 8. Business Intelligence – Maintenance Tab Reports, Sources, and Timing

Table 9. Business Intelligence – Statistics Tab Reports, Sources, and Timing