Smart City Part III

A Deep Dive into Smart City: Bus Location Use-Case

By Tamanna Chawla Chopra

In part two of our three-part look at the Smart City, we examined the importance of geo-mapping and explained a bit of how the many obstacles posed by a dense, urban environment can be overcome. In this final post, I’d like to think about sensors, the basic building blocks of Smart Anything, and about the information they collect and the data that they generate. Sensors already deployed around the world have been transmitting reams of data for some time now. This is a component of Big Data, a whole separate topic of discussion. Just collecting data that sensor generation does not make something “smart.” To clear the higher ‘smart’ bar, it is not enough for data simply to exist; smart data needs to be actionable.  To demonstrate how this works in practice, let’s examine a real world use case deployed by Microshare: Smart City Bus Tracking application.

In partnership with a major American city and one of the world’s largest telecom firms, we installed sensors in buses that transmit location data. This data is collected by gateways (antennas) installed at multiple locations around the city and then sent over the wire such that it can be shared and used by different applications for various tasks. For example, in this case we are calculating the real time ETA for the next bus approaching a bus stop. Importantly, to ensure long battery life and flawless execution in a dense urban area, we rely on LoRaWan technology rather than WiFi or another more expensive, less reliable networking solution.

There are three things must coexist to make this possible:

  1. The sensors on buses transmit location data to gateways every few seconds.
  2. The gateways collect this sensor data and relay it over the wire to the appropriate service provider – in this case our major telecom partner.
  3. Finally, a data application that tags and assesses the data, leveraging it to forecast real time locations and calculate ETAs for the buses.

While the first step is to obtain the sensor location data and place all those location markers on a map (google maps), making this real time location data more useful requires doing some calculations. Let’s say there is an inner city bus service with five buses numbered 1 through 5. These buses run on a specific loop with 10 stops in each. We receive location data for these buses using sensors and we pinpoint their locations on a  map. But the goal is to give the user the real time ETA for the next bus approaching a user selected bus stop.

Here’s where it gets technical. We now have data for all the buses mapped by bus number to their on-board sensors (named Buses Info). We also have latitude and longitude information for  all the bus stops (named Bus Stops Info). So we need to create the following

three associative key-value pair (dictionary) objects to store data for our calculations.

  1. BusStopsBusesDictObj: For mapping bus stops to real time buses locations
  2. BusStopsWaitTimeDictObj: For mapping bus stops to the wait time of the buses at those bus stops
  3. BusStopsRealTimeDictObj: For mapping bus stops to  the real time ETA for travel between all those bus stops

At Microshare™, we have developed robots that can be triggered to start processing by events. This might be the arrival of a new data record entry, or they could be set to begin automatically at pre-specified time intervals and frequencies.

The Microshare robots process, package and assemble the data such that the user gets useful data in return for their request. The processing can involve simple to complex calculations, writing new records, or reading existing records. We then apply customized rules i that are used for data governance (ownership, privacy, sharing and managing of data).

Each time new sensor data comes in, a robot (let’s name it the Mapping Bus Stops Buses Robot) gets triggered. This robot looks up information for the bus that the sensor data belongs to and compares its new location data to all the bus stops locations (coming from Bus Stops Info). If the bus is very close to a bus stop, it updates the BusStopsBusesDictObj dictionary object to map the bus number to its closest bus stop. This process is independently and automatically triggered by arrival of any new sensor data and the mapping is done in real time.

The BusStopsWaitTimeDictObj dictionary object contains a mapping of wait times for the buses at different bus stops. This is something that does need not happen in real time and could be a one time task. We will need this information later in order to get better approximation of the ETA arrival times of the buses at the stops.

The BusStopsRealTimeDictObj dictionary object contains a mapping of all the bus stops and the time it will currently take to travel between these stops. This real time data comes from the google maps distance matrix api using traffic data time estimations. This information is kept updated independently (you can set up the frequency for when to update it). In fact, in Microshare there is a “Scheduler Robot” that is triggered on its own at predetermined time interval. Isn’t that cool!!

Note the  difference between how the update to the BusStopsBusesDictObj dictionary object is triggered each time new sensor data arrives versus how the BusStopsRealTimeDictObj dictionary object gets triggered automatically at the frequency you decide.

If you’ve gotten this far, give yourself a pat on the back!! We now have all systems ready to fire – the three dictionary objects, the Bus Stops and the Buses Info. When the user chooses a bus stop, follow these steps to get the closest bus number and ETA time for an approaching bus for the chosen bus stop:

  1. Lookup the BusStopsBusesDictObj dictionary object for the chosen bus stop.
  2. Let’s say the bus stop was found at index 6 of the BusStopsBusesDictObj dictionary object. Now start looking up  each descending index (starting from index 5) of the BusStopsBusesDictObj dictionary object for buses at any of these indexes (5,4,3,2,1 and then 0 – if no bus so far even at index 0 start from the highest index 9,8,7…and so on). As soon as you find one, get its  bus number and its current bus stop from the BusStopsBusesDictObj dictionary object.
  3. Now you have  the bus stop for  the approaching bus and its bus number. Now  add all the real times in BusStopsRealTimeDictObj starting from the bus stop at which the closest approaching bus was found and ending at the bus stop chosen by the user. Let’s say you found the bus number 2 at bus stop 3. Look in the BusStopsRealTimeDictObj dictionary object and add all the real times of bus stop 3 (time from bus stop 3 to bus stop 4) , and bus stop 4 (time from bus stop 4 to bus stop 5).
  4. Additionally,  lookup the BusStopsWaitTimeDictObj dictionary object and add all the stop wait times for the bus stop the closest approaching bus is found at to the chosen bus stop, that is bus stops 3 and 4.
  5. Sum the total real time and the total stops wait time to get  your real time ETA for  the next approaching bus. Here you go, you got it!

Tamanna Chawla Chopra is a Software Engineer at Microshare.