Autonomous drone docks sit at an awkward boundary: they look like IoT devices, but a command can eventually affect a real aircraft. That makes a conventional "send request and retry on failure" integration unsafe. The software must distinguish observation from authorization, reject stale or ambiguous commands, and fail closed whenever state cannot be proven.
This article presents a reference architecture for that integration problem. It uses the UNITED UAV UK03 drone docking station as a concrete product context because its current listing includes API availability, RTK, internal and external cameras, weather sensing, optional edge computing, optional mesh networking, and optional SIM-based 4G. The listing does not publish an endpoint schema, so every endpoint and payload below is deliberately illustrative. A production implementation must use the current vendor documentation and the approved aircraft-management workflow.
Commercial disclosure: UNITED UAV Official publishes this technical article and links to a product sold through the UNITED UAV store.
Start by separating four kinds of state
Many integrations become dangerous because they compress several questions into one boolean such as ready: true. A safer model records at least four independent states:
- Observed state — what the dock, aircraft, weather sensors, and network last reported.
- Validated state — whether those observations are recent, internally consistent, and within the operating envelope.
- Authorized intent — which mission was approved, by whom, for which aircraft, site, route, and time window.
- Executed state — what the vendor platform accepted and what later telemetry proves actually happened.
A positive observation is not authorization. An accepted API response is not proof of aircraft motion. A dashboard that has stopped updating is not evidence that conditions remain unchanged. Keeping these states separate makes the system easier to audit and prevents a stale green status from becoming a launch decision.
Put an adapter in front of the vendor API
Do not let schedulers, dashboards, or business applications call the dock API directly. Put a narrow adapter between them:
Planner -> Intent Store -> Safety Gate -> Dock Adapter -> Vendor Platform
| | |
v v v
Audit Log State Snapshot Readback Worker
The adapter should expose only the small set of operations the organization has approved. It can normalize vendor-specific status codes, enforce request IDs, apply timeouts, and redact secrets from logs. If the vendor API changes, only the adapter should need to understand the new schema.
This boundary is also where command and telemetry permissions can be separated. A monitoring service may need read-only access to weather, dock health, charging state, and alarms. It should not automatically inherit permission to open the dock, schedule a route, or dispatch an aircraft.
Make every command an expiring intent
A mission request should be an immutable record, not a transient button click. For example:
{
"intent_id": "01J6E7Y9M2K8Q4R5T6V7W8X9ZA",
"site_id": "solar-north-01",
"aircraft_id": "uis220-07",
"mission_revision": 4,
"approved_by": "ops-review-queue",
"not_before": "2026-08-28T02:00:00Z",
"expires_at": "2026-08-28T02:10:00Z",
"required_state_revision": 1842
}
The intent_id becomes the idempotency key. mission_revision prevents an older route from being dispatched after an edit. expires_at prevents a delayed queue message from starting a mission outside its approval window. required_state_revision binds the decision to a particular validated snapshot instead of whatever state happens to exist later.
If the vendor API supports an idempotency header, pass the intent ID through. If it does not, the adapter must keep its own durable command ledger and query vendor state before deciding whether a retry is safe. Never generate a new intent ID merely to make an uncertain request succeed.
Validate freshness before values
A weather value can be numerically safe and operationally useless if it is old. Every safety-relevant observation should carry three timestamps:
- when the sensor measured it;
- when the platform received it;
- when the integration read it.
The safety gate should reject missing timestamps, future timestamps beyond an allowed clock-skew window, and observations older than the system's documented freshness limit. Apply the same rule to dock-door state, aircraft-in-place detection, charging state, RTK status, network health, and camera availability.
A compact TypeScript-style check might look like this:
type GateResult =
| { ok: true; snapshotRevision: number }
| { ok: false; reasons: string[] };
function validateSnapshot(s: Snapshot, nowMs: number): GateResult {
const reasons: string[] = [];
if (nowMs - s.observedAtMs > 15_000) reasons.push("snapshot_stale");
if (!s.aircraftInPlace) reasons.push("aircraft_not_confirmed");
if (s.activeAlarmCount > 0) reasons.push("active_alarm");
if (!s.weather.dataQualityOk) reasons.push("weather_quality_unknown");
if (!s.network.commandPathHealthy) reasons.push("command_path_unhealthy");
if (s.maintenanceLock) reasons.push("maintenance_lock");
return reasons.length
? { ok: false, reasons }
: { ok: true, snapshotRevision: s.revision };
}
The example intentionally does not hard-code wind, temperature, rainfall, or battery thresholds. Those limits must come from the most restrictive verified value across the aircraft, payload, dock configuration, route, regulation, and operator procedure.
Use a command state machine
A boolean sent field cannot represent an external command safely. Use explicit states:
prepared
-> rejected_prewrite
-> dispatch_requested
-> accepted_unverified
-> verified
-> outcome_uncertain
rejected_prewrite means no external write occurred. It is safe to prepare a new intent after correcting the reason. accepted_unverified means the vendor acknowledged the request, but independent state has not yet proved the result. outcome_uncertain means a timeout or connection loss happened after transmission may have begun. That state must trigger readback, not a blind retry.
Persist the transition before and after the external call. The log should contain the intent ID, payload digest, vendor request correlation ID when available, response status, timestamps, adapter version, state revision, and redacted error class. It should never contain API keys, session tokens, or complete signed URLs.
Read back the effect independently
After a command is accepted, query the authoritative state surface. For a scheduled mission, verify the mission identifier, route revision, aircraft, dock, planned time, and enabled status. For a door or charging operation, verify the resulting hardware state and its observation timestamp.
Use a different read path when the platform provides one. For example, a command endpoint may acknowledge queueing while a mission-status endpoint reports execution. Telemetry can then confirm physical progress. These layers answer different questions and should not be treated as duplicates.
A successful readback should be narrow and deterministic:
const accepted = await adapter.dispatch(intent);
await ledger.markAccepted(intent.intent_id, accepted.correlationId);
const finalState = await adapter.readMission(accepted.missionId);
assert(finalState.intentId === intent.intent_id);
assert(finalState.revision === intent.mission_revision);
assert(finalState.aircraftId === intent.aircraft_id);
await ledger.markVerified(intent.intent_id, finalState);
If any assertion fails, preserve both records and escalate. Do not overwrite the mismatch with the newest response.
Keep humans at the right boundary
Human approval should apply to a complete, reviewable mission intent. The reviewer should see the route revision, aircraft and payload, launch window, forecast and live weather, site status, airspace or operating approval, expected communications path, and defined abort behavior.
The integration may automate collection, validation, expiry, and readback. It should not silently broaden an approval when a route, aircraft, payload, time window, safety limit, or site changes. Those changes create a new revision and may require a new approval.
This distinction also helps during incidents. Operators can determine whether a bad outcome came from incorrect source data, a validation defect, an authorization error, an adapter failure, vendor-platform behavior, or a physical-system fault.
Design network loss as a normal state
The UK03 listing describes optional 4G and mesh capabilities, but multiple bearers do not make a network infallible. Define behavior for at least these cases:
- the adapter cannot reach the vendor platform before dispatch;
- the request times out after bytes may have been transmitted;
- telemetry continues but the command channel is unavailable;
- the dock is reachable but the aircraft link is degraded;
- the WAN fails during a mission;
- buffered events arrive out of order after reconnection.
For each case, document which component owns the safe response. Flight-critical failsafes belong in the validated aircraft and approved control system, not in a remote web service. The external integration should observe and report those states without pretending it can replace them.
Test faults before unattended operation
A staging environment is useful, but it is not enough. The production configuration should go through controlled acceptance tests with the real dock, supported aircraft, network path, and management platform. Include:
- duplicate command delivery with the same intent ID;
- an expired intent arriving late;
- a route revision changing after approval;
- stale weather and dock-status observations;
- API timeout before and after request transmission;
- loss and recovery of WAN, RTK corrections, and telemetry;
- an aircraft not correctly detected in the dock;
- an active maintenance lock or unresolved alarm;
- a readback that disagrees with the accepted command;
- adapter restart during every state-machine transition.
Record the expected safe state and pass criterion before each test. A fault-injection exercise is successful when the system prevents or contains the unsafe action and preserves evidence, not merely when it emits an error message.
A practical production checklist
Before enabling an autonomous dock integration, confirm that:
- vendor API documentation matches the delivered hardware, licenses, and software version;
- read-only and command credentials are separated and can be rotated;
- every intent is immutable, versioned, expiring, and idempotent;
- observations include freshness and data-quality checks;
- command outcomes have explicit uncertain and verified states;
- retries require readback after any ambiguous transmission;
- logs are durable, redacted, time-synchronized, and reviewable;
- human approval covers the exact mission revision and operating window;
- aircraft and dock failsafes work without the external automation;
- controlled fault tests have been completed and defects closed.
The central design principle is simple: an automation system should only advance when it can prove that the required state, authorization, and prior outcome all match. Anything less becomes a stop condition. That approach may produce more visible refusals during development, but it also makes the integration understandable, testable, and safer to operate.
Review the current UK03 product listing for the published configuration starting point, then request the applicable API documentation, supported-aircraft matrix, licensing details, and acceptance procedure for the actual deployment.
