How do airline ground crews handle data on the ramp?

IATA describes ramps as busy, confined areas in which aircraft, ground support equipment and people are in constant motion in all weathers. Ground handling during a turnaround spans areas such as passenger services, aircraft loading, load control and cargo, the subjects IATA’s Airport Handling Manual covers.

Each of these produces data. Bags are tracked through their journey from acceptance to arrival. Loading feeds load control. Aircraft movement messages report what the aircraft did and when, and delays are recorded with standard codes.

Three IATA programmes set the shape of this work.

• Airport Handling Manual (AHM). The AHM gives industry-approved policies and standards for ground handling. IATA calls it policy driven, “what to do”. Its contents include delay code procedures and aircraft movement messages.
• IATA Ground Operations Manual (IGOM). The companion manual is procedure driven, “how to do”. IATA calls for the ground handling industry to adopt it globally for consistent and safe operations.
• ISAGO. The IATA Safety Audit for Ground Operations assesses how ground handling service providers implement their management systems and standardised operating procedures.

Baggage has its own rule. IATA Resolution 753 requires member airlines to track baggage at four points: acceptance, loading, transfer and arrival. IATA describes the result as a verifiable audit trail for the acquisition and handover of baggage, and airlines must share tracking information with interline partners. IATA also notes that adoption has been slower than expected, citing differences in airport infrastructure maturity, technological readiness and investment.

A ramp record can be evidence that responsibility moved from one party to another: the bag was loaded, the hold was closed, the check was done. That makes three failure modes serious.

The first is losing the record. If a scanner cannot reach the system and the app does not keep the scan, the audit trail has a hole. The second is giving it the wrong time. A scan uploaded late must still show when the bag was loaded, not when the upload arrived, or the record tells the wrong story. The third is the duplicate. If a device sends a scan, the confirmation is lost on the way back, and the device sends it again, the system must recognise the second copy rather than record a second event. What happens to a write made offline? covers the general case.

Android’s offline-first guidance describes three ways to write data, and a ramp app can use all three:

• Lazy writes save to the device first and queue the change for the network at the earliest opportunity. The guidance calls this the correct choice when data is critical to the app, which fits scans and completed checks.
• Queued writes go into a queue drained with exponential backoff, for data that is not time sensitive, such as analytics and logs.
• Online-only writes succeed only if the network accepts them, for actions that must happen in near real time. The guidance’s example is a bank transfer. On the ramp, whether an action belongs here is a procedural decision set by the airline’s manuals, not by the app.

Two details make lazy writes safe. Each record carries the time it happened and an operation ID, so a retried upload is recognised and applied once. And the app shows plainly what is still waiting to upload, so a crew lead can see whether a gap is in the work or only in the network.

Queuing solves the link between one device and the airline’s systems. It does not help two crew members at the same aircraft see each other’s progress when neither can reach those systems.

That is a local problem, and device-to-device software can address it. Handhelds within radio range can keep a shared replicated document, such as the turnaround checklist, and merge edits when they reconnect. Fields that can only have one correct value, such as who signed off a check, need a rule decided in advance, because a merge picks a result but does not know the procedure. The airline’s systems stay the record. Local sharing keeps the crew working from the same picture until the data reaches them.