OnBlock — Station Operations Platform

The problem

The information existed.
It just wasn't in one place.

A station this size runs on four separate truths, each in somebody else's format. The engineer walking to stand 11 has to hold all four in their head — and the one that changed most recently is usually the one nobody saw.

Printed weekly

The roster on the wall

Who works which flight, transcribed by hand and out of date the moment someone calls in sick.

Emailed nightly

The airport's schedule

AOT's Excel with tomorrow's real movements. Authoritative — and downloaded by hand, every night.

Posted ad-hoc

The LINE group

Bay changes and tows typed in shorthand at 02:00, scrolling away above the next message.

Airborne

The aircraft itself

Delayed, diverted, or a different airframe than filed. The only source that outranks the rest.

The system

Thirteen screens.
You need three on any given day.

Every screen below is the running app. The data is the built-in demo — invented flights and invented people — so this page carries no real staff or customer information.

Movements board

The whole day, at a glance.

Arrivals and departures with real times, stands, aircraft and the crew on each one — merged live and readable from across the room. This is the screen on the office TV, and the same board in a mechanic's pocket.

Live timesTail + typeCrew per flightConflict alerts

The OnBlock movements board showing a day of arrivals and departures with aircraft types, times and assigned crew

Auto-roster

A legal week, in one press.

The generator honours type ratings, airline authorisations, a twelve-hour shift ceiling and rest between duties. When it cannot cover a flight legally it says so — and turns the gap into the number of people management would need to send.

Rating-awareOT balancedShortfall statedPublishes fleet-wide

The auto-roster review screen showing coverage metrics, overtime hours and the reasoning behind the schedule

Data sources

The paperwork arrives by itself.

The airport's nightly schedule and its bay-change telexes are read straight from email. The ops group's chat messages are parsed for stand changes. Live flight data and an ADS-B sweep fill in the rest. Nobody opens a file.

AOT email ingestLINE parsingADS-B sweepFull audit trail

The data sources panel showing daily schedule ingest, station sync and the live API with a parse audit log

Ops Control

The whole week's duty, on one grid.

Every engineer and mechanic across seven days — shift times, overtime, training, days off and sudden absence. Tap a cell to mark someone unavailable and the board, the coverage check and everyone's phone follow within seconds.

Published duty gridPer-day absenceOT visibleInstant fan-out

The Ops Control week roster duty grid showing shift times, overtime, training and days off for every engineer

Handling guides

Every airline's procedure, in your hand.

Twenty-one operators, each with its own transit checklist, fluids and spares, ground power, towing script and contacts. Tick items as you work — the ticks follow you between your phone and the office.

21 airlinesPer-user ticksPower by typeTap to call

The handling guides screen for Singapore Airlines showing the transit checklist with block-on and block-off time fields

Vehicles

Nothing expires unnoticed.

Ramp passes, insurance, tax and fleet cards for every station car and cart, with the weekly checklist, the six-month service and the monthly wash. Thai documents show Buddhist-era years, exactly as the paperwork does.

Expiry alertsWeekly e-checklistDefect logAuditor export

The vehicles registry showing fleet cards with document expiry status, renewal progress and weekly check state

Leave

Coverage first, then the calendar.

Staff request time off, planners approve, and approved leave feeds straight into the roster generator — so nobody is ever rostered on a day they are away. The coverage view warns before an approval leaves a day thin.

Self-serviceCrunch warningsFeeds the roster12-month view

The leave module showing a rolling twelve-month calendar with a legend for leave kinds and coverage warnings

Toolkit

The calculators, in the language of the job.

MEL deadlines by category, oil consumption, fuel uplift for eleven carriers, a torque converter, and the wheel-change kit list you tick off in the office so nothing is missing when you reach the aircraft.

MEL A/B/C/DFuel upliftTorqueWheel kit

The wheel kit checklist for a B787 wheel change, listing the tools to collect before walking out

Updates

What changed, week by week.

The platform ships continuously — straight to the station, no release window. This is the running log, newest first. It replaces the monthly PDF: every station reads the same page.

Architecture

Three sources. One board.
An order that never bends.

The hard part was never showing flights. It was deciding, for every field, which of four disagreeing sources is telling the truth right now — and being able to explain the answer afterwards.

Tier 1

The weekly roster

The station's own plan — who works what, and everyone's days off. The baseline the week is built from.

Weekly

Tier 2

The airport's daily schedule

AOT's file for the day. Once it lands it is the authority on what is operating — a flight missing from it is not flying, and its crew is released.

Nightly

Tier 3

The aircraft, live

Flight data and an ADS-B sweep every five minutes: real times, real tails, real stands, delays and diversions.

5 min

Override

A human on the apron

Someone standing at the aircraft outranks every feed. A manual edit wins, and stays won until it is cleared.

Instant

Local first

It works with the internet down

Every device holds the full picture. Edits queue offline and merge when the connection returns — last writer wins, enforced by the server, not hoped for by the client.

Server-enforced

Permissions are not decoration

Who may sign a release, approve leave or publish a roster is decided by database policy. The interface only hides buttons; it is never the thing standing in the way.

Always awake

A Raspberry Pi holds the station open

Alerts need a device that is awake and watching. A headless Pi in the office is that device, 24 hours a day, with a watchdog that checks the screen itself rather than the process.

Where it stands

Six weeks, and it runs the station.

0

Lines of code

One codebase — board, roster, forms, sync, alerts.

0

Modules live

Each replacing paper, a spreadsheet or a chat thread.

0

Releases

Every one deployed straight to the station.

0

Days to build

8 July to 19 August 2026, alongside a full shift pattern.

The mark is two chocks

Phuket is one station.
The problem isn't.

Nothing in this platform is specific to Phuket except the data in it. Every station runs the same four disagreeing sources, rosters against the same licence rules, and files the same two forms. It was built at HKT because that is where the problem was standing in front of me — it was built to move.

See it running at HKT Back to the system

OnBlock · Station Operations Platform · built for KLM E&M Phuket Thanawat “Arthur” Sriruen · app.onblock.win

The information existed.It just wasn't in one place.