Описание технического решения.
В качестве основы технического решения для отказоустойчивой и доверительной передачи информации с производственных линий в базы данных предприятия выбраны свободно распространяемые программные продукты с открытым программным кодом, полностью открытой документацией и поддержанные комьюнити.
Для передачи данных используется открытый протокол MQTT (Message Queuing Telemetry Transport) в основе которого лежит телеметрический принцип — говорит только тот, кому есть что сказать. В России этот протокол стандартизован ГОСТ Р 58603— 2019 в версии 3.1.1. Система состоит из трёх частей:
- MQTT издатель (паблишер) это программный блок (FB) с сайта технической поддержки Siemens версии 1. Из изменений только комментарии и адаптация к среде разработки Step 7, потому что оригинал только для TIA Portal-а. Размещается программный блок в контроллере управления производственной линией. Контроллеры могут быть разные S7-1200/1500 и S7-300/400 как со встроенным Ethernet портом, так и с Ethernet портом на коммуникационном процессоре. Среда разработки может быть Step7 v5.6 или TIA Portal (ниже ссылки на все варианты версий). В зависимости от того какие данные публикует паблишер в брокер используется QoS0, для “мгновенных” значений, или QoS2, информации о партии выпущенной продукции.
- MQTT брокер Mosquitto, программный пакет размещаемый на IES (Industrial Edge Server). В качестве IES применяется ЭВМ под управлением Linux OpenWRT. IES физически располагается в непосредственной близости к контроллеру управления производственной линией. Электропитание IES защищено ИБП (источник бесперебойного питания). (В качестве IES обычно роутер TP-Link или одна из разновидностей Raspberry Pi (Orange Pi, Nano Pi) под управлением Linux OpenWRT, ИБП это БИРП 12/1.6 или аналогичный). Таким образом, при отсутствии электропитания или связи, до 12 часов подряд, данные опубликованные с QoS2 не пропадут и, в конечном счёте, попадут в базу данных SQL. Можно конечно и больше 12 часов, это всего лишь вопрос конфигурации брокера и ёмкости аккумулятора ИБП. Но, наверное, это не нужно, ибо сложно представить себе ситуацию, при которой, зная о наличии проблем на круглосуточном производстве, 12 часов подряд никто не предпринимает никаких действий по их устранению.
- MQTT подписчиков может быть несколько. Подписчик это нода MQTT свободно распространяемого программного продукта Node-RED. Этот программный продукт по сути является графическим языком программирования. Помимо имеющихся графических блоков – нод, можно создавать свои. В ноде под названием function можно написать какую-то свою программку на JS-скрипт. На экране ноды соединяются линиями означающими последовательность из выполнения. Таким образом программа как бы рисуется. Node-RED может работать как в операционной системе Windows так и в любой операционной системе Linux. В рассматриваемой структуре в Node-RED также осуществляется подготовка данных к размещению в базу данных SQL, например, шкалирование, и собственно размещение в базу данных SQL. Node-RED может работать с любыми базами данных SQL и сразу с несколькими.
Чтобы система была единообразной, для передачи информации с производственных линий где применяются контроллеры не Simatic, а какие-то другие, прикладную программу которых невозможно дополнить MQTTпаблишером, такие АСУТП можно дополнить операторской панелькой с поддержкой MQTT. Панелек с поддержкой MQTT уже очень много разных выпускается “на любой вкус и кошелёк”.
Конфигурация брокера MQTT.
У пакета mosquito-nossl в OpenWRT есть дополняющий пакет, который дополняет WEBинтерфейс Luci настройками MQTT брокера, однако настройка брокера настолько простая, что устанавливать его не имеет никакого смысла. Конфигурация брокера состоит из двух файлов, в одном ничего и никогда не надо править, а в другом если и надо, то совсем чуть-чуть. Вот пример рабочего конфигурационного файла /etc/config/mosquitto
Вот пример конфигурационного файла /etc/mosquito/mosquito.conf
В этом файле можно поправить максимальное время хранения сообщений с QoS1 или QoS2 и максимальное количество хранимых сообщений. Значения должны быть соизмеримыми, скажем, если одна пачка продукции выходит в час, то устанавливать максимальное количество хранимых сообщений 100 при времени хранения 12 часов не имеет смысла, только лишнее резервирование памяти.
Файл пользователей и паролей должен иметь вид (только цифры и буквы английские, прописные и срочные):
User1:Password1
User2:Password2
User3:Password3
и т.д.
Следует напомнить, что некоторые настройки MQTT могут быть несовместимы. Например, если выбрано QoS2, то не может иметь Clean session значение 1. Password Flag не может иметь значение 1 если у User Name Flag значение 0. А также Client Identifier должен быть уникальным для всех подключающихся клиентов.
Дополнения в программном обеспечении контроллеров производственных линий.
· В системных настройках контроллера или, в некоторых случаях, коммуникационного процессора в составе контроллера прописать синхронизацию времени по NTP. IP адрес NTP сервера это адрес IES. Как правило это один из крайних IP адресов LAN производственной линии, но не всегда. IES легко найти по открытым UDP порту 123 и TCP порту 1883.
· В системных настройках контроллеров проверить правильность выбора часового пояса. Контроллеры S7-300/400 не все понимают часовой пояс, поэтому функция UnixTime для них имеет вход для корректировки метки времени в секундах. При публикации информации о партии выпушенной продукции метка времени в топике обязательна, иначе, если топики будут одинаковыми, предыдущее сообщение перепишется на брокере. При публикации “мгновенных” значений перезапись старых публикаций может быть. Функция UnixTime, найденная на просторах интернета, и один нюанс – работает правильно только для дат после миллениума. Если дата в контроллере 1994 год, например, метка времени будет совсем неправильная. Но поскольку у нас все контроллеры синхронизируют своё время по NTP это не имеет значения.
· Добавить из предоставленных ниже образцов в проект пользовательского ПО контроллера блоки MES, MQTT, UnixTime и пользовательские типы данных относящиеся к MQTT. Как можно видеть из примеров, данные в messageпередаются бинарной кучей, соответственно это бинарную кучу нужно парсить в сабскрайбере в такой же последовательности. (Если линия подключается по MQTT через панельку с поддержкой MQTT, например MT8090xe или SK-070QS-G, у них message JSON.)
- Прописать вызов блока MES в конце OB1. Предложит создать MES_DB, соглашаемся. Если в Step7 SCL перекомпиляцию просит, соглашаемся.
- В блоке MES обновить интерфейс вызова блока MQTT — предложит создать MQTT_DB, соглашаемся.
- В блоке MES постоянно проверяется статус MQTT, если есть сбой MQTT выкл-вкл. Желательно сообщение об этом для оператора сформировать на панель оператора, особенно если на линии нету принтера этикеток.
- ID соединений, без разницы какой тип интерфейса, в рамках контроллера должны быть уникальными. Соединение всегда подразумевает как приём, так и передачу. Проверяем правильность указания физического адреса Ethernet интерфейса, при необходимости правим.
- Наполнение передаваемых параметров правим в блоке MES.
- Привязку к событиям, вызывающим передачу параметров тоже правим в блоке MES.
- В блоке MQTT, в области декларации, находим параметры TCP соединения и правим IP адрес на адрес брокера линии. Там же обращаем внимание на уникальность, в рамках данного контроллера, ID соединения (с IES на порт 1883).
- В блоке MQTT правим в самом начале строку вида ZZZ\XX, где ZZZ код завода и XX это номер линии. Так как таблицы в БД для переделов разные, а в рамках одного передела номера линий уникальные, то вводим привычный нам номер линии. Примечание: ноль в начале необязательно, например, 07 и 7 воспримется одинаково как 7.
- В области деклараций MQTT блока находим имя издателя и правим как надо. Например: было «sushylka», правим на «press».
На этом настройка MQTT издателя завершена. Если всё правильно, то связь с брокером должна установиться, два верхних выхода блока MQTT в true, статус 00000000. Комментариев внутри проектов немало и help никто не отменял :)
Ссылка на описание стандарта.
Ссылка на ГОСТ MQTT.
Пример публикации мгновенных значений (TIA Portal 16, S7-1200)
Пример публикации batch данных 4 стола выгрузки (Step7, S7-400, СP)
Пример публикации batch данных 1 стол выгрузки (Step7, S7-400, CP)
Пример публикации batch данных 1 стол выгрузки (Step7, S7-300, CP)
Пример публикации batch данных 1 стол выгрузки (Step7, S7-300/400, Ethernet)
Пример публикации batch данных 6 столов выгрузки (TIA Portal 15.1, S7-1500)
Представленные примеры для Step7 нормально мигрируют в TIA Portal, если конечно TIA Portal поддерживает мигрируемое железо. Поэтому, чтобы не плодить сущности, примеры S7-300/400 для TIA Portal-а не вижу смысла выкладывать.
Ссылка на статью про IES
Удачи!