When Gateway Failover Preserves the Wrong State
A maintenance gateway can restore communication while leaving the outcome of an aircraft command unresolved. In the hypothetical failure examined here, the active gateway resets after forwarding a maintenance write but before recording its acknowledgement. The standby restores the session and repeats the write, exposing the assumption that an unanswered command has not executed.
The reset exposes an unfinished transaction
The observable symptom is a repeated maintenance action following an apparently successful gateway takeover. The trigger is the active gateway reset during the interval between command delivery and durable acknowledgement recording; the failure mode is duplicate execution when the standby replays the outstanding request. A transport acknowledgement would establish receipt at its own protocol layer, but only application evidence could establish whether the aircraft endpoint accepted and completed the operation. Root cause analysis therefore has to correlate the ground request journal, gateway forwarding record and endpoint execution evidence, preserving uncertainty where those records cannot establish ordering. The design assumption that stopped holding was that the gateway journal remained an authoritative account of endpoint state across a reset.
Availability needs a boundary
The surviving gateway should keep observation available while withholding further maintenance writes until it can establish the outstanding transaction’s outcome and exclusive authority to transmit.
Preserve meaning across takeover
For a worked design target, consider a gateway takeover deadline of 250 ms, selected here as an illustrative requirement rather than an aircraft limit: meeting it establishes transport recovery, not permission to resume writes. Safe continuation requires the standby to recover the operation identity, intended effect and execution evidence, while the aircraft interface rejects traffic from a controller whose authority has expired. Where the endpoint supports durable duplicate suppression, it must retain the operation identity and result consistently with the state change itself, because a gateway transaction identifier alone cannot prevent repeated execution. Where that support is absent, reconciliation must use endpoint evidence capable of distinguishing the commanded effect from an unrelated state change; a generic status read may be insufficient. Observation also needs queues and processing capacity that command reconciliation cannot exhaust, otherwise the mechanism intended to contain uncertainty removes the engineer’s means of resolving it. These provisions consume storage, protocol complexity and recovery time, but they allow the remaining infrastructure to provide useful service without treating an unresolved write as permission to repeat it.
Make uncertainty a tested operating state
Airborne software and electronic hardware development assurance guidance, grouped in the FAA’s assurance resources, concerns defined certification scopes; citing that guidance does not establish the correctness of a ground gateway’s takeover protocol. For this architecture, verification should interrupt the command path at delivery, endpoint execution and acknowledgement recording, then demonstrate that the recovered gateway either establishes the result or explicitly retains an unresolved transaction. The evidence must also show that the former controller cannot regain write authority merely by restarting and that retained observations remain distinguishable from fresh endpoint data. Apply this decision rule: resume maintenance writes only when exclusive ownership is established and every outstanding operation has either a known outcome or endpoint enforced protection against duplicate execution. If the aircraft interface cannot provide that evidence, the remaining engineering decision is whether to extend the endpoint protocol or accept an explicit reconciliation stop in the maintenance workflow.