DJI Enterprise and AERONEX FH2 & UTM

FlightHub 2 Integration Architecture

FH2 & UTM

A practical integration model for pushing drone telemetry, mission events, and operator context from FlightHub 2 into a UTM or airspace management platform.

Telemetry Forwarding Event Callback MQTT Bridge REST / Middleware
Dock / Aircraft
FlightHub 2
Integration Interface
Middleware
UTM Platform
P0MQTT path
P1Events
P2API bridge

Integration Goal

Connect drone operations with low-altitude traffic awareness.

FlightHub 2 manages aircraft, Dock operations, route tasks, remote command, device status, and telemetry. The UTM platform needs selected data in a stable, governed format so it can display live aircraft positions, operational status, and mission-related events.

Situational awareness

Forward aircraft position, altitude, speed, heading, Dock state, and mission status into the UTM operating picture.

Event visibility

Push alarms, task events, device state changes, and operational updates through callback or middleware flows.

Airspace workflow

Allow UTM teams to consume drone operation status without manually watching multiple command platforms.

Project flexibility

Choose MQTT, webhook, REST, or middleware based on deployment mode, UTM capability, and customer IT constraints.

Reference Architecture

From Dock and aircraft telemetry to UTM platform consumption.

Capture DJI Hardware Dock 2 / Dock 3 and aircraft generate telemetry, device status, task updates, and events.
Operate FlightHub 2 Public Cloud or On-Premises deployment coordinates devices, users, tasks, routes, and live operations.
Integrate Interface Layer MQTT forwarding, event callbacks, OpenAPI, or middleware converts FH2 data into the UTM-side contract.
Consume UTM Platform Receives live status and events for airspace awareness, monitoring, review, and operational coordination.

Integration Paths

Choose the path based on deployment mode and UTM capability.

P0 Primary

MQTT Bridge / Telemetry Forwarding

Best fit when the UTM platform can provide or consume an MQTT broker.

  • Real-time OSD and device status forwarding.
  • Works well for live map rendering and airspace awareness.
  • Requires broker address, port, authentication, TLS, topics, and IP allowlisting agreement.
P1 Recommended

Event API / Webhook

Best fit for event-driven updates where UTM does not need every telemetry sample.

  • Pushes alarms, task changes, device events, and operator-related updates.
  • UTM provides HTTPS endpoint, authentication method, and payload acknowledgement logic.
  • Useful as a lightweight starting point before deep integration.
P2 Flexible

Middleware / REST Bridge

Best fit when the UTM platform prefers REST, WebSocket, or a custom API model.

  • Middleware subscribes to FH2-side data and transforms payloads.
  • Can normalize coordinate, timestamp, device identity, and task fields.
  • Adds project control, but needs clear ownership and maintenance responsibility.

Telemetry Content

UTM-relevant fields should be agreed before integration.

Data group Typical fields UTM value Notes
Aircraft OSD Latitude, longitude, altitude, speed, heading, battery, flight mode Live map position and traffic awareness Use WGS84 coordinates and agreed timestamp format.
Dock / device status Online state, Dock state, aircraft SN, device health, charging / standby state Asset supervision and operational readiness Field availability depends on device model and FH2 deployment mode.
Task / route status Task ID, task state, route progress, mission result, execution time Mission awareness and post-operation review UTM should define whether it needs live progress or only event updates.
Alerts / events Device alarm, task exception, battery warning, connectivity state Operational alerting and incident workflow Event callback is often the cleanest channel for this group.

UTM-side Preparation

What the UTM platform should provide before technical onboarding.

The integration can move quickly when the receiving platform confirms its preferred interface, security rules, and payload contract upfront.

For MQTT

Broker address and port, user/password or client certificate, TLS requirement, topic plan, QoS expectation, and source IP allowlist.

For Webhook

HTTPS endpoint, authentication method, retry and acknowledgement rules, event schema, and failure handling policy.

For REST / WebSocket

API endpoint, auth scheme, JSON payload schema, rate limit, session policy, and map refresh requirement.

For Security Review

Network zone, firewall rules, certificate policy, log retention, account roles, and data residency requirement.

Deployment Mode

On-Premises gives the deepest integration surface; Cloud can still support practical forwarding.

On-Premises / AIO

Recommended for production-grade UTM integration

  • Better fit for data sovereignty and customer-controlled network boundaries.
  • Supports deeper integration patterns including MQTT bridge, event callback, and broader API access.
  • Requires clear system integrator ownership for infrastructure, security, and maintenance.
Public Cloud

Useful for faster proof-of-concept and lighter workflows

  • Can support telemetry forwarding and event-based integration where available.
  • Scope can be narrower than On-Premises and should be validated before customer commitment.
  • Best used when customer policy allows cloud operation and the UTM requirement is not deeply customized.

Recommended Roadmap

Start with visibility, then deepen toward operational control.

A phased path reduces integration risk and gives the customer a visible result before committing to deeper platform-to-platform automation.

Suggested phases

  • Phase 1: Confirm UTM receiving interface and payload schema.
  • Phase 2: Forward live telemetry for map display and device visibility.
  • Phase 3: Add event callbacks for alerts, tasks, and operational exceptions.
  • Phase 4: Add middleware transformation, audit logs, and customer-specific rules.
  • Phase 5: Evaluate whether any command/control workflow is required and permitted.

AERONEX Positioning

A practical bridge between DJI Enterprise operations and customer UTM systems.

AERONEX can support the solution framing, integration scoping, partner coordination, and technical onboarding needed to connect FlightHub 2 workflows with UTM or low-altitude management platforms.

Reference input: supplied FH2 & UTM Integration Architecture HTML deck, restyled and customer-facing. Technical note: final interface availability must be confirmed against the selected FlightHub 2 deployment mode, product version, customer network policy, and UTM platform capability. Security note: broker credentials, certificates, endpoint authentication, IP allowlisting, and data retention must be agreed during project onboarding.