Главная / Журнал / АСУ ТП
АСУ ТП

Ошибки в ТЗ на автоматизацию: что актуально в 2026 году

21.05.2026 · 9 мин чтения · ООО «Аквис-Сервис»

Техническое задание на АСУ ТП и диспетчеризацию должно быть рабочим документом для проектирования, разработки ПО ПЛК, сборки шкафа, монтажа и ПНР. В 2026 году для России важно учитывать обновлённые стандарты комплекса ГОСТ 34, требования к документации, электробезопасности, ЭМС и, для отдельных объектов, к безопасности КИИ.

В материале
ГОСТ 34.602-2020 для структуры ТЗ
ГОСТ Р 59793-2021 для стадий создания АС
ПЛК, HMI, SCADA и протоколы обмена
КИИ и требования ФСТЭК для значимых объектов

Где ТЗ чаще всего ломает проект

Проблема обычно не в самом факте наличия ТЗ, а в том, что в нём не хватает проверяемых требований.

Неполный перечень сигналов

В ТЗ нет диапазонов аналоговых сигналов, типов дискретных входов, источников данных, единиц измерения, частоты опроса и требований к точности.

Режимы описаны общими словами

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

Аварии не разделены по важности

Предупреждения, аварийные остановы, технологические блокировки и сервисные сообщения попадают в один список, поэтому их сложно правильно вывести на HMI и SCADA.

Протоколы заданы без деталей

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

Не описаны архивы и журналы

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

Шкаф и монтаж вынесены за скобки

Не указаны резерв по модулям ввода-вывода, требования к клеммам, маркировке, заземлению, месту установки, вентиляции шкафа и условиям обслуживания.

Важное изменение для 2026 года

ГОСТ 34.601-90 по стадиям создания автоматизированных систем утратил силу на территории РФ с 1 декабря 2023 года. В новых ТЗ корректнее ссылаться на ГОСТ Р 59793-2021, а структуру самого ТЗ выстраивать по ГОСТ 34.602-2020.

Нормативная база, на которую стоит опираться

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

  • ГОСТ 34.602-2020 — основной стандарт для состава, содержания и оформления ТЗ на создание, развитие или модернизацию автоматизированной системы. Введён в действие в РФ с 1 января 2022 года, статус — действует.
  • ГОСТ Р 59793-2021 — стадии создания автоматизированных систем. Введён с 30 апреля 2022 года, статус — действует.
  • ГОСТ 34.201-2020 — виды, комплектность и обозначение документов при создании АС.
  • ГОСТ Р 59795-2021 — требования к содержанию основных документов, разрабатываемых при создании АС.
  • ГОСТ 34.601-90 — больше не следует использовать как действующую норму по стадиям в РФ: Росстандарт указал прекращение применения с 01.12.2023 и применение ГОСТ Р 59793-2021.
  • ТР ТС 004/2011 и ТР ТС 020/2011 — применимы к низковольтному оборудованию и электромагнитной совместимости технических средств, если оборудование выпускается в обращение и попадает в область действия регламентов.
  • 187-ФЗ о безопасности КИИ и приказ ФСТЭК России № 239 — важны для АСУ ТП, которые относятся к объектам критической информационной инфраструктуры или могут быть отнесены к значимым объектам.

Эти документы не заменяют проектные нормы по конкретному объекту: ПУЭ, СПДС, профильные СП, требования промышленной безопасности, правила эксплуатации оборудования и внутренние стандарты заказчика всё равно должны быть проверены по назначению системы.

Что должно быть в ТЗ, чтобы его можно было проверить

Чем точнее требования сформулированы до проектирования, тем меньше спорных решений возникает на монтаже и ПНР.

Раздел ТЗЧто указатьЧто происходит, если пропустить
Объект автоматизации Границы системы, оборудование, режимы работы, смежные разделы, ответственность заказчика и подрядчиков АСУ ТП начинает «забирать» чужие зоны ответственности или не покрывает важные узлы
Сигналы КИПиА AI, AO, DI, DO, диапазоны, единицы, точность, тип датчика, питание, место установки, частота опроса На ПНР обнаруживаются лишние модули, неверные шкалы, перепутанные состояния и неполные тренды
Алгоритмы управления Переходы режимов, приоритеты команд, межблокировки, условия запуска и останова, реакции на отказ Программа ПЛК начинает уточняться прямо на объекте, а не до сборки шкафа
Аварии и события Классы сообщений, квитирование, задержки, фиксация причины, вывод на HMI/SCADA, журналирование Эксплуатация не видит первопричину отказа и теряет время на диагностику
Интеграция Modbus RTU/TCP, OPC UA, BACnet или другой протокол, адресация, карта тегов, роли устройств, отказ связи Связь формально есть, но данные неполные, нестабильные или неправильно интерпретируются
HMI и SCADA Мнемосхемы, тренды, архивы, роли пользователей, уставки, отчёты, удалённый доступ, резервирование Оператор получает экран управления без полноценного инструмента эксплуатации
Шкаф управления IP, климат, резерв места, резерв I/O, вводы кабелей, клеммы, маркировка, заземление, питание, ИБП Шкаф сложно обслуживать, расширять и принимать по исполнительной документации
Испытания и приёмка Программа и методика испытаний, имитация отказов, проверка блокировок, критерии готовности ПНР Приёмка превращается в обсуждение ожиданий вместо проверки заранее согласованных критериев

Семь ошибок, которые стоит убрать до выпуска ТЗ

1. Ссылаться на устаревшую стадию работ

Если в ТЗ по привычке указать ГОСТ 34.601-90 как действующий стандарт по стадиям, документ уже выглядит неаккуратно для 2026 года. Корректнее использовать ГОСТ Р 59793-2021, а саму структуру ТЗ вести по ГОСТ 34.602-2020.

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

2. Описывать систему без границ

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

Для производственной линии это могут быть конвейеры, частотные приводы, весовые дозаторы, сушилка, пресс, упаковочная машина, система аспирации и диспетчеризация. Для инженерного объекта — ИТП, насосные группы, вентиляционные установки, узлы учёта и связь с BMS или SCADA.

3. Давать перечень сигналов без инженерных параметров

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

На практике именно этот раздел чаще всего влияет на состав ПЛК, модулей I/O, клемм, кабельных линий и объём ПНР.

4. Не фиксировать алгоритмы в проверяемом виде

Алгоритм должен отвечать на простые вопросы: кто имеет приоритет, когда разрешён запуск, что останавливает механизм, как система выходит из аварии, какие команды доступны в ручном режиме, что происходит при пропадании связи с HMI или SCADA.

Если эти условия не описаны, программист ПЛК вынужден принимать технологические решения сам. Для заказчика это риск: система будет работать логично с точки зрения разработчика, но не обязательно так, как ожидает эксплуатация.

5. Считать SCADA только экраном диспетчера

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

Если планируется MasterSCADA 4D или другая SCADA-платформа, важно заранее описать не бренд как таковой, а функции: какие данные хранить, сколько времени, кто имеет право менять уставки, какие аварии должны приходить диспетчеру и какие действия фиксируются в журнале.

6. Забывать про защищённость и удалённый доступ

В 2026 году удалённый доступ к АСУ ТП нельзя описывать одной строкой. Нужно указать допустимые каналы, роли пользователей, порядок выдачи доступов, журналирование действий, сегментацию сети, требования к резервным копиям и порядок обновления ПО.

Для объектов, которые относятся к КИИ, требования безопасности должны попадать в ТЗ или частное ТЗ на подсистему безопасности. Приказ ФСТЭК № 239 прямо связывает требования к безопасности значимого объекта с техническим заданием, стадиями работ, применяемыми средствами и составом документации.

7. Не задавать критерии ПНР и приёмки

Хорошее ТЗ заканчивается не списком оборудования, а проверяемыми критериями. Нужно заранее определить, какие режимы и отказные ситуации проверяются на ПНР, какие протоколы испытаний оформляются, какие замечания считаются критичными, а какие уходят в перечень доработок.

Мы обычно отдельно фиксируем проверку цепей, адресации сигналов, масштабирования аналоговых входов, реакций на аварии, блокировок, работы HMI, обмена со SCADA и восстановления после отключения питания.

Как мы проверяем ТЗ перед разработкой автоматики

Такой порядок помогает найти пробелы до закупки оборудования и сборки шкафов.

Сверяем границы системы

Определяем, какие механизмы, шкафы, датчики, исполнительные устройства, HMI, SCADA и смежные системы входят в контур работ.

Разбираем сигналы

Проверяем типы входов и выходов, диапазоны, питание, резерв, адресацию, диагностику обрыва и соответствие будущей карте тегов.

Формализуем алгоритмы

Описываем режимы, блокировки, приоритеты, аварии, переходы состояний и действия оператора так, чтобы их можно было проверить на ПНР.

Проверяем обмен данными

Уточняем Modbus RTU/TCP, OPC UA, BACnet или другой протокол, роли устройств, карту регистров, период опроса и поведение при потере связи.

Готовим критерии приёмки

Формируем перечень испытаний, протоколов и исполнительной документации, чтобы сдача системы опиралась на согласованные требования.

Мини-чек-лист для заказчика

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

Нужно проверить ТЗ на АСУ ТП перед проектированием?

Пришлите исходное ТЗ, перечень оборудования и схему объекта. Мы проверим состав сигналов, алгоритмы, протоколы обмена, требования к шкафам, SCADA и ПНР и покажем места, которые лучше уточнить до разработки.

AI-консультация

AI-консультант по заявке

Опишите задачу в свободной форме. Консультант уточнит детали и передаст заявку инженерам, когда будут контакты.

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