На 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 секунд попадают в типичные окна: Modbus TCP timeout и retry суммарно 10-30 с, TCP retransmit, hold time на кольцевых топологиях, таймер «связь потеряна» в SCADA 20-60 с. Именно здесь всплывает «залипший» драйвер: Connected=true, данные не обновляются.
Шестьдесят секунд и больше - отдельный тест для длительного простоя (ночь, ремонт магистрали). Для FAT достаточно ступеней 5 с, 30 с, 120 с по согласованию. Минимум, который стоит не пропускать - 30 с с полной фиксацией.
Тест делают на каждом критичном сегменте: SCADA - основной ПЛК, ПЛК - удалённый I/O, HMI - ПЛК. Один успешный тест «в серверной» не покрывает цеховой свитч.
Согласуйте окно с технологом: процесс в безопасном режиме, механизмы отключены или на ручном, оператор предупреждён. Зафиксируйте 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 (удержание, переход в безопасное состояние по ТЗ). Это тест согласованности АСУ с технологией при потере верхнего уровня, не только «кабель выдернули».
После вставки патч-корда в течение 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 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 не трогаем» - если на объекте оба, оба в матрице тестов.
Минимальный протокол - три обрыва в одной сессии FAT с паузой 15 минут на стабилизацию. Пять секунд проверяет, что нет «хрупкого» reconnect при кратком дребезге линка (плохой патч, неаккуратное задевание кабеля). Тридцать секунд - основной тест таймаутов приложения. Сто двадцать секунд - поведение при ремонте: не уходит ли оператор в ручной обход, не срабатывает ли незадокументированный safe stop насосов.
После каждой ступени - полная таблица baseline vs факт. Если на 5 с всё OK, а на 30 с нет - дефект в пороге «потеря связи», не в физике.
Не объединяйте тесты «выдернули на минуту и сразу проверили всё подряд» - в логах не разделить, какой обрыв что сломал.
Исполнитель обрыва - не тот, кто смотрит SCADA: два человека минимум. Третий - при необходимости технолог, подтверждающий безопасность процесса. На FAT с реальным техпроцессом (не симуляция) - наряд или регламент.
Запрещено тестировать обрыв на магистрали к ядру завода без согласования с ИТ. Рвать только порт access к одному шкафу или одному сегменту OT.
Формулировка «связь не восстановилась» недостаточна. Укажите: сегмент, длительность обрыва, t_restore, скрин HMI, фрагмент лога драйвера, ожидание по ТЗ, факт. Без t_restore интегратор «чинит» перезапуском службы, на объекте проблема вернётся.
Блокирующий дефект - если HMI показывал GOOD при отсутствии обновлений. Это риск ложных решений оператора, хуже чем лишняя авария.
Sequence of events должен содержать: начало потери связи (с меткой времени), конец, возможно аварию коммуникации. Если SOE пустой, а оператор видел серый экран - архив не настроен или фильтр отсекает события.
Журнал действий оператора не должен терять записи за период обрыва на стороне SCADA. Проверьте также, не появились ли фантомные квитирования после reconnect.
Для SAT на объекте повторите тот же сценарий на production свитче в согласованное окно. Подпись в пакете документов при вводе - ссылка на протокол FAT/SAT с временем восстановления.
Для SAT на объекте повторите тот же сценарий на production свитче в согласованное окно. Подпись в пакете документов при вводе - ссылка на протокол FAT/SAT с временем восстановления.
Если на объекте есть и Web-HMI, и толстый клиент SCADA, тест 30 с обрыва делают для обоих. Web может показать stale page при живом TCP, fat-client - Bad quality. Критерии приёмки одинаковые по смыслу: оператор не должен видеть «свежую» цифру без связи.
Браузерный клиент после reconnect может потребовать re-login - это отдельный сценарий, не смешивайте с comm fault ПЛК. В протоколе FAT два пункта: связь SCADA-ПЛК и сессия Web.
В общий протокол FAT и SAT добавьте раздел «Устойчивость связи» с тремя длительностями обрыва. Без отдельной строки в акте тест «делали на память» на пуске не защитит интегратора и не даст эксплуатации рычаг.
Согласуйте с заказчиком допустимое t_restore до подписания контракта. Иначе на SAT спор: «30 секунд - это много» vs «у нас всегда так».
| Шаг 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 ПЛК - другой сценарий.
Кто подписывает протокол?
Представитель заказчика, интегратор, при необходимости - ИТ сети. Без подписи тест «делали, но не записали» на пуске не спасёт.