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

1. Creating of OPC UA clients with .NET and helper class

2. OPC UA Client Library

3. On-line справка Step 7 Professional V15.1

4. SIMATIC S7-1500, ET 200MP, ET 200SP, ET 200AL, ET 200pro Communication. Function Manual (10/2018 A5E03735815-AG)

5. Здравый смысл

Протокол OPC UA (https://ru.wikipedia.org/wiki/OPC_UA) появился впервые в контроллерах Simatic во второй версии прошивки и в Step 7 версии 14. Тогда контроллер можно было настраивать только в качестве OPC UA - сервера, то есть ПЛК мог отвечать на запросы и отдавать данные, но не мог сам инициировать связь и опрашивать других участников сети.

Радикально ситуация меняется в ноябре-декабря 2018 года с выходом прошивки 2.6 и Step 7 версии 15.1. Появляется возможность настроить CPU в качестве OPC UA клиента. А это, в свою очередь дает нам возможность организовать защищенный канал обмена информацией машина-машина (контроллер-контроллер). И это важно (про существование Secure OUC мне так же известно, однако OUC являет собой обмен данными в свободном формате, чего хватает для маленьких объемов, но отсутствие строгого формата данных накладывает свой отпечаток…). Большинство протоколов полевого уровня для промышленности разрабатывалось в прошлом веке и рассчитаны они, в первую очередь, на честных людей. Только время идет, честных людей становится меньше, злодеев - больше, поэтому обмен данными надо как можно лучше спрятать, зашифровать, запаролить, обложить сертификатами, а всем посторонним в ответ показывать обидные жесты и говорить неприличные слова.

Итак, настройка контроллера (S7-1512 FW2.6) в качестве OPC UA сервера.

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

1. По умолчанию OPC UA отключен в настройках, поэтому заходим в свойства CPU, ищем ветку OPC UA > Server > General и активируем OPC UA Server.

2. Использование OPC UA в контроллерах Simatic требует приобретение лицензии, поэтому покупаем лицензию, заходим в свойства Runtime licenses > OPC UA и ставим тип приобретенной лицензии. Лицензии для 1500ой серии бывают трех типов: маленькая, средняя и большая, в зависимости от типа CPU. S7-1510 и S7-1512 требуют «small».

3. По желанию можно задать Application name для OPC UA сервера, порт и временные интервалы. Интервалы сбора (sampling) и публикации (publishing) я выставил минимальными. Стоит помнить, что уменьшение интервалов повышает нагрузку на CPU. Имя приложения и номер порта оставил по умолчанию.

4. Базовая настройка закончена. Компилируем и грузим PLC.

5. Пора бы и проверить, работает ли вообще. Запускаем программу OPC UA Client (ее можно скачать с SIOS по первым двум ссылкам в начале заметки). Ставлю ip адрес моего контроллера — 192.168.43.10 и нажимаю кнопку Get Endpoints. Получаю возможные «точки входа»

Захожу по самому первому варианту, без сертификатов, без шифрования, без пароля, нажимаю «Connect to selected Endpoints» и перехожу на вкладку «Browse nodes». В контроллере загружена программа управления котельной, нахожу одну переменную (Node или узел — так называется «тэг» или «переменная» в протоколе)

В правой верхней части есть строчка Node id (идентификатор узла или «адрес переменной»), выделяю его мышкой и жму Ctrl-C

Перехожу на вкладку Read/Write, вставляю скопированный node id и нажимаю кнопку Read

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

Закрываю программу. Базовый функционал есть, и он работает. Но этого мало. Сейчас OPC UA сервер настроен на режим «заходи, кто хошь, бери, че хошь». Необходимо добавить немного безопасности.

6. Включаем «глобальные настройки безопасности» в свойствах CPU, Protection&Security > Certificate Manager, ставим галочку Use global settings…

7. В навигации всего проекта находим Security Settings > Settings. Смело нажимаем кнопку Protect this project. Действие необратимое. Снять защиту с проекта уже не получится. Дело в том, что оффлайновый проект будет содержать сертификаты серверной и клиентской машины, они должны быть защищены во избежании покражи. После нажатия кнопки Protect система предложит создать администратора проекта:

Теперь любое открытие проекта TIA Portal будет требовать ввода логина и пароля. Кроме администратора проекта, разумеется, можно и нужно создать пользователей с меньшими правами.

8. После того, как мы активировали глобальные настройки безопасности, необходимо заново вручную сгенерировать сертификат контроллера. В дальнейшем лучше, конечно же, сразу защищать проект, создавать администратора проекта и ставить контроллерам «глобальные настройки безопасности», но данная заметка частично носит общеобразовательный характер. Возвращаемся в настройки CPU, ищем OPC UA > Server >Security

Нажимаем кнопку «…» рядом с надписью «Server certificate»,а в появившемся окне — кнопку «Add new».

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

Сейчас предлагаю скомпилировать проект, загрузить его в ПЛК и проверить программой, как работает связь. На самом деле, в результате последних изменений в настройках уровень секьюрности не поднялся ни на йоту. Все это было лишь подготовительным процессом. Потихоньку приходит время приступать к настройкам контроллера, который будет играть роль OPC UA клиента, проверить обмен данными, ну а потом уже закрыть все бреши в безопасности. Но вначале необходимо выгрузить xml файл с описанием всех тэгов (узлов, nodes) контроллера-сервера. Этот файл формируется достаточно просто — система выбирает только те переменные, которые помечены флагом Accessible from HMI/OPC UA и разрешает их запись, если стоит флаг Writable from HMI/OPC UA . При этом блок данных тоже должен быть доступен по OPC UA (по умолчанию доступен). Например:

Для экспорта снова заходим в настройки CPU и ищем там OPC UA > Server > Export, нажимаем кнопку «Export OPC UA XML file»

Переходим к настройкам OPC UA клиента, то есть той стороны обмена, которая будет инициировать связь, запрашивать и записать переменные. В качестве клиентской части у меня выступает S7-1510 с прошивкой FW2.6.

9. Добавляю контроллер в проект и сразу активирую глобальные настройки безопасности.

10. Активирую OPC UA клиента

11. Активирую лицензию OPC UA

12. Генерирую сертификат этого второго, клиентского контроллера. В дальнейшем контроллер-сервер и контроллер-клиент обменяются (не без моей помощи) своими сертификатами, а подключение незнакомых устройств будет запрещено. В свойствах CPU идем на Protection & Security, жмем Add new.. в таблице Device certificates, жмем на кнопку «…» в появившейся пустой строке, жмем «Add new» в появившемся окне, наблюдаем уже знакомое окно создания нового подписанного сертификата:

В поле usage я дополнительно указал, что сертификат используется для OPC UA Client'а, по умолчанию у меня был выставлен Tls.

13. Наступает одно из самых интересных: настройка клиентского интерфейса,а точнее — настройка соединения к серверу и создания наборов данных для чтения и/или записи. В структуре проекта у второго (клиентского) контроллера:

PLC_2 > OPC UA communication > Client Interfaces >Add new client interface

Жмем кнопку «Import interface» и подгружаем ранее экспортированный XML файл

Теперь открыты все Nodes серверного контроллера. Поскольку стоит задача учебного характера, требуется немного — просто считать 4 переменных блока OKPumpsAuto.

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

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

Необходимо прописать ip-адрес сервера, в моей случае 192.168.43.10.

На странице Security выбираем ранее созданный клиентский сертификат и пока ничего более не меняем.

Создание и заполнение клиентского интерфейса привело к автоматическому созданию двух блоков данных: Client interface_1_Data и Client interface_1_Configuration.

Смотрим блок данных Data, там уже указаны те переменные, которые планируем читать. Чертовски удобно.

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

В проект добавляются следующие меркерные переменные

Ищем функцию OPC_UA_Connect и перетаскиваем ее в нетворк OB1

Имя экземплярного блока я оставил по умолчанию. Что радует — этот вызов имеет графический конфигуратор, как, например, вызовы S7-связи в TIA Portal'е или вызов PID-регулятора. Этот конфигуратор экономит просто уйму времени, а это не может не радовать.

Остается выбрать только созданный клиентский интерфейс (он один) и обвязать блок вспомогательными переменными.

Для лучшего понимания привожу скриншот из онлайн справки Step 7. Именно в таком порядке необходимо выполнять вызовы (как минимум три) перед тем, как приступить к чтению/записи данных. Любой вызов выполняется по переднему фронту входа Req. Успешное или неуспешное выполнения вызова я фиксирую (не сбрасывая, сброс только ручной) в переменных с именами done или err.

Теперь привожу скриншоты всех нетворков программы уже после того, как я последовательно сделал запрос на выполнение функциональных блоков. Как вы видите бит запроса req у меня выставлен в истину (блок отрабатывается только по переднему фронту), биты успешного исполнения (done) выставлены в истину. Если у вас ни done, ни error не выставляется в истину,а connectionid первого вызова остается равным нулю, значит, что-то сделано не так. Например, используется не тот Server Endpoint или неправильно установлен сертификат. Эти вызовы должны вызваться последовательно один за другим. Я взводил биты руками и смотрел на результат вызова, а только потом переходил к следующему. Очевидно, что полноценная программа должна осуществлять вызов автоматически и переходить на следующий шаг в зависимости от результата текущего.

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

В результате вызова нетворка 4 в блоке данных DB2 появились прочитанные данные:

15. В настоящий момент два контроллера общаются по протоколу OPC UA, цель почти достигнута. Но не полностью. Настройки безопасности до сих пор находятся на уровне «бери, чо хошь». Я спокойно могу подключиться программой OPC UA Client и читать/записывать все возможные данные. Давайте ограничим круг общения этих ПЛК, пусть они «дружат» только друг с другом. Переходим на серверный контроллер, свойства CPU, OPC UA > Server > Security > Secure channel, убираем из Endpoint'ов политику «No Security»

Проматываем ниже до Trusted Clients. Добавляем сертификат контроллера-клиента (PLC_2). Снимаем галочку Automatically accept client certificates during runtime. Сервер теперь не будет общаться ни с кем, кроме как с клиентским PLC.

Переходим на User authentication, запрещаем гостевой доступ, создаем логин/пароль для пользовательского доступа: user1 / password1.

Прогружаем серверный PLC. Возвращаемся к клиентскому PLC, открываем Client interface, закладка Configuration, выбираем Security, в поле General выставляем режим и политику безопасности:

Проматываем ниже, выбираем тип аутентификации — пользователь и пароль, указываем имя пользователя user1, пароль password1

Снимаем галочку Automatically accept server certificate during runtime

Жмем на зеленую стрелочку, сразу переходим на другую закладку настроек ищем там поле «сертификаты партнерских устройств» и добавляем в него сертификат сервера

Компилируем и прогружаем клиентский ПЛК (PLC_2), открываем мониторинг OB1 и последовательно вручную исполняем блоки в нетворках 1..4 Если все сделано правильно, то все блоки отработают успешно, а данные будут успешно прочитаны в DB2.

16. Осталось лишь проверить, пустит ли кого-нибудь еще серверный контроллер. Запускаем OPC UA Client и пробуем подключиться. Список Endpoint'ов возвращается. Подключаемся по Basic256 SignAndEncrypt, указав имя пользователя user1 и пароль password1.

Предлагается проверка сертификата сервера, принимаем его

Но соединение не устанавливается, сервер не принимает сертификат «левого» клиента.

Итого, поставленная цель достигнута. Настроен безопасный обмен данными на уровне ПЛК, то есть - "горизонтальное" взаимодействие.