Key Concepts and Calculations

The myAvail's CAD/AVL System section reviews important basic concepts and approaches that guide the development and continuing improvement of myAvail. It emphasizes the concept of position-based security that myAvail uses. This section also provides an overview of the available features presented in the context of an example workflow that is broken out into Back Office, Public Facing, and In-Vehicle systems. 

Key Concepts and Calculations

This section explains key concepts such as what is a trigger box, best practices for creating trigger boxes, how myAvail counts riders and attributes them to a stop, how myAvail determines whether a departure is late, and how myAvail estimates future departure times.

Vehicle Location Report Triggers

AVL reports include in the following:

• Location (Latitude/Longitude)
• Date time
• Direction of travel
• Speed
• Vehicle ID
• Operator ID
• Route
• Run
• Trip

The following events trigger AVL reports:

• Vehicle ignition changes state (on to off or off to on).
• An operator logs on to a specific run or block.
• A maximum time interval has elapsed since the last communication (default 60 seconds).

• A vehicle has traveled a maximum distance since the last communication (default ¼ mile).
• A vehicle enters a trigger box.
• A vehicle exits a trigger box.
• An operator sends a message to Dispatch, including replies or acknowledgement of dispatcher messages.
• An operator puts a vehicle in “Manual Announcement,” “Out of Service,” or “Driver Off” modes.
• An operator logs off.
• When cellular communications are temporarily lost, the in-vehicle system stores AVL reports for the configurable keep alive time. If the cellular connection is re-established before the keep alive duration ends, the in-vehicle system sends all stored reports to the backend system.

For more information about the in-vehicle systems, consult the In-Vehicle section.

An Overview of Trigger Boxes and Considerations When Creating Them

This section discusses the best practices for creating and modifying trigger boxes. For information about the mechanics of creating trigger boxes, please read the Geographic Tools chapter in the myAvail User Guide.

What is a trigger box? A trigger box are virtual boundaries around stops that users define with a graphical tool in myAvail. myAvail distributes trigger box information to vehicles with the schedule data.

A trigger box is myAvail’s implementation of a geo-fence. The IVU uses GPS data to determine whether the vehicle has entered a trigger box. However, the system must determine whether a trigger box is valid for the active trip using the order of stops and which stops have been completed for this trip. Starting with the first stop that has not been serviced for this trip the system checks if it is in the stop, if not it then checks the remaining stops in the trip. If the system detects it is in a stop for the current trip that is past any un-serviced stops then those un-serviced stops are removed from the stop search as they are if serviced for this trip. Stops that are part of a different trip are ignored. When routes intersect, vehicles on one route will ignore the other route’s stop. Where routes use the same street for the inbound and out bound trips, vehicles traveling in one direction will ignore stops for the opposite direction.

After the system confirms that it is a valid stop on this trip, it performs actions when the vehicle enters the trigger box, such as changing the destination sign and making announcements. Additionally, the system might perform other actions when the vehicle exits the trigger box, such as relaying passenger boards and alights, and schedule adherence information to myAvail’s backend. In the final trigger box for a trip, the vehicle sends a “trip change” record to the backend system.

Unless the trip is the vehicle’s last trip of the day, the last stop of one trip is the first stop of the next trip. The next trip can be the next revenue trip for this operator and vehicle, the first trip of the next operator’s run for this block, or a deadhead trip to a new location. However, there will be two trigger boxes for this stop, one associated with the first trip and one associated with the second trip. The size and location of these boxes must be the same, but they should have different actions associated with them. For example, an announcement action should not be set on both trigger boxes, or the announcement will be made twice. Set an announcement action on the last trigger box of a trip, but do not set an announcement action for the first trigger box of a trip to avoid a double announcement.

For more information about Trigger Boxes, see Fixed Route Schedule Data Input/Modification Process.

The direction the vehicle enters the trigger box is the “Heading” on the Trigger Box entry tab of the Geographic Tools tab, which Avail also refers to as the “Angle of Entry.” This field is optional. For example, a vehicle is travelling from east to west on the road (i.e., its heading is due west), as it enters, a trigger box has an angle of entry of 270 degrees. The angle of entry in myAvail does not have to match the vehicles angle of entry exactly. The system has a 15 degree margin of error on both sides of the value you enter. Therefore, for 270 degrees, myAvail accepts actual entry angles ranging between 255 and 285 degrees. The trigger box entry function has a compass display to help set this value.

The field has a drop-down list providing a selection of 16 values evenly separated by 22.5° as displayed on the compass example above.

Guidelines for Drawing Trigger Boxes

The best case is that the trigger boxes do not overlap:

However, while it is not preferred, trigger boxes can overlap if each trigger box contains only one stop. Riders who board in either trigger box are usually attributed to the first stop.

If the vehicle passes the stop to turn around or for a layover, make sure the vehicle does NOT leave the trigger box until ready to continue the trip.

This is GOOD.

These are BAD. Vehicle leaves the trigger box to turn around at end of trip.

Vehicle leaves, and reenters trigger box.

No trigger box should ever encompass two or more stops. These will fail.

An Overview of How Ridership Is Attributed to Block/Run/Route/Trips/Stops

The IVU plays a central role in ridership processing. The APC unit records passenger counts when the IVU tells the APC that the doors are open, and the IVU determines when counts are downloaded and cleared from the APC. Additionally, the IVU assigns counts of boards and alights to specific stops by using a combination of data points including door closure, vehicle movement, and whether the vehicle is in a trigger box. The IVU tracks all the boards and alights for each trip to calculate the number of riders that ride-through from one trip to the next. It calculates the ride-throughs on a trip-by-trip basis to reduce the accumulation of APC errors for the on-board count.

Ridership can be either qualified or unqualified. Qualified ridership occurs when the block, run, route, and trip are known. If any of these values are unknown, the ridership is unqualified.

Unqualified ridership occurs when the vehicle ignition is on, the initial log on registers with myAvail’s servers, and one of the following conditions exist:

• The operator puts the vehicle “Out of Service.”
• The operator puts the vehicle in “Manual Mode.”
• The operator has logged off.
• The vehicle requested a schedule file, but it has not been downloaded. Collecting unqualified ridership is optional.

Unqualified ridership will generate exceptions when myAvail processes the counts. A myAvail user will need to specify all missing information for the unqualified ridership, or myAvail will report it as “undefined.”

The system classifies flag downs (boards between stops) as qualified ridership when it knows the Block, Run, Route, and Trip. How the system processes qualified boards and alights depends on whether the action occurs within a stop’s trigger box.

When the vehicle stops outside a valid trigger box for the current trip, the door opens, and the system registers at least one board or alight upon resumption of movement, the vehicle sends a special record to the backend. This record contains the number of boards and alights, the event's latitude and longitude, and the previous stop’s name.

When boards and alights occur within a stop’s trigger box, the IVU associates these events with that stop. An exception to this rule occurs when the stop at the end of one trip is also the first stop of the next trip, which is the typical arrangement. In this situation, the system attributes alights to the trip that is ending and boards to the trip that is beginning.

The system also performs the calculations for ride-through passengers and the onboard count, as shown in the example below.

The system processes stops during a trip in a straight-forward manner. It sends the counts of boards and alights to myAvail, accumulates the boards and alights for the trip, updates the on-board value and clears the stop counts in the APC. However, the calculation at the end of a trip is more complex.

myAvail reports all collected boards and alights with the associated block, run, route, trip and stop where these attributes can be determined with a high degree of certainty. myAvail applies logic that calculates ride-through passengers and the on-board count. If you need to modify this configuration, please contact your FAST representative.

The following scenario illustrates the ride-through and on-board calculations that Avail recommends:

Suppose a vehicle runs Route A outbound then inbound all day. This example starts with a Route A 10:00 AM outbound trip and follows it through the 10:30 AM inbound and the start of the 11:00 AM outbound trip.

For simplicity, the vehicle leaves the first stop with:

0 - Ride-through passengers

0 - Onboard

Over several stops on the 10:00 AM outbound trip before the final stop there are:

7 - Boards

5 - Alights

At the final stop of the 10:00 AM outbound trip, which is also the first stop of the 10:30 AM inbound trip, there are:

3 - Boards

1 - Alight

The system creates two stop reports for this stop. First, it creates the report for the 10:00 AM outbound trip that records 1 alight and zero boards. Then, it creates the report for the 10:30 AM outbound trip that records 0 alights and the 3 boards. Ride-through counts are only calculated for the 10:30 AM trip. The onboard count for the final stop of the outbound trip equals the difference between the outbound boards and alights that occurred during the trip (7 - 5 = 2). Using these calculations, the report for the final stop of the 10:00 AM outbound trip shows the following counts:

0 - Boards

0 - Alight

N/A - Ride-through

2 - Onboard

At the same time, the system creates a second stop report for the same stop, but for the 10:30 AM inbound trip. For this stop report, the system sets the alights to 0 and the boards to 3.

The ride-through count, which can never be negative, equals the on-board count for the previous trip (2) minus the alights from this stop (1) plus the ride-through from the previous trip (o): 2 - 1 + 0 = 1.

The onboard count equals the boards for this stop (3) plus the ride-through passenger (1): 3 + 1 = 4. Therefore, the report for the first stop of the inbound 10:30 AM trip shows the following counts:

3 - Boards

0 - Alight

0 - Ride-through Passenger

4 - Onboard

Over several stops on the 10:30 AM inbound trip, but before the final stop, there are the following events:

10 - Boards

7 - Alights

The boards number (10) includes the 3 riders that boarded at the inbound trip’s first stop.

At the final stop of the 10:30 AM inbound trip, which is also the first stop of the 11:00 AM outbound trip, there are the following events:

2 - Boards

0 - Alight

Again, the system creates two stop reports. It creates a stop report for the 10:30 AM inbound trip with 0 alights and 0 boards. The 2 boards are recorded for the next trip. Ride-through counts are calculated only for the 11:00 AM trip. The onboard count is the difference between the boards and alights that occurred on the 10:30 AM inbound trip plus the ride-through passenger (10 - 7 + 1 = 4). Consequently, the report shows:

0 - Boards

0 - Alight

N/A - Ride-through

4 - Onboard

At the same time, the system creates a second stop report for the same stop, but for the 11:00 AM outbound trip. For this stop report, the system sets the alights to 0 and the boards to 2.

The ride-through count equals the board count for the previous trip minus the alights from that trip (10 - 7 = 3).

The onboard count is the boards from this stop plus the ride-through passenger (2 + 3 = 5) therefore the report shows:

2 - Boards

0 - Alight

3 - Ride-through Passenger

5 - Onboard*

* The reports indicate that the vehicle arrived with 4 onboard, had 2 more passengers board, and there were no alights. These numbers suggest that there are 6 onboard. However, Avail will indicate that the vehicle leaves the stop with only 5 onboard rather than 6. The system does not include the one ride-through passenger from the 10:00 AM trip past the 10:30 AM trip to prevent APC errors from propagating beyond one trip.

How is Dwell Time Calculated? 

Dwell time is the duration that a vehicle is at a stop. It includes both the time passengers spend boarding and alighting and the time the operator spends waiting for the scheduled departure time. The calculations for dwell time depend on a variety of conditions. To obtain all necessary information for these calculations, the in-vehicle system waits until the vehicle leaves the trigger box to calculate dwell time, and then reports it to the backend system.

The system collects the following information to calculate dwell time:

• Trigger box entry time.
• Each time the vehicle becomes stationary.
• Each time either door is opened.
• Each time either door is closed.
• Each time the vehicle moves after being stationary.
• Trigger box exit time.

The in-vehicle system uses the data to determine which of the following scenarios occurred and, therefore, how to calculate the dwell time.

Scenario 1

The vehicle does not stop within the stop’s trigger box. This scenario is common at stops that are not published timepoints and when there are no riders boarding and alighting. In this case, the dwell time is zero.

Scenario 2

The vehicle stops within the stop’s trigger box but does not open either door. This scenario is ambiguous because the vehicle can stop and start multiple times within the trigger box. The vehicle might be stopped at a traffic signal. In this case, Avail does not assume zero dwell time. Instead, the in-vehicle system uses the duration of the final stationary period in the trigger box for the dwell time and uses the end of that dwell time for the departure time.

Scenario 3

The vehicle stops within the stop’s trigger box and opens either door. This scenario is the most complex because the vehicle can stop and start and open and close the doors multiple times within the trigger box. In this case, the in-vehicle system calculates the dwell time as follows:

• The start of the dwell time occurs at the beginning of the first stationary period in which the operator opens either door. The operator opening the door for the first time tells the in-vehicle system which of multiple stationary periods to use for the beginning of the dwell time. However, the start time occurs when the vehicle stops moving rather than when the door opens.
• The end of the dwell time occurs the first time the vehicle begins moving after the operator closes the door for the final time in the trigger box. The operator closing the door for the last time tells the in-vehicle system which of multiple vehicle starts to use for the end of the dwell time. However, the end time occurs when the vehicle begins moving rather than when the door closes. Because the system uses the first movement after the final door close for the end of the dwell time, if the operator closes the door, moves the vehicle, and then stops but does not re-open the door, it does not extend the dwell time.

How is Vehicle Speed Evaluated? 

Avail examines vehicle speed to trigger two actions:

• Display an alert on the Operations Map display when vehicles are speeding.
• Trigger the Speeding Event.

For information about the contents of the AVL messages and what triggers the vehicle to send AVL information, see Vehicle Location Report Triggers.

NOTE: The processing for the Operations Map and the Speeding Event are independent functions. The Operations Map is a client-side process and the Event processing is a server-side process. They share the service that provides speed limit information and share some common parameters. However, there are other parameters that only the event processing uses.

How does the system alert dispatchers and others about speeding vehicles?

When the system determines that a vehicle is speeding, the vehicle’s icon on the Operations Map starts blinking. Speeding indicates that the previous AVL report shows one of the following conditions:

• If the system knows the speed limit for the vehicle’s location, the vehicle’s speed exceeds the speed limit plus a configurable percentage.
• If the system does not know the speed limit for the location, the vehicle’s speed exceeds a default value.

The icon continues to blink until the system processes an AVL record that determines the vehicle is no longer speeding.

A third-party service provides the speed limits.

What triggers the Speeding Event?

Much of the logic behind the function that generates the speeding event determines when NOT to generate an event. Consider a rural or an express route where the vehicle can travel a long distance without stopping or picking up riders. Unless this process is carefully managed, the system will generate many redundant speeding events, which clutters the system.

Consequently, the speeding function performs several tests before assessing vehicle speed:

• Is the speed test parameter enabled?
• Does the vehicle have a good communication status?
• Does the vehicle have a good GPS status?
• Is the vehicle traveling above the value in the minimum speed parameter?
  • Default is 25 MPH
• Has the vehicle traveled the minimum distance since the last event?
  • Default is 2640 feet
• Has the minimum amount of time elapsed since the last event?
  • Default is 15 minutes

If these tests all pass, the function compares the vehicle’s speed to the speed limit for that location plus a configurable percentage. If the third-party service that provides the speed limits does not provide a speed limit for the vehicle’s location, the function uses a default speed limit.

If the function determines that the vehicle is speeding, the system generates an event. By default, this event goes to event history for later reporting. Additionally, the system creates a message for the vehicle. However, vehicles can use this message only when its IVU software is at least version 3.2 and the vehicle’s DVR supports metadata tag requests from the Avail system.

Caching Speed Limit Data

Web API calls are pricey and Avail developers found a method to cache speed limit data to reduce the number of calls. The system includes this data in the RealtimeAVL object for the vehicle and being passed on to MyAvailServer.

To accomplish these savings, developers added new TransitAuthority tables to cache the speed limit data with our route and detour segments.

To use the cached speed limit data, developers changed the OffRoute logic in BWS. The system pulls the speed limit data from the database at the same time it requests the OffRoute status data on a vehicle. Additionally, developers added speed limit data to the RealtimeAvl object, which was already being passed onto MyAvailServer. The speed limit logic built into the MyAvail Silverlight client, and the MyAvailServer Speed Limit Manager are now using these new speed limit fields, instead of making their own 3^rd party web API calls.

Consequently, the speed limit code in the Operations tab no longer makes web API calls for speed limit data. Instead, it uses the new speed limit properties of the RealtimeAVL class.

Triggers that update the speed limit data in the database

• MyAvailServer: When a schedule publish occurs, it updates all route and detour segment points. Not just missing segments.
• GeoTools: When a route segment is updated in the active schedule, it updates route segment points only.
• MyAvailCoreWeb Detour: When a new detour is created or updated, it updates detour segment points only.

Determining speed limits for a latitude/longitude location

BWS retrieves speed limit data when it checks the vehicle for OffRoute status. The code searches route segment geometry based on the current block the vehicle is logged into. When it finds an intersecting segment, it drills down into the segment’s point locations, and finds the closest speed limit.

• If a vehicle is not logged in, the default speed limit is assigned to the vehicle.
• If a vehicle is determined to be OffRoute, the default speed limit is assigned to the vehicle.
• The default speed limit comes from the dbo.Config_Global (ID=4013, Name=’ Client Default Speed Limit’) table.

How to Calculate Public Estimated Departure Times

Avail uses the following algorithm to estimate real-time arrivals and departures for all public information sources.

• The Prediction Controller accesses the schedule data at the start of each day. These data include the planned time between each stop (a segment) on each trip. The software then keeps the planned time and actual time for each stop arrival and departure.
• Until a vehicle starts a block, the scheduled stop departure time is used as the next arrival/departure time for the stops on that block.
• After an operator enters the block number on the control head and starts the block, the Prediction Controller begins tracking the actual departure time of the vehicle at stops along the block. It estimates the arrival and departure times at the block level because it properly accounts for interlining and reliefs within the block.
• The system uses the end of the dwell time for the departure time. Exiting the trigger box prompts the in-vehicle system to calculate the dwell time and send a message to the backend identifying the stop. This message tells the Prediction Controller (PC) exactly where the vehicle is in the route without requiring any latitude/longitude calculations. Next, the PC calculates the arrivals and departures at all other stops in the block by adding the planned time for each segment between the current stop and the remaining stops.
• When a vehicle is running late, the system considers all layovers within the block, whether mid-trip or between trips, to be time that is available to get the vehicle back on schedule.
• The features of the algorithm are based on several basic premises:
  • Always attempt to error on the low side by displaying fewer minutes delayed than expected. Suppose a vehicle is shown to be departing in 10 minutes, but it actually departs in 5 minutes. To the customer, it appears that the vehicle left early. In fact, a trusting customer might have left the stop due to this information.
  • Never update the time so frequently that it wavers back and forth. This wavering has proven to be annoying on prior estimation prototypes. The amount of time the estimate must change before the system updates the time is a value that can be configured for your property.
  • As soon as the update satisfies the algorithm requirements, such as the one discussed above, the system presents the updated information to customer interfaces as soon as possible. As stated above, the estimations for a vehicle’s stops are recalculated with every stop report from the vehicle. This information is made available right away to all customer interfaces monitoring these stops.
• The accuracy of the departure estimation depends on having accurate stop locations and running times in the route schedule data. myAvail monitors the scheduled running times and compares them to historical running times and highlights areas where these don’t match and makes recommendations about adjusting the schedule. Accurate predictions depend on the accuracy of the schedule data.

Possible sources of error:

• myAvail’s Prediction Controller uses the stop to stop travel time between all stops. While the total running time between published timepoints on a route is usually accurate, the same care is not always applied distributing the running time across the intervening stops. If these times are inaccurate, there can be errors in the estimated departures for these stops.
• Accounting for frequent delays due to traffic or heavy ridership by padding the stop to stop run time will introduce errors in the departure times. The proper method is to add layover time when there is variability in the stop to stop running times. myAvail supports having layover time at all stops in the trip.
• Leaving the trigger box before intended. A common practice is for the vehicle to arrive at a stop, drop off all riders, then move off to park for a break or to await a relief operator. The vehicle then returns to the stop to board more riders, then continues the block. It is important that the vehicle does NOT leave the trigger box on the way to the waiting area or on the return to the stop.
• Missed trigger boxes. Missing the trigger box means the stop is not detected. This problem causes errors in future departure estimates until the vehicle departs a later stop and successfully triggers a stop report. myAvail includes reports to help identify frequently missed stops. Common reasons a trigger box is missed include:
  • The angle of entry to the trigger box is incorrect.
  • The trigger box is misplaced. This can happen when a stop is moved but the trigger box is not moved to be around the new stop location.

For more information on how to set trigger boxes, see An Overview of Trigger Boxes and Considerations When Creating Them.

How to Calculate Operations Tab Schedule Deviation/Adherence

The schedule deviation and adherence algorithm differs from the algorithm that produces the public departure and arrival estimates.

On one hand, as defined by regulation, schedule deviation and adherence reports use only vehicle departure times from published stops (timepoints). These reports describe the difference between scheduled and actual departures for completed events. These reports do not estimate future departures. myAvail calculates schedule deviations using stop departure records from the vehicles and displays them on the Status window of the Operations Tab. The departure time in a record is the end of a stop’s dwell time.

On the other hand, the public needs estimates for all stops that the system continually recalculates using departures from all stops - not just timepoints (See How to Calculate Public Estimated Departure Times). Additionally, these calculations produce estimates of future departures.

Because schedule deviations and public estimates are used and calculated differently, they often do not agree. There are many valid reasons why the Operations tab can say a vehicle is on time, but public information says it is late.

Critical Transfers

Critical transfers are a separate set of events. A critical transfer is one where an outgoing vehicle is the last transfer opportunity for a passenger that day. This determination is made by the daily schedule table. The system allows critical transfers to be handled with a higher level of urgency.

The amount of time an outgoing/destination vehicle should wait for a critical transfer is configurable using a new configuration table.

The system allows authorized users to define a list of individuals who the system notifies when a vehicle does not wait the prescribed period of time for a transfer using the existing alert scheme.

1. Critical transfer events have their own event ID and are not grouped under the Transfer in danger events. Denoted events have both critical and non-critical types.
   • • Transfer lookup Failed
     • Invalid Transfer Request
     • Transfer Warning No Vehicle on block (critical and non-critical)
     • Transfer Denied No Vehicle on route (critical and non-critical)
     • Transfer Denied (critical and non-critical)
     • Transfer Denied because of EA (critical and non-critical)
     • Transfer Non Acked (critical and non-critical)
     • Transfer Requested (critical and non-critical)
     • Vehicle did not hold as requested (critical and non-critical)
2. System determines whether a vehicle held for the time sent and assumes the transfer happened if the following if the sending bus arrived at the transfer stop (plus a buffer) before the receiving bus departed. In these cases, the system updates the status for transfers to be successful.
3. System generates an event when the following is true for both critical and non-critical.
   • • The Receiving bus departed before the departure time + hold time (different parameters for critical).
     • The sending bus didn't arrive at the stop before the departure time of the receiving bus.
4. In cases where the receiving bus departed before the sending bus (plus buffer), the system indicates the transfer was non-successful.
5. The configuration is in a cfg table, which includes the critical transfer parameters.