Интеграция DJI Cloud API с корпоративной системой: вопросы до начала проекта

Сначала определите границы DJI Cloud API

Cloud API — не готовый пользовательский интерфейс и не полный аналог FlightHub 2. Это набор интерфейсов для подключения совместимых устройств к собственной облачной платформе. DJI публикует документацию по функциям устройств, управлению организацией, прямым трансляциям, медиаданным, маршрутам, событиям HMS и другим модулям.

Первый документ проекта — матрица совместимости. В строках указывают Dock, пульт, летательную платформу и полезную нагрузку; в столбцах — регистрация, телеметрия, управление миссией, трансляция, загрузка медиа, журнал состояния и обновление. Для каждой ячейки ставят ссылку на актуальную страницу документации и дату проверки.

Протоколы и компоненты архитектуры

Документация DJI разделяет обмен на MQTT-сообщения, HTTPS-запросы и отдельные механизмы передачи медиа и трансляций. Не следует сводить проект к одному «подключению по API». Сервер должен принимать события, хранить состояние, отправлять команды, обрабатывать повторную доставку и отличать временную потерю связи от отказа устройства.

Типовой безопасный контур включает шлюз подключения, брокер сообщений, сервис идентификации устройств, очередь событий, хранилище медиа, журнал аудита и корпоративный интерфейс. Конкретная реализация зависит от требований компании. Документация-пример DJI помогает запустить стенд, но не заменяет промышленную архитектуру, мониторинг и резервирование.

Для Dock отдельно проверяют процесс привязки к серверу, лицензирование, сетевую доступность и зависимости Pilot 2 или станции. Release notes важны: поддержка моделей и функций добавляется по версиям, поэтому спецификация должна фиксировать проверенную дату, а не обещать вечный паритет.

Какие данные проходят через интеграцию

Составьте каталог данных: идентификаторы устройств и организации, телеметрия, состояние батареи и станции, маршруты, события, предупреждения, фотографии, видео, прямые трансляции и пользовательские действия. Для каждого типа определите источник, частоту, срок хранения, потребителей и правила удаления.

Медиаданные требуют отдельного расчёта пропускной способности и хранения. Поток телеметрии мал по сравнению с фотографиями и видео, но критичен по задержке и порядку сообщений. Система должна корректно переживать повтор, задержку и временный разрыв связи, не создавая дублирующие задания.

Единицы измерения, системы координат, часовые пояса и семантику статусов документируют в модели данных. Иначе одинаковое поле может интерпретироваться по-разному аналитикой, операторским интерфейсом и архивом.

Безопасность и эксплуатационная ответственность

Секреты интеграции не хранят в исходном коде или пользовательском браузере. Используют управляемое хранилище секретов, ротацию, минимальные права и разделение тестового и промышленного контуров. Логи не должны содержать токены или персональные данные сверх согласованной цели.

Команды устройству требуют проверки авторизации, идемпотентности и аудита: кто инициировал действие, какой сервис его подтвердил и что вернуло устройство. Для критичных операций устанавливают двухэтапный пользовательский процесс и безопасное состояние при потере связи.

Назначьте владельцев: команда интеграции отвечает за приложение, ИТ — за инфраструктуру, служба эксплуатации — за устройство и регламент полётов, информационная безопасность — за модель угроз, а поставщик — за заявленную совместимость. Граница поддержки должна быть записана до пилота.

Пилот и критерии приёмки

1. Стенд: отдельная организация, тестовые устройства и изолированные учётные данные.
2. Happy path: регистрация, состояние, маршрут, медиа и журнал без ручной правки.
3. Сбои: потеря сети, повтор событий, истёкшая сессия, переполнение хранилища.
4. Нагрузка: согласованное число устройств, сообщений и медиаданных.
5. Безопасность: роли, ротация секретов, аудит и удаление тестовых данных.
6. Обновление: процедура проверки release notes, совместимости и отката.

Для готовой платформы управления сравните проект с материалом о решениях DJI Enterprise. Коммерческий состав разработки и оборудования можно запросить через форму КП.

Частые вопросы

Cloud API заменяет FlightHub 2?

Не автоматически. API предназначен для собственной платформы; FlightHub 2 — готовый продукт с интерфейсом и эксплуатационными функциями.

Можно ли начать с примера DJI?

Да, для стенда. Пример не является промышленной архитектурой и требует доработки безопасности, мониторинга и резервирования.

Поддерживается ли любой дрон DJI?

Нет. Совместимость зависит от модели, режима подключения и версии API. Её сверяют по документации на дату проекта.

Что фиксировать в договоре?

Устройства, функции, версии, ограничения, критерии приёмки, поддержку обновлений и границы ответственности.

Первичные источники

• DJI Developer — Cloud API Tutorial
• DJI Cloud API — Tutorial Map
• DJI Cloud API — Topic Definitions
• DJI Cloud API — Dock Access
• DJI Developer China

Источники проверены 08.09.2026. Материал не заменяет руководство производителя, юридическую экспертизу и проект внедрения.