IoT Based Airport Management

IoT Based Airport Management — Topics for IoT Students

A Highly Available GTFS-RT Positions System [System]

Joshua Wong Kin Tsang California State University, Los Angeles California State University, Los Angeles Los Angeles, California, United States Los Angeles, California, United States jwong159@calstatela.edu ktsang3@calstatela.edu

ABSTRACT technical assistance for transit agencies’ implementation GTFS real-

We develop a system for real-time public transportation data, decid- time data system, leading to increased useage of GTFS-RT (General ing to use the data standard GTFS-RT (GTFS Realtime), an open data Transit Feed Specification - Realtime) in the near future (1-3 years). format for public transit data. We give an overview of the design of The goal of this paper is to develop a highly available, real-time a physical GPS sensor device, its firmware, and processes.

Next, we data system for public transportation, at a low cost. This system arXiv:2508.01121v1 [eess.SP] 2 Aug 2025

give the algorithms used to translate raw sensor data into a public should be easy for public transit agencies to implement, in order to GTFS-RT data feed. We deploy this feed over a highly available reap the benefits of realtime data with minimal cost. cluster across multiple regions to maintain high availability. 2 PRIOR WORK CCS CONCEPTS OneBusAway [3], is a set of tools that creates a system for transit • Information systems → Location based services; Geographic traveler information.

The system originally included Route Maps, information systems; Global positioning systems; • Computer sys- Timetables, a Real-Time Tracker, Service Alerts, and a Trip Plan- tems organization → Embedded and cyber-physical systems; Dis- ner. Overtime, OneBusAway has been deployed in many places tributed architectures. such as Tampa, Florida, Atlanta, Georgia, and New York City, New York. These deployments have created positive results, with 92% of KEYWORDS respondents to a survey reporting that they were more satisfied us- Public Transit Data, Highly Available Systems, Distributed Systems ing public transit result of using OneBusAway.

Additionally, users of OneBusAway also reported an increases in public transit trips, ACM Reference Format: Joshua Wong and Kin Tsang. 2025. A Highly Available GTFS-RT Positions allowing for transit agencies to gain more revenue [4]. System [System].

In Proceedings of 33rd ACM SIGSPATIAL International Con- Barbeau’s research team worked on Pinellas Suncoast Transit ference on Advances in Geographic Information Systems (ACM SIGSPATIAL Authority’s (PSTA) GTFS-RT, located at Pinellas County, Florida. ’25). ACM, New York, NY, USA, 4 pages. https://doi.org/10.1145/nnnnnnn. Using this feed, they deployed an instance of OneBusAway for nnnnnnn data analysis, discovering three sources of errors.

The GTFS-RT producer issues include missing data, along with inconsistent data 1 INTRODUCTION in relation to the GTFS static data [1]. Overall, troubleshooting the GTFS-RT feed with the team, agency, and vendor (GTFS-RT Many small, municipal public transportation agencies do not have producer) was highly challenging, as OneBusAway functions more a realtime data system. Realtime data for public transit has many as a user application rather than a data validator.

PSTA staff had positive effects, from increasing ridership [4], to increasing the to catch errors in real-time through the OneBusAway mobile app, satisfaction of the ridership experience [5]. Unfortunately, there are causing a lot of resistance in their debugging. many factors that contribute to small agencies not having a realtime U.S. Patent No. 20170270790 claimed a “Vehicle Prediction Mod- data system.

According to RebelGroup [14], one of the primary ule” system, in which a series of modules are created in order to factors is a lack of resources for transit technology, particularly in process inputs of vehicle positions and output ETAs (Estimated the effort required procure contracts. However, one way the State of Time of Arrival) for transit vehicles using a database of historical California has promoted the adoption of certain transit technologies arrivals and scheduled stops. and standards, such as GTFS (General Transit Feed Specification), is Finally, U.S.

Patent No. 10977941 claimed a system where transit through endorsement and support, leading to increased usage and terminals, such as payment terminals, use a user device’s geoloca- implementation of these endorsed technologies and standards. As tion as a geolocation for that interacting terminal device [10] [7]. a California Public Benefit Nonprofit Corporation, in partnership Then, other users could use that prior geolocation from a user’s with a State Government initiative, we will endorse and provide device via their own devices.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation 3 DATA FORMAT on the first page. Copyrights for components of this work owned by others than the GTFS, General Transit Feed Specification [9], is a data format that author(s) must be honored.

Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission allows for public transit to be machine-readable to transit applica- and/or a fee. Request permissions from permissions@acm.org. tion providers.

GTFS can include data such as routes, schedules, and ACM SIGSPATIAL ’25, November 03–06, 2025, Minneapolis, MN stops. GTFS also has a real-time component [8], often shorthanded © 2025 Copyright held by the owner/author(s). Publication rights licensed to ACM.

ACM ISBN 978-x-xxxx-xxxx-x/YY/MM. . . $15.00 as GTFS-RT. This component of the specification contains time https://doi.org/10.1145/nnnnnnn.nnnnnnn sensitive data such as vehicle position and trip progress. GTFS-RT

ACM SIGSPATIAL ’25, November 03–06, 2025, Minneapolis, MN Wong et al.

data can be created from an AVL (Automatic Vehicle Location) sys- packet are two 32-bit floating-point numbers representing the vehi- tem [11] and a set of GTFS data. In our system, we would have a cle’s latitude and longitude, followed by its bearing (in degrees) and processing step similar to [13] to manage the creation of GTFS-RT speed (in kilometer per hours), also as 32-bit floats. Next, there is a data. vehicle id as a 32-bit unsigned integer.

Finally, the timestamp, in Unix epoch format, is the last 8 bytes as a 64-bit unsigned integer. 4 SENSOR HARDWARE All floating-point numbers in this packet are using the IEEE-754 standard representation. The hardware chosen as the sensor is the LILYGO®T-A7670G R2 de- velopment board. The development board features a Espressif®ESP32- WROVER-E CPU package with 4MB of Flash and 8MB of PSRAM, SIMCOM®A7670 LTE and GPS modem, and a Quectel®L76K GPS Figure 1: Application Layer Packet Byte Layout modem.

The GPS modem on the A7670 requires a powered antenna, thus LILYGO®also attached the Quectel®L76K GPS modem to pro- vide GPS functionality with a passive antenna. The development board was chosen because of its low price and compatibility with mobile networks in the United States. Along with the T-A7670G R2 development board, other variants of the development board were tested.

The 2 other variants tested include the T-A7080G S3 and the T-A7600G. Differences of the T- A7080G S3 compared to the T-A7670G R2 is the inclusion of a more powerful ESP32-S3 processor and change of modem from A7670 to A7080, which required different handling in firmware for GPS functionality, explained in the next section. The difference of the T-A7600G compared to the T-A7670G R2 is the use of the older A7600 modem, which due to the sunset of 3G networking, is now unable to authenticate with mobile carriers.

5 SENSOR FIRMWARE

The primary goals of the sensor firmware were twofold. One, to collect and parse GNSS data to send. Second, the GNSS data is sent via LTE networking to a server for further processing.

The sensor firmware was created for the LILYGO®T-A7670G R2 with GPS. The A7670G and L76K are logically connected to Figure 2: Device with simultaneous GNSS and LTE network- the ESP32 via serial pins. Each development board is connected ing to a server cluster via LTE Cat-M1, as they are equipped with an IoTDataWorks 64 kbps Unlimited IoT SIM Card, which uses the T-Mobile US network.

The firmware executes the primary steps 6 NETWORK ARCHITECTURE listed in Figure 2. Our deployment of our demonstration system primarily focused on There is, however, another variant of the firmware designed for redundancy and consensus, as it contained the minimum amount devices that cannot receive GNSS and LTE signals simultaneously. of clusters (3) for consensus to be viable. We separated our nodes The individual steps are similar, but there is no initialization se- physically into separate networks, each with unique IPv4 addresses, quence.

The init system steps are moved to the main loop, as the so that we can use Anycast DNS in order to route requests users device requires both GNSS and LTE modules to be enabled and send to us to the nearest node. Each node was also connected via a disabled sequentially to maintain mutual exclusivity. WireGuard Mesh VLAN because our chosen consensus algorithm, The first step of each loop (run every 500ms) is to obtain a reading Raft [12], is not Byzantine Fault Tolerant [2].

To maintain the se- from the L76K GNSS module. The program then extracts GNSS data, curity of our service, we deployed Raft within a private network using the Arduino Library TinyGPS++ [6], from the $GPGGA and where its service is not exposed publicly. $GPRMC NEMA sentences that the module produces. Another thing collected is the time (as a datetime string) from the mobile network, as GTFS-RT does not need centisecond accuracy that the 7 SERVER SOFTWARE GNSS module can provide [15].

This time is then parsed from the Given the position of a transit vehicle, its ID, the time, the route ID, and string, which is formatted as “DD/MM/YY,HH:MM:SS±HH”, using the GTFS Schedule data, can we determine a proper VehiclePosition another Arduino Library called TimeLib. If the location, bearing, for the vehicle? speed, or time is not valid, the loop returns early without going into the second step of the main loop. 7.1 Preprocessing Next, each loop sends 28 bytes (see Figure 1) to a UDP server, The server has three primary data structures (Fig. 4) that need to encapsulated by a IPv4/UDP packet.

The first eight bytes of the be filled with preprocessed data before the primary threads of the

A Highly Available GTFS-RT Positions System [System] ACM SIGSPATIAL ’25, November 03–06, 2025, Minneapolis, MN

these packets are analyzed in order to determine their validity be- fore being sent to the data processing thread. We do not want our feed to contain invalid data, which is why this step is required.

7.4 Data Analysis

The validated packets are sent to to the Data Analysis thread. It performs operations on the correctly formatted packets, by extract- ing the data and correlating it with previously set data, such as a route ID for their vehicle. For this correlation, the system queries a Key/Value Map, which contains mappings between vehicle IDs and their descriptors, which is metadata about the vehicle including their id, label, license plate, and wheelchair accessibility.

Then, this data is constructed into a valid VehiclePosition GTFS-RT message using Algorithm 1. Algorithm 1 generates a GTFS-RT VehiclePosition message from Figure 3: Cluster Network Topology a GPS reading, vehicle ID, and timestamp. It cross-references a shared vehicle-to-route mapping and a time-indexed trip schedule to determine the most probable trip the vehicle is operating on. server can run.

First, the GTFS-RT message stored in global memory When multiple trips are possible, it selects the most likely one is initialized with the current timestamp and header data. Next, the using spatial indexing via a KDTree [16]. If the vehicle is within 20 K/V map that is used for in-memory queries of vehicle and route meters of a stop, it includes that stop in the message and assigns a attachment data is initialized with preset data from a file.

Finally, StoppedAt status if the vehicle’s speed is zero. a GTFS file is preprocessed into an interval tree, where each of its The VehiclePosition message then is sent to update the GTFS-RT trips are stored in nodes. This allows the program to do trip queries Message, which is the final result for all real-time data. This GTFS- in 𝑂 (log 𝑛), where each trip is in a given interval.

RT Message is kept up to date with the most recent information and is what the HTTP/HTTPS servers return when they are sent 7.2 Architecture requests. In Figure 4, the architecture of the server-side software of this system is shown. The figure shows how the server handles the data 7.5 HTTP/HTTPS Service flow and processing pipeline of converting the packet format in Figure 1 received from GPS sensors, into GTFS-RT messages.

Since A client can request GTFS-RT data, via HTTP or HTTPS. This will GTFS-RT is a standard, we will use it as a data format to provide live cause the HTTP Server or HTTPS Server retrieve the GTFS-RT information regarding our transit system. The architecture revolves Message from the server cache and then return it to the client. around a central server cache and includes four primary threads that do the following: UDP ingestion, data analysis, and HTTP/HTTPS 8 DISCUSSION AND CONCLUSION service.

All of these threads work in parallel to receive, process, This work presents the design and implementation of a GTFS-RT and serve real-time transit data efficiently. positions system, from sensor hardware and embedded firmware, along with a server-side data for distributed feed delivery. Our system demonstrates that it is feasible to build a low-cost, highly available solution for real-time public transit data, tailored for small and mid-sized agencies that may lack significant technical or fi- nancial resources.

By building a modular and open architecture, we lower the barrier to entry for transit operators and simplify maintenance and deployment. Compared to prior work like OneBusAway and vendor-provided systems, our approach focuses on physical system-level control and transparency, allowing agencies to generate and troubleshoot their own GTFS-RT feeds with confidence. Our design choices, such as Figure 4: Internal Server Architecture choosing open standards, using minimal and energy-efficient hard- ware, and distributing load across cloud regions, directly support our goals of cost-effectiveness, reliability, and long-term scalability.

While patent literature often focuses on proprietary prediction sys- 7.3 UDP Ingestion tems or sensor-device interactions, our contribution centers around The process begins with a UDP ingest thread, which listens for in- public, standards-compliant data feeds that any user or app can coming UDP packets from external sources, likely vehicle tracking access. systems or transit agencies. These packets contain raw vehicle po- Finally, there are still areas for future work.

For example, GTFS- sition data or other GTFS-RT message components. Once received, RT has data fields for real-time ETA predictions, which require

Input: Position: (Latitude, Longitude, Bearing, Odometer, [3] Brian Ferris, Kari Watkins, and Alan Borning. 2009. OneBusAway: A transit Speed), Vehicle ID, Timestamp traveler information system. In International Conference on Mobile Computing, Applications, and Services.

Springer, 92–106. Output: VehiclePosition [4] Brian Ferris, Kari Watkins, and Alan Borning. 2010. OneBusAway: results from Acquire lock on Shared Vehicle Map providing real-time arrival information for public transit.

In Proceedings of the Lookup (vehicle, route_id) using Vehicle ID SIGCHI Conference on Human Factors in Computing Systems. 1807–1816. [5] Aaron Gooze, Kari Edison Watkins, and Alan Borning. 2013. Benefits of real-time Release lock on Shared Vehicle Map transit information and impacts of data accuracy on rider experience. Transporta- if route_id is None then tion Research Record 2351, 1 (2013), 95–103. [6] Mikal Hart. 2013.

TinyGPS++: A New View of Global Positioning. https: return VehiclePosition with minimal fields filled (no //arduiniana.org/2013/09/tinygps-a-new-view-of-global-positioning/ Accessed: trip info) 2025-05-01. [7] Reuben Kan and Cayden Meyer. 2021. Passenger transit vehicle geolocation. end https://patents.google.com/patent/US10977941B2/en US Patent 10,977,941 B2, Compute seconds_since_midnight from timestamp Assignee: Google LLC. [8] MobilityData. 2024.

General Transit Feed Specification (GTFS) Realtime Reference. Acquire lock on Shared Trip Tree https://gtfs.org/realtime/reference/ Accessed: 2024-08-05. Get all trips overlapping seconds_since_midnight [9] MobilityData. 2024.

General Transit Feed Specification (GTFS) Schedule Refer- ence. https://gtfs.org/schedule/reference/ Accessed: 2024-08-05. Release lock on Shared Trip Tree [10] Bruce D. Neiger, Philip Jon Matuskiewicz, David A.

Laidig, and Michael S. Fru- foreach trip in trips do min. 2017. Vehicle Prediction Module. https://patents.google.com/patent/ Find closest stop before and after current time US20170270790A1/en Filed on May 13, 2016, Published on September 21, 2017. [11] Akande Oluwatobi. 1999.

A GPS based automatic vehicle location system for bus Collect stops between these two points transit. 0 20 (1999), 40–60. Store as tuple (trip_id, stop_times) [12] Diego Ongaro and John Ousterhout. 2015. The raft consensus algorithm.

Lecture Notes CS 190 (2015), 2022. end [13] Dejan Rančić, Bratislav Predić, Vladan Mihajlović, and A Medvedeva. 2008. Online if all trip_ids are equal then and post-processing of AVL data in public bus transportation system. Wseas Transactions on Information Science & Applications 5, 3 (2008), 229–236.

Set trip_id to that common value [14] RebelGroup. 2024. Caltrans TDDC | Report on Transit Technology Ecosystem. end Technical Report. California Integrated Mobility Program, Caltrans, Washington, DC. https://resources.calitp.org/calitp/Caltrans.Report.on.Transit.Technology. else Ecosystem.with.Detailed.Appendix.pdf Final report.

For each trip candidate: [15] Ronald Tumuhairwe and Nathan Amanquah. 2019. Determining the Location of a Bus in Real-Time Using LoRa Technology. In 2019 IEEE AFRICON.

IEEE, 1–6. Build 2D KDTree with stop coordinates [16] Joshua Wong. 2025. Algorithmic Analysis of GTFS-RT vehicle position accuracy.

Find nearest stop to position; arXiv:2506.06479 [physics.geo-ph] https://arxiv.org/abs/2506.06479 Store closest trip_id Pick trip with nearest stop as final trip_id end Find full trip object matching trip_id Build KDTree of all stops in selected trip Find nearest stop to current position return VehiclePosition with trip, stop_id, current_stop_sequence, and vehicle info Algorithm 1: GPS Data to GTFS-RT Vehicle Position

using machine learning models. Furthermore, we could also work on supporting other types of GTFS-RT feeds, such as Alerts and TripUpdates. Nevertheless, our system establishes a functional, end-to-end foundation that aligns with the growing expectations for real-time data in public transportation.

As public pressure and regulatory guidance increase in favor of open data, we believe systems like ours will play a crucial role in expanding GTFS-RT adoption across smaller transit operators in California and beyond.

ACKNOWLEDGMENTS

Thank you Hacker Initiative for sponsoring this work through Lavender Computing Collective, a 501(c)(3) non-profit corporation.

REFERENCES

[1] Sean J Barbeau. 2018. Quality control-lessons learned from the deployment and evaluation of GTFS-realtime feeds. In 97th Annual Meeting of the Transportation Research Board, Washington, DC. [2] Christopher Copeland and Hongxia Zhong. 2016.

Tangaroa: a byzantine fault tolerant raft. Stanford University (2016).

ACKNOWLEDGMENTS

REFERENCES

ACKNOWLEDGMENTS

REFERENCES

ACKNOWLEDGMENTS

REFERENCES