Нашёл в базе знаний Siemens (SIOS) интересный пример использования контроллеров линейки S7-1200 и S7-1500 в качестве клиента протокола MQTT. Ссылка на первоисточник .
По ссылке вы можете найти саму библиотеку с функциональным блоком MQTT_Client (кстати, с открытым исходным кодом) и пояснительную записку например.
Сама документация весьма обширна; те, кто знает английский, могут смело перейти по ссылке и не читать эту заметку, тем самым подарив себе несколько увлекательных часов инженерных изысканий.
А для остальных, менее опытных и/или более ленивых, я вкратце расскажу основы и продемонстрирую свой пример работы клиента, творчески переработанной для более-менее реального применения.
Коротко об условиях.
MQTT — транспорт телеметрии очереди сообщений.
Протокол телеметрии для передачи сообщений.
Мне сложно правильно перевести название на русский язык.
Сообщение - сообщение.
Непосредственно сами передаваемые данные.
Сообщение состоит из нескольких частей:
- Тема, тема сообщения.
Строка символов, размер которой в исходном примере ограничен 200 символами.
Для получения сообщений клиенты должны сначала подписаться на определенную тему, т.е.
тему
- QoS, качество обслуживания.
Дополнительный знак, указывающий, ждать подтверждения получения сообщения или нет.
- Текст сообщения, текст сообщения.
Текстовая строка длиной 500 символов.
При клиент-серверном подходе один или несколько участников играют роль сервера, т.е.
узла в сети, отвечающего на запросы клиентов.
Сам сервер не инициирует связь и не активен; он только отправляет запрошенные данные и получает настройки и команды.
При этом адресация данных, тип данных и т.п.
закладываются и структурируются изначально на этапе разработки серверной части.
Клиент также должен знать эту «карту адресов Modbus».
Изменение набора данных требует перенастройки как клиента, так и сервера.
В модели подписчик-издатель, используемой в протоколе MQTT, нет необходимости заранее создавать, настраивать или программировать набор данных (тем).
В общем, нет необходимости настраивать какие-либо данные на стороне сервера.
Темы создаются издателем автоматически.
Подписчики в свою очередь подписываются на темы, а вы даже можете подписаться на тему, в которую еще ни один издатель не писал.
Как только в эту тему будет отправлено хотя бы одно сообщение, его получат все подписчики.
Итак, роли в протоколе MQTT. Издатель – также известный как издатель.
Узел, отправляющий сообщения (текстовую информацию) по определенной теме (теме).
Подписчик – также известный как подписчик.
Узел, который подписывается на определенные темы.
Абонент автоматически получает новые сообщения в заявленных темах.
Роли издателя и подписчика можно совмещать на одном сетевом узле.
Это роли клиента.
Роль сервера в протоколе MQTT выполняет узел, называемый брокером.
Именно брокер запоминает, какие клиенты на какие темы подписались.
Именно брокер получает сообщения от издателей по определенной теме и автоматически рассылает их соответствующим подписчикам.
К брокеру можно подключить несколько подписчиков и паблишеров.
Я не знаю максимального количества.
Предположу, что все ограничивается только мощностью оборудования, на котором работает брокер, и настройками стека TCP/IP операционной системы.
В первоисточнике (см.
ссылку в начале) содержится архив с библиотекой LMQTT_Client. Архив необходимо распаковать, а библиотеку подключить к уже созданному проекту Шаг 7. Библиотеку необходимо подключить через пункт меню Параметры → Глобальные библиотеки → Открыть библиотеку.
В результате вы увидите следующее:
Библиотека подключена к проекту Библиотека содержит две версии клиентского функционального блока протокола MQTT — для контроллеров S7-1200 и S7-1500. В моем примере будет использоваться ПЛК нижнего уровня S7-1214. Реализации отличаются тем, что более старый S7-1500 позволяет обращаться к брокеру по имени домена, а S7-1200 позволяет обращаться к нему только по IP-адресу.
Вам необходимо перетащить блок LMQTT_Client из библиотеки на вкладку Program Files контроллера.
Типы данных будут скопированы в проект автоматически.
Далее я отклоняюсь от примера и вызываю FB MQTT_Client из моего собственного функционального блока под названием MQTTExchange:
В принципе, если правильно выполнить все настройки и поиграться с запросами через поля экземпляра функционального блока, проверить работоспособность можно прямо сейчас.
Но сначала давайте пройдемся по основным входным и выходным контактам этого FB. включить — когда фронт этой дискретной переменной положительный, устанавливается соединение с MQTT-брокером; когда фронт отрицательный, соединение закрывается.
Те.
Для работы необходимо держать этот вход в состоянии TRUE publicData — структура для отправки (публикации) сообщения.
Состоит из бита запроса публикации (для отправки сообщения бит должен быть установлен в значение true и сброшен в значение false после появления флага выполнено или ошибка), темы и текста сообщения, а также индикатора качества QoS. subscribeToTopic - структура, содержащая флаг запроса на подписку, флаг запроса на отписку (да, от темы можно отписаться в любой момент), само название темы и индикатор качества На начальном этапе нам важны следующие две структуры, необходимые для установления связи с брокером: это tcpConnParam и mqttParam. Эти структуры я заполняю один раз в OB100 при запуске контроллера.
Минимум, необходимый для работы протокола, описан ниже.
Идентификатор оборудования интерфейса контроллера Идентификатор интерфейса («сетевой карты») ПЛК.
В моем случае у меня только один интерфейс.
Его идентификатор я уже помню наизусть, поэтому пишу 64. Посмотреть идентификатор оборудования можно в конфигурации оборудования ПЛК.
Следующим является идентификатор соединения.
Это логическое соединение по протоколу TCP/IP, идентификатор соединения.
Должно иметь значение от 1 до 4096, присвоенное программистом, каждое логическое соединение должно иметь свой уникальный «ID», иначе соединение не будет функционировать.
В моем случае подключение одно, и я смело присваиваю ему «1».
Следующим пунктом назначения является IP-адрес хоста, на котором работает брокер.
В этом примере брокер работает на моем домашнем «рабочем» компьютере с общедоступным статическим IP-адресом.
В целях информационной безопасности два байта IP-адреса стерты.
Mosquitto для Windows выступает в роли брокера.
Различные способы установки брокера хорошо описано по ссылке .
Там вы можете скачать брокера, уже настроенного в базе данных , это то, что я использую.
Никакие специальные настройки не применяются.
Сертификаты шифрования не используются (подробнее об этом позже).
Программа mosquitto.exe просто запускается на удаленном компьютере, и порт 1883 (порт для стандартной связи MQTT) перенаправляется в локальную сеть на удаленном маршрутизаторе.
Я намеренно использую брокера, которого нет локально.
Одно дело поднять все внутри локальной сети в любимом диапазоне адресов 192.168.0.х или 192.168.1.х, и совсем другое – убедиться, что система может работать как надо, по удаленным каналам связи.
Ведь сам контроллер сейчас находится в лаборатории, он подключен к локальному роутеру от провайдера, а у контроллера только локальный IP-адрес, а не публичный и тем более не публичный статический IP. Кстати, мы помним, что для организации «доступа в Интернет» контроллер в этом случае должен явно указать «шлюз» в настройках своего IP-адреса.
Необходимо прописать адрес роутера, иначе ПЛК не сможет подключиться к внешним ресурсам глобальной сети.
Следующий параметр — это порт, на котором удаленный брокер прослушивает соединения.
По неизвестной причине в примере этот порт указан как 1884, тогда как стандартный порт для незашифрованной связи — 1883. Я задал его явно:
Последняя настройка — символическое имя клиента.
Должно быть уникальным в системе.
В качестве имени у меня установлено S7-1214.
Было бы гораздо разумнее автоматически сделать имя клиента уникальным.
Например, сделайте его составным из слова «SIMATIC» и уникального серийного номера центрального процессора (считав его соответствующей системной функцией и преобразовав в строковое представление).
С остальными настройками рекомендую ознакомиться в документации.
Я остановлюсь на двух из них, которые очень интересны.
Первый.
Последнее желание.
Буквально по-русски – «завещание» (сетевые граждане – такие юмористы!).
Если вы сделаете эту настройку, клиент также передаст ее при подключении к брокеру.
В случае «сбоя связи» клиента брокер автоматически отправит это завещание всем участникам биржи.
«Завет» — это то же послание; у него та же тема и текст. Второй.
Возможность шифрования трафика.
Для общего тестирования можно обойтись и без него.
В производстве - ни при каких обстоятельствах.
Задав в настройках поле activeSecureConn, нужно провести еще ряд манипуляций — активировать глобальные настройки безопасности проекта, импортировать сертификат брокера, создать сертификат контроллера и так далее.
Я уже поднимал вопросы шифрованного соединения в заметке о коммуникациях OPC UA. В целом действия здесь больше напоминают настройки безопасного соединения Open User Communications (SecOUC).
В этом примере я пренебрегаю безопасностью передаваемых данных.
Подробности настройки описаны в той же документации.
Закончив настройку, необходимо убедиться, что все работает как надо.
Для начала, конечно, просто подключимся к удаленному брокеру.
Для этого просто примените true к входу разрешения функционального блока LMQTT_Client:
Как видите, при применении разрешения выходные биты tcpEstablished и mqttEstablished содержат «true», что означает, что соединение установлено успешно.
В ходе тестирования я обнаружил интересное поведение блока, а именно, при подаче «true» на вход разрешения подтверждение связи появлялось на одну-две секунды и исчезало.
Связь установилась только со второй попытки.
Кроме того, если соединение физически прервано, этот ФБ просто сообщает об отсутствии соединения и не пытается автоматически переподключиться.
Для автоматического подключения и переподключения добавлена следующая сеть:
Смысл следующий - если в течение 5 секунд флаг запроса на связь установлен, но подтверждения нет, снимите флаг запроса на связь.
И если в течение 5 секунд флага запроса нет, установите флаг запроса.
В тепличных условиях лаборатории это прекрасно работает. В полевых условиях, когда связь нестабильна, постоянные времени целесообразно корректировать.
В этом примере предполагается, что контроллер не только отправляет некоторую информацию брокеру, но и подписан на тему.
Точнее даже две темы, чтобы пример был интереснее.
Полученная информация может быть чем угодно – командами, настройками, запросами архивной информации или состоянием оборудования.
В принципе, все ограничивается исключительно объемом свободной рабочей памяти.
Было бы вполне логично подписаться на нужные темы сразу после установления соединения.
А для этого вам нужно будет поиграться с полями структуры subscribeToTopic, которую лучше всего рассматривать как «управляющую» структуру.
По нарастающему фронту (то есть по мгновенному факту) установления соединения я повышаю локальную битовую переменную #SubscriveToTopics и устанавливаю «номер шага» процедуры подписки на 1. Номер шага используется из-за того, что все наши операции асинхронны, и выполнять их нужно последовательно, одну за другой, а не все сразу (все сразу выполняться не будут).
Первым шагом подписки является подписка на тему под названием «глобальная».
Если операция подписки прошла успешно, переходим к следующему шагу.
В противном случае проводим процедуру переподключения (хотя реакция может быть другой, на усмотрение разработчика)
Давайте посмотрим.
Если бит «подписки» установлен и шаг = 1, то.
.
если бит структуры управления «подписка» не установлен, то установите имя интересующей темы (глобальное) и поднимите бит структуры управления «подписка» .
если бит «подписки» структуры управления поднят, тогда посмотрите на биты выполнения и ошибки выполнения задачи.
Когда появится бит готовности, сбросьте бит «подписки» управляющей структуры и перейдите к шагу №2. При возникновении ошибки переподключитесь к брокеру.
Шаг 2. На этом этапе вам вообще ничего делать не нужно.
Этот шаг необходим для того, чтобы клиентский FB вызывался хотя бы один раз со сброшенным битом структуры управления «подписка».
Для этого есть более элегантные решения, но я ограничился простым таймером.
Подождав 100мс просто переходим к следующему шагу, подписаться на вторую тему (шаг №3).
Шаг №3 аналогичен шагу №1, за исключением названия темы.
После успешного завершения шага №3 локальный бит «подписки» (#SubscriveToTopics) сбрасывается, а шаги «подпрограммы подписки» сбрасываются в ноль.
После завершения подписки вы можете смело проверять работу клиента.
Для этого я вызываю программу mosquitto_pub.exe :
mosquitto_pub.exe -h myhost.mydomain.ru -t global -m «убить всех людей», Где myhost.mydomain.ru — доменное имя удаленного брокера global — «глобальная» тема, на которую только что подписался клиент убить всех людей - текст сообщения в глобальной теме После отправки сообщения посмотрите на структуру вывода subscribesMessage:
Как видите, в глобальной теме было размещено сообщение «убить всех людей».
Флаг newMessageReceived пригодится нам позже.
Этот флаг устанавливается сразу при получении нового сообщения и действителен в течение одного цикла сканирования.
Будет очень удобно обрабатывать полученные команды, настройки или запросы.
Вторая задача контроллера в этом примере — регулярная отправка информации о процессе.
Например, каждый день.
Или каждые два часа.
Ну или каждые 10 секунд, потому что в обучающем примере не очень хочется тратить время на ожидание ничего.
Поэтому каждые 10 секунд я поднимаю локальный флаг «отправить данные» и устанавливаю шаг «подпрограммы отправки» на 1:
Для разнообразия сеть отправки данных написана на SCL, а не на LAD. Действительно, работать со строками в графических языках — не самое удобное дело.
Всего отправляется значение 4 переменных, три из которых задаются статически в блоке данных, а одна постоянно увеличивается на небольшую дельту.
На первом шаге «подпрограммы» задается имя темы, это имя — личный0. Также генерируется строка сообщения.
Поскольку мы оперируем символьными данными, нам приходится выполнять преобразование типа REAL_TO_WSTRING и конкатенацию строк.
Для контроллеров, особенно начального уровня, это не самое лучшее — память расходуется очень быстро и вычислительные ресурсы расходуются достаточно хорошо.
Длина передаваемого сообщения составляет 500 символов, есть возможность расширения.
Вы также можете добавить временную метку.
Вы можете создать буфер сообщений, накопив тем самым хотя бы минимум данных за период отсутствия связи.
В общем, здесь можно делать все, что угодно (но лучше делать то, что написано в технических характеристиках).
После формирования строки бит структуры управления «отправить сообщение» повышается и номер шага изменяется.
На втором этапе проверяется успешность или неудача отправки, после чего сбрасывается локальный бит «выполнить отправку» и сбрасывается номер шага «процедуры отправки».
Запустим MQTT-клиент и посмотрим, что приходит в топик Personal0 (именно в этот топик ПЛК отправляет данные):
Ну, и наконец.
Демонстрация возможностей дистанционного управления.
Если сообщение об уничтожении получено в теме «personal0», дискретный выход Q0.0 устанавливается в состояние «истина».
Команда издательства:
mosquitto_pub.exe -h хост.домен.Сеть программ контроллера:ру -t личный0 -m «уничтожить»
Входящее сообщение проверяется только по факту прихода самого сообщения (бит newMessageReceived), что вполне логично.
А дальше вам останется только проверить название темы и текст сообщения.
Любые дальнейшие действия можно запрограммировать по желанию.
На этом технический пример заканчивается и хотелось бы немного поговорить о возможностях применения.
Они существуют, и они кажутся довольно широкими.
Фактически это можно использовать в любых распределенных недорогих системах, где присутствуют небольшие объемы информации и из-за этого использование специализированных «телемеханических» протоколов нецелесообразно из-за их высокой стоимости.
Ну, например, в ЖКХ.
Если небольшой ПЛК смотрит потребление энергоресурсов (общий дом, а может даже и квартира) и раз в день отправляет отчет в центр управления.
Или смотрит состояние общедомового оборудования, параметры отправляет раз в час, а в случае аварии - мгновенно.
Достаточно просто оснастить ПЛК GSM-модемом, и по сути больше ничего не требуется, кроме простого компьютера с фиксированным IP-адресом.
Рассуждая дальше, можно обойтись и без физического ПК, поместив его «в облако».
Главное не забыть правильно настроить шифрование трафика.
В этом случае имеет смысл сразу добавить данные об энергопотреблении от клиента в базу данных, но для этого уже требуется высокоуровневое программирование.
Или, как вариант, та же распределенная система, но не только сбор данных, но и М2М (контроллер-контроллер) взаимодействие.
Здесь всё точно так же, достаточно минимального канала связи и доступного брокера.
Вы даже можете выводить информацию в Scud, не особо заморачиваясь с программированием серверной (брокерской) части.
Ведь ничто не мешает вам настроить все полевые контроллеры на отправку сообщений брокеру, взять другой контроллер, прочитать эти сообщения и распределить их результаты по блокам данных, а с них выводить показания в тот же WinCC Advanced. Дальнейшие исследования показали превосходное использование mqtt в сочетании со средой Node-RED. На Node-RED «нарисована» программа, которая получает эти данные от брокера, парсит полученную строку и записывает всю информацию (метку времени, значение) в базу данных MariaDB. Эта же программа на Node-RED позволяла вытащить информацию за заданный период времени, показать ее в виде таблицы, графика и загрузить в виде файла .
csv. Теги: #iot #Интернет вещей #Промышленное программирование #iiot #mqtt #siemens #simatic #s7 #s7-1200 #s7-1200 #s7-1200
-
Старый, Но Все Еще Работающий 286
19 Oct, 24 -
Протокол Spdy Появился В Firefox Nightly
19 Oct, 24 -
Финансирование Стартапа От Государства
19 Oct, 24
