Расширение данных о транспортных средствах в бизнес-системах

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

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

Целый проект по интеграции данных за несколькими дополнительными полями

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

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

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

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

Формат запроса и детали аутентификации описаны в технической документации. А здесь мы рассмотрим, что происходит с данными после их получения платформой.

Как внешние данные присоединяются к потоку данных транспортного средства

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

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

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

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

Расширение данных транспортных средств в реальных рабочих процессах

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

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

Подтверждение платежа может превратиться в действие с транспортным средством

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

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

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

Пример схемы в IoT Logic

Одна из возможных схем может выглядеть так:

Payment provider → HTTP Push → Сопоставление транзакции с транспортным средством → Проверка статуса платежа → Отправка команды разблокировки

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

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

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

Правила для транспортных средств часто работают с фиксированными порогами. Это работает до тех пор, пока условия вокруг транспортного средства не меняются.

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

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

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

Пример схемы в IoT Logic

Иллюстративная схема может быть следующей:

Погодная служба → HTTP Push → Сопоставление погодных условий с транспортным средством → Объединение с телеметрией транспортного средства → Применение специфичной логики → Оповещение или действие

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

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

Бизнес-записи могут сопровождать данные о транспортном средстве

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

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

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

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

Пример схемы в IoT Logic

Базовая схема может выглядеть так:

ERP / CRM / внутренняя система → HTTP Push → Сопоставление бизнес-атрибутов с транспортным средством → Обогащенные данные о транспортном средстве → Обработка или передача по цепочке

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

Какие атрибуты включать в поток, зависит от конкретной операции. Смысл не в том, чтобы копировать все записи из CRM или ERP в платформу, а в том, чтобы предоставить несколько значений, которые сделают данные о транспортном средстве более полезными.

Данные о батарее от OEM могут восполнить пробелы в телеметрии трекера

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

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

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

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

Пример схемы в IoT Logic

Одна из возможных схем выглядит следующим образом:

Платформа OEM / BMS → HTTP Push → Сопоставление данных с транспортным средством → Добавление атрибутов батареи → Объединение с телеметрией трекера → Обработка, оповещение или передача по цепочке

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

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

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

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

Когда еще один источник данных больше не означает еще одной интеграции

Для партнеров и системных интеграторов это меняет привычный разговор с клиентом. "Можем ли мы добавить эти данные в Navixy тоже?" уже не обязательно сразу приводит к "Нам придется разрабатывать интеграцию".

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

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

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