Сбоит Modbus/TCP

[petr2off]

Добрый день. Столкнулся в очередной раз с проблемой взаимодействия SCADA с контроллером по Modbus/TCP.

В качестве объекта управления - водородка, состоит из 2 блоков - основного и резервного. Каждый управляется своей стойкой, в которой стоит OWEN и Waintek. В каждой стойке стоит свой свич - MOXA-205. К ней подключаются панель и контроллер и далее свичи от первой и второй стойки подключены к 205 MOXA, но уже с оптическим портом. По которому она приходит к Итачу. И у контроллера и у панели маска почему то 255.255.0.0. Почему - производитель мне объяснить не смог.

Так вот, когда подключена одна стойка водородки - все работает. Стоит подключить другую - начинаются выпадения. Причем в каждый момент времени работает только одна стойка. Провел эксперимент, подключил обе стойки к верхнему свичу, Ситуация улучшилась, но не решилась. Теперь работа идет с обеими стойками, но периодически (реже раз в 10) какая то из них отлетает, на 1 - 5 секунд.

Понятно, что косяк в организации сети, наверно ситуация улучшится, если вместо L2 на верхнем уровне L3 использовать. Но эта хрень будет стоить раза в 3 дороже. Может есть еще какие нибуть идеи, как это победить ?

[Ryzhij]

"Овно" на водородке?!
OMG!!!
Думаю, надо вместо неуправляемых коммутаторов установить роутеры и сконфигурировать их, чтобы разгрузить мозги "Овна" - нет там ни коммуникационных сопроцессоров, ни путного софта, чтобы ему разбираться с потоками запросов.

[Никита]

Первое что пришло в голову - где-то айпишники пересеклись. Но наверняка уже проверили).
Второе - я бы еще и мак-адреса проверил, у Овна особенно.
Третье - какие конкретно адреса заданы? Зачем сеть B? Если все устройства в нее загнаны без маршрутизации - удивительно что вообще что-то работает.
Четвертое - как связаны основной и резервный блоки?

[petr2off]

1 - Не пересеклись
2 - Маки проверил
3 - У основноного шкафа 10.0.6.10 - контроллер, 10.0.6.9 - панель
У резервного 10.0.6.11 - контроллер, 10.0.6.8 - панель
3 Тут все просто, производитель водородки поставляет свои шкафы как законченные устройства своего изделия. И возникла потребность интегрировать часть данных в АСУ ТП верхнего уровня (600 метров). Вот ее и интегрировали с помошью MOХA 205.
4 Вот так и связаны, через MOXA 205.

Сегодня провел дополнительный эксперимент, маску в стойках у контроллера и панели поменял с 255.255.0.0 на 255.255.255.0.
Улучшения кардинальные. На уровне скады все стоит нормально. Но когда смотрю протокол на сервер КИПА, (там вертится OPC Modbus) То вижу, постоянные сбои пакетов, с периодичностью секунд 5 наверно.

Завтра попробую к штатной схеме вернутся, с внутренними свичами. Кстати, сегодня специально в шкаф залез, там не MAXA, там DLink стоит, DES 1005, 5 портовый.

[Serex]

А между панелью и контроллером какой протокол крутиться? Тоже Modbus TCP. Это в одной сети несколько мастеров (клиентов) ?

[Никита]

OPC наверху один стоит или несколько? Панели клиентом подключаются?
Принципиально: потери пакетов с повтором или обрывы TCP-соединения с переустановкой? в OPC, случаем, галка закрытия TCP-сессии не установлена какая-нибудь?
На относительно недавнем объекте у известного форумчанам Заказчика наблюдалась интересная чехарда с моксовским MB3480. Выяснилось, что в определенных режимах маршрутизации MGate в принципе не может держать несколько подключений. В нашем случае или опрос с панели, или со стороны OPC. Кто первый подключится, в т.ч. и при переустановке связи. В других настройках одна мокса нормально обслуживала и OPC и панель. Вылечилось сменой режима маршрутизации в MGate по результатам переписки с поддержкой. Т.е. несколько мастеров для TCP возможны, но есть нюансы для конкретного железа.
Тут, похоже, обратная ситуация. Надо бы предметно поинтересоваться сокетами. И ответить на вопрос мой и Serex'а про связь панель-контроллер. И что наверху.

[Ryzhij]

А между панелью и контроллером какой протокол крутиться? Тоже Modbus TCP. Это в одной сети несколько мастеров (клиентов) ?

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

[petr2off]

Нет, между панелью и контроллером крутится свой протокол, у ОВНА есть свой шлюз к панели.
Но даже если это был бы Modbus - тут криминала нет. Сервер- клиент, это близкая - но не тождественная модель Modbus. Есть Master есть Slave. Одни девайс может быть и мастером и слэйвом одновременно. У той же панели есть вариант подключения в рассечку между контроллером и АРМом. При этом она одновременно и Master TCP и Slave TCP. Я делал приложение на OpenScada, которое выступало как Master по отношению к контроллеру на Isagraf и slave по отношению к АРМ на WinCC.

[Никита]

зависит лишь от способности этого сервера обрабатывать запросы в мультикастовом режиме.

Вот к этому я и спросил)
Честно говоря, не вижу явных косяков в построении (в описанном объеме), кроме маски /16. Впрочем, для 10-й сети некритично. И непонятно, что дало перетыкание свитчей.
А что простейшими пингами, кстати?

[petr2off]

Просто теряются пакеты на участке КОнтроллер - OPC. Причем, в такой конфигурации все работает. Просто пакеты частовато теряются. на мой взгляд.
Ну и опять же, это я временное решение применил, а проектное то никто не отменял, включу я завтра в цепочку 2 D-LINKa и что то мне кажется развалится развалится схема. Фактически было как минимум 2 косяка.
1-й маска 255.255.0.0 - которая несчастную MOXA 205 - перегружала.
2-й - нехорошая топология, когда под свичем L2 верхнего уровня стояло 2 свича L2 нижнего уровня, причем еще и разных производителей.

Фактически я эти две компоненты убрал, когда поставил маску 255.255.255.0 и пробросил кабели мимо D-Linkов, фактически напрямую подключил 2 панели и 2 контроллера в MOCA 205. И с точки зрения АРМа оператора - вообще все хорошо. Данные идут не пропадая. Но в протоколе OPC - шлейф пропадающих пакетов. Там параметр стоит - 10 попыток повтора, и этого хватает. Но похоже есть еще какая то маленькая засада.

Отправлено спустя 2 минуты 33 секунды:
С Пингами все отлично. И в проектной архитектуре (3 свича) и во временной 1 свич. Времена конечно разные. Причем в проектном варианте еще и нестабильные времена - но в пределах приличия.

[Никита]

Я потому и спросил про верх и всю сеть. В асушной сети сложно перегрузить коммутатор, у которого задействованы три порта. "несчастная" 205-я мокса вообще не имеет представления об IP-адресах и масках. Все зависит от того, что еще летает в сети.
Топология - ну так свитчи же. "Правило четырех хабов" уже неактуально.
Теряются -это уже скорее к физике. Нестабильные времена туда же.

[petr2off]

Подвожу итоги великой борьбы. Удалось снизить число сбойных пакетов,путем следующих мероприятий:
1) Выставил сетку 255.255.255.0
2) Вместо D-Link поставил моксу и феникс (ну не оказалось 2-х одинаковых свичей)
3) В OPC снизил размер пакета обмена с 64 параметров до 32.

На уровне СКАДА - все ОК.
На уровне OPC - 1 отказ в течении 40 секунд на каждом канале связи с контроллером.
Нужно будет наверно ы фанатов ОВЕНА поспрошать, какие у них есть процессы с 40 секундным циклом.

[Никита]

А промежуточных результатов нет? После выполнения каждого из пунктов?

[petr2off]

Последовательное улучшение. Т.е. каждый пункт вносил свою лепту, что столку то и сбивало.

[Никита]

Т.е. каждый пункт вносил свою лепту, что столку то и сбивало.

Именно в таком порядке?

[petr2off]

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

[petr2off]

Новые данные получил. Я думал все более- менее устаканилось. Нет, довольно продолжительное время оба контроллера как то работали (число сбоев не превышало 10) скада их не замечала, все ОК. А потом, один из контроллеров слетел, и начал сбоить на уровне скады, где то раз в 2-3 минуты. Выдернул из свича устойчиво работающий, и неустойчивый вдруг очень устойчиво заработал, даже сбойные пакеты пропали. Потом подключил втиорой контроллер и вернулся в начальное состояние. Т.е. сбои идут по обеим контроллерам, но скада пока их не видит, утром надо полагать один отвалится. Т.е. получается они друг другу как то мешают. Интересно, если их по разным подсеткам развести, они перестанут мешать друг - другу ?

[Михайло]

Кабели Ethernet длинные? Оборудование промышленное какое вокруг? Как организована защита от помех по питанию? Заземление грамотно сделано? Витая пара экранирована?

Первая мысль: может у вас по экрану уравнительные токи текут?

[petr2off]

Там меди совсем немного. БУквально метров по 6-8. Потом они в 205 моксу приходят и далее по оптике 600 метров до 208 моксы, атам метровым пачкордом до OPC сервера. Питание - там везде ИБП шки стоит и преобразование на 24 вольта.Кабель стандартный 5е.

[Никита]

Интересно, если их по разным подсеткам развести, они перестанут мешать друг - другу ?

Надо бы ради интереса каким-нить WireShark'ом посмотреть что вообще в сети происходит. Для начала - на уровне OPC-сервера. А вообще, не пришлось бы в ARP лезть-"травить" и весь трафик мониторить (я так понимаю, трафик отзеркалить невозможно) . Эта история по трудозатратам и квалификации уже может перекрыть стоимость Овеновского ПЛК...

[Михайло]

Ну допустим ПЛК110 не такой уж и дешёвый, как многим кажется... Так что надо ещё пробовать пытаться решить проблему за счёт бесплатного таланта.

Удалось снизить число сбойных пакетов,путем следующих мероприятий:
1) Выставил сетку 255.255.255.0
2) Вместо D-Link поставил моксу и феникс (ну не оказалось 2-х одинаковых свичей)
3) В OPC снизил размер пакета обмена с 64 параметров до 32.

Обратите внимание: все три мероприятия так или иначе изменяют неаппаратные сущности. Попробуйте снизить частоту запросов на мастере сети Modbus TCP, вы наверное перегрузили траффик/буферы и какому-то устройству это "не нравится", предположительно Овну.

[petr2off]

Тут все просто, в аппаратуру я лезть не могу. Она типа на гарантии. В понедельник приедет представитель производителя - бкдем шаманить. На сервере OPC опрос вообще снизило то 3-х секунд.

[Никита]

На сервере OPC опрос вообще снизило то 3-х секунд.

Кстати, а читаются параметры цепочкой или каждый отдельно запрашивается? Десяток параметров за секунду спокойно можно по последовательному каналу на 9600 читать.
В порядке бреда: а не стороннее ли это вмешательство (вируса, или наоборот, антивируса, или еще чего, что вашей сети спокойно жить не дает...)?

[petr2off]

Это в настройках OPC задается. Там сейчас выставлено чтение 32. Регистров за один запрос. Кроме ОВЕНА, это OPC также читает параметры с ИБП и подсистемы ВИБРОБИТ - там все нормально читается. Сеть эта исключительно АСУ ТПшная. С Интернетом она никак не общается.

[dijio]

Было нечто подобное при недожатом коннекторе у Ethernet провода.
У всех проводов обжим корректный?
Я бы ещё попробовал Ethernet кабеля поменять на экранированную 6 категорию.