Проверка систем автоматизации перед приёмкой промышленного оборудования: что тестировать и как принимать работу

Приёмка системы автоматизации — это не формальная подпись в акте, а последняя возможность обнаружить ошибки проекта до того, как они превратятся в остановки производства. Главный принцип проверки прост: система принимается не «в целом работает», а по заранее согласованному списку функций, каждый пункт которого подтверждается демонстрацией и записью результата. Если такого списка нет до начала испытаний, приёмка превращается в переговоры, а риски остаются у заказчика.

В этой статье разобрано, из каких этапов состоит проверка систем автоматизации промышленного оборудования, какие тесты обязательны для контроллера, визуализации, датчиков и исполнительных механизмов, какие документы запросить у интегратора и на какие признаки проблем стоит обращать внимание ещё до подписания акта.

Зачем нужна формальная приёмка и чем она отличается от «пуска»

Пуск оборудования и его приёмка — разные задачи. Пуск показывает, что машина физически запускается и выполняет базовый цикл. Приёмка отвечает на другой вопрос: делает ли система то, что написано в техническом задании, во всех режимах, включая аварийные, и можно ли это доказать. Разница проявляется через месяцы эксплуатации: оборудование может работать годами без замечаний или регулярно останавливаться из-за ошибок, которые не проверили при сдаче.

Формальная приёмка защищает обе стороны. Исполнитель получает зафиксированный объём работ и закрытый перечень замечаний, заказчик — документальное основание требовать устранения дефектов по гарантии. Без протоколов испытаний спор о том, «было ли это в проекте», почти всегда решается в пользу того, кто лучше подготовился к сдаче.

FAT и SAT: два уровня проверки

В практике автоматизации принято разделять испытания на два этапа:

• FAT (Factory Acceptance Test) — заводские испытания на площадке изготовителя или интегратора до отгрузки. Проверяется логика работы программы, работа щита управления, имитация сигналов датчиков, поведение визуализации. Здесь исправления дёшевы: доступ к стенду, программисту и оборудованию есть одновременно.
• SAT (Site Acceptance Test) — приёмо-сдаточные испытания на объекте после монтажа и подключения реальных датчиков, приводов и коммуникаций. Проверяется уже связка «программа + реальная обвязка», включая кабельные трассы, настройку приводов, обмен с верхним уровнем и работу в условиях площадки.

Пропуск FAT ради экономии времени — распространённая и дорогая ошибка. Ошибка логики, найденная на SAT, означает простой монтажной бригады, повторные командировки специалистов и сдвиг сроков запуска. Ошибка, найденная на FAT, обычно устраняется за часы.

Что должно быть готово до начала испытаний

Приёмка начинается не в день тестов, а с проверки комплектности документации. Если бумаги отсутствуют, испытания проводить рано: вы не сможете сверить фактическое поведение системы с проектом.

• Техническое задание с согласованными изменениями — основной критерий приёмки.
• Описание алгоритмов работы: последовательности операций, переходы между режимами, логика блокировок.
• Таблица входов-выходов (список сигналов) с привязкой к клеммам и адресам контроллера.
• Электрические схемы силовых цепей и цепей управления, схемы щитов.
• Описание интерфейса оператора: экраны, параметры, права доступа, архивация.
• Программа испытаний — перечень проверок с ожидаемыми результатами, согласованный до начала тестов.

Отдельно уточните, что именно передаётся вместе с системой: исходные коды программ, резервные копии проектов, пароли доступа разных уровней, лицензии на ПО. Отсутствие исходников означает зависимость от исполнителя на весь срок службы линии — это допустимо как осознанное решение, но не как случайность, обнаруженная через два года.

Программа испытаний: как составить список проверок

Программа испытаний — центральный документ приёмки. Её структура обычно одинакова независимо от отрасли:

1. Номер и название проверки.
2. Ссылка на пункт технического задания.
3. Методика: какие действия выполняются, какие сигналы подаются или имитируются.
4. Ожидаемый результат, сформулированный наблюдаемо: «клапан открывается не ранее, чем давление достигнет уставки», а не «работает корректно».
5. Фактический результат и отметка о соответствии.

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

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

Ядро любой системы автоматизации — программа ПЛК (программируемого логического контроллера). Тестировать её нужно по слоям, а не «запустили цикл — работает».

Базовые проверки логики

• Последовательность операций. Прогон полного технологического цикла от старта до завершения, с фиксацией таймингов каждого шага. Сверяйте фактическую последовательность с описанием алгоритма, а не с памятью участников.
• Режимы работы. Ручной, полуавтомат, автомат, наладочный режим — каждый проверяется отдельно. Частая ошибка подрядчиков: автоматический режим отлажен, ручной работает «примерно», хотя операторы будут пользоваться именно им.
• Блокировки и защиты. Каждое условие запрета проверяется принудительно: открытие ограждения, отсутствие давления, незакрытая крышка. Блокировка, которая «должна срабатывать», но ни разу не продемонстрирована, считается непроверенной.
• Аварийный останов. Нажатие кнопки аварийного останова в разных фазах цикла. После сброса система обязана вернуться в безопасное состояние и потребовать осознанного рестарта, а не продолжить движение сама.
• Обработка отказов. Имитация обрыва датчика, короткого замыкания в цепи, потери связи с частотным преобразователем. Правильное поведение — диагностируемое сообщение и безопасная остановка, а не зависание или неконтролируемое продолжение работы.

На что смотреть в поведении программы

Обратите внимание на устойчивость к действиям оператора. Двойное нажатие пуска, переключение режима во время движения, запуск при незавершённом предыдущем цикле — типичные сценарии, в которых сырая программа ведёт себя непредсказуемо. Также проверьте реакцию на восстановление питания после кратковременного отключения: система должна либо корректно возобновить работу, либо явно потребовать действий оператора, но не стартовать механизм самопроизвольно.

Проверка датчиков, приводов и исполнительных механизмов

Реальная обвязка на объекте — источник большинства замечаний при SAT. Логика может быть идеальной, но неправильно подключённый или неоткалиброванный датчик сделает её бесполезной.

• Соответствие сигналов. Для каждого входа проверяется, что физическое событие вызывает правильный сигнал в системе: концевик «открыто» действительно означает открыто, а не наоборот. Полная проверка таблицы входов-выходов занимает время, но пропуски здесь дороже всего.
• Калибровка измерений. Для датчиков температуры, давления, расхода сравните показания системы с эталонным прибором минимум в двух точках диапазона. Расхождение фиксируется и устраняется до подписания акта.
• Работа приводов. Частотные преобразователи проверяются на разгон, торможение, реверс, реакцию на задание скорости и обработку аварии. Для сервоприводов дополнительно — точность позиционирования и повторяемость.
• Исполнительные механизмы. Клапаны, заслонки, дозаторы проверяются на полные ходы, время срабатывания и совпадение положения с индикацией на экране оператора.

Полезный приём: попросите показать «живую» картину сигналов в отладчике или на диагностическом экране во время тестов. Это позволяет сразу видеть, какой именно сигнал не соответствует ожиданию, вместо поиска причины вслепую.

Проверка визуализации и рабочего места оператора

HMI/SCADA-система — то, с чем персонал будет работать ежедневно, поэтому её качество напрямую влияет на эксплуатацию.

• Все экраны соответствуют описанию, навигация понятна человеку, который видит систему впервые.
• Аварии отображаются с текстом, временем и приоритетом; квитирование сообщений работает.
• Архивы параметров пишутся с заявленной периодичностью и читаются за нужный период.
• Права доступа разграничены: оператор не может менять уставки технолога, технолог — логику программы.
• Индикация состояний однозначна: различимы «работает», «остановлен», «авария», «нет связи».

Хороший практический тест — дать поработать на системе будущему оператору под наблюдением. Задачи, которые он выполняет с затруднениями, почти всегда указывают на проблемы интерфейса, а не на квалификацию человека.

Инженерные аспекты: сеть, питание, безопасность

Эти разделы часто выпадают из внимания, потому что «оборудование же работает». Но именно они определяют надёжность в долгосрочной эксплуатации.

• Промышленная сеть. Проверьте топологию, загрузку каналов, поведение при потере узла. Для резервированных сетей отказ основного канала демонстрируется отключением кабеля, а не принимается на слово.
• Качество электропитания. Источники бесперебойного питания должны удерживать контроллер и сеть при пропадании напряжения на заявленное время. Проверка выполняется отключением ввода — это штатный тест, если он предусмотрен программой.
• Заземление и экранирование. Наводки от частотных преобразователей — классическая причина «плавающих» аналоговых сигналов. Признак проблемы: показания меняются при включении и выключении силового оборудования.
• Промышленная безопасность. Функции безопасности (световые барьеры, дверные блокировки, предохранительные клапаны) проверяются по отдельному перечню, желательно с участием специалиста по безопасности, особенно если применяются сертифицированные компоненты.
• Кибербезопасность. Минимальный набор: смена заводских паролей, отключение неиспользуемых сервисов, ограничение доступа к управляющей сети. Требования в этой области быстро меняются, поэтому конкретные меры стоит сверять с актуальными рекомендациями на дату проекта.

Документы, которые вы получаете по итогам приёмки

Результат испытаний фиксируется документально. Минимальный комплект:

• Заполненный протокол испытаний с фактическими результатами по каждому пункту.
• Перечень замечаний с классификацией: блокирующие, некритичные, пожелания. Для каждого — срок устранения и ответственный.
• Акт приёмо-сдаточных испытаний, подписываемый только после устранения блокирующих замечаний.
• Переданная эксплуатационная документация: инструкции, схемы, паспорта компонентов.
• Резервные копии программ всех контроллеров и панелей, пароли, лицензионные ключи.

Распространённая практика — подписание акта с перечнем некритичных замечаний и согласованным графиком их устранения. Это нормально, если сроки и ответственность зафиксированы письменно. Подписывать акт при наличии нерешённых блокирующих замечаний не следует ни под давлением сроков, ни под обещания «потом доделаем»: после подписания рычаги влияния резко слабеют.

Типичные ошибки при приёмке систем автоматизации

• Испытания без программы. Проверка «по ходу» неизбежно что-то упускает, а спорные пункты решаются в пользу исполнителя. Альтернатива: согласовать программу испытаний заранее, ещё на этапе договора.
• Проверка только нормального режима. Оборудование большую часть жизни проводит в штатной работе, но репутацию системе делают её действия при отказах. Аварийные сценарии обязательны.
• Приёмка «под ключ» одним человеком. Один проверяющий физически не охватывает технологию, электрику и ПО. В комиссии полезны технолог, который знает процесс, и представитель эксплуатации, который будет обслуживать систему.
• Подписание документов задним числом или пустых протоколов. Протокол без фактических значений не доказывает ничего. Если пункт не проверен — так и пишется, с планом проверки.
• Игнорирование обучения персонала. Система, которую никто не умеет эксплуатировать, будет «ломаться» руками людей. Обучение и материалы для него включайте в объём приёмки.
• Отсутствие резервных копий. Выход из строя панели или контроллера без архива проекта означает переписывание программы с нуля. Копии и пароли — часть передаваемой ценности, а не бонус.

Сценарии: как действовать в разных ситуациях

Ситуация	Разумное действие
FAT пройден, найдены мелкие замечания по интерфейсу	Зафиксировать в протоколе, устранить до отгрузки или включить в условия SAT с конкретными критериями
На SAT не сходится логика блокировок	Не подписывать акт; потребовать исправления и повторной демонстрации затронутых пунктов программы
Сроки горят, часть проверок не выполнена	Подписать протокол с явным перечнем непроверенных пунктов и датой их завершения; акт — только после них
Исполнитель настаивает, что «так задумано»	Сверить с техническим заданием и описанием алгоритма; расхождение трактуется в пользу документа
Система работает, но документация не передана	Удержать финальную оплату до передачи комплекта документов и резервных копий, если это предусмотрено договором

Чек-лист приёмщика: минимальный набор проверок

• Программа испытаний согласована до начала тестов, каждая проверка имеет наблюдаемый критерий.
• Полный технологический цикл пройден во всех предусмотренных режимах.
• Все блокировки и защиты продемонстрированы принудительным созданием условий.
• Аварийный останов проверен в разных фазах работы, восстановление требует осознанного действия.
• Таблица входов-выходов сверена с реальными сигналами, измерения откалиброваны по эталону.
• Визуализация, архивы, аварии и права доступа работают согласно описанию.
• Поведение сети и питания при отказах проверено практически.
• Замечания классифицированы, блокирующие устранены до подписания акта.
• Получены протоколы, документация, резервные копии программ и пароли.
• Персонал обучен, обучение зафиксировано.

С чего начать прямо сейчас

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

Главный ориентир всей процедуры: система принимается тогда, когда каждое существенное требование подтверждено демонстрацией и записано в протоколе. Всё, что не проверено, остаётся риском заказчика — поэтому полнота программы испытаний важнее скорости подписания акта.

Материал носит информационный характер и описывает общую практику приёмки систем автоматизации. Конкретные требования к испытаниям, составу документации и функциям безопасности зависят от отрасли, типа оборудования и применимых нормативных требований — при существенных решениях привлекайте профильных специалистов и сверяйтесь с актуальной нормативной базой.