FAT (Factory Acceptance Test) и SAT (Site Acceptance Test) часто воспринимают как «папку для подписи». На пуске выясняется, что протокол был формальным: не проверили отказ канала, не прогнали негативные сценарии, не согласовали критерии приемки. В итоге дорогой простой идет на поиск «почему на стенде работало».
Ниже - практический подход: где проходит граница FAT и SAT, какие критерии приемки должны быть, какие негативные сценарии обязательны и шаблон протокола с блоком pass/fail и замечаниями.
Короткий ответ
FAT подтверждает, что система соответствует проекту и логике в контролируемых условиях (стенд, эмуляция поля). SAT подтверждает, что система работает на реальном объекте с реальными кабелями, питанием, сетью и персоналом. Чтобы не ловить сюрпризы на пуске, в протоколах должны быть измеримые критерии, негативные сценарии и явные pass/fail с планом устранения замечаний до начала промышленной эксплуатации.
Границы FAT и SAT: кто что доказывает
Правило: то, что можно доказать на стенде, не откладывайте на SAT, если это не требует реального оборудования.
Критерии приемки: как сделать их измеримыми
Плохой критерий: «работает стабильно».
Хороший критерий: «при сценарии X за Y минут нет событий класса A, а отклонение параметра Z не превышает N».
Минимальный набор групп критериев:
- Функциональность - соответствие логике и HMI по перечню сценариев.
- Обмен данными - опрос, таймауты, восстановление после обрыва.
- Производительность - цикл ПЛК, нагрузка на сеть, отклик SCADA.
- Безопасность - блокировки, permissive, аварийные цепи.
- Эксплуатация - роли, журналы, резервное копирование, процедуры.
Обязательные негативные сценарии (минимум)
Проверяйте не только «счастливый путь»:
- обрыв связи с критичным узлом и восстановление;
- потеря питания/перезапуск ПЛК и поведение после старта;
- отказ одного канала связи при резервировании;
- превышение уставок и корректность тревог;
- действия оператора вне последовательности (ошибочные нажатия);
- режимы переналадки/сервиса, когда часть функций должна быть заблокирована;
- нагрузочный сценарий (массовый опрос, пик событий).
Если негативные сценарии не в протоколе, они случатся на первой неделе эксплуатации.
Шаблон протокола FAT/SAT (с pass/fail и замечаниями)
Используйте как основу, расширяя под объект.
Шапка протокола
Таблица сценариев
Итоговый блок
Как избежать «формализма ради формализма»
- держите протокол коротким, но жестким по критериям;
- фиксируйте версии ПО и проектов в шапке;
- не смешивайте FAT и SAT в один день без разделения ответственности;
- любой fail должен иметь владельца и срок;
- повторный прогон только для failed сценариев после исправления.
Типовые провалы
- FAT без эмуляции реальных задержек и шума;
- SAT без участия эксплуатации;
- отсутствие негативных сценариев;
- «Pass» при известных дефектах «потом поправим»;
- нет критериев производительности и надежности связи.
Где уместен СТАБУР
Качество FAT/SAT зависит от предсказуемости нижнего уровня: стабильные модули, понятная диагностика, единые шаблоны проектов между объектами. На практике это проще выдерживать в стеке с проверенной интеграцией, в том числе в проектах на базе решений СТАБУР.
Заключение
FAT и SAT нужны не для галочки, а чтобы перенести риск в контролируемую зону. Четкие критерии, негативные сценарии и явные pass/fail с замечаниями снижают стоимость пуска и споров между заказчиком и интегратором. Если сценарий нельзя проверить измеримо, его нельзя принять.
FAQ
Можно ли проводить SAT без полного производства?
Частично, но критичные цепи должны быть на реальном оборудовании или максимально близкой копии.
Сколько сценариев достаточно?
Лучше меньше, но с полным покрытием рисков, чем сотня формальных строк.
Что делать, если заказчик торопит?
Фиксировать известные риски письменно и переносить непокрытое в отдельный план с датой.
Нужен ли отдельный протокол для кибербезопасности?
Да, как минимум для удаленного доступа, учеток и сегментации.
Кто подписывает итог?
Представитель заказчика и ответственный за ввод в эксплуатацию.