{"id":13506,"url":"\/distributions\/13506\/click?bit=1&hash=27fcb5113e18b33c3be66ae079d9d20078d1c30f1b468cdc86ecaeefa18446c2","title":"\u0415\u0441\u0442\u044c \u043b\u0438 \u0442\u0432\u043e\u0440\u0447\u0435\u0441\u0442\u0432\u043e \u0432 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438? \u0410 \u0435\u0441\u043b\u0438 \u043d\u0430\u0439\u0434\u0451\u043c?","buttonText":"\u0423\u0436\u0435 \u043d\u0430\u0448\u043b\u0438","imageUuid":"2c16a631-a285-56a4-9535-74c65fc29189","isPaidAndBannersEnabled":false}
CodeInside

Анализ коммуникационных протоколов в сфере IoT для сбора данных с приборов учета

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

Концепция «умного» дома постепенно масштабируется до «умного» квартала и даже «умного» города. Одним из направлений автоматизации «умного» города является сфера жилищно-коммунального хозяйства.

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

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

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

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

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

Википедия дает достаточно емкое определение протоколу связи:

Протокол передачи данных (протокол связи) — набор определенных правил или соглашений интерфейса логического уровня, который определяет обмен данными между различными программами. Эти правила задают единообразный способ передачи сообщений и обработки ошибок.

Все протоколы можно разделить на 2 большие группы.

  • Протоколы, используемые для IoT — сюда попадают протоколы связи прикладного уровня, применимые для интернета вещей. При этом на рынке доступны конечные устройства (датчики, счетчики и т.д.), реализующие работу по этим протоколам. В качестве примера можно привести такие протоколы как MQTT, ModBus, AMQP, XMPP, ZigBee.
  • Протоколы, не имеющие никакого отношения к IoT. К этой группе относятся любые протоколы физического, сетевого и др. уровней, не имеющие реализаций на прикладном уровне, либо протоколы прикладного уровня, не используемые в сфере интернета вещей. Примеры: Ethernet, TCP, RS-232, Icmp и др.

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

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

Предлагается следующая сравнительная таблица протоколов.

Сравнительная таблица протоколов

Расшифровка критериев.

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

Возможность интеграции со шлюзом. Для обмена данными с устройством требуется аппаратный или программный шлюз, который берет на себя задачи по обмену данными с устройством. Примеры: брокер mqtt, шлюз ZigBee. Если устройство подразумевает работу исключительно с аппаратным проприетарным шлюзом, то это сильно усложнит поддержку данного устройства и протокола. С другой стороны, открытый программный шлюз MQTT, который может быть легко развернут на виртуальной машине или в образе docker, не создает каких-либо сложностей в работе с устройствами.

Распространенность, доступность. Здесь учитывается доля устройств на рынке, открытость протоколов, полнота и доступность документации, а также тенденции к росту или уменьшению количества устройств, поддерживающих этот протокол.

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

Исходя из представленного сравнения протоколов, наиболее релевантной выглядит реализация поддержки протоколов MQTT и ModBus. Причины такого выбора достаточно очевидны:

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

К тому же, реализация поддержки этих протоколов позволяет опробовать подходы к работе как с бинарными протоколами (ModBus), так и текстовыми (MQTT), как с шлюзовыми решениями (MQTT), так и точка-точка (ModBus). Полученные наработки в будущем можно будет использовать при реализации поддержки оставшихся протоколов.

Облачные решения, такие как «Стриж», «Saures», «МТС» следует рассматривать по отдельности, т. к. логика работы и API у них могут значительно отличаться. Решение о поддержке следует принимать, исходя из доступности конкретного облачного решения в целевом регионе/городе, а также из требований потребителей системы автоматизации.

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

Надеемся, были для вас полезными :)

0
Комментарии
Читать все 0 комментариев
null