FAT без спектакля: как доказать готовность PLC/SCADA

Scope и критерий приёмки

До сценариев определяются system under test, исключённые подсистемы, реальное и моделируемое оборудование, роли сторон и различия между FAT, SAT, SIT, loop check и commissioning.

Допустимые открытые замечания и условная приёмка задаются заранее. Иначе каждый участник приносит на FAT собственное представление о готовности.

Readiness gate

На входе нужны утверждённые control narrative/cause-and-effect, I/O и tag lists, HMI/alarm principles, сетевые интерфейсы, собранная версия PLC/SCADA, ведомость IDE/runtime/firmware и baseline backup.

Каждое предупреждение сборки устраняется или признаётся допустимым с документированным объяснением.

Требование → тест → доказательство

Для требования фиксируются предусловия, воздействие, шаги, ожидаемый результат, допустимые времена, фактический результат, evidence и defect ID. Отрицательные требования «не запускаться» или «не принимать команду» тестируются так же явно.

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

Стенд и пределы модели

Описываются PLC/эмулятор, I/O simulator, HMI/SCADA, historian, gateway, сеть, время, пользователи и ограничения модели процесса. Если симулятор не воспроизводит электрическую цепь, динамику или конкретный telegram, это ограничение доказательства.

Demo build не должен иметь случайного маршрута записи в production.

Нормальные и запрещённые сценарии

Проверяются Manual/Auto, Local/Remote, start/stop/hold/resume/abort/reset, state transitions, таймеры, параллельные команды, граничные значения, сохранение параметров и restart.

Затем вводятся отказ permissive/interlock/trip, bad quality, потеря связи, отказ подтверждения механизма, failover и reset при активной причине.

HMI, alarms и история

FAT проверяет навигацию, роли, команды, единицы, quality, alarm priority/text/action, acknowledgement, first-out, события, тренды, архив, отчёты, time zone и синхронизацию.

Субъективное «экран выглядит нормально» заменяется операторским сценарием и ожидаемым действием.

Дефекты и закрытие

Во время теста фиксируются шаг, timestamp, baseline, фактический результат, trace/log/screenshot, defect ID и необходимость regression. На выходе — протокол, punch list, waivers и архив принятой версии.

Любое последующее изменение проходит impact analysis и повтор затронутых тестов.

Тестовый случай как воспроизводимая запись

Хороший тест можно повторить другой командой без устных пояснений автора. Помимо шагов он содержит ссылку на требование, исходную конфигурацию, состояние установки, роли пользователей, тестовые данные, способ воздействия и измеримый ожидаемый результат. Формулировка «авария отображается корректно» для этого недостаточна.

Фактический результат записывается отдельно от ожидаемого, даже если тест пройден. Evidence связывается с Test ID и baseline: trace, журнал событий, выгрузка alarm history, screenshot или checksum архива. Если часть результата невозможно доказать на стенде, ограничение отмечается непосредственно в тесте.

• Test ID и ссылка на редакцию требования;
• предусловия и способ восстановления исходного состояния;
• воздействие и ожидаемая последовательность;
• pass/fail с допустимым временем или диапазоном;
• фактический результат, evidence и подписи ролей.

Выбор сценариев по риску и области изменения

Количество тестов само по себе не характеризует качество FAT. Набор строится от требований, критичности функций, новизны решений и области изменения. Типовая функция может проверяться представительным набором экземпляров только при доказанной одинаковости конфигурации; уникальные защиты, интерфейсы и режимы требуют собственных сценариев.

Полезно разделить базовые проверки сборки и конфигурации, функциональные сценарии, negative tests, отказные воздействия и recovery. Изменение общего библиотечного блока повышает объём регрессии, потому что затрагивает всех его потребителей. Локальная правка текста HMI обычно имеет другой профиль влияния, хотя тоже требует проверки связанного alarm или faceplate.

• высокое последствие отказа → более подробная трассировка и независимое подтверждение;
• новый интерфейс → normal, malformed, stale, timeout и reconnect;
• общий блок → representative tests плюс проверка затронутых вариантов конфигурации;
• исправленный дефект → retest причины и regression связанных функций.

Практический сценарий: цепочка пуска агрегата

Иллюстративный сценарий начинается не с нажатия Start, а с подтверждённого исходного состояния: выбран требуемый режим, причины запрета отсутствуют, модель обратных связей сброшена, журнал очищен или отмечено время начала. После команды проверяются промежуточные состояния, выход PLC, моделируемое подтверждение механизма и итоговый статус на HMI.

Затем тот же маршрут повторяется с невыполненным permissive, отсутствующим подтверждением, потерей качества и восстановлением. Ожидаемая реакция берётся из утверждённого control narrative; FAT не должен изобретать её во время встречи. Для каждого этапа сохраняются PLC trace, экран состояния и журнал событий с согласованными метками времени.

• штатный пуск и штатный останов;
• команда при активной причине неготовности;
• исчезновение условия в процессе запуска;
• неполучение подтверждения за предусмотренное время;
• устранение причины, reset и новый пуск как отдельные действия.

Тестовые данные и управляемое внесение отказов

Симулятор должен различать нормальное изменение процесса и принудительно внесённый отказ. Для каждого force или injected fault фиксируются точка воздействия, владелец, время установки и условие снятия. После сценария стенд возвращается в известное исходное состояние, иначе следующий тест может получить скрытую зависимость от предыдущего.

Особое внимание требуется данным, которые могут попасть за пределы стенда: OPC UA write, сообщения в MES, команды приводам, email и отчёты. Маршруты production изолируются организационными и техническими мерами, соответствующими среде проекта. Сам факт наличия эмулятора PLC не гарантирует, что остальные компоненты также отделены от действующей системы.

• идентификатор инъекции и связанный Test ID;
• компонент, сигнал и выбранное значение или качество;
• время включения и ожидаемая реакция системы;
• подтверждение снятия force после теста;
• контроль отсутствия нежелательных внешних записей.

Единая временная шкала доказательств

При проверке последовательности событий важно знать, чьи часы сформировали каждую метку. PLC, SCADA, historian, simulator и инженерный ноутбук могут иметь разные источники времени, timezone и точность. Screenshot с временем рабочего стола не доказывает порядок двух быстрых событий в контроллере.

В протоколе указываются источник синхронизации, замеченное расхождение и разрешающая способность evidence. Для OPC UA полезно различать SourceTimestamp и ServerTimestamp, а для журналов — время возникновения и время поступления. Если стенд не способен подтвердить требуемую точность, тест фиксирует это как ограничение, а не создаёт ложный вывод.

• единая контрольная отметка перед началом серии тестов;
• PLC trace для быстрых переходов;
• alarm/event log для действий оператора и уведомлений;
• historian export для продолжительных изменений;
• связь каждого файла evidence с baseline и Test ID.

Retest и границы регрессии после дефекта

Закрытие defect ID требует не только показать исправленный шаг, но и оценить влияние изменения. Правка общего FB, структуры DB, типа HMI или alarm class может затронуть функции, которые ранее прошли FAT. Impact analysis определяет минимальный обоснованный набор повторных тестов; принцип «исправили здесь — проверили только здесь» не всегда достаточен.

После retest сохраняются новая версия, причина изменения, затронутые требования, повторённые Test ID и обновлённое evidence. Если исправление выполнено после формального закрытия FAT, стороны отдельно фиксируют, какая baseline теперь считается принятой и какие проверки перенесены на SAT или иной этап.

• повторить первоначально упавший сценарий;
• проверить соседние переходы и общий код, затронутый исправлением;
• обновить requirements-to-tests matrix и punch list;
• архивировать новую сборку и конфигурацию стенда;
• не переносить открытое ограничение на следующий этап без явного владельца и решения.