С развитием средств коммуникаций и вычислительной техники большое распространение получают технологии интернета вещей (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 в уже существующую систему.
Надеемся, были для вас полезными :)