Полный текст

1. ВВЕДЕНИЕ

Взаимодействие контроллера с внешними устройствами позволяет реализовывать управление механизмами, анализ данных для последующей обработки информации, аккумулирование и обработку данных для передачи в системы верхнего уровня, такие как SCADA системы. Взаимодействие ПЛК с другими устройствами обеспечивается с помощью промышленных протоколов передачи данных. Промышленные протоколы передачи данных в свою очередь можно разделить на предметные области, в которых каждое решение имеет свои преимущества. Протоколы типа master – slave, позволяют обеспечить беспрерывную связь между двумя устройствами в системе. Как пример протокол Modbus.

Перечень промышленных протоколов передачи данных стандартных для ПЛК представлена в табл. 1.

Таблица 1. Стандартный набор протоколов передачи данных на программируемый логический контроллер ПЛК

2. ПОСТАНОВКА ЗАДАЧИ

Целью выполнения работы является расширение возможностей промышленного контроллера путём интеграции дополнительных протоколов взаимодействия.

Материалы и методы. В нынешнее время протоколы передачи данных в системах автоматизации, управления и телемеханики играют важнейшую роль, предоставляя возможность обмена данными между устройствами всех уровней автоматизации. Поддержка устройством возможности отправлять и принимать информацию позволяет использовать данные решения в системах, которые требуют аккумулировать, анализировать, обрабатывать и отображать необходимые для системы данные [1].

3. ОБЕСПЕЧЕНИЕ ПОДДЕРЖКИ КОНТРОЛЛЕРОМ ПРОТОКОЛА ПЕРЕДАЧИ ДАННЫХ

Для обеспечения поддержки контроллером того или иного протокола передачи данных следует реализовать управленческий алгоритм (драйвер) данного протокола. Протоколы сильно отличаются порой друг от друга в принципе и последовательности действий для обеспечения передачи данных. Но в каждом из них есть основополагающие принципы, объединяющие их. Протоколы передачи данных характеризуются различными уровнями взаимодействия систем по модели OSI (см. рис. 1).

Рис. 1. Сетевая модель The Open Systems Interconnection model OSI.

Сетевая модель OSI (The Open Systems Interconnection model) — сетевая модель стека сетевых протоколов OSI/ISO. Посредством данной модели различные сетевые устройства могут взаимодействовать друг с другом. Модель определяет различные уровни взаимодействия систем. Каждый уровень выполняет определённые функции при таком взаимодействии [2].

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

3.1. ВЫБОР ПРОТОКОЛА ДЛЯ РЕАЛИЗАЦИИ

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

Для примера обратим внимание на протокол передачи данных Modbus RTU, в стандартной реализации данный протокол сам по себе реализует прикладной уровень модели OSI. Базируется на физическом уровне, используя последовательные порты RS232 или RS485. На канальном уровне архитектуру master\slave (табл. 2).

Таблица 2. Архитектура протокола Modbus RTU

Из этого следует, что для драйвера данного протокола необходим доступ к последовательным портам устройства, его буферам RX и TX и функция передачи пакетов через последовательные порты. Канальный уровень в данном случае реализуется путём разделения отправленного пакета (TX) и ожидания прихода ответа на него (RX) [3].

В свою очередь у такого популярного протокола передачи данных как MODBUS существует отдельная реализация, именуемая MODBUS TCP\IP (табл. 3). На всех уровнях кроме прикладного данный протокол отличается от своего брата RTU. На физическом уровне используется витая пара, оптоволокно, также возможно использование WIFI. На канальном уровне соответственно используя витую пару, будет ETHERNET, а используя WIFI, будет IEEE 802.11. На сетевом уровне поиск конечных устройств и их уникальных адресов будет разворачиваться, используя протокол IP. На транспортном уровне данный протокол базируется на TCP, так как для него необходима целостность и правильный порядок отправленных и полученных данных, что не может предоставить, например, UDP [4].

Исходя из данных вводных, приходим к выводу о том, что для реализации драйвера MODBUS TCP\IP, необходимо:

1. Наличие на устройстве порт ETHERNET либо сетевую карту с поддержкой IEEE11.
2. Иметь возможность конфигурировать IP адрес устройства, маску и шлюз.
3. Иметь доступ для функций работы с сокетами типа TCP\IP.

Обе реализации MODBUS RTU и MODBUS TCP\IP на прикладном уровне практически не различаются. Так как эти протоколы уровня приложения.

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

Таблица 3. Архитектура протокола Modbus TCP

С другой стороны, на чём базируется протокол, непосредственно влияет на его конечные свойства, быстродействие, устойчивость и так далее. Но такие параметры чаще всего уже определены для каждого протокола, так как разработка спецификаций уже учитывает особенности того, на чем основан тот или иной протокол.

3.2. ОПРЕДЕЛЕНИЕ АРХИТЕКТУРЫ ПРОТОКОЛА

Определившись с выбором, обращаем внимание на архитектуру и тип протокола. От этого зависит общая структура построения программы.

Далее необходимо определить на каком физическом канале связи будет использоваться протокол. От этого зависит, на каком протоколе физического уровня будет базироваться протокол.

Рассмотрим некоторые возможные архитектуры:

• Ведущий – ведомый (master - slave)
• Клиент – сервер (Client - Server)
• Издатель – подписчик (Publisher - subscriber)

3.2.1. АРХИТЕКТУРА ВЕДУЩИЙ – ВЕДОМЫЙ (MASTER – SLAVE)

В архитектуре протоколов передачи данных с ведущим и ведомым (master-slave) участвуют два устройства. Ведущее устройство отправляет запросы на получение данных, в то время как ведомое отвечает на полученные запросы. Инициатором передачи данных может быть только ведущее устройство. Таким образом, процесс передачи данных осуществляется через отправку пакета запроса и получение ответа на него [5].

3.2.2. АРХИТЕКТУРА КЛИЕНТ – СЕРВЕР (CLIENT – SERVER)

Клиент – сервер (client - server) — архитектура организации передачи данных, к которой присутствует устройство сервер, к которому подключаются устройства клиенты. После подключения клиенты имеют, возможно, обмениваться сообщениями, как с сервером, так и с клиентами, подключенными к нему непосредственно через сервер. Инициатором подключения в данном случае будут клиенты, которые отправляют запрос на подключение. Так при необходимости обмена данными запросы на информацию передают клиенты серверу [6].

3.2.3. АРХИТЕКТУРА ИЗДАТЕЛЬ – ПОДПИСЧИК (PUBLISHER – SUBSCRIBER)

Издатель-подписчик (publisher-subscriber) – способ организации сети, в которой участвует два типа устройств — серверы и клиенты. Отличие от клиент-серверной архитектуры заключается в том, что клиенты могут выступать в двух ролях, издатель и подписчик. Издатель имеет возможность публиковать сообщения в темы (topics), которые хранятся в сервере, а подписчик подписываться на темы [7]. Таким образом, организация передачи данных приставляет из себя такую последовательность:

1. Клиент подписчик подписывается на тему в сервере;
2. Клиент издатель публикует сообщение в топиках;
3. Сервер при получении новых сообщений в топике передаёт их всем подписавшимся.

3.3. АНАЛИЗ НЕОБХОДИМЫХ ВОЗМОЖНОСТЕЙ АЛГОРИТМА СЕРВЕРА

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

Для реализации возможности подключения клиентов к серверу необходимо:

• Создать сокет для подключения по TCP\IP
• Принять входящее подключение по данному сокету
• Передать данные о входящем соединении в программный блок, описывающий работу с клиентом.

Создание сокета и принятие входящего подключения производится возможностями операционной системы устройства, на котором реализуется алгоритм.

Передача информации о входящем подключении передаются возможностями среды программирования.

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

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

В данном программном модуле должна быть реализована обработка получаемых данных от сервера, при помощи буферизованных данных из принимаемых пакетов. А также обработка и буферизация данных, передаваемых серверу [8].

Передача и получение пакетов данных на уровне TCP\IP осуществляется при помощи возможностей, которые может предоставить операционная система.

Рис. 2. Алгоритм работы сервера.

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

3.4. АНАЛИЗ НЕОБХОДИМЫХ ВОЗМОЖНОСТЕЙ АЛГОРИТМА КЛИЕНТА

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

Алгоритм работы клиентской части соединения клиент-сервер представлен на рис. 3.

Рис. 3. Алгоритм работы клиента.

Во включенном состоянии алгоритм в первую очередь всегда единожды очищает области памяти от хранения данных предыдущего подключения, это необходимо для того, чтобы информация о новом подключении с вероятностью в сто процентов была записана верно. Дальнейшим шагом является создание сокета, при помощи которого будет осуществляться подключение, — настройка требуется для нестандартных способов подключения. После того как сокет был успешно создан, требуется подключиться к сокету сервера по заданному IP адресу либо имени хоста. В свою очередь при успешном подключении клиент с сервером могут обмениваться пакетами данных [9].

4. МЕТОДИКА ИНТЕГРАЦИИ ПРОТОКОЛА ПЕРЕДАЧИ ДАННЫХ В ПЛК

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

Рис. 4. Методика интеграции протокола передачи данных в программируемый логический контроллер ПЛК.

4.1. ЭТАП ПОДГОТОВКИ

В первую очередь того, чтобы решить задачу реализации протокола передачи данных для ПЛК в среде программирования Codesys 3.5, требуется определить, какой стандарт будет подлежать реализации. Определившись с протоколом передачи данных подлежащим реализации, необходимо получить спецификацию по его работе, документ, в котором описаны механизмы работы, как и в каком виде, будут передаваться данные, а также требования к работе программного драйвера.

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

В случае если протокол передачи данных на физическом уровне использует последовательный порт, то соответственно данным портом должен обладать ПЛК. Абсолютно таким же образом выглядит требование к ПЛК, если протокол использует на физическом уровне сетевой канал, на контроллер должен обладать сетевой картой и портами Ethernet либо поддерживать беспроводной канал передачи данных, к примеру, WI-FI.

4.2. ЭТАП РАЗРАБОТКИ СТРУКТУРЫ

Приступая к началу, разработки приложения необходимо определить основную структуру программы. Оптимальным для данной задачи структурой приложения для ПЛК, программируемом при помощи Codesys 3.5, является проект вида библиотеки. Так как драйвер протокола передачи данных при использовании будет являться инструментом для формирования автоматизированных систем, и будет предоставлять возможности и функции для передачи информации. Непосредственный открытый код для этого программисту, использующему данный драйвер, не требуется. Достаточно ограничиться исчерпывающей документацией по работе данного программного продукта.

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

Структура проекта библиотеки для Codesys 3.5 представляет собой набор программных блоков. А именно функциональных блоков, функций, структур, перечислений и так далее. В свою очередь функциональные блоки предназначены для того, чтобы хранить в себе алгоритмическую часть драйвера, так как позволяют иметь методы для хранения часто используемого кода. Функции, как и в любой другой среде программирования, являются набором действий, которое устройство должно выполнить за один цикл программы и вернуть результат. Структура данных представляют собой структуры из нескольких заранее определенных переменных определённого типа. Области применения структур множество, но по большей части они требуются для того, чтобы обозначить определенного типа группы информации, к примеру, типовой пакет данных. Перечисления при программировании ПЛК чаще всего требуются для обозначения последовательностей, шагов либо кодов возврата после выполнения.

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

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

Основными процессами для драйвера, обеспечивающего обмен информацией, являются:

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

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

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

Передача данных осуществляется при помощи функций доступных в среде выполнения, в которую сформированный буфер данных передается по каналу связи в другое устройство. Для данного процесса необходимо определить условие при успешной отправке и обеспечить обрыв данного действия по таймауту, так как возможно, что при определенных условиях отправка никогда не будет произведена успешно [10].

Во время процесса получения данных ПЛК должен циклично вызывать функцию ожидания принятия пакета данных. Так как протокол передачи данных представляет собой набор правил, в котором подразумевается, что драйвер не должен неограниченное количество времени выполнять одно действие, то на получение пакета необходимо установить два условия. Условие, которое выполниться при успешном получении пакета данных, а также условие завершения процесса по таймауту, для того чтобы оборвать данный процесс по истечении определенного времени.

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

4.3. ЭТАП ПРАКТИЧЕСКОЙ РЕАЛИЗАЦИИ

На данном этапе производится непосредственная реализация драйвера протокола передачи данных на основе описанных на предыдущем этапе шагов. А именно требуется создать проект библиотеки для Codesys 3.5 и реализовать описанные ранее блоки программы, функции и структуры. По мере написания кода программы имеет смысл проверять реализованный функционал с использованием имитаторов протокола передачи данных, выбранных на этапе подготовки.

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

Тестирование должно проводиться в различных сценариях, включая как стандартные, так и предельные условия работы, что поможет выявить поведение системы в ситуациях, близких к реальным эксплуатационным условиям. Например, в рамках архитектуры клиент-сервер целесообразно протестировать, как драйвер справляется с множественными одновременными запросами от клиентов, а также как он обрабатывает задержки и потери пакетов. Для архитектуры ведущий-ведомый важно проверить, как система реагирует на изменения в состоянии ведущего устройства, включая его отключение и повторное подключение. Аналогично, в архитектуре издатель-подписчик необходимо убедиться, что подписчики корректно получают сообщения от издателя и могут обрабатывать их в реальном времени.

Для анализа правильности последовательности передачи пакетов данных требуется использовать анализатор пакетов — специализированную программу, которая визуально отображает пакеты данных, отправленные и полученные через устройство. Такой инструмент обеспечивает детальный мониторинг и анализ сетевого трафика, позволяя выявлять ошибки в передаче и подтверждать корректность формата сообщений. Использование анализатора пакетов является ключевым аспектом тестирования, так как он предоставляет возможность не только отслеживать успешные передачи, но и диагностировать проблемы, возникающие в процессе обмена данными. Например, анализатор может помочь в определении причин задержек в передаче, а также в выявлении несоответствий между ожидаемыми и фактическими данными. Таким образом, интеграция этих методов и инструментов в процесс тестирования драйвера способствует созданию надежных и высокопроизводительных систем автоматизации, что имеет критическое значение для успешной реализации промышленных решений. Это, в свою очередь, обеспечивает уверенность в том, что разработанный драйвер будет эффективно работать в условиях реального времени, соответствуя современным требованиям к надежности и производительности [11].

Рассмотрим интеграцию на базе методики нового протокола взаимодействия в промышленный контроллер. Для непосредственной реализации в рамках данной методики был выбран протокол MQTT версии 3.1.1.

Программируемый контроллер компании ООО «НПА Вира Реалтайм» серии «Сателлит Р» модели «ПР-10» (рис. 5) представляет собой контроллер, программируемый в среде разработки Codesys 3.5. На нём присутствует сетевая карта и реализована на уровне операционной системы взаимодействие с использованием транспортного протокола передачи данных TCP. Технические характеристики данного устройства представлены в табл. 4.

Рис. 5. Внешний вид контроллера Сателлит ПР-10.

Таблица 4. Технические характеристики Сателлит ПР-10

На этапе подготовки требуется произвести подготовительные действия перед началом интеграции протокола передачи данных в ПЛК. Следуя описанной методике в первую очередь необходимо оценить возможность реализации драйвера протокола на выбранном ПЛК. Для стандарта MQTT от устройства требуется:

• сетевая карта с портами Ethernet либо беспроводным каналом связи, на котором будет возможна передача данных по транспортному протоколу TCP;
• работа со строковыми типами данных.

Выбранный для ПЛК Сателлит ПР-10 удовлетворяет этим требованиям.

Для качественного и эффективного внедрения протокола передачи данных потребуются устройства с поддержкой данного стандарта или программные имитаторы протокола MQTT. В качестве имитатора клиента MQTT выбор был остановлен на приложении для ОС Windows «MQTT.fx», а в качестве сервера-брокера MQTT «mosquito» для ОС Windows.

Проект, включающего в себя драйвер протокола передачи данных реализуемый в Codesys 3.5 представляет собой внедряемую в проект приложения библиотеку. Структура библиотеки должна включать:

Перечисления (ENUM) – структурные данные, представляющие из себя структуру, в которой последовательно перечисляются состояния. Позволяют в удобном виде описать в строковом виде коды ошибок, этапы алгоритма и флаги.

Функциональный блок (FB) – для реализации алгоритма драйвера. Именно данный программный элемент будет в дальнейшем создан как экземпляр драйвера в приложения для ПЛК.

Глобальные переменные (константы) (GVL) — поля объявления переменного постоянного значения, необходимые для стандартизации часто используемых данных.

Структуры (STRUCT) – структуры данных позволяющие объединить переменные в группы для множественного доступа.

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

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

Блок, отвечающий за передачу пакета данных, имеет структуру:

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Указание времени для таймера таймаута данного этапа программы.
4. Вызов метода формирования пакета данных на отправку.
5. Передача сформированного пакета данных.

Далее следуют два условных ветвления.

Первое ветвление выполняется в случае удачной передачи пакета последовательность действий имеет вид:

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Запись пакета данных в логгер.
4. Очищение буфера передачи.
5. Переход к следующей последовательности действий.

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

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Переход к шагу разрыва соединения.

Блок, отвечающий за получение пакета данных, имеет структуру:

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Указание времени для таймера таймаута данного этапа программы.
4. Ожидание получения пакета данных.

Далее следуют два условных ветвления.

Первое ветвление выполняется в случае удачного принятия пакета последовательность действий имеет вид:

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Запись пакета данных в логгер.
4. Переход к следующей последовательности действий.

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

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Переход к шагу разрыва соединения.

Блок, отвечающий за анализ пакета данных, имеет структуру:

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Указание времени для таймера таймаута данного этапа программы.

Далее следует условное ветвление. В случае если вызванный метод анализа пакета данных вернул положительный результат, то:

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Переход к следующей последовательности действий.

В случае если метод анализа пакета данных вернул отрицательный результат, то:

1. Формирование диагностического сообщения.
2. Запись диагностического сообщения в логгер.
3. Переход к шагу разрыва соединения.

Реализация алгоритма протокола была произведена в среде программирования ПЛК Codesys 3.5 SP6 Patch 4, для промышленного контроллера Сателлит ПР-10 в виде проекта библиотеки.

Проект представлен в виде проекта библиотеки для внедрения в проект приложения. Конструкция сетевого подключения предоставляется базовым транспортным протоколом TCP, используемым MQTT. В стандарт протокола MQTT версии 3.1.1 входят два типа программных элементов (рис. 6):

• клиент, выполняющий роли издателя и\или подписчика;
• сервер, выполняющий роль сервера брокера.

Рис. 6. Схема простого взаимодействия между подписчиком, издателем и брокером.

5. ЗАКЛЮЧЕНИЕ

Взаимодействие контроллера с внешними устройствами позволяет реализовывать управление механизмами, анализ данных для последующей обработки информации, аккумулирование и обработку данных для передачи в системы верхнего уровня, такие как SCADA системы. Взаимодействие ПЛК с другими устройствами обеспечивается с помощью промышленных протоколов передачи данных. Промышленные протоколы передачи данных в свою очередь можно разделить на предметные области, в которых каждое решение имеет свои преимущества. Протоколы типа master – slave, позволяют обеспечить беспрерывную связь между двумя устройствами в системе. Как пример протокол Modbus [12].

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

Об авторах

Сергей Сергеевич Гусев

Автор, ответственный за переписку.
Email: gs-serg@mail.ru
Россия

Вадим Владимирович Макаров

Email: makfone@mail.ru
Россия

Александр Юрьевич Мещеряков

Email: aymesh@inbox.ru
Россия

Список литературы

Дополнительные файлы