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

S7 routing работает в «тысячной» серии просто прекрасно, и не требует никаких специальных настроек или сакральных знаний. Единственное требование — это заданная сетевая конфигурация оборудования, разовая индивидуальная прогрузка каждого CPU, после чего можно спокойно пользоваться этим функционалом. К примеру, вот такая несложная схема:

В данном случае CPU 1516 по интерфейсу X1 (адрес 192.168.43.1) соединяется с CPU 1214 (адрес 192.168.43.2). По интерфейсу X2 я просто подключаю программатор. Сконфигурировано две сети:

PLC_PLC — связь между контроллерами;

TO_PG — для связи с программатором.

Оба контроллера прогружены . Теперь для выхода в онлайн контроллера PLC_2 мне нет необходимости подключаться к нему непосредственно, достаточно лишь убедиться, что программатор соединен с интерфейсом X2 PLC_1 и выбрать для подключения сеть TO_PG. Шлюз система определит автоматически.

Прошу обратить внимание на следующий факт, а именно — на выбранные мной IP-адреса. Я не использую в своих экспериментах сети 192.168.0.X и 192.168.1.X Связано это с тем, что программатор в тепличных лабораторных условиях посредством адаптера WiFi смотрит еще и в Интернет, а офисный (домашний) рутер в 99% случаев настроен именно на эти диапазоны адресов. Поэтому, перед любыми сетевыми экспериментами убедитесь, что вы не используете «офисные» адреса или просто отключите WiFi.

Но вернемся к вопросам маршрутизации. В принципе, функционала S7 routing хватает почти на все. За некоторым исключением. Во-первых, мы можем использовать исключительно устройства, поддерживающие S7 routing (большинство современного оборудования Simatic). Во-вторых, маршрутизация пакетов S7 маршрутизирует только… пакеты S7, а именно — PG, OP или обмен данными посредством S7-коммуникаций «контроллер-контроллера», например, на базе механизма Put/Get.

Говоря менее заумным языком, попробуйте пропинговать контроллер PLC_2.

Разумеется, данная попытка заведомо обречена на провал: ноутбук (программатор) находится в другой подсети. Для таких случаев, когда необходимо общение именно на уровне протокола IP и предназначен новый функционал. Сейчас я предлагаю путем проб и ошибок «походить по граблям» и настроить эту маршрутизацию, чтобы я мог пропинговать мой S7-1214 с ноутбука.

Функционал форварда IP пакетов находится в свойствах CPU в закладке Advanced Configuration

Поставим эту галочку, выполним download и попробуем пропинговать PLC_2. Я даже скриншот приводить не буду, сразу скажу, что это бесполезно. С чем это связано? Для ответа на этот вопрос требуется базовое пониманием межсетевого протокола (internet protocol) и маршрутизации. Лучше выполним на нашем программаторе команду

tracert 192.168.43.2

Я получил следующее:

C:\Users\Earl>tracert 192.168.43.2

Tracing route to 192.168.43.2 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.1.1

Смотрим на третью строку. Пакет, предназначающийся узлу сети с адресом 192.168.43.2, пошел по маршрутизации на узел с адресом 192.168.1.1. Адрес 192.168.1.1 — это шлюз по умолчанию офисного роутера. Смотрите, что происходит. Проводной интерфейс, которым я подключен к PLC_1, настроен на ip-адрес 192.168.143.100. Если я начну пинговать интерфейс X2 контроллера PLC_1, адрес которого 192.168.143.1, то пакеты и пойдут по этому проводному интерфейсу. Но адрес 192.168.43.2, который интересен мне, находится в другой подсети. Мой программатор не знает, куда направить пакет этого адреса, и отправляет его на офисный маршрутизатор. Который, в свою очередь, тоже не особо знает, что это за адрес, и скидывает его дальше в "непонятном направлении".

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

Далее выполняем команду route print

Смотрим вначале первую часть: Interface list, список интерфейсов. Мне интересна сетевая плата с именем Intel(R) Ethernet Connection (2) I219-LM, именно с ее помощью я подключен к CPU. В вашем случае интерфейс будет, разумеется, другим. Номер моего интерфейса = 14, запоминаю его.

Далее при помощи команды route add я должен сообщить своему ноутбуку, через какой интерфейс и через какой маршрутизатор надо отправлять пакеты, предназначенные для PLC_2.

C:\Windows\system32>route add 192.168.43.0 mask 255.255.255.0 192.168.143.1 IF 14

OK!

Рассмотрим команду route add 192.168.43.0 mask 255.255.255.0 192.168.143.1 IF 14 подробнее. Смысл ее следующий: все пакеты в сеть 192.168.43.Х с сетевой маской 255.255.255.0 направлять на маршрутизатор с адресом 192.168.143.1 через интерфейс ноутбука с номером 14

192.168.43.0 — диапазон адресов, который касается записи в таблице маршрутизации ноутбука

mask 255.255.255.0 — сетевая маска этого диапазона (сети)

192.168.143.1 — адрес интерфейса X2 контроллера PLC_1, по этому интерфейсу у нас и устанавливается соединение… по суть, это адрес роутера, который должен направлять пакеты далее

IF 14 — это номер моего интерфейса

В ответ должно быть сообщение «ОК!»

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

Таким образом, наш контроллер PLC_1 отзывается по адресу интерфейса, с которым у нас нет физического соединения (ведь наша непосредственная сеть имеет адрес 192.168.143.Х).

Может показаться, что теперь можно еще и удачно пинговать PLC_2 по адресу 192.168.43.2, но не тут-то было!

Чего же не хватает? Давайте посмотрим сетевые настройки PLC_2 и снова вспомним принципы работы межсетевого протокола.

А не хватает следующего. PLC_2 находится в сети «43», а к нему приходят пакеты из сети «143». При этом на PLC_2 даже не задан шлюз по умолчанию. Грубо говоря, запросы пингов PLC_2 получает, но не знает, куда отправлять ответы. Добавим в качестве роутера для контроллера 2 адрес сетевого интерфейса X1 контроллера 1, т.е. 192.168.43.1 и выполним download.

После этой настройки контроллер начал давать ответы на ping

В принципе, внимательный и/или опытный читатель к этому времени уже может смело упрекнуть меня — «А зачем оно? Ради какого-то пинга? Да еще и с симатиковским же оборудованием в аппаратной конфигурации».

Все оборудование в проекте было симатик, это точно. Но исключительно для упрощения жизни. Сейчас я предлагаю отвязаться от S7-1200 и представить на его месте некое абстрактное устройство с поддержкой протокола Modbus TCP (его серверную часть). Для этого на S7-1200 я быстро настроил Modbus Server и проверил его в работе.

Как видно, клиентская часть спокойно опрашивает сервер. Сейчас давайте отвяжемся от S7-1200 в нашем проекте. Отсоединим его от сети PLC_PLC.

Даже больше, полностью удалим PLC_2 из проекта:

Сделаем прогрузку PLC_1. При этом у нас сохранился ping 192.168.43.2. И клиент modbus на ноутбуке продолжает успешно опрашивать подчиненное устройство. То есть, свое применение у этого функционала, несомненно, имеется, когда речь заходит не только об устройствах S7.

Во встроенной справке на функционал IP Forwarding есть вполне подробное описание. Таблица маршрутизации контроллера S7-1500 строится на основании сетевой конфигурации. Откровенно говоря, я ожидал, что после удаления PLC_2 из проекта и прогрузки PLC_1, PLC_2 вообще перестанет отвечать на какие-либо запросы, и потребуется установить в сеть PLC_PLC какое-либо фиктивное устройство с ip адресом. Однако, скорее всего, в связи с предельной примитивностью этого примера, дополнительных действий не потребовалось.

Еще одно возможное применение. Применять форвард пакетов для функционирования Simatic PDM. К интерфейсу X1 CPU S7-1516 подключены две линейки расширения, одна из которых содержит аналоговый модуль с поддержкой HART, это io device 2. К каналу 0 этого AI подсоединен датчик давления HART. Виртуальная машина с установленным Simatic PCS 7 в PDM, подключена к интерфейсу X1 ПЛК. Адреса сети ПЛК-комп относятся к 192.168.1.X, "контроллерная сеть" - 192.168.43.X.

Тут все происходит аналогично. Необходимо разрешить IP Forward в настройках CPU. Необходимо задать default gateway для io device 2.

Конечно же, в машине с PCS выполняем команду route add. После этих нехитрых настроек, функционал HART становится доступным. Особо в тонкости PDM я в этом примере не углублялся, так даже базу данных "умных полевых приборов" не устанавливал, проверялся сам факт работоспособности функционала.

Необходимо дополнительно остановиться на нюансах. Первое. Корректировка таблицы маршрутизации на уровне компьютера с отправкой команды - дело, разумеется, веселое и полезное (мало того, так и приведено в примерах Siemens), но немного бестолковое. Разумеется, этот вопрос необходимо решать аппаратными маршрутизаторами. Второе. Не забываем, что при таком подходе у нас пропадает разделение сетей. А это уже влияет на безопасность. Применять эти знания следует с умом.