Интеграция телематических данных с помощью HTTP Push в IoT Logic

В разных отраслях телематическим приложениям часто требуется больше контекста, чем могут предоставить только данные транспортных средств и устройств. Например, может понадобиться объединить пробег с данными о последнем техническом обслуживании из системы управления ТО. Есть несколько способов объединить такие данные, и выбор влияет на объем кода, инфраструктуры и дальнейшего обслуживания, необходимых для интеграции.

Обогащение данных с помощью HTTP Push, недавно добавленное в IoT Logic от Navixy, позволяет напрямую передавать внешние данные в телематическую обработку. Рассмотрим подробнее, как это работает, что можно построить с помощью этой возможности и что меняется с точки зрения интеграции.

Итак, что такое обогащение данных с помощью HTTP Push?

Обогащение данных с помощью HTTP Push позволяет внешней системе отправлять данные напрямую в Navixy IoT Logic, low-code среду для обработки и преобразования телематических данных от IoT-устройств и OEM-систем.

Внешняя система отправляет HTTP-запрос со своими данными. Настроенное сопоставление связывает входящие данные с соответствующим трекером и делает атрибуты доступными для обработки в IoT Logic.

Телеметрия трекера и внешние данные поступают независимо друг от друга.

Допустим, трекер передает:

hardware_mileage = 197450

а система управления техническим обслуживанием автопарка отправляет пробег, зафиксированный во время последнего ТО:

{
  "vehicle_ref": "VEH-318",
  "odometer_at_service": 182300
}

Теперь оба значения доступны в IoT Logic. Поток может рассчитать, что с момента зафиксированного технического обслуживания автомобиль проехал 15 150 километров, и использовать результат для дальнейшей обработки.

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

Что внешние данные добавляют в телематический поток

Добавление внешнего значения в IoT Logic полезно, когда оно может повлиять на то, что поток рассчитывает, решает или делает. Особенно хорошо это показывают два сценария.

Чтобы подробнее узнать о бизнес-сценариях такого подхода, прочитайте нашу статью об обогащении данных транспортных средств.

Создание условий на основе двух источников данных

Для некоторых операционных правил одновременно нужны телеметрия и информация, которая хранится в других системах.

Допустим, трекер сообщает, что рефрижератор въехал в геозону депо, а внешняя система передает:

inspection_required = true

IoT Logic может оценить оба значения и использовать результат для запуска следующего шага рабочего процесса.

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

Внешнее приложение предоставляет контекст, которым располагает. IoT Logic использует этот контекст вместе с данными трекера, поэтому ни одна из систем не должна содержать полное операционное правило целиком.

Запуск действия на стороне телематики из другой системы

Внешние данные также могут инициировать рабочий процесс в обратном направлении.

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

immobilization_requested = true

Запрос может поступить в IoT Logic через HTTP Push. Поток может проверить дополнительные условия и, если конфигурация потока и возможности трекера это позволяют, инициировать соответствующее действие с устройством.

Внешнему приложению не нужно самостоятельно реализовывать уровень коммуникации с устройством. Оно передает запрос на уровне бизнес-логики, а Navixy обеспечивает коммуникацию на стороне телематики.

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

Сопоставление внешних идентификаторов с трекерами

Исходной системе не обязательно идентифицировать объект так же, как это делает Navixy. Например, система управления техническим обслуживанием автопарка может уже использовать собственные идентификаторы транспортных средств:

VEH-318
VEH-319
VEH-320

При настройке обогащения данных с помощью HTTP Push подходящий параметр входящих данных можно использовать в качестве первичного ключа для сопоставления этих значений с трекерами:

VEH-318 → трекер 12345
VEH-319 → трекер 12346
VEH-320 → трекер 12347

Таким образом, система технического обслуживания может продолжать отправлять payload на основе собственного идентификатора:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

IoT Logic использует настроенное сопоставление для vehicle_ref, чтобы связать входящие данные с соответствующим трекером. Таким образом, преобразование идентификаторов остается на границе интеграции, и исходному приложению не приходится переходить на ID трекеров или другой специфичный для Navixy идентификатор.

От инфраструктуры интеграции к бизнес-логике

До появления обогащения данных с помощью HTTP Push внешние бизнес-данные нельзя было напрямую передавать в IoT Logic таким способом. Для этого мог потребоваться отдельный интеграционный компонент между внешним приложением и телематической обработкой.

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

HTTP Push переносит эту часть интеграции в IoT Logic. Внешняя система отправляет данные, настроенные сопоставления связывают их с трекерами, а поток определяет, что произойдет дальше.

Если собственный компонент в решении нужен главным образом для приема внешних данных и их подключения к телематической обработке, HTTP Push может полностью устранить этот инфраструктурный компонент. Для TSP или интегратора, который развертывает похожие решения для нескольких клиентов, это также означает на один сервис меньше для развертывания и поддержки в каждой реализации.

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

HTTP Push и другие механизмы интеграции Navixy

HTTP Push, Navixy Generic Protocol и Navixy API выполняют разные задачи.

Механизм	Роль
Обогащение данных с помощью HTTP Push	Добавление внешних атрибутов в IoT Logic и их привязка к существующему трекеру для обработки вместе с его телеметрией
Navixy Generic Protocol	Подключение источника, который сам выступает полноценным источником телематических данных и передает собственную телеметрию
Navixy API	Создание, чтение, обновление и удаление поддерживаемых сущностей и конфигураций Navixy

Особенно важно различать HTTP Push и NGP.

При использовании NGP подключенная система является источником телеметрии. При использовании HTTP Push телеметрия трекера уже поступает независимо, а другая система добавляет дополнительную информацию, связанную с этим трекером.

Это различие также задает техническую границу. Основные атрибуты позиционирования, такие как координаты, скорость, направление движения, количество спутников и HDOP, нельзя перезаписать с помощью обогащения данных через HTTP Push. Если другая система является фактическим источником этих измерений, ее следует подключать как источник телеметрии, а не использовать для обогащения данных.

Navixy API выполняет другую задачу. Он предоставляет программные CRUD-операции для поддерживаемых сущностей и конфигураций платформы, а не альтернативный способ передачи произвольных внешних данных для обработки в потоке IoT Logic.

Собственный интеграционный код по-прежнему может потребоваться в исключительных случаях, когда доступные механизмы платформы не позволяют выполнить требования интеграции. Однако он не должен быть необходим только потому, что у сторонней системы есть данные, которые требуется использовать при обработке в IoT Logic.

Конфигурация по-прежнему требует инженерного подхода

Перенос транспортного уровня и сопоставления в конфигурацию не отменяет интеграционный контракт.

Возьмем такое сопоставление:

VEH-318 → трекер 12345

Если трекер заменяется или внешний идентификатор меняется, сопоставление также необходимо изменить. Поэтому по мере роста развертывания стабильные идентификаторы становятся все важнее.

Названия и типы атрибутов требуют такой же дисциплины. Например:

maintenance_due
maintenance_work_order
odometer_at_service

проще поддерживать, чем универсальные поля status, id или value. А если поток ожидает:

{
  "maintenance_due": true
}

изменение значения на "yes" меняет контракт для логики, которая использует эти данные.

HTTP Push использует API-ключ, поэтому отправляющее приложение должно защищать эти учетные данные как секрет интеграции.

На этапе ввода в эксплуатацию Data Stream Analyzer помогает проверить, что ожидаемые идентификатор, сопоставление, атрибуты и последующая обработка корректно поступают в поток.

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

Настройка обогащения данных с помощью HTTP Push

Обогащение данных с помощью HTTP Push настраивается в узле Data Source в IoT Logic.

Выберите трекеры, которые должны получать внешние данные, и настройте HTTP Push в качестве программного источника данных. После сохранения потока IoT Logic предоставляет URL HTTP Push, который будет использовать внешнее приложение. Запросы аутентифицируются с помощью API-ключа.

Затем выберите входящий параметр, который будет использоваться в качестве первичного ключа, и настройте его сопоставление с соответствующими трекерами:

VEH-318 → трекер 12345
VEH-319 → трекер 12346
VEH-320 → трекер 12347

После этого внешнее приложение может отправить:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

IoT Logic определяет VEH-318 с помощью настроенного сопоставления и делает отправленные атрибуты доступными для обработки вместе с данными, которые независимо поступают от трекера.

Точные поля конфигурации и актуальные требования HTTP Push приведены в документации по обогащению данных с помощью HTTP Push.

Внешний контекст становится частью телематической логики

HTTP Push дает внешним бизнес-данным прямой вход в IoT Logic. Эти данные могут использоваться в условиях вместе с телеметрией трекера или инициировать рабочие процессы, которые продолжаются на стороне телематики.

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

Есть сценарий, в котором нужно объединить внешние данные и телеметрию? Свяжитесь с нашей командой, чтобы обсудить, как реализовать его с помощью IoT Logic.