На FAT всё зелёное: Modbus TCP отвечает, тренды бегут, квитирование проходит. Акт подписан. На второй неделе эксплуатации электрик случайно выдернул патч-корд на минуту между свитчем и шкафом ПЛК. После восстановления кабеля SCADA «ожила», но часть уставок ушла в safe default, журнал событий обрезан, оператор пропустил переходный процесс. Начальник цеха спрашивает, почему приёмка не поймала «тридцать секунд тишины».
Короткий обрыв Ethernet на стенде редко входит в стандартный чек-лист «пинг есть, регистры читаются». А на объекте именно 30-60 секунд без связи проверяют устойчивость драйверов, таймауты reconnect, поведение аварий, целостность SOE и то, не остаётся ли HMI в «замороженном GOOD». Статья даёт минимальный сценарий для FAT/SAT и критерии приёмки. Это не курс по прокладке кабеля - физику и топологию смотрите в материале про промышленные сети; здесь - процедура и ожидаемое поведение АСУ.
Короткий ответ
Добавьте в FAT контролируемый обрыв Ethernet на 30 секунд с фиксацией до/после: связь, quality тегов, аварии, журнал, уставки. Ожидание: за время обрыва SCADA показывает потерю связи (не последнее GOOD без предупреждения), после восстановления - автоматический reconnect без ручного restart службы, критичные уставки и режимы не «тихо» сбрасываются без записи в SOE. Критерий приёмки - по таблице шагов ниже, с подписью в протоколе FAT. Если поведение не определено в проекте - сначала согласуйте с заказчиком и зафиксируйте в паспорте, потом тест. Общая рамка приёмки - FAT и SAT без сюрпризов на пуске.
Зачем именно 30 секунд, а не «выдернули на секунду»
Секундный обрыв многие стеки пережёвывают без видимых последствий - тест ничего не показывает. 30 секунд попадают в типичные окна: Modbus TCP timeout и retry суммарно 10-30 с, TCP retransmit, hold time на кольцевых топологиях, таймер «связь потеряна» в SCADA 20-60 с. Именно здесь всплывает «залипший» драйвер: Connected=true, данные не обновляются.
Шестьдесят секунд и больше - отдельный тест для длительного простоя (ночь, ремонт магистрали). Для FAT достаточно ступеней 5 с, 30 с, 120 с по согласованию. Минимум, который стоит не пропускать - 30 с с полной фиксацией.
Тест делают на каждом критичном сегменте: SCADA - основной ПЛК, ПЛК - удалённый I/O, HMI - ПЛК. Один успешный тест «в серверной» не покрывает цеховой свитч.
Подготовка сценария на стенде FAT
Согласуйте окно с технологом: процесс в безопасном режиме, механизмы отключены или на ручном, оператор предупреждён. Зафиксируйте baseline: скрин мнемосхемы, экспорт тренда за 5 минут, список активных аварий, значения 5-10 критичных уставок, время NTP.
Назначьте исполнителя обрыва (выдернуть патч на свитче access, не на core) и наблюдателя у SCADA с секундомером. Включите запись журнала событий и при возможности mirror port для Wireshark - не для обязательного анализа, а для споров после пуска.
Документируйте точку обрыва: «порт 7 свитча FAT-SW1, линк ПЛК-1». После теста - восстановление кабеля, без перезагрузки ПЛК и SCADA, если регламент не требует иного.
Что наблюдать во время обрыва
В первые 5-15 секунд драйвер Modbus TCP обычно уходит в retry. На HMI ожидают индикатор «нет связи» или quality BAD на тегах - по проекту. Если на 30-й секунде цифры всё ещё обновляются с меткой времени «сейчас» - дефект отображения или локальный кэш без stale flag.
Аварии «потеря связи с ПЛК» должны прийти в заданное время, не дольше согласованного в ТЗ (часто 10-20 с). Квитирование до восстановления связи - по логике проекта; важно, чтобы после reconnect не дублировались ложные пуски.
ПЛК в это время продолжает работу автономно. Проверьте, что выходы ведут себя по fail-safe (удержание, переход в безопасное состояние по ТЗ). Это не тест Ethernet как такового, а тест согласованности АСУ с технологией при потере верхнего уровня.
Если на 30-й секунде цифры всё ещё обновляются с меткой времени «сейчас» - дефект отображения или локальный кэш без stale flag. Это блокирующий дефект: оператор принимает решения по иллюзии связи.
Аварии «потеря связи с ПЛК» должны прийти в заданное время, не дольше согласованного в ТЗ (часто 10-20 с). Квитирование до восстановления связи - по логике проекта; важно, чтобы после reconnect не дублировались ложные пуски и не терялись события в журнале.
ПЛК в это время продолжает работу автономно. Проверьте, что выходы ведут себя по fail-safe (удержание, переход в безопасное состояние по ТЗ). Это тест согласованности АСУ с технологией при потере верхнего уровня, не только «кабель выдернули».
Восстановление связи: reconnect без ручного restart
После вставки патч-корда в течение 1-3 минут ожидают: драйвер Connected, опрос регистров, синхронизация времени если применимо. Не должно требоваться: ручной restart runtime SCADA, reboot ПЛК, очистка кэша браузера для Web-HMI (для fat-client SCADA - отдельно).
Зафиксируйте время восстановления от t0 (линк up) до t_first_good - первого обновления тега с GOOD. Если больше 180 с - заводите дефект, даже если «само прошло через пять минут».
Сравните уставки и режимы с baseline. Любое отличие без события в журнале - блокирующий дефект FAT. Особенно setpoint ПЧ, разрешения на пуск, interlock bypass flags.
Modbus TCP и ProfiNet: разное поведение на обрыве
Modbus TCP stateless на уровне приложения: каждый запрос - новая транзакция. Типичные проблемы - залипший TCP socket на стороне клиента, half-open connection. После 30 с обрыва смотрите unit id, transaction id, не сыпятся ли exception в лог.
ProfiNet и Ethernet/IP опираются на установленные IO connections с watchdog. Потеря связи может перевести модули в substitute value или last value - по GSD/EDS. Тест 30 с обязателен и там, с другими ожидаемыми флагами в диагностике.
Не смешивайте в одном протоколе приёмки «у нас Modbus, ProfiNet не трогаем» - если на объекте оба, оба в матрице тестов.
Ступенчатый сценарий: 5, 30 и 120 секунд
Минимальный протокол - три обрыва в одной сессии FAT с паузой 15 минут на стабилизацию. Пять секунд проверяет, что нет «хрупкого» reconnect при кратком дребезге линка (плохой патч, неаккуратное задевание кабеля). Тридцать секунд - основной тест таймаутов приложения. Сто двадцать секунд - поведение при ремонте: не уходит ли оператор в ручной обход, не срабатывает ли незадокументированный safe stop насосов.
После каждой ступени - полная таблица baseline vs факт. Если на 5 с всё OK, а на 30 с нет - дефект в пороге «потеря связи», не в физике.
Не объединяйте тесты «выдернули на минуту и сразу проверили всё подряд» - в логах не разделить, какой обрыв что сломал.
Роли участников и безопасность на стенде
Исполнитель обрыва - не тот, кто смотрит SCADA: два человека минимум. Третий - при необходимости технолог, подтверждающий безопасность процесса. На FAT с реальным техпроцессом (не симуляция) - наряд или регламент.
Запрещено тестировать обрыв на магистрали к ядру завода без согласования с ИТ. Рвать только порт access к одному шкафу или одному сегменту OT.
Что писать в дефект при провале теста
Формулировка «связь не восстановилась» недостаточна. Укажите: сегмент, длительность обрыва, t_restore, скрин HMI, фрагмент лога драйвера, ожидание по ТЗ, факт. Без t_restore интегратор «чинит» перезапуском службы, на объекте проблема вернётся.
Блокирующий дефект - если HMI показывал GOOD при отсутствии обновлений. Это риск ложных решений оператора, хуже чем лишняя авария.
SOE, журнал оператора и «тихие» потери
Sequence of events должен содержать: начало потери связи (с меткой времени), конец, возможно аварию коммуникации. Если SOE пустой, а оператор видел серый экран - архив не настроен или фильтр отсекает события.
Журнал действий оператора не должен терять записи за период обрыва на стороне SCADA. Проверьте также, не появились ли фантомные квитирования после reconnect.
Для SAT на объекте повторите тот же сценарий на production свитче в согласованное окно. Подпись в пакете документов при вводе - ссылка на протокол FAT/SAT с временем восстановления.
Для SAT на объекте повторите тот же сценарий на production свитче в согласованное окно. Подпись в пакете документов при вводе - ссылка на протокол FAT/SAT с временем восстановления.
Web-HMI и fat-client: один протокол, разные риски
Если на объекте есть и Web-HMI, и толстый клиент SCADA, тест 30 с обрыва делают для обоих. Web может показать stale page при живом TCP, fat-client - Bad quality. Критерии приёмки одинаковые по смыслу: оператор не должен видеть «свежую» цифру без связи.
Браузерный клиент после reconnect может потребовать re-login - это отдельный сценарий, не смешивайте с comm fault ПЛК. В протоколе FAT два пункта: связь SCADA-ПЛК и сессия Web.
Интеграция с FAT и SAT: куда вписать сценарий
В общий протокол FAT и SAT добавьте раздел «Устойчивость связи» с тремя длительностями обрыва. Без отдельной строки в акте тест «делали на память» на пуске не защитит интегратора и не даст эксплуатации рычаг.
Согласуйте с заказчиком допустимое t_restore до подписания контракта. Иначе на SAT спор: «30 секунд - это много» vs «у нас всегда так».
Минимальный протокол FAT: шаг, ожидание, критерий
| Шаг FAT | Ожидаемое поведение | Критерий приёмки |
|---|---|---|
| Baseline 5 мин стабильной связи | Теги GOOD, аварий нет (кроме тестовых) | Скрин + экспорт уставок |
| Обрыв Ethernet 5 с | Краткий retry, возможно без аварии | Нет crash службы SCADA/ПЛК |
| Обрыв 30 с | Авария/индикатор потери связи, BAD quality | Срабатывание не позже T_loss из ТЗ |
| HMI во время обрыва | Не показывать «свежее» без связи | Stale flag или явный баннер |
| ПЛК автономно | Выходы по fail-safe | Соответствие таблице безопасности |
| Восстановление кабеля | Авто reconnect | t_restore < 180 с, без ручного restart |
| Уставки после | Равны baseline | Допуск только по документированным правилам |
| SOE / журнал | Записи start/end comm fault | Полные метки времени, NTP в допуске |
| Повтор через 1 ч | То же поведение | Стабильность, не деградация |
| Web-HMI (если есть) | Аналог fat-client | Баннер + reconnect, session по регламенту |
Документируйте в паспорте объекта: кто подписывает протокол FAT по связи, какие сегменты тестировались, какие нет. «Не проверяли цеховой свитч» на пуске обернётся спором через две недели.
Вопросы с пуска
Можно ли имитировать обрыв firewall rule вместо патч-корда?
Да, если правило точно соответствует потере линка для нужного сегмента. Для FAT предпочтительнее физический обрыв access-порта - так видит и цеховой свитч.
Что если через 30 с всё «красиво», а через 5 минут опрос деградирует?
Добавьте soak test: 24 ч мониторинг счётчиков retry. Одноразовый 30 с не ловит утечки сокетов.
Нужно ли останавливать ПЛК на время теста?
Нет, цель - работающий низ при мёртвом верхе. STOP ПЛК - другой сценарий.
Кто подписывает протокол?
Представитель заказчика, интегратор, при необходимости - ИТ сети. Без подписи тест «делали, но не записали» на пуске не спасёт.
Обсуждение