Блог

FAT и SAT без формализма: Как принимать систему автоматизации так, чтобы не ловить сюрпризы на пуске

2026-04-15 10:26
FAT (Factory Acceptance Test) и SAT (Site Acceptance Test) часто воспринимают как «папку для подписи». На пуске выясняется, что протокол был формальным: не проверили отказ канала, не прогнали негативные сценарии, не согласовали критерии приемки. В итоге дорогой простой идет на поиск «почему на стенде работало».
Ниже - практический подход: где проходит граница FAT и SAT, какие критерии приемки должны быть, какие негативные сценарии обязательны и шаблон протокола с блоком pass/fail и замечаниями.

Короткий ответ

FAT подтверждает, что система соответствует проекту и логике в контролируемых условиях (стенд, эмуляция поля). SAT подтверждает, что система работает на реальном объекте с реальными кабелями, питанием, сетью и персоналом. Чтобы не ловить сюрпризы на пуске, в протоколах должны быть измеримые критерии, негативные сценарии и явные pass/fail с планом устранения замечаний до начала промышленной эксплуатации.

Границы FAT и SAT: кто что доказывает

Этап
Где
Что доказываем
Типичные ограничения
FAT
завод/интегратор
логика, HMI, обмен, базовая производительность
эмуляция поля, не вся физика
SAT
объект
реальные сигналы, шум, питание, сеть, эксплуатация
сложнее повторять все негативы
Правило: то, что можно доказать на стенде, не откладывайте на SAT, если это не требует реального оборудования.

Критерии приемки: как сделать их измеримыми

Плохой критерий: «работает стабильно».
Хороший критерий: «при сценарии X за Y минут нет событий класса A, а отклонение параметра Z не превышает N».
Минимальный набор групп критериев:
  1. Функциональность - соответствие логике и HMI по перечню сценариев.
  2. Обмен данными - опрос, таймауты, восстановление после обрыва.
  3. Производительность - цикл ПЛК, нагрузка на сеть, отклик SCADA.
  4. Безопасность - блокировки, permissive, аварийные цепи.
  5. Эксплуатация - роли, журналы, резервное копирование, процедуры.

Обязательные негативные сценарии (минимум)

Проверяйте не только «счастливый путь»:
  • обрыв связи с критичным узлом и восстановление;
  • потеря питания/перезапуск ПЛК и поведение после старта;
  • отказ одного канала связи при резервировании;
  • превышение уставок и корректность тревог;
  • действия оператора вне последовательности (ошибочные нажатия);
  • режимы переналадки/сервиса, когда часть функций должна быть заблокирована;
  • нагрузочный сценарий (массовый опрос, пик событий).
Если негативные сценарии не в протоколе, они случатся на первой неделе эксплуатации.

Шаблон протокола FAT/SAT (с pass/fail и замечаниями)

Используйте как основу, расширяя под объект.

Шапка протокола

Поле
Значение
Тип
FAT / SAT
Объект / линия
Версия проекта ПЛК/SCADA
Дата и время начала/окончания
Участники (роли)
заказчик, интегратор, АСУ ТП, эксплуатация
Ссылка на ТЗ/перечень сценариев

Таблица сценариев

ID
Сценарий
Критерий приемки
Метод проверки
Pass/Fail
Замечания
Ответственный за устранение
Срок
F-01
Пуск линии в автомате
выполняется последовательность A-B-C без блокировок
пошаговый прогон
F-02
Аварийный стоп
останов в пределах T сек, статусы корректны
тест кнопки/цепи
N-01
Обрыв связи Modbus/TCP
восстановление без зависания, нет дублей команд
отключение линка
N-02
Перезапуск ПЛК
безопасный старт, нет неожиданных выходов
power cycle
P-01
Нагрузка опроса
p95 задержки < X мс при Y тегах
измерение

Итоговый блок

Итог
Значение
Общий статус
Pass / Pass with comments / Fail
Критичные замечания (блокирующие пуск)
да/нет, перечень ID
Условия допуска к следующему этапу
Подписи

Как избежать «формализма ради формализма»

  • держите протокол коротким, но жестким по критериям;
  • фиксируйте версии ПО и проектов в шапке;
  • не смешивайте FAT и SAT в один день без разделения ответственности;
  • любой fail должен иметь владельца и срок;
  • повторный прогон только для failed сценариев после исправления.

Типовые провалы

  • FAT без эмуляции реальных задержек и шума;
  • SAT без участия эксплуатации;
  • отсутствие негативных сценариев;
  • «Pass» при известных дефектах «потом поправим»;
  • нет критериев производительности и надежности связи.

Где уместен СТАБУР

Качество FAT/SAT зависит от предсказуемости нижнего уровня: стабильные модули, понятная диагностика, единые шаблоны проектов между объектами. На практике это проще выдерживать в стеке с проверенной интеграцией, в том числе в проектах на базе решений СТАБУР.

Заключение

FAT и SAT нужны не для галочки, а чтобы перенести риск в контролируемую зону. Четкие критерии, негативные сценарии и явные pass/fail с замечаниями снижают стоимость пуска и споров между заказчиком и интегратором. Если сценарий нельзя проверить измеримо, его нельзя принять.

FAQ

Можно ли проводить SAT без полного производства?

Частично, но критичные цепи должны быть на реальном оборудовании или максимально близкой копии.

Сколько сценариев достаточно?

Лучше меньше, но с полным покрытием рисков, чем сотня формальных строк.

Что делать, если заказчик торопит?

Фиксировать известные риски письменно и переносить непокрытое в отдельный план с датой.

Нужен ли отдельный протокол для кибербезопасности?

Да, как минимум для удаленного доступа, учеток и сегментации.

Кто подписывает итог?

Представитель заказчика и ответственный за ввод в эксплуатацию.

Внутренняя перелинковка