Another Flowchart: GTFS-RT creates arrival/departure times, travel times, headways and dwell times. These calculate performance metrics: schedule adherence, pax wait times and pax travel times with input from archive data and pax arrival rates, and GTFS. All of this produces through the API info to MBTA mgmt and MBTA customers

Sample output shows real-time performance as well as last five days; headways at Park St. Station towards Harvard Station; and Travel Time from Park St. Station to Harvard Station.

Thought about predictions of what performance will be in 20 or 30 minutes - that is a little harder to do, but it is a goal

Question: have you looked at connections? Going from Kendall to Kenmore - how much time do I spend at Park Street? Or maybe an express bus to the suburbs - even a 3-minute delay on a train might make me miss a bus. London does this - you tap on and tap off, so they know the journey time for every journey. The T would like to know an entire journey time for an individual. Could also measure how many connections were missed.

Question: How to deal with bus bunching? Transit Master allows dispatchers to see where all the buses are, but each dispatcher is managing 250 buses. Need to get the info into the field to someone who is managing a lot less buses.

The MBTA has 1,000 buses operating at rush-hour with 4 dispatchers

Question: platform with back-end for managers in the field and then on the front side for public accountability. Will this replace the scorecard? Will they be able to drill down into the details? It is going to augment or replace parts of the scorecard.

Question: What is the conversation with dispatchers to improve their role in this chain? Dispatchers handle too much right now. Currently, the hierarchy of decisionmaking is not well-defined.

Question: When bunching, would you be able to let the driver know that there is bunching? You would have to add yet more hardware on all 1,000 buses.

Question: How close are we to autonomously-run trains? The T has discussed this. London has retrofitted a few lines for full automation. Because of safety, there is no room for error. If we had the funding, several lines could be automated. in the meantime, we need to have humans mimicking computers. Is the cost of automating trains increasing, and should we invest earlier? It is an expensive policy discussion.

Question: The way that bunching handled - have a hyper-screen that displays the whole system. Each on-the-ground staff person has a tablet in their quadrant to show if they need to deadhead someone back to the terminal.

Question: Is there a difference between schedule capacity and design capacity? Yes. The limitation of rail is the signal system. What is the capacity you are actually running - the T is more interested in this. During every rush hour, how close are we to design capacity? Is that a management element for discussion? At rush hour, most Green Line trains are at capacity.

Question: Handling scheduled events. For example, Red Sox game, Green Line is over capacity. Look at impact of special events - studied at Harvard. Peak hour starts 3 hrs before the game - 200 people every 15 minute before the game. Carrying an additional 12,000 people on the system before the game. Don't know if the T has ever calculated the numbers.

Ari OGood comment: we can analyze where the problems exist, but then have to work with communities to change streets where they exist.

Resilience: need greater recognition that walking is most resilient option. Facilities and operations should support this. Private transport providers can fill gaps when public options are struggling, have complementary roles. Climate change, emissions, materials- can there be system for rating using metrics.

OneBusAway includes a robust, secure, scalable back end that accepts, stores, archives and interprets real-time vehicle location data in combination with transit schedules and other related data.

OneBusAway supports many interfaces:

2 desktop web applications

1 mobile web application

several native mobile applications

2 SMS interfaces (TextMarks and MobileCommons)

2 IVR interfaces (hardware vs Twilio)

OneBusAway offers a suite of application programming interfaces (APIs) that facilitate the support the development of a wide range of third party applications, based on actual vehicle locations and on scheduled and predicted arrival times.

Currently OneBusAway expects Automated Vehicle Location (AVL) software to already be in place. There is no open source on-board bus hardware available, but it should be relatively easy to create. Just follow this specification . The BusTime installation performs its own AVL based on this specification.