Aviation operations tooling
Purpose-built tooling for aircraft loading, unit load device management, operational documentation and the ground workflows that run an aircraft turnaround.
Overview
A suite of specialist tools built around real airline ground-operations workflows: aircraft loading, unit load device management, and the structured documentation produced during and after a turnaround.
Every aircraft turnaround generates a large amount of structured information, spread across loadsheets, loading instructions, baggage reports and operational messages. This project examined how much of that handling could be made faster and less error-prone with purpose-built software.
The problem
Ground operations are highly procedural and highly time-constrained. The same facts — positions, unit load device numbers, weights, destinations, special loads — are transcribed repeatedly between documents and message formats.
A small transcription error creates disproportionate downstream work, and the work happens against a departure time that does not move.
The objective was to reduce repetitive manual handling of the same information while leaving operational control firmly with the people accountable for it.
The product
The tooling captures operational information once and transforms it into the formats each downstream process expects, rather than requiring it to be retyped for each one.
A dedicated loading interface represents aircraft hold positions visually, so unit load devices can be assigned to the correct positions under aircraft-specific loading rules.
Structured flight and load information then supports the preparation of standard operational messages and post-flight documentation.
Key capabilities
Aircraft loading interface
Hold positions represented visually — left and right positions, container and pallet positions, empty and restricted positions — so the interface matches how the aircraft is actually loaded rather than presenting a generic database form.
Unit load device management
A unit load device is the container or pallet that baggage and cargo travel in. The tooling tracks identifiers, positions, weights, categories, special loads and empties across the turnaround.
Loading instruction workflow
Works from loading instructions and structured operational information to support production of updated loading documentation, covering positions, identifiers, destination, weight and load classification.
Operational message generation
Structured information is transformed into standardised message formats, removing the duplication between the source data and the message finally transmitted or recorded.
Post-flight documentation
Supports the standard message set produced around a flight: LDM, CPM, UCM and MVT — explained below in plain language.
Baggage and offload location
When a specific bag has to be located — a passenger offload, a missed connection — the relevant aircraft position is surfaced from operational records rather than traced by hand across several documents.
Engineering
The services were written in Go, chosen for predictable behaviour under concurrent load and for straightforward deployment rather than for novelty.
Integration boundaries were treated as the principal risk. Each interface has explicit failure behaviour — timeouts, retries, and a defined position on what to display when upstream data is stale — so a partial outage degrades visibly instead of quietly showing an operational picture that is no longer true.
The standard messages the tooling works with are ordinary aviation vocabulary rather than proprietary terms. LDM, the Load Message, reports how an aircraft was loaded by compartment. CPM, the Container and Pallet Distribution Message, records which container or pallet sits in which position. UCM, the ULD Control Message, covers movement of unit load devices between stations. MVT, the Movement Message, carries the aircraft movement times. They are spelled out here because a procurement evaluator should not have to be a ground-operations dispatcher to understand what the software does.
Product experience
The interface deliberately avoids visual decoration. Operational software has different priorities from a consumer application: speed, clarity, predictable behaviour, unambiguous position information, minimal interaction and firm data validation.
The system supports the operator; it does not replace them. It does not make loading decisions autonomously, and human operational responsibility for those decisions is retained in full.
Outcome
- Operational information that previously had to be assembled from several sources is available through one interface.
- Information captured once can be transformed into the operational outputs that follow, with human verification retained at each step.
Our role
- Backend service development in Go
- Aircraft loading interface design and development
- Integration with existing operational data sources
- Structured document and message workflows
Have a comparable requirement?
Send the brief or the procurement reference. We will tell you whether this is work we can do well.