# Intelligent, machine assisted train supervision through Ridership pattern collection via  anonymized RF metadata collection in conjunction with agent-based modeling of travel patterns

Even when the signaling is fully computerized, and the rolling stock is fully modernized - incidents will occur that cause delays. The existing communications infrastructure can be leveraged to provide remarkably precise data on the destinations of customers, and computer modeling can then be applied to ensure service is rerouted and supplemented


In short, we propose to use cellular, bluetooth and/or wifi sensors to detect individual mobile devices within the system. Mobile devices have a number of digital radios inside them, each with a unique identifier. This can be an IMEI or a MAC address. The identity of that device is anonymized, and it’s presence is recorded in each station it passes through - using the existing Transit Wireless infrastructure - until it is no longer detected within the system.

The identity of the IMEI or MAC address can be passed through a cryptographic hash function so that it can be unique to the device, but not identifiable in reverse. These functions are commonly used in cryptography and password-storage to ensure that, for example, a website login has a database to compare your entered password with, but that database doesn’t actually contain your password.

For an added layer of anonymization, the hash function can be “salted” with a variation of the current date, so that the same hashed IMEI is not identifiable day-to-day, in case there are privacy concerns with that.

Such anonymization would not interfere with data collection. We are not proposing to build a database of individual’s travel habits. Instead, we propose to record aggregate entry point/exit point/time data such that there is deep, robust statistical data on, for example, how many customers at times square at 3:30pm on a Friday are trying to go to Morningside heights.

While not all trips will be recorded, as not every passenger has a mobile device - the overwhelming majority do.

Further, the number of devices detected within a given station complex can give a clue, compared to historical averages, if platforms are overcrowded. By examining the number of connects when a train pulls in we can determine if trains are overcrowded.

Next, based on the data on how the system is being used, an agent based modeling system can be set up to model every passenger and train in the system. What seems like a daunting challenge is actually fairly straightforward. Agent-Based modeling (ABM) solutions use digital “agents” that are programmed with certain traits and interact with other elements in a computer model. As a notable example, the 2015 revival of SimCity used agent based modeling to actually have virtual citizens choose a route to commute to work in a virtual city.

We want to be abundantly clear at this point that we are not suggesting the use of SimCity to dispatch trains.

However - that underlying technology can be applied to something of a “Service Disruption Simulator”. Based on the statistical entry-exit ridership data we’ve gathered, we can now based on time of day, day of week and month of year, create a field of agents within the software that would represent average ridership and destination at a given time. Since the schedules and terminals of the individual trains are known, we can model them as agents too.

With all this programmed - we can model what will happen, if say, the 7th ave tracks are completely out of service at 14 st during a morning rush.

A properly programmed agent-based-modeling solution, running on appropriate hardware, could quite rapidly run multiple scenarios of rerouting, and could determine, statistically, how to get the most passengers to their destinations as quickly as possible.

This could be used to provide more granular service alerts to passengers, and to dispatch trains in the most effective way.