Manual registers
Tower workflows are traditionally handled through paper logbooks and disconnected records.
CASE STUDY · PROJECT 01 / AVIATION SOFTWARE
A web platform for the control tower that replaces paper logbooks and movement registers with one accountable, real-time record of tower operations.
Development complete for current scope.
01 / THE PROBLEM
Tower workflows are traditionally handled through paper logbooks and disconnected records.
Traffic movements and operational updates are often spread across separate manual records.
On a shared tower position, it must always be clear which controller made each entry and each correction.
02 / THE SOLUTION
AOMS brings the records a tower keeps by hand — arrivals, departures, the logbook, aircraft on the ground — into a single authenticated web application, designed from the controller’s position: quick entry during busy traffic, clear attribution of every entry, and no record that can quietly disappear.
OPERATIONAL CONTEXTThe design draws on my own professional experience in tower operations, including my on-the-job tower training at Hargeisa (HCMH). This reflects my experience only; it is not a claim of official adoption or deployment by any airport.
Strip numbers are allocated inside PostgreSQL, records are archived rather than deleted, and audit history cannot be rewritten.
Controllers confirm their identity with their initials and a PIN, so every movement, correction and log entry is attributed to the controller who made it.
Registers, the logbook and operational boards update in real time, so every position works from the same picture.
03 / WORKFLOWS
Each arrival is recorded with its callsign, registration, route and actual time of arrival in Zulu, and receives a strip reference from the database. The entry form also captures the active runway, remaining endurance and people on board.
A departure can be prefilled from an aircraft already on the ground, including night stops, or recorded manually. The register filters by status, flight rules, destination and date range, and searches by callsign, registration or strip number.
Totals of movements, arrivals, departures and people on board for a chosen period, with daily movements split into arrivals and departures and a breakdown by operator.
All screenshots are taken from a demonstration environment containing only synthetic flight and movement data. They are not live airport records.
04 / FOR CONTROLLERS
05 / ARCHITECTURE
Next.js App Router renders pages on the server; interactive workspaces run in the browser. Responsive, with dark and daylight themes.
Input validation, role capability checks and session-aware routing sit on the server boundary.
Authentication, PostgreSQL with row-level security, database functions for strip allocation and attribution, and realtime updates.
Separate development, UAT and production environments, plus a scheduled server job.
Engineering record taken from the project repository, October 2026.
06 / CHALLENGES
Numbers are allocated by a database function with monthly uniqueness, and historical imports share the same numbering, so two entries can never receive the same strip.
The tower station login is shared, so each controller verifies with initials and a PIN. Attribution was moved to verified sessions in stages, with each migration rehearsed first.
A tower day does not follow the browser’s clock. The airport time zone is locked, and an operational-day rollover replaced an earlier automatic station closure.
Ordered migrations across separate environments, verification scripts, and a release runbook with rehearsed rollback and re-entry paths.
07 / STATUS
Case study of the software as built — not a claim of airport deployment or adoption