Почему важно тестировать ПО до выезда на объект?
При разработке АСУ ТП основная часть логики пишется в офисе, без подключения к реальному оборудованию. Классический риск: на площадке выясняется, что алгоритм не учитывает инерцию задвижки, блокировка срабатывает не в тот момент или оператор не может понять мнемосхему. Исправление на объекте стоит в разы дороже, требует остановки производства и создаёт нервотрёпку для всех участников.
Наш подход — тестировать прикладное ПО контроллера на всех этапах: от разработки до внедрения, используя симуляционную модель, которая живёт внутри самого проекта. Ниже — как это устроено технически.
Как устроена модель тестирование
Модель не рассчитывает процесс по уравнениям. Она делает то же, что реальное оборудование с точки зрения контроллера, — отвечает на команды теми же сигналами и с теми же задержками.
Контроллер дал команду на открытие задвижки: через секунду-две пропадает «закрыто», ещё через несколько секунд появляется «открыто» — модель просто выдерживает время хода. У насоса после команды приходит подтверждение пуска, разгоняется частота, растёт ток. Уровень в ёмкости поднимается при открытом приточном клапане и падает при работающем насосе. Продукт появляется на фотодатчике через то время, за которое физически доезжает от предыдущего узла. Температура при включённом нагреве плавно подходит к уставке и так же плавно снижается после отключения.
Алгоритмов работы три: выдержка времени, накопление (приход минус расход) и плавное приближение к значению. Этого хватает, чтобы воспроизвести поведение практически любого механизма на участке, и это заметно проще в разработке и сопровождении, чем полноценная математическая модель.
FAT тестирование
По завершении внутреннего тестирования мы всегда проводим FAT (Factory Acceptance Test) совместно с заказчиком. Стенд разворачивается на наших виртуальных машинах:
программный контроллер с рабочей версией ПО и активной симуляцией;
сервер и клиент SCADA в проектной конфигурации;
сетевая структура проекта;
при необходимости — эмуляция удалённых станций ввода-вывода и обмен с верхним уровнем.
Заказчик участвует очно или подключается удалённо. Работаем по согласованной программе и методике испытаний (ПМИ): заказчик своими руками управляет механизмами, отрабатывает блокировки, гоняет автоматические режимы и сверяет поведение системы с алгоритмами и техническим заданием.
На выходе — протокол и лист замечаний с классификацией по критичности. Замечания появляются всегда: часть — ошибки, часть — уточнения технологии, которые проявляются только тогда, когда человек, знающий процесс, видит логику в работе. Все замечания закрываются до выезда на объект.
SAT и пусконаладка
Для нашего класса объектов SAT в классическом виде смыкается с пусконаладкой на площадке. С момента загрузки программы в реальный контроллер начинается ПНР:
поканальная проверка ввода-вывода;
прозвонка цепей;
контроль направления вращения приводов;
калибровка аналоговых каналов;
опробование вхолостую и под нагрузкой.
Промежуточный этап — разворачиваем симуляционную модель непосредственно на площадке, с операторами, мастерами и технологами. На ней прогоняются штатные операции, аварийные ситуации и нестандартные режимы. Это одновременно:
приёмка теми, кто будет работать с системой каждый день: оператор находит то, что не видно из офиса — неудобную мнемосхему, избыточные подтверждения, недостающую индикацию;
обучение персонала в среде, где ошибка ничем не заканчивается.
После этого подключается реальный ПЛК.
Что получает заказчик от нашего подхода к тестированию
Пусконаладка проходит без затяжных простоев: все сценарии отработаны ещё до приезда на объект. Ошибки выявляются на этапе разработки, где правка занимает минуты, а не дни, — соответственно, и стоит она несопоставимо дешевле. Операторы успевают освоить систему на симуляторе, не останавливая производство и не рискуя оборудованием. Модель остаётся у заказчика, поэтому алгоритмы остаются прозрачными, а любую доработку можно проверить в любой момент. И на FAT, и на площадке, и в эксплуатации работает один и тот же код — без отдельной «версии для испытаний» и «версии для объекта». В итоге объём работ на площадке сводится к проверке физических цепей и настройке под реальный процесс, то есть к собственно пусконаладке.
