Supporting Safe Travel With Real-Time Occupancy
By: Elyse Wyatt
Tags: Software Development, Auckland, Case Study, Covid 19, Transport

In response to COVID-19, and the increasing need for passengers to make informed decisions about their safe travel, Auckland Transport and software vendor Propellerhead have introduced real-time occupancy levels into the official Auckland Transport travel planning app AT Mobile. Passengers can see occupancy levels on a bus or train at any given time.

After releasing the Live Occupancy feature in March, we’ve had interest from transport authorities from around the world. We’d like to share more around how Auckland Transport and Propellerhead have achieved this to help the global fight against COVID-19, and to provide info to other agencies who’d like to adopt similar measures.

This blog is from a whitepaper written by Propellerhead Technical Strategist Jan von Bargen, with support from Sophia Wong, Elyse Wyatt and Tammy Chee.

Auckland City as seen from Devonport. Photography by Chris McLennan.

Supporting Transport Across New Zealand’s Largest City

In Auckland, where 33.4% of New Zealand’s population lives, transport projects and services are run by Auckland Transport (AT). This council-controlled organisation of Auckland Council is responsible for all transport infrastructure (excluding state highways and railway tracks) and public transport. AT designs, builds and maintains roads, ferry wharves, cycleways and walkways; coordinates road safety and community transport initiatives; and it plans, coordinates and funds bus, train and ferry services.

Over the last six weeks and at the height of the COVID-19 epidemic here, the New Zealand government restricted travel to only essential movements, allowing vital services (like supermarkets, pharmacies, clinics, petrol stations, and lifeline utilities) to operate.

AT, like many other transport authorities around the world, is facing a unique challenge to continue to operate the public transport network during this crisis, and keeping its staff and passengers as safe as possible.

To help with this, AT introduced new maximum occupancy rules for public transport, asking passengers to retain 2 metres distance from each other. As passengers planned their journeys, however, it was impossible to tell if they’d be able to follow these guidelines upon boarding. It would also be difficult for drivers to note occupancy levels.

This provided an opportunity — AT began work on the Live Occupancy feature.

The Face of Real-Time Data: Command Centre

Auckland Transport’s occupancy data, particularly for buses, has been available for several years.

However, limitations on the extensibility of the used software meant that these figures have only been used for capacity planning — but not in real-time, and not made available to the public. Additionally, the raw numbers without the context, like available spaces, are not very useful; and the context hadn’t been readily accessible.

New software was built, named “Command Centre”, which allows operations and operators to monitor the public transport network in real-time (and historical), as well as publish arrival/departure predictions, changes to the network, and alerts to the public.

The Command Centre interface for operators.

Command Centre includes a real-time view of all public transport vehicles — and their occupancy.

As part of Command Centre, a new real-time event processing platform was developed — the “Datahub”. It ingests real-time data from various sensors across the network and translates the data into a common format that Command Centre, but also other consumers, can use.

AT Mobile, Auckland Transport’s official travel-planning app, consumes data from the Datahub, first for real-time arrival/departure predictions, and now, for occupancy data.

A user viewing AT Mobile.

Displaying occupancy data in AT Mobile has been discussed before. The challenge wasn’t a technical one — it was this question:

“What are users going to do with occupancy information that was generated ten stops before they board the bus? It would have changed significantly by the time the bus arrives.”

The arrival of COVID-19 made providing occupancy data to travellers more urgent — and at the same time, with significantly reduced user numbers, predicting future occupancy is slightly less relevant.

How Data Is Generated

Most passengers using public transport in Auckland use a smart-card based ticketing system called HOP. Developed by Thales, it allows passengers to load funds onto their HOP cards. The fare is deducted from the card when the customer “tags on/off” at the start and end of their journey.

A person tagging onto public transport with their HOP card. Image courtesy Auckland Transport.

AT has equipped each bus with card readers, which transmit the current difference between tag-on and tag-off in real-time over the 3G network, together with the bus position, the bus identification, and which trip the bus is running. This data forms the primary source of information for occupancy on buses.

For trains, the system is designed differently: card readers are positioned at each station. This approach still allows the correct fare to be determined but makes it harder to determine the occupancy for a specific train — or even per carriage.

To solve this, an APC (automatic passenger counting) solution by Dilax was installed, which counts passengers as they enter/exit through the doors. Similarly to buses, the APC solution transmits occupancy in real-time over the 3G network.

For ferries, the New Zealand Maritime Law requires captains to capture occupancy numbers. The integration with ship log management systems, and particularly the real-time aspect of it, are still under development.

How Data Is Processed

The “Datahub” ingests all data produced in real-time (occupancy, but also vehicle positions, start and end of trips, etc.) in their original data format. As part of the Command Centre software, a decision was made early on to use open standards for AT’s software. General Transit Feed Specification (GTFS) Realtime (RT), initially developed by Google and TriMet, was chosen as a data format internally — and also for public interfaces.

GTFS RT describes changes to the transport network — like vehicles moving, arriving at stops, or new predictions about arrival/departure times becoming available — as “messages”. It also includes occupancy levels as part of its vehicle position update message. The Datahub transforms all incoming data into GTFS RT in its first processing stage.

Raw occupancy numbers aren’t meaningful by themselves without context — as alluded to above. To get a view of the actual “fullness” level, the data is further combined with data from a fleet list, which contains the size and characteristics of each vehicle in use. This aggregation allows the platform to convert data like “20 passengers” in a double-decker bus to the valuable metric “Many Seats Available” — without getting distracted by too specific numbers, or occasionally occurring minor issues with counting.

Datahub uses Apache Kafka as its transport mechanism for all messages, and a micro-service architecture to process messages. It processes real-time data from approximately 1500 buses, trains and ferries transporting customers at the same time — or about 150 “messages” per second. The platform is currently deployed to Microsoft’s Azure cloud environment — but is developed to be cloud-agnostic.

Showing Live Occupancy To Users Through AT Mobile

AT Mobile allows travellers to plan journeys across Auckland Transport’s public transport network, and view real-time information like departure time predictions as well as occupancy levels of departing buses, trains and ferries. Occupancy data is now displayed next to all departing services which have data available.

Different views showing the Live Occupancy feature for Trains.

Occupancy levels, allowing for 2 metres of distances, were adjusted. Usually, the threshold for (for example) “Many Seats Available” and “Few Seats Available” would stand at 40% and 90% of the seating capacity. During the epidemic, it has been reduced to 20% and 45%, respectively.

The Datahub publishes all real-time messages, and with it, occupancy data, as a stream of real-time data through HTTP web sockets.

AT Mobile on average is used by more than 250,000 travellers each month, and accounts for more than 150,000 journey plans, and approx 1.5 million requests for departure information each day. It is implemented in React Native, and available both for iOS and Android-based mobile devices for free.

Moving Forward

The live occupancy feature was able to be released to the public after just one week of development, keeping costs low for such a meaningful initiative. This quick release time was enabled by the robust yet agile infrastructure around it.

The approach AT has taken allows them to move quickly and present existing data in new, meaningful ways. As COVID-19 subsides, the same data can again be quickly reshaped to show relevant information as passenger numbers increase again.

Propellerhead has worked closely with AT to make Command Centre, the Datahub, AT Mobile, and other AT software open and agile platforms to monitor and manage public transport. We are proud of our vision for this software — a multifunctional tool rather than a single-use application.