Для интернета вещей MQTT стал основным протоколом данных. Для связи устройств и облачных приложений эта легковесная реализация шаблона «Издатель-подписчик» с качеством обслуживания оказалась лучшим выбором. Транспортная телематика, которая является частью мира IoT, также активно переходит на MQTT.
В этом посте мы расскажем почему протокол MQTT становится все более важен для интеграторов GPS-решений, каких технических трудностей стоит ожидать при его внедрении, и как Navixy помогает их обойти.
Сложные и масштабные проекты переходят на MQTT первыми
Сегодня в транспортной телематике MQTT главным образом используется в крупных и многофункциональных системах. Именно в них приходится сочетать оборудование и приложения от разных вендоров и разной степени новизны. Для масштабируемых проектов важно, чтобы эти компоненты было легко интегрировать и поддерживать независимыми командами разработчиков. Поэтому если вы создаете такие системы, то наверняка уже столкнулись с MQTT или это произойдет в скором времени.
Если посмотреть на те проекты, которые реализуются партнерами Navixy с использованием MQTT, то чаще всего сегодня они находятся в следующих сферах:
- Управление цепочками поставок
Крупные торговые сети и производства требуют от своих поставщиков четкого соблюдения графика поставок и условий транспортировки, например, температуры груза. Поскольку автопарки поставщиков оснащены самыми разными системами от большого числа GPS-провайдеров, данные от них приходится аккумулировать из разных источников. - Приложения Gig и Sharing экономики
В сервисах для такси, автоаренды, каршеринга, городской мобильности необходимо обрабатывать большие массивы данных, состоящих из машинных данных и пользовательских запросов. При этом информация зачастую должна обрабатываться молниеносно, а серверы могут быть расположены в разных регионах. - Страховая телематика
Расчет страховых премий и расследование обстоятельств дорожных происшествий – два аспекта, в которых страховые компании все больше полагаются на данные, собранные со специальных автомобильных устройств. Между тем, анализ объема использования, скоринг навыков вождения, реконструкция ДТП, статистическая и предиктивная аналитика — это отдельные задачи, предполагающие сложные алгоритмы процессинга. Поэтому обмен IoT данными между устройствами и приложениями здесь играет ключевую роль. - Умные города, налоговое и госрегулирование
Решение вопросов дорожной безопасности, трафика и состояния окружающей среды в современных городах связано с использованием сигналов от миллионов датчиков, смонтированных на транспорте и объектах инфраструктуры. Эти данные рассматриваются во взаимосвязи и образуют единый контекст для управления на всех уровнях. Поэтому требуется эффективный обмен данными при одновременном соблюдении законодательства о месте их хранения и обработки.
Многие из таких проектов реализуются на базе Navixy Cloud и облачных IaaS, включая специализированные IoT-платформы AWS IoT platform, Google Cloud IoT, IBM Watson IoT platform, Microsoft Azure IoT и др.
Поддержка протокола MQTT производителями GPS-трекеров становится фактором выбора в их пользу
Производители устройств для транспортной телематики, конечно же, хотят, чтобы интеграторы использовали именно их продукцию в наиболее крупных проектах. Поэтому протокол MQTT встречается в новых линейках оборудования все чаще. Такие модели сейчас массово выпускают DCT, Xirgo, Globalmatix, Teltonika, TOPFLYtech и другие компании.
Поскольку в основном проекты с MQTT оказываются достаточно специфичны, пилотными для производителей становятся устройства с гибкой конфигурацией. Например, это 4G-шлюзы с возможностью подключения разнообразных датчиков, работы с CAN-шиной, задания программной логики. Но постепенно протокол MQTT появляется хотя бы в виде опции и на других моделях, даже с простейшей функциональностью. При этом производители очень рационально используют преимущества протокола MQTT, включая паттерны подписок (topics) и три уровня обслуживания (QoS).
Практические трудности при построении транспортных телематических систем на базе MQTT
Несмотря на то, что MQTT является удобным и распространенным протоколом для создания IoT-решений, его реализации в разных автомобильных устройствах и особенности транспортной телематики требуют дополнительного внимания со стороны интеграторов, производителей и разработчиков.
А именно, на практике приходится учитывать два фактора:
- Поступающие от устройств данные неоднородны. Из-за разнообразия моделей GPS-трекеров, подключенных датчиков и самих автомобилей, данные поступают в разных форматах, единицах измерения, требуют дополнительных вычислений и т.д. Бывает даже так, что внутри MQTT находятся обернутый в него проприетарный протокол производителя устройств. Поэтому если предварительно не производить нужные манипуляции с данными, чтобы привести их к одному виду, разработчикам IoT-приложений придется решать эти задачи для каждого функционального модуля отдельно, а это перечеркивает основную пользу от MQTT как от универсального и простого протокола.
- Автомобильные IoT-устройства не только передают данные приложениям, но и регулярно получают от них команды. Для этого в устройствах реализуется не только Publish, но и Subscribe механизмы MQTT. Семантика и синтаксис команд в значительной мере определяются аппаратными возможностями устройств и тем, для каких целей они используются в автомобилях. Для разработчиков приложений выгоднее абстрагироваться от этих различий, чтобы сэкономить время на разработку и сделать систему более масштабируемой.
Для того, чтобы помочь интеграторам эффективно преодолеть эти трудности, в состав платформы Navixy может быть включен модуль MQTT Central. Он помогает унифицировать коммуникацию между IoT устройствами и приложениями.
MQTT Central как «вокзал» для транспорта между IoT компонентами системы
Navixy MQTT Central — это опциональный модуль платформы, который позволяет интеграторам и разработчикам легко организовать обмен между IoT устройствами и приложениями по общепринятому протоколу MQTT.
При этом важным преимуществом MQTT Central является то, что передаваемые данные и команды могут быть попутно унифицированы, то есть стандартизованы и нормализованы. Это позволяет разработчикам абстрагироваться от не принципиальных для бизнес-логики особенностей, таких как «зоопарк» используемых GPS-устройств или различия в CAN-контроллерах автомобилей.
Благодаря MQTT Central создание, кастомизация и объединение телематических систем может быть выполнено в более короткие сроки, решения будут обладать высокой отказоустойчивостью и отличной масштабируемостью, а также совместимы с современными IoT-платформами.
Среди дополнительных преимуществ Navixy MQTT Central, обусловленных внутренней архитектурой, стоит выделить:
- JSON или XML: вывод данных в выбранном протоколе с низкой задержкой
- REST API и ETL: выгрузка данных в ERP и BI-системы
- On-Premise или Cloud с 99.9% доступностью
Представить возможности такого подхода с разных сторон более наглядно помогут два юз-кейса.
Пример А. Сервис автоэвакуаторов и помощи на дорогах
В качестве первого и наиболее простого примера приведем систему, которую построил партнер Navixy для крупного национального сервиса помощи на дорогах. Автопарк клиента, состоящий из автоэвакуаторов и «техничек», был уже оснащен оборудованием фирм Skypatrol, Concox и TOPTFLYtech. Партнеру требовалось разработать для клиента кастомное решение по ситуационному мониторингу с выводом информации на экраны в четырех региональных диспетчерских центрах. В системе использовались параметры автомобилей включая местоположение и скорость, а также статус доступности автомобиля для нового вызова.
Таким образом, данные предстояло собирать в реальном времени с большого числа разных устройств, работающих как по MQTT-протоколу, так и по проприетарным, и независимо обрабатывать в четырех локациях. Сначала планировалось использовать межсерверную ретрансляцию данных, которая позволила бы обмениваться данными моментально и решила бы проблему унифицированного протокола, который бы не зависел от устройств. Однако использование Navixy MQTT Central и, соответственно, протокола MQTT для связи между приложениями, позволило ускорить разработку приложения, сделать систему более масштабируемой (планировалось введение дополнительных диспетчерских центров) и отказоустойчивой благодаря Subscription-модели с QoS 1 и QoS 2.
Пример Б. Сервис каршеринга и аренды автомобилей
Второй пример демонстрирует преимущество так называемых топиков MQTT, когда отдельные компоненты сложных программных систем могут подписываться на необходимый набор данных. То есть с помощью топиков можно определить подмножество данных, которое получает то или иное приложение большого программного комплекса.
В данном примере компания, которая работает в сегментах Сar Sharing и Rent-a-Car, самостоятельно занимается программной разработкой ключевых для бизнеса приложений. При этом отдельные функциональные модули создаются и поддерживаются разными командами разработчиков. Отчасти такое разделение обусловлено соображениями продуктивности, отчасти произошло из-за организационных причин, поскольку компания активно росла за счет поглощения конкурентов.
Автопарк компании, к тому времени насчитывающий больше 1,5 тысяч автомобилей, оборудовался преимущественно специально разработанными телематическими шлюзами. В них имеются GPS-навигация, работа с CAN-шиной и другие датчики, а также мобильное видеонаблюдение MDVR.
Операционная часть бизнеса осуществляется на базе собственной программной платформы, при этом за каждой из ее функций отвечает отдельная команда:
- Мобильные приложения с рекомендацией ближайших доступных автомобилей, заказ и оплата и другие аспекты взаимодействия с пользователем;
- Обслуживание автомобилей с помощью штата водителей перегонщиков и техников подготовки автомобилей на основе информации об остатке топлива, пробеге, сигналах ошибок системы самодиагностики DTC и др.;
- Реагирование на нештатные ситуации включая несанкционированное использование, ДТП, повреждения и угоны;
- Расчет стоимости поездок включая скоринг водителей по резким маневрам и нарушением ПДД.
Каждый из этих модулей представляет собой самостоятельную и по-своему сложную задачу, однако зачастую в них используются общие данные GPS, акселерометра, CAN-шины и датчиков, видеонаблюдения и т.д. Поэтому программистам было важно иметь возможность легко получать необходимые данные и отправлять команды на устройства. Например, для своевременного технического обслуживания из CAN-шины важно получать статус MIL и коды ошибок, VIN-номер, показания одометра, а для скоринга водителей — сведения о скорости, ремне безопасности, положения педали акселератора, оборотах двигателя.
Использование Navixy MQTT Central позволило реализовать эти задачи наиболее эффективным образом. Команды разработчиков смогли настроить получение их приложениями необходимых данных и отправки на устройств команд. При этом они сэкономили время, объединив старые системы и актуальную в одно общее пространство, отказались от работы с устройствами на низком уровне и смогли сфокусироваться на развитии бизнес-функционала. Преимущества MQTT также обеспечили высокую надежность связи географически распределенных серверов и дальнейшую масштабируемость системы.
Важность MQTT для построения современных систем транспортной телематики и IoT
Как заложенные в MQTT возможности, так и сама растущая популярность этого IoT-протокола подталкивают производителей, разработчиков и интеграторов активно переходить на его использование. Реализуемые в последнее время проекты для мониторинга транспорта и подвижных объектов это наглядно подтверждают. Со временем будет создаваться больше GPS-систем на базе MQTT, причем не только функционально сложных, но и массовых.
Разработка продуктов и внедрение решений на основе MQTT обходится дешевле. Их развертывание и кастомизация происходят быстрее, а развитие и поддержка упрощается. Вместе с тем, всегда есть нюансы, связанные с особенностями реализации MQTT в GPS-устройствах и конкретных юз-кейсах. Navixy MQTT Central позволяет исключить эти особенности и сфокусироваться на содержательной части создания масштабируемых и надежных решений. Функциональность MQTT Central доступна во всех трех вариантах поставки Navixy и легко интегрируется с ведущими облачными IoT платформами.
