DroneCommand™ separates the command layer from the vehicle.
The architecture exists to make one thing possible: adding a new asset type should be an integration task at a single layer, never a migration of the whole system.
Sovereign deployment topology: on-premise, edge or air-gapped.
Four layers, one boundary that matters.
- 01
COMMAND LAYER
Mission, tasking and the shared picture
- 02
AUTONOMY SERVICES
Perception, classification, planning
- 03
HARDWARE ABSTRACTION LAYER
One interface, many vehicles
- 04
AGENTS
Aerial, ground and static assets
Mission, tasking and the shared picture
Operators express intent as tasks against capabilities. The command layer resolves which agents can satisfy a task, maintains the shared situational picture and records every authorisation decision.
Perception, classification, planning
Assistive services run alongside the command layer, on the edge or on your infrastructure. They propose; they never actuate. Availability of these services is not a precondition for flight.
One interface, many vehicles
Vehicle-specific behaviour is confined to adapters built on open standards and open-autopilot platforms. Adding a manufacturer touches this layer only.
Aerial, ground and static assets
Each agent publishes state and capabilities and executes authorised tasks. Flight control remains onboard and independent of the command layer.
Three topologies, one codebase.
The deployment topology changes where the software runs, not what it does. Interfaces, authorisation model and audit behaviour are identical across all three.
Full deployment inside your data centre, under your administration and your network policy.
Command and autonomy services co-located with the operation for low latency and link independence.
No external connectivity. Local model execution, offline update packaging, local audit storage.
Open where it counts.
| Interface | Purpose |
|---|---|
| REST + streaming API | Tasking, telemetry subscription, fleet state and audit export. |
| Open-standard vehicle interfaces | Adapters speak the open protocols already used by supported autopilot platforms. |
| Existing ground control software | Can remain in the loop during transition in most deployments. |
| Audit and logging export | Structured, timestamped records of every authorisation and task transition. |