Говоря сухим языком, МЭК 60870-5-104 – протокол телемеханики, предназначенный для передачи сигналов в систему верхнего уровня, регламентирующий использование сетевого доступа по протоколу TCP/IP. Чаще всего применяется в энергетике для информационного обмена между энергосистемами, а также для получения данных от измерительных преобразователей (вольтметры, измерительные преобразователи и прочее).

А теперь, отбросив официоз, попробуем настроить сервер этого протокола в SCADA системе Simatic WinCC Open Architecture.

Компания Siemens в версии 17 TIA Portal Step7 для FW ≥4.5 (S7-1200) и FW ≥2.9 (S7-1500) встала на путь легкого принуждения к повышению уровня информационной безопасности. Теперь TIA Portal мягко предлагает задать пароль на хранилище сертификатов CPU, пароль на чтение/запись программы CPU, пароль на обмен с HMI и, конечно же, шифрованный обмен с применением сертификата. Все это, конечно, отключаемо, но зачем отключать то, что предлагается «из коробки»? События этого века показали всю важность инфобеза систем промышленной автоматики, а так же показали, что происходит при защите систем «от честного человека» (я про stuxnet, да). Основная причина, по которой, как мне кажется, шифрование не применяется - непонимание принципов работы и инерционность мышления (наши деды ни про какой TLS не слышали, и мы тоже не будем). В рамках одного проекта TIA Portal все еще более-менее ясно, а как быть с подключением «непортальных» систем? Рассмотрим такое подключение на примере S7-1500 FW2.9 и WinCC OA 3.18.

Продолжаем разбирать коммуникационные возможности системы WinCC OA. Но этот раз рассмотрим подключение к контроллеру «гражданской» автоматизации (AKA автоматизация зданий) Siemens PXC12 по протоколу Bacnet, который и был разработан аккурат для автоматизации зданий.

Большинство драйверов промышленных протоколов, будь то S7 / S7Plus, Modbus, IEC-101 / 104 и т.д. настраиваются и работают как в версии под управлением Windows, так и Linux. Исключения, разумеется, есть. В первую очередь - это классический OPC. Обратите внимание, именно OPC, а не современный мультиплатформенный OPC UA. Надеюсь, что многие еще помнят, что аббревиатура OPC раскрывалась изначально, как OLE for Proccess Control. Ну, а анекдотов про Open Proccess Communication насочиняли уже позже. Технология OLE относится к механизмам OC Windows и несовместима с Linux. Вторым исключением является драйвер Cerberus (пожаро-охранная система).

Рассмотрим настройку связи с контроллером Simatic S7-1500 при помощи драйвера S7Plus в версии под Debian 10. Этот драйвер предназначен для опроса ПЛК серии S7-1200/1500 с использованием символьной адресации.

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

Для обеспечения связи с оборудованием при использовании сервера OPC нам так же необходимо добавлять в систему драйвер. Рассмотрим на примере драйвера OPC DA (data access, простой обмен данными). В качестве сервера OPC в данном примере используется широко известный Lectus, который по протоколу Modbus TCP будет связываться с локальным программным сервером Modbus TCP. Напоминаю, что сервер - это тот, кто отвечает на запросы. Клиент эти самые запросы генерирует.

Итого, в этой связке у нас получается по 2 клиента и по 2 сервера:

• драйвер OPC DA является клиентом OPC для сервера Lectus

• Lectus является сервером OPC для драйвера и одновременно клиентом Modbus TCP для внешнего устройства, с которым мы организовываем связь

• сервером протокола Modbus выступает отдельная прогамма, установленная локально

Проект уже создан, версия 3.18.

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

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

Продолжаем расширять мой базовый курс работы с системой WinCC OA. На этот раз речь пойдет о драйвере Modbus TCP.

Связи S7 лет уже много. И многие про него знают тоже много. И даже много используют. Работать с ними весьма легко - создал S7 connection, разместил, где надо, функциональные блоки PUT/GET (самый простой вариант) или BSEND/BRECEIVE, выполнил download, и все - полный превед, знай только, контролируй состояние флагов NDR и Error.

Чаще всего оба коммуникационных партнера находятся в одной сети. А что делать, если CPU находятся в разных сетях Profinet? Или, еще круче, один участник обмена подключен к некоему промежуточному узлу по Profinet, а второй - к этому же промежуточному узлу по Profibus.

В данной заметке рассмотрим функционал, появившейся в «прошивке» 2.8 (поддерживается в Step 7 версии 16 и выше) серии контроллеров S7-1500, а именно — перенаправление (форвард) ip-пакетов между интерфейсами.

Классические линейки контроллеров Siemens, а именно — Simatic S7-300 и Simatic S7-400, поддерживают протокол Modbus TCP как в качестве клиента, так и в качестве сервера. Эта поддержка не лишена одного существенного недостатки, она платная, и стоимость лицензии весьма высока.

Если заказчик — «богатый», а интегратор — «умный» (опытный), то факт платности лицензии и ее стоимость не приводит к неприятностям, все известно заранее, на этапе составления спецификации, бюджет согласован заранее. Если применяется серия S7-1200 / 1500, то вопрос даже не поднимается, эти PLC поддерживают Modbus RTU и TCP без дополнительного лицензирования.

На практике встречаются случаи, когда ничто не «предвещало беды», но модбас на «трехсотнике» неожиданно становится нужен (никогда такого не было, и вот опять!). Не учли что-нибудь, форс-мажор или просто разгильдяйство. Какие в этом случае пути решения?

В предыдущей заметке (https://habr.com/ru/post/651329/) был затронут вопрос организации связи программируемого реле Logo! компании Siemens по протоколу Modbus TCP. В том примере применялись отдельные диаграммы для каждого устройства. Кроме режима диаграмм Logo!Soft Comfort предоставляет возможность создания т.н. «сетевых проектов» (network projects).

Disclaimer. Написанное относится к 16ой версии и публикуется очень запоздало. В версии 17 функционал был расширен, и добавлена возможность мигания как минимум динамическим диалогом свойства background color.

Свежие (в том числе и относительно свежие) модели программируемого реле Logo! от компании Siemens поддерживают передачу данных по протоколу Modbus TCP как в качестве клиента, так и в качестве сервера. К ним относятся модули версий 8.1 & 8.2 (FS4) и 8.3. В настоящей заметке рассматривается простой вариант с использованием circuit diagram, сетевой проект не используется. В качестве среды разработки применяется LOGO!Soft Comfort версии 8.3.0.

-Нам срочно нужна связь

-Половую предложить не могу!

(с) Звездные Войны. Буря в стакане. Студия "Божья Искра" (ст. о/у Goblin)

Году эдак в 2011 я на правах фрилансера написал и внедрил ПО для управления водонапорной станцией. По итогам система получилась распределенной и даже немного сложной, но начиналось все с локальной станции управления одной насосной установкой.

Проектная организация заложила CPU Simatic S7-313C. Неожиданно мне стало интересно, как это будет выглядеть на новой линейке Simatic? Влезет ли прикладная программа, легко ли она портируется? Сколько стоит решение - внедренное ранее и выбранное мной сейчас?

Обнаружил в базе знаний Siemens (SIOS) интересный пример использования контроллеров линейки S7-1200 и S7-1500 в качестве клиента протокола MQTT

Ссылка на первоисточник.

Попробуем разобраться?

S7-соединения, применяемые для обмена информацией между устройствами серии S7-300, 400, 1200, 1500, являются конфигурируемыми. Это означает, что необходимо явно указать устройствам, кто с кем общается. В общем случае эти соединения являются двунаправленными (двухсторонними или же bilaterally), т.е. добавление конфигурируемого соединения происходит для обоих ПЛК, что приводит к необходимости прогрузки обоих ПЛК. Это не вызывает особенных проблем, если оба ПЛК находятся в ведомстве службы АСУТП предприятия, и для обоих ПЛК есть на руках актуальное прикладное ПО. Но встречаются и частные случаи — необходимо наладить обмен между «старым» S7-300 и «новым» S7-1500, причем, исходники старой программы утрачены. Ну, или эксплуатация просто боится трогать ПЛК. Или эксплуатации просто нет, задача организации обмена «висит» на интеграторе «новой» системы, что приводит к предыдущему условию — трогать ППО неизвестной системы никому особо не хочется.

Давно хотел рассказать про тонкости программирования обмена по протоколу Modbus RTU в случае, когда контроллер (в нашем случае S7-1214) выступает RTU Master'ом. Недавно меня попросили помочь с обменом между ПЛК и частотным преобразователем Sinamics V20, ну и почему бы не написать заодно заметку, постаравшись приблизить решение задачи к боевым условиям.

Продолжаем тему программирования протокола Modbus TCP на контроллерах Simatic S7-1500. В прошлый раз речь шла о серверной части, сегодня опишем клиентскую. Клиент Modbus TCP — это узел, который генерирует запросы к серверу, т.е. запрашивает данные и передает уставки/команды. В терминологии Modbus RTU это «мастер», ведущее устройство. В отличии от RTU, в протоколе TCP может быть несколько «мастеров» (правильно — клиентов).

Первая спецификация протокола Modbus была опубликова в 1979 году. Протокол предназначен для опроса подчиненных устройств по принципу «запрос-ответ». Modbus RTU (Remote Terminal Unit) работает по последовательному интерфейсу передачи данных (RS-232, RS-485, RS-422). Сегодня речь пойдет о немного измененном протоколе, Modbus TCP, работающий на прикладном уровне стека протоколов TCP/IP.

Для начала посмотрим, как настраивается (программируется, если быть точнее) серверная часть. Modbus TCP Server — аналог Modbus RTU Slave, то есть, является подчиненным устройством. Это важно, не путайте. Сервер лишь отвечает на запросы, но не генерирует их.

В данном примере применяется CPU S7-1516 с версией прошивки 2.6. Серия S7-1200 программируется аналогично.