Control the complete interface, not only the connector
An interface control document, or ICD, should describe every boundary from the
operator to the controlled function. A useful first diagram is deliberately
plain:
operator -> GCS -> ground gateway -> network provider -> airborne gateway
-> onboard computer -> flight controller or payload controller
Power, time, identity, configuration, security, and logging cross several of
those boxes. A supplier that owns one box may not own the end-to-end behavior.
Name the party responsible for each boundary, the party responsible for system
acceptance, and the evidence each party must deliver.
NASA's interface-management guidance
describes interface definition, control, verification, and change management as
an ongoing systems-engineering activity. That is the useful model here. A pinout
issued at preliminary design is not a finished interface if the command state
machine, network policy, or software version can later change independently.
The ICD should point to controlled artifacts rather than restating them
informally. Those artifacts normally include electrical drawings, connector and
cable specifications, a data dictionary or interface description language,
network rules, security and key-management plans, software compatibility
matrices, and verification procedures. Give each artifact an owner, revision,
approval state, and applicable hardware and software versions.
Define authority before defining messages
The system must know who may command what. Identify every possible command
source: pilot controls, ground-control software, mission software, an onboard
automation function, a maintenance terminal, and any alternate control station.
For each mode, define which source has authority, how authority transfers, what
interlocks apply, and how the operator sees the current state.
Do not use network reachability as authorization. A connected application is not
automatically permitted to arm, change a route, control a payload, or alter link
configuration. Document identity, role, permitted command set, operating mode,
and any required human confirmation separately.
Addressing must also be unambiguous. Define vehicle, system, component, and
session identifiers, including allocation ownership and collision handling. The
MAVLink component-ID guidance
illustrates why identifiers are part of integration, not an incidental byte:
several components can share a link, and routing or command targeting depends on
consistent assignments. The same discipline applies to other protocols.
Automation does not remove these decisions. The
automation and autonomy authority test
helps determine who sets goals, changes plans, and handles off-nominal
conditions. Record those answers in requirements and mode-transition logic.
Specify command and state semantics
A message name is not a behavior. For each command, define:
- valid sender, receiver, modes, parameters, units, ranges, and preconditions
- what constitutes acceptance, rejection, start, progress, completion, and
failure
- timeout origin and duration, retry policy, and maximum attempt count
- sequence or transaction identifier, duplicate detection, and ordering rules
- whether the operation is idempotent and what a repeated command does
- state and event messages that let the GCS reconcile the final result
An acknowledgment can mean that a packet arrived, that a command passed
validation, or that an operation completed. Those meanings cannot be inferred.
The MAVLink command protocol, for
example, defines command acknowledgments and result states, including accepted,
in-progress, temporarily rejected, and failed outcomes. That protocol behavior
is a documented example, not a requirement to use MAVLink.
Heartbeats need equally precise treatment. Define their source, expected rate,
timeout, meaning, and relationship to actual command-path availability. The
MAVLink heartbeat documentation
says systems can infer disconnection after missing expected heartbeats, while
rates and timeout behavior depend on the channel. It also warns that components
unaware of their own failure state should not emit heartbeats that imply health.
Those local liveness signals do not by themselves establish end-to-end C2
health.
Close the physical and electrical interface
For each installed device, control the connector manufacturer and part number,
mating connector, contact assignment, keying, retention, cable construction,
bend and strain limits, shielding, grounding, and installation inspection.
Define voltage range at the device, steady and peak current, inrush, allowable
ripple, brownout behavior, reverse-polarity protection, power sequencing, and
what happens after power interruption.
For Ethernet, serial, USB, CAN, or another bus, state the physical-layer
variant, speed, duplex or termination, isolation, grounding, and required cable
length. State who supplies adapters and whether they are flight articles. Close
thermal, environmental, and electromagnetic-compatibility assumptions rather
than treating a laboratory connection as installed evidence.
The
payload integration interface gate
covers the broader mass, power, thermal, mechanical, data, timing, and software
questions for an attached payload. A C2 integration should use the same gate
discipline even when the component is called a modem, router, or onboard
computer.
Define the network as an end-to-end service
Record IPv4 or IPv6 use, static or dynamic addressing, subnet ownership, ports,
transport protocols, flow direction, maximum packet size, fragmentation policy,
DNS dependence, multicast behavior, and firewall rules. Identify every NAT,
carrier-grade NAT, proxy, tunnel, broker, and cloud relay. Document which side
initiates a session and how it reconnects after address or path changes.
For multiple links, define route selection, route preference, session
persistence, and whether paths are truly independent. Two modems may still share
one airborne router, antenna system, power rail, identity provider, cloud
gateway, or ground backhaul. Those common dependencies belong in the
architecture and failure analysis.
Bandwidth, latency, jitter, loss, reordering, duplication, and data age need
separate requirements in each direction. Average latency alone can hide a long
tail. Specify the observation point, test duration, percentile or maximum, and
traffic load. The
RF, LTE, satellite, and mesh comparison
and Starlink integration analysis explain why a
bearer or internet service does not by itself define C2 performance.
Make time and traffic policy testable
For every timestamp, state the clock source, epoch, time zone or UTC treatment,
resolution, accuracy, expected drift, synchronization method, and behavior
during loss of synchronization. State where age is calculated and whether a
receiver rejects data that are stale, too far in the future, or out of order.
Logs from different components are difficult to correlate when their clocks do
not share a controlled reference.
Traffic priorities must identify the classifier, marking, queue, scheduler, rate
limit, congestion response, and owner at every hop.
RFC 2474 defines the
Differentiated Services field and per-hop behavior concept, while
RFC 4594 gives service-class
configuration guidance. Neither document guarantees that a provider will honor a
marking end to end. Verify the installed path under simultaneous command,
telemetry, video, and payload load.
Draw security boundaries explicitly
Identify the endpoint that authenticates each device, user, application, and
message. Separately identify where confidentiality begins and ends. An
authenticated command may still be visible in plaintext on an intermediate bus,
and an encrypted tunnel does not prove that the sender is authorized to issue a
particular command.
Document credential provisioning, secure storage, renewal, rotation, revocation,
recovery, and replacement. Include factory, integration, operational, depot, and
end-of-life states. Define maintenance ports, default accounts, local debug
access, remote administration, audit events, and the conditions under which each
is enabled.
NISTIR 8259A
provides a general device baseline covering identification, configuration, data
protection, logical access, software update, and cybersecurity-state awareness.
It is not an aviation C2 approval standard. Its companion
manufacturer activities guidance
is useful for procurement because device capabilities alone are insufficient
without support, documentation, vulnerability response, and lifecycle plans.
Security architecture and threat treatment are developed further in the
secure BVLOS communications guide.
Define health, failover, and lost-link handoffs
List every health input and its units, sample interval, valid range, threshold,
hysteresis, and confidence. Distinguish radio attachment, IP reachability,
application session health, command round-trip success, and data freshness. A
modem can report a healthy local link while an upstream gateway or GCS is
unreachable.
For each degraded state, name the detector, decision owner, transition delay,
traffic policy, operator alert, aircraft response, and recovery criteria. For
failover, define whether commands can be in flight on both paths, how duplicates
are suppressed, whether state is synchronized, and what happens to a partially
completed transaction. Test restoration as carefully as initial switching.
The UAS lost-link procedures guide owns
the operational response after loss is declared. The interface owns the signals
and timing that support that declaration. A NASA
C2 communication concept presentation
depicts an end-to-end architecture with aircraft, ground station, service
providers, and supporting services. Treat it as a research concept, not a
mandated small-UAS architecture or performance specification.
Control logs, configuration, and updates
Require logs to identify hardware, firmware, software, configuration, mission,
vehicle, user or command source, network path, and synchronized time. Capture
commands, validation results, acknowledgments, mode changes, health transitions,
failover decisions, authentication events, configuration changes, update events,
and relevant link metrics. Define format, export method, retention, integrity
protection, access control, storage exhaustion behavior, and who may redact
operationally sensitive data.
An update interface needs an authenticated source, authorization policy,
integrity check, compatibility check, interruption behavior, rollback or
recovery path, audit record, and post-update verification. Define who approves
updates and how emergency fixes differ from scheduled releases.
NASA's configuration-management guidance
ties configuration identification, control, status accounting, and audits to a
known product baseline. Applying that discipline prevents a test result for one
software and configuration set from being presented as evidence for a different
installed set.
Specify what the operator must see and control
The GCS interface should define the available commands, displayed state, units,
refresh rate, data age, stale-data treatment, link identity, authority owner,
security state, degraded modes, alerts, and required acknowledgments. Specify
how the UI distinguishes command sent, accepted, in progress, completed,
rejected, and timed out.
Protect against the wrong vehicle, wrong component, wrong mode, and stale
display. Define confirmation rules for consequential actions and how an operator
cancels or safely recovers a partial action. Test annunciations with real timing
and failures, not only static screenshots.
Turn the ICD into acceptance evidence
Every interface requirement should have a unique identifier, verification
method, responsible party, configuration, procedure, expected result, and
recorded result.
NASA's requirements verification matrix
is a useful model for keeping those relationships visible.
NASA's product verification guidance
also emphasizes verification against requirements in the intended or a
representative environment.
The following are editorial test examples, not values prescribed by the cited
sources:
- exercise every command through accepted, rejected, timed-out, duplicate, and
interrupted paths
- test minimum, normal, peak, and competing traffic while measuring both
directions at named observation points
- inject loss, latency, jitter, reordering, duplication, stale data, clock
offset, and abrupt clock changes
- remove each network path and common supporting dependency, then verify
detection, failover, operator alerting, aircraft response, and recovery
- present invalid, expired, revoked, and rotated credentials and verify that
unauthorized control remains unavailable
- interrupt power, sessions, configuration changes, and software updates, then
verify deterministic recovery and preserved audit evidence
- reboot components in different orders and confirm identity, routing,
authority, configuration, and state converge correctly
- correlate GCS, gateway, onboard, and controller logs to the same injected
event and confirm the record is sufficient for diagnosis
Procurement checklist
Before selecting or accepting a component, require written answers to these
questions:
- Who owns each physical, electrical, network, application, security, and
operator interface, and who accepts the complete system?
- Which protocol and software versions interoperate, and what is the supported
compatibility and end-of-life policy?
- How are command authority, identity, acknowledgment, completion, retries,
duplicates, ordering, and stale data handled?
- Where do authentication and encryption start and stop, and who provisions,
rotates, revokes, and recovers credentials?
- What are the measured latency, loss, data-age, and capacity limits with every
required traffic class active?
- Which health signals drive degraded, failover, and lost-link states, and how
were thresholds and recovery tested?
- What dependencies remain common across supposedly redundant paths?
- Which logs and configuration records will be delivered, in what format, and
under what access and retention terms?
- How are updates approved, authenticated, interrupted, recovered, rolled back,
and supported through product end of life?
- Which requirements remain unverified, what representative conditions were
excluded, and who owns closure before operation?
A complete interface package does not guarantee operational approval. It does
make claims reviewable, changes controllable, and failures reproducible. That is
the minimum foundation for deciding whether the selected C2 architecture can
support the intended aircraft and operation.
