CC BY
50
Cloud of Science. 2019. T. 6. № 4 http:/ / cloudofscience.ru
Микроконтроллерная реализация распределенной доставки ZMQ сообщений для интернета вещей1
А. Б. Колкер*,**, C. C. Дубров*,***
Новосибирский государственный технический университет 630073, Новосибирск, пр-т К. Маркса, 20
Сибирский региональный научно-исследовательский гидрометеорологический институт 630099, Новосибирск, ул. Советская, 30
Институт ядерной физики Г. И. Будкера СО PAH 630090 Новосибирск, пр-т Академика Лаврентьева, 11
e-mail: a.kolker@corp.nstu.ru, dubrovss@binp.nsk.su
Аннотация. В статье изложено описание разработки отдельной модели библиотеки ZeroMQ для микроконтроллерных устройств. Рассматриваются основные модели библиотеки распределенного обмена сообщениями ZeroMQ и обосновывается выбор модели издатель-подписчик при использовании 8-битного микроконтроллера AVR. Приведена схемотехническая реализации TCP/IP стека для микроконтроллера ATmega328P при помощи устройства с сопроцессором Ethernet WIZnet W5500. Рассмотрена и обоснована алгоритмическая реализация модели издатель-подписчик. В заключение исследована программная реализация модели издатель-подписчик при помощи измерения временных характеристик выполнения процедуры рассылки и чтения сообщений. Ключевые слова: интернет вещей, распределенный обмен данными, библиотека ZeroMQ, связующее программное обеспечение, модель издатель-подписчик.
1. Введение
Распределенные системы управления и обработки данных нуждаются в надежном и скоростном протоколе обмена информацией для взаимодействия между собой. Одним из популярных стандартизированных протоколов для этой цели является MQTT (message queuing telemetry transport). Также существуют нестандартизиро-ванные протоколы, основанные на очередях сообщений, изначально не предназначенные для промышленного применения, однако успешно себя зарекомендовавшие в автоматизации и сборе телеметрических данных и постепенно замещающие ранее применявшиеся устоявшиеся подходы.
1 Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта № 18-5876003
Одним из таких протоколов является ZeroMQ. Первые релизы проекта появились в 2012 г., и за время своего развития библиотека успешно применялась во множестве проектов, например в связующем программном обеспечение для работы ускорителей CERN и пришла на замену COBRA, опередив остальных кандидатов по совокупности оценок [1]. Данная библиотека проста в применении, обладает хорошей производительностью, полной документацией, обширным сообществом и реализацией для многих языков программирования.
Помимо CERN, ZeroMQ пользуются следующие производители и разработчики: AT&T, Cisco, EA, Los Alamos Labs, NASA, Weta Digital, Zynga, Spotify, Samsung Electronics and Microsoft [2].
2. Библиотека обмена сообщениями Zmq и ее реализации
ZeroMQ — это система обмена сообщениями или «связующие программное обеспечение, ориентированное на сообщения». Она используется в таких разнообразных средах, как финансовые услуги, разработка игр, встроенные системы, научные исследования и авиакосмическая промышленность [3].
Традиционные системы распределенного обмена сообщениями нуждаются в центральном сервере сообщений, так называемом «брокере». Каждый узел связывается с другими узлами системы, используя брокера как посредника, что имеет свои сильные и слабые стороны. Системы, которые не нуждаются в брокере (к которым и относится ZMQ), оказываются намного проще в реализации и, как правило, более гибкими и быстрыми [4]. В случае с ZeroMQ при необходимости брокер может быть организован при помощи функциональных возможностей библиотеки, однако для реализации базовых моделей обмена данными необходимости в его применении нет. В дизайне без брокера приложения должны обмениваться данными напрямую — без посредников. ZeroMQ поддерживает несколько шаблонов MQ-сообщений следующих типов:
- запрос-ответ (REQ-REP) — связывает набор клиентов с набором услуг — это удаленный вызов процедур и шаблон распределенных задач;
- издатель-подписчик (PUB-SUB) — связывает набор издателей с набором подписчиков — это шаблон распределения данных.
- конвейер (Pipeline) — соединяет узлы путем разветвления и слияния в шаблонах, которые могут иметь несколько шагов и циклов — это шаблон параллельного распределения и сбора задач.
- эксклюзивная пара (Exclusive pair) — соединяет исключительно два соке-та — этот шаблон предназначен для соединения двух потоков в процессе и не предназначен для традиционных Berkley пар сокетов [5].
Помимо названных реализованы и другие шаблоны (XPUB, XSUB, DIALER), которые расширяют возможности существующих методов, но для контроллерной реализации не являются приоритетными.
Библиотека ZeroMQ может быть использована для управления и вычислений в распределенных системах. Она реализована под Linux, Windows, MacOS и других популярных ОС и имеет поддержку более чем на 50 языках программирования [6]. К сожалению, до настоящего времени не существовало реализаций модели, способной функционировать при помощи интегральных схем и микроконтроллеров, хотя к этому существует довольно большой интерес со стороны инженеров — разработчиков устройств. Единственная существующая на момент написания данной статьи реализация [12] способна обеспечить только метод "PUSH", с большим количеством ограничений и без возможности создания ответной части, что существенно ограничивает ее область применения.
Наибольший интерес для создания распределенных систем автоматики представляет модель обмена издатель-подписчик (PUB/SUB). Это поведенческий шаблон проектирования передачи сообщений, в котором издатели напрямую не привязаны программным кодом отправки сообщений к подписчикам. Вместо этого сообщения делятся на классы и не содержат сведений о своих подписчиках, если таковые есть. Аналогичным образом подписчики имеют дело с одним или несколькими классами сообщений, абстрагируясь от конкретных издателей [7]. Важной особенностью данной модели является отсутствие обязательств у абонентов (подписчиков) перед сервером, а у сервера (публикатора) перед абонентами. Отключение/подключения как сервера, так и клиента в произвольный момент времени не является исключительной ситуацией и не приводит к состоянию ошибки. Такой шаблон передачи данных нашел широкое применение в промышленном интернете вещей для сбора информации с телеметрических датчиков, где датчики — это издатели, а компьютеры или другие вычислительное устройства — подписчики. Инициатива в этом случае лежит на устройстве издателе, а жесткие обязательства по публикации и подписке не выдвигаются. Зеркальная модель, когда компьютер является издателем, а микроконтроллер (устройство) подписчиком, является также весьма востребованной поведенческой моделью интернета вещей, реализующая произвольное подключение и отключение компонент без необходимости переинициализации всей системы.
Обмен сообщениями пары сокетов типа издатель-подписчик происходит в асинхронном режиме. В ZeroMQ подписчик получает сообщение из очереди (message queue) столько раз сколько вызвана функция zmq_recv(). В случае отсутствия сообщений подписчик блокирует выполнение потока, пока не будет получено
сообщение. Попытка послать сообщение zmq_send() подписчиком вызовет ошибку, так же как и попытка получить сообщение zmq_recv() издателем [8].
Отсутствие реализации библиотеки ZeroMQ для микроконтроллеров, усложняет интеграцию встраиваемых устройств в системы, где используется данный протокол распределенного обмена сообщениями. В таком случае приходится вводить дополнительный интерфейс между компьютером и микроконтроллером, что усложнит разработку такой системы. В таком случае будет необходимо синхронизировать работу разных интерфейсов, а также отлаживать и тестировать их по отдельности. Реализация модели издатель-подписчик ZeroMQ для микропроцессорных устройств позволит разместить их на одном уровне с прикладным ПО, тем самым поможет избежать вышеперечисленные проблемы и упростит разработку архитектуры системы.
3. Схемотехнические особенности сопряжения с микроконтроллером
Реализация вычислительно-затратных сетевых протоколов целесообразна на специализированных сетевых сопроцессорах. Устройства с сопроцессором Ethernet уже имеют полную реализацию TCP/IP протокола, а управление и доступ к регистрам, буферу данных происходит через сторонний интерфейс. Это освобождает центральный контроллер от множества задач по формированию пакетов и повышает общую эффективность системы. В работе применяется популярное Ethernet устройство WIZnet W5500 — аппаратное решение со встроенной буферной статической памятью для организации сокетов, что обеспечивает высокую производительность канала Ethernet и одновременно простое управление, и возможность полноценной реализации стека при использовании даже сравнительно вычислительно слабых 8-битных микроконтроллеров [9].
Чип W5500 в режиме ведомого предоставляет интерфейс SPI (последовательный периферийный интерфейс) с 4 сигналами (SCSn, SCLK, MOSI, MISO) для внешнего устройства, которое будет управлять чипом в качестве ведущего.
WIZnet W5500 может быть подключен через SPI интерфейс к микроконтроллеру, как показано на рис. 1 и 2, в соответствии с его режимом работы (режим данных переменной длины / данных фиксированной длины). В режиме данных переменной длины (как показано на рис. 1) можно использовать шину SPI с другими устройствами SPI. В режиме с фиксированной длиной (как показано на рис. 2) SPI шина выделена для W5500 и не может быть использована совместно с другими устройствами.
SPI MASTER 4 SPI SLAVE
мси (External Host) W5500
SCSn SCLK MOSI MISO SCSn SCLK MOSI MISO
Рисунок 1. Режим данных переменной длины (БСБп управляется внешним устройством)
Рисунок 2. Режим фиксированной длины (БСБп подключена на землю)
На рис. 3 и 4 представлены схемы подключения микроконтроллера ATmega328P и чипа W5500. Вход ЮТп работает в активном низком режиме. Его необходимо подключить, если планируется использовать регистр прерывания чипа WIZnet. Настройка регистра прерывания происходит через SPI интерфейс и подробно описана в документации W5500 [9, с. 34-38, 48, 57]. При использовании чипа W5500 стоит обратить внимание на то, что напряжение питания и логических уровней для него будет различаться — 3.3 и 5 вольт соответственно, а напряжение питания для ATmega328p лежит в диапазоне 1.8-5 вольт.
Рисунок. 3. Схема подключения Ethernet контроллера W5500 через SPI шину
Рисунок 4. Схема подключения микроконтроллера ATmega328P через SPI шину
В TCP/IP протоколе контроль доставки сообщения происходит путем отправки сообщения ACK от получателя к источнику. По умолчанию чип W5500 использует Delayed ACK. Это означает, что WIZnet делает некоторую задержку перед посылкой сообщения ACK. Delayed ACK конфигурируется в 5 бите регистра Sn_MR [10, с. 44], а задержка — в регистре RTR [10, с. 38]. Регистр RTR также отвечает за время ожидания ACK сообщения отправителем. По истечении этого времени отправитель сделает повторную отправку (retransmission) сообщения.
При настройках по умолчанию время ожидания ACK сообщения у отправителя и время его отправки у получателя будет одинаково и равно 200 мсек. Такая ситуация будет приводить к гарантированной ретрансмиссии у отправителя. Более того, пока чип отправитель не получит подтверждения от чипа получателя (или число ретрансмиссий не превысит порог), он не освободит участок памяти выходного буфера, ожидающий подтверждение получения ACK. Настройки регистра времени ретрансмиссии по умолчанию (200 мсек) для выходного буфера 2кб приводят к переполнению и потерям данных уже на скоростях обмена сообщениями выше 10 Кбайт/с. Поэтому для высокопроизводительных приложений рекомендуется отключать Delayed ACK либо уменьшать его задержку RTR.
4. Алгоритмическая реализация моделей
Прежде чем начать обмен сообщениями, участники протокола должны пройти несколько этапов авторизации. Данная процедура обязательная для всех моделей ZeroMQ и проходит по одинаковому принципу.
- Приветствие (Greetings). Оба участника согласовывают версию и механизм безопасности подключения, отправляя друг другу данные, или закрывают соединение.
- Рукопожатие (Handshake). Прохождение механизма безопасности путем договоренности о методе шифрования или обмена NULL-сообщениями в случае отсутствия его.
- Метаданные (Metadata). В качестве финальной команды оба участника передают друг другу метаданные о соединение. Каждый узел проверяет полученные метаданные и принимает решение о продолжении соединения или его закрытии.
После прохождения авторизации может происходить обмен сообщениями в рамках используемой модели. Формат и последовательность передачи данных при авторизации и работе приведены в официальный документации ZeroMQ в формате БНФ [11].
В модели обмена сообщениями издатель-подписчик их отношение представлено как один ко многим. В ранних версиях ZeroMQ издатель рассылал сообщения всем подписчикам. Решение принять или отклонить сообщение проходило на стороне подписчика, который хранил список всех своих подписок. В версиях 3.0 и выше список подписок хранится также и на стороне издателя, что позволяет сократить трафик между узлами.
Модель издателя выполнена следующим образом:
- соединение с несколькими подписчиками;
- чтение только подписок/отписок;
- асинхронная передача сообщений;
- контроль соединений;
- хранение подписок и их подписчиков.
Разрабатывая протокол ZeroMQ для микроконтроллерных устройств, нужно помнить об ограниченности их ресурсов. Основной ресурс — это оперативная память. Второй не менее важный ресурс, особенно если планируется разрабатывать систему реального времени, это скорость выполнения алгоритма.
Прежде чем разослать сообщение, издатель должен найти всех участников, подписанных на заголовок этого сообщения. Поиск строки в некоторой структуре данных — это ресурсоемкая операция, поэтому необходимо минимизировать количество ее выполнений. Использование ассоциативного массива позволяет снизить количество операций поиска до 0(1) в случае хэш-таблицы и O (log n) в случае красно-черного дерева, если в качестве ключа использовать строку-подписку. Тогда значением для соответствующего ключа будет список подписанных клиентов, которых можно представить в виде 8-битовой маски — по количеству максимально возможных соединений на чипе W5500.
Хэш-таблицы хорошо себя зарекомендовали при работе со статическими множествами, такими как словари. Однако в множествах, где количество данных заранее не предопределено и может меняться в широком диапазоне, хэш-таблицы не так эффективны. В нашем случае количество строк-подписок изначально равно 0, и сколько их будет заранее неизвестно. Для того чтобы обеспечить временную
сложность поиска строки-подписки, близкую к 0(1), хэш-таблице необходимо поддерживать коэффициент наполнения на нужном уровне. Каждый раз при превышении этого коэффициента хэш-таблица должна быть переиндексирована, что ведет к созданию новой таблицы, в которую заново заносятся все пары ключей и значений. Поэтому выбор красно-черного дерева предпочтительнее, так как в этом случае всегда можно предположить, что вставка, удаление и поиск будут выполнены за время O (log n ).
Алгоритм рассылки издателем представлен на рис. 5 и может быть описан тремя основными действиями:
- проверка задействованных сокетов;
- проверка входящих сообщений подписок/отписок;
- поиск подписанных на заголовок и рассылка сообщения.
Издатель выполняет проверку соединений при каждом вызове процедуры рассылки. При этом на стороне издателя всегда сохраняется правило: в активном состоянии находится только один слушающий сокет со статусом LISTEN или ни одного, если все сокеты заняты. В случае, когда какой-нибудь из подписчиков закончит сеанс, издатель закрывает сокет, соответствующий конкретному подписчику, завершившему работу. В случае, если на слушающем сокете появилось новое соединение, издатель откроет новый слушающий сокет со статусом LISTEN.
При получении сообщения издатель проверяет его на соответствие формату подписки/отписки. В случае несоответствия формату отбрасывает его, так как в модели издатель-подписчик отсутствует прием сообщений издателем.
В ZeroMQ существует класс подписок на все сообщения от издателя, который представлен в виде нулевой строки. Поэтому при поиске подписчиков, зарегистрированных на какой-то класс сообщений, нужно также учитывать подписчиков, зарегистрированных на все сообщения.
Шаблон подписчик выполнен следующим образом:
- подключение и подписка к нескольким издателям;
- блокирующее чтение входящего сообщения;
- контроль и восстановление соединений;
- подписка/отписка в любой момент времени.
Подписчик выполняет непрерывно проверку соединений при каждом вызове процедуры чтения, пока не будет получено сообщение. При этом подписчик может соединиться с несколькими издателями. Для этого подписчик хранит два списка — один для хранения данных об издателях (адрес, порт), второй для хранения всех своих подписок. После успешной авторизации с издателем подписчик высылает все подписки разом, тем самым регистрируясь на нужные классы сообщений. В любой
момент времени может быть добавлена или удалена подписка с последующей отправкой команды всем издателям, с которыми установлено соединение.
При вызове функции чтения, когда пришли сообщения от нескольких издателей, подписчик извлекает сообщения из входного буфера первого по списку издателя. Например, подписчик, зарегистрированный на двух издателей и считывающий сообщение раз в 1 секунду, никогда не получит сообщение от издателя, который идет вторым по списку, если оба издателя будут рассылать сообщения также раз в 1 секунду (и быстрее). Такая ситуация характерна для библиотеки ZeroMQ для ПК и ее реализации для микроконтроллеров.
Алгоритм чтения подписчиком представлен на рис. 6 и может быть описан тремя основными действиями:
- проверка задействованных сокетов;
- восстановление потерянных соединений;
- считывание сообщения у первого обработанного сокета.
Рисунок 5. Алгоритм процедуры рассылки сообщений издателем
Рисунок 6. Алгоритм процедуры чтения сообщений подписчиком
5. Детали программной реализации модуля
В качестве управляющего микроконтроллера был использован 8-битный микроконтроллер АУ^ 328 в составе отладочной платы прототипирования АМшпо, одна-
ко код может быть легко адаптирован и для компиляции под конфигурацию «одиночного» микроконтроллера. Код модулей нацелен на компилятор avr-gcc. Модули, описанные в данной статье, опубликованы на Git ресурсе [14] и доступны для свободного использования с соблюдением лицензии GPL.
В нотации для платы макетирования Arduino реализованы следующие функции, обеспечивающие:
- соединение и 3-ступенчатую авторизацию;
- автоматическое восстановление соединения подписчиком;
- асинхронную работу сокетов;
- организацию и хранение служебных данных;
- передачу сообщений в формате ZeroMQ;
- возможность подписки/отписки подписчиком в любой момент времени;
- завершение соединения любой из сторон.
Библиотека реализована на языке C/C++. Авторы старались соблюсти архитектуру оригинальной библиотеки, чтобы упростить разбор исходного кода третьим лицам, знакомым с ZeroMQ.
Для управления W5500 использовалась одноименная библиотека с открытым кодом, предоставленная производителем этого чипа на условиях LGPL. В библиотеку пришлось внести значительные изменения, без которых не получилось реализовать весь программный модуль.
6. Исследование технических характеристик представленной реализации
Для оценки быстродействия и временных характеристик разработанного программного модуля были произведены измерения его производительности при помощи осциллографа Tektronix TBS2000 (см. рис. 7, 8). Использовалась следующая методика измерений: перед стартом процедуры рассылки на стороне издателя на цифровой вывод микроконтроллера подавался высокий уровень сигнала, который оставался в состоянии 1 до окончания процедуры передачи данных. Длительность этого импульса позволяет оценить время выполнения процедур, а также служить сигналом для синхронизации. Хронометраж подписчика осуществлялся по аналогичному пути: на стороне подписчика высокий уровень на цифровом выходе микроконтроллера сигнализировал о активной процедуре приема и обработки поступившего сообщения. Временные диаграммы позволяют оценить задержки и длительность обработки сообщений.
На рис. 7, 8 приведены осциллограммы, когда подписчик и издатель непрерывно выполняют операции чтения и рассылки. На рис. 7 измеряется время выполнения всей процедуры чтения подписчиком. На рис. 8 только та часть, которая от-
вечает за извлечение данных из входного буфера. Из рисунков видно, что подписчик считывает сообщения и начинает чтение нового сообщения. Однако новое сообщение еще не было отправлено издателем, поэтому подписчик переходит в режим ожидания.
Примечание. Чтобы измерить максимальную скорость чтения подписчиком, нужно обеспечить рассылку сообщений быстрее, чем он будет успевать считывать их.
Рисунок 7. Время, затраченное на рассылку издателем (верхний канал) и чтение подписчиком (нижний канал)
ЕЯ 2.(ХЛГ Ц, ИГЛ 100Ц5 12.5МБ/5 ШН V 9.80У 14:09:55
Т 50.13% 20К точек <10Нг
Рисунок 8. Время, затраченное на рассылку издателем (верхний канал) и чтение входного буфера подписчиком (нижний канал)
Измерения проводились при различных конфигурациях шаблона издатель-подписчик. Исследовались следующие комбинации модулей:
- микроконтроллер-издатель, компьютер-подписчик;
- микроконтроллер-подписчик, компьютер-издатель;
- микроконтроллер-издатель, микроконтроллер-подписчик.
Первый случай демонстрирует ситуацию, когда издатель одновременно посылает сообщение нескольким подписчикам. Передача данных происходит в односто-
роннем (unicast) порядке: каждому адресату, подписанному на это сообщение. В связи с этим время выполнения процедуры рассылки с каждым новым подписчиком растет линейно, что и подтверждает график на рис. 9.
Реализовать широковещательную рассылку не представляется возможным в текущей связке ZeroMQ и WIZnet W5500, так как библиотека ZeroMQ поддерживает только нестандартизованные pgm (Pragmatic General Multicast) и epgm протоколы (Encapsulated Pragmatic General Multicast) для широковещательной передачи данных, а чип WIZnet W5500 реализует multicast только при помощи протокола IGMP.
2.6 2.4 S 22 \ 2
2 4
2. 15
1. S8
1 18 i16 114 1.56/"*^
1.28
112
0.8 0.6 0.4 0 72
0 4Г/
12345678« Количество одновременных рассылок
Рисунок 9. Зависимость скорости рассылки от количества единовременных рассылок
при полезной нагрузке 10 байт
На рис. 10 представлены результаты, когда каждому подписчику соответствует уникальный заголовок подписки. Соответственно, рассылка сообщения происходит только одному подписчику. Для оценки скорости выполнения алгоритма берется самый худший вариант, т. е. рассылка сообщения с заголовком, находящимся в самом низу дерева.
0.95 0.9 ш 0.85
Г**
0.Й 0.79 ^^
1 0.75 | 07 | 0.65 I 06 о- 0.55 0.5 0.45
0. 55 ^^
0 5
У
1 4 5 6 " Количество подписчиков
Рисунок 10. Зависимость скорости рассылки от количества подписчиков с уникальной подпиской при полезной нагрузке 10 байт
Высота дерева может меняться в зависимости от порядка добавления ключей при их одном и том же количестве. Например, при добавлении ключей "subi", "sub2", "sub3" и т. д. дерево будет вырождаться в список, так как все узлы будут попадать в самую правую ветвь. В случае красно-черного дерева этого не происходит из-за его перебалансировки. Однако высота при таком добавлении будет увеличиваться всегда раньше, чем при равномерном добавлении, но все равно будет не больше 2log(n +1) [13]. При вышеописанном порядке добавления узлов увеличение высоты дерева происходит на 2, 4 и 6 подписчиках (см. рис. 11).
а) 6) в)
Рисунок 11. Увеличение высоты красно-черного дерева происходит при добавлении а) 2-го б) 4-го в) 6-го заголовка-подписки
Как видно из графика на рис. 10, зависимость времени рассылки от количества подписчиков близка к линейной. Каждый новый подписчик, которому не производится рассылка, увеличивает время выполнения процедуры на 0.06 мсек. Это время, которое уходит на опрос состояния сокета. Увеличение высоты дерева подписок повышает время выполнения рассылки на 0.02-0.03 мсек. В случае, изображенном на рис. 10, используются подписки размером 5 байт вида "Неаё№, где N — число от 1 до 8.
Выпадении задержки при 8 подписчиках из полученной закономерности обусловлено тем, что при 7 и 8 подписчиках высота дерева и фактическое количество задействованных сокетов чипа W5500 одинаковое. Это обусловлено тем, что всегда должно быть задействовано N + 1 сокетов (но не более 8), где N — количество текущих соединений. Соответственно, при 7 и 8 подписчиках всегда будет активно 8 сокетов.
На рис. 12 представлено измерение времени процедуры чтения и рассылки сообщений в зависимости от полезной нагрузки "payload" в байтах. В обоих случаях измерения происходили при работе микроконтроллера с компьютером. Компьютер может выдать скорость рассылки значительно больше (около 10 тыс сообщений в секунду), чем скорость чтения подписчика на микроконтроллере ATmega328p. Таким образом, подписчик будет работать на максимальной скорости без блокировки потока. В случае издателя блокировка потока происходит только при ожидании
ответного пакета АСК, отправка которого осуществляется на аппаратном уровне W5500, поэтому скорость считывания подписчиками не имеет значения.
1.1 1
0.9 OS 0.7
£
1 0.6 0.5 0.4 0.3 0.2 0.1
—*— Подписчик
—■— Издатель
n
0 20 40 60 SO 100 120 140 160 180 200 220
Полезная нагрузка, байт
Рисунок 12. Зависимость времени рассылки и чтения от полезной нагрузки
Как видно из графика, скорости выполнения процедуры рассылки и чтения зависят линейно от полезной нагрузки. Скорость рассылки меньше, чем скорость чтения и это обусловлено следующим:
- большим количество SPI команд для записи в выходной буфер W5500 и отправки сообщения;
- более трудоемким алгоритмом;
- с увеличением размера отправляемых данных увеличивается время транспортировки по Ethernet сети, а значит, время блокирующего ожидания ответа ACK.
Разработанный модуль показал, что зависимость быстродействия издателя от полезной нагрузки (payloads), количества одновременных рассылок и подключенных подписчиков близка к линейной. Быстродействие подписчика также линейно зависит от полезной нагрузки. Издатель может обеспечить максимальную скорость от 400 до 2400 сообщений в секунду на каждого подписчика при их количестве от 8 до 1 соответственно (при полезной нагрузке в 10 байт). Подписчик может обеспечить скорость чтения от 1500 до 5000 сообщений в секунду при полезной нагрузке от 200 до 5 байт соответственно. Приведенные данные справедливы для связки микроконтроллер ATmega328 и компьютер.
7. Предстоящая работа
Модель издателя-подписчика будет использоваться в проекте «Самообучающаяся роботизированная сервисная система "I see you" (ICU)» (грант РФФИ № 18-5876003) для создания распределенной сети сбора данных с датчиков и сенсоров.
Данная система предназначена для автоматизации работы руки-манипулятора в неопределенных условиях, когда необходимо принимать решения в процессе ее функционирования, основываясь на полученных данных. Задача усложняется тем, что робот должен работать совместно с человеком. Таким образом, часть работы по приему и передаче данных между компьютерами и микроконтроллерами будет возложена на библиотеку распределенного обмена сообщениями ZeroMQ.
В дальнейшем планируется реализовать при помощи микроконтроллера и другие перспективные для аппаратного применения модели библиотеки ZeroMQ, такие как Request-Reply, Pipeline и Exclusive pair, а также реализовать возможность использовать данную библиотеку другими микроконтроллерами. Учитывая, что протокол ZeroMQ — это прикладной уровень, а реализация TCP/IP стека происходит на W5500, фактически необходимо реализовать управление чипом W5500 через SPI-интерфейс для конкретного микроконтроллера, не затрагивая реализацию самой библиотеки ZeroMQ.
S. Заключение
В интернете вещей на данный момент используется множество различных протоколов для обмена данными. В статье представлена разработка программного модуля распределенного обмена сообщениями для микроконтроллеров на основе аппаратных решений WIZnet модели PUB/SUB, что не было реализовано ранее, несмотря на высокую популярность данной модели для реализации обмена данными. Модуль разрабатывался с учетом совместимости с актуальной на момент публикации библиотекой ZeroMQ 3-го поколения (обратно совместим на уровне протокола с 4-м поколением библиотек). Код модуля предоставлен в общественное использование на условиях лицензии GNU-GPL.
Эксперименты показывают, что данная система может работать на скоростях до нескольких тысяч сообщений в секунду, что является хорошим результатом для 8-битного контроллера.
Литература
[1] Dworak A., Sobczak M., Ehm F., Sliwinski W., Charrue P. Middleware trends and market leaders 2G11 // Conf. Proc. ICALEPCS41. — Grenoble, France, 2G11. P. 1334-1331.
[2] ZeroMQ. Intro manual section. [Электронный ресурс] URL: http://zeromq.org/intro%3 Aread-the-manual
[3] Sústrik M. The Architecture of Open Source Applications, Vol. II: Structure, Scale, and Few More Fearless Hacks. — 2G13. P. 359.
[4] AkgulF. ZeroMQ. — Birmingham, 2G13. P. 11.
[5] Hintjens P. Zeromq messaging applications. — Sebastopol : O'REILLY Media, 2013. P. 3738.
[6] ZeroMQ. Binding section. [Электронный ресурс] URL: http://zeromq.org/bindings%3Acpp
[7] Издатель-подписчик [Электронный ресурс] URL: https://ru.wikipedia.org/wiki /Издатель-подписчик_(шаблон_проектирования)
[8] Hintjens P. Code Connected. Volume 1: Learning ZeroMQ. iMatix Corporation, 2013. P. 20.
[9] Иванов О. Удаленный сбор информации с приборов учета на основе решений wiznet // Control Engineering Россия. 2015. Vol. 56. No. 2. P. 70-73.
[10] W5500 Datasheet [Электронный ресурс] URL: https://www.wiznet.io/product-item/w5500/
[11] ZeroMQ Message Transport Protocol [Электронный ресурс] URL: https://rfc.zeromq.org/ spec:23/ZMTP/
[12] Sebastian dicoy. Sending ZeroMQ messages from Arduino (limited zmq wire protocol implementation) [Электронный ресурс] URL: https://github.com/dicoy/zeromq-arduino-example
[13] Кормен Т. и др. Алгоритмы: построение и анализ. 2-е изд. — М. : Вильямс 2011. С. 336364.
[14] Страница проекта на GitHub [Электронный ресурс] URL: https://github.com/Scaarj/ ZeroMQMCU
Авторы:
Алексей Борисович Колкер — кандидат технических наук, доцент кафедры автоматики, Новосибирский государственный технический университет; директор, ФГБУ Сибирский региональный научно-исследовательский гидрометеорологический институт
Степан Сергеевич Дубров — магистрант, Новосибирский государственный технический университет; инженер лаборатории промышленных ускорителей № 12, Институт ядерной физики Г. И. Будкера СО PAH
Microcontroller Implementation of Distributed Delivery of ZMQ Messages for the Internet of Things
A. B. Kolker***, S. S. Dubrov****
*Novosibirsk State Technical University, Russia, 630073, Novosibirsk, K. Marx Ave., 20 **Siberian Regional Research Meteorological Institute, Russia 630099, Novosibirsk, Sovetskaya 30 ***Budker Institute of Nuclear Physics of Siberian Branch Russian Academy of Sciences (BINP SB RAS) 11, Acad. Lavrentieva Pr., Novosibirsk, 630090 Russian Federation email: a.kolker@corp.nstu.ru, dubrovss@binp.nsk.su
Absrtact. The article describes the development of a separate model of the ZeroMQ library for microcontroller devices. The main models of the ZeroMQ library are considered, then the choice of the publisher-subscriber model when using an 8-bit AVR microcontroller is explained. A schematic implementation of the TCP / IP stack for the AT-mega328P microcon-
troller using a device with an Ethernet coprocessor is shown. The algorithmic publisher-subscriber model is analyzed when using a microcontroller. In conclusion, the software implementation of the publisher-subscriber model for the microcontroller was investigated by measuring the time characteristics of the procedure for sending and reading messages. Keywords: IoT, distributed data exchange, ZeroMQ library, message-oriented middleware, pub-lisher-subscriber model, microcontroller, Ethernet coprocessor.
References
[1] DworakA., SobczakM., Ehm F., Sliwinski W., Charrue P. (2011) Middleware trends and market leaders 2011. In Conf. Proc. ICALEPCS'11 (Grenoble, France), pp. 1334-1337.
[2] http: //zeromq. org/intro%3Aread-the-manual
[3] SustrikM. The Architecture of Open Source Applications, Vol. II: Structure, Scale, and Few More Fearless Hacks. 2013. P 359.
[4] AkgulF. (2013) ZeroMQ. P. 11.
[5] Hintjens P. (2013) Zeromq messaging applications (O'REILLY Media), pp. 37-38.
[6] http: //zeromq. org/bindings%3Acpp
[7] https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
[8] Hintjens P. (2013) Code Connected Volume 1: Learning ZeroMQ. iMatix Corporation, pp. 20.
[9] Ivanov O. (2015) Control Engineering Russia, 56(2):70-73. [In Rus]
[10] https://www.wiznet. io/product-item/w5500/
[11] https://rfc.zeromq.org/spec:23/ZMTP/
[12] https://github.com/dicoy/zeromq-arduino-example
[13] Kormen T. et al. (2011) Algoritmy:postroenie i analiz, 2 ed. (Wiliams), pp. 336-364. [In Rus].
[14] https://github.com/Scaarj/ZeroMQMCU
