Как писать руководства для АСУ: перечень документов, структура и рекомендации

Дата публикации: 7 сентября 2026 года.

• Что такое документация для АСУ ТП
• Нормативная база: на что опираться техпису
• Перечень документов: что нужно в любом проекте
• Структура ключевых документов: что писать в каждом разделе
• Скрытые сложности: о чём молчат ГОСТы
• Практические рекомендации для техписа
• Заключение

Технический писатель получает техническое задание, но не знает, как писать документацию для АСУ ТП. В ТЗ — 37 пунктов. Срок — две недели. Разработчики молчат, заказчик требует "как в ГОСТе", а в ГОСТе — 150 страниц общих фраз. Никто не сказал техпису, какие документы нужны на самом деле, а какие можно пропустить. И что в каждом из них должно быть.

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

Что такое документация для АСУ ТП и почему она отличается от обычной IT-документации

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

В отличие от документации для веб-сервиса или мобильного приложения, документация для АСУ ТП:

• Регламентируется государственными стандартами (ГОСТ Р 2.601-2019, ГОСТ 34.201-2020, ГОСТ 19.101-2024) и отраслевыми руководящими документами (РД).
• Адресована нескольким типам специалистов: оператору, системному программисту, администратору, инженеру-наладчику.
• Должна описывать не только штатные режимы, но и аварийные ситуации, действия при отказах, блокировках и защитах.
• Имеет юридическую силу — ее соблюдение проверяет Ростехнадзор и другие надзорные органы.

Проектирование АСУ ТП начинается с технического задания (ГОСТ 34.602-89), а заканчивается комплектом эксплуатационной документации. И если на этапе разработки АСУ ТП инженеры ещё могут как-то обойтись устными договорённостями, то на этапе эксплуатации без документов — никак.

Нормативная база: на что опираться техпису

Технический писатель в проекте АСУ ТП сталкивается с тремя основными системами стандартов. Не пытайтесь выучить их все — достаточно знать, что в каждом стандарте искать.

ГОСТ Р 2.601-2019 — эксплуатационные документы

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

ГОСТ 34.201-2020 — основной стандарт для документации АС

Это базовый стандарт из серии ГОСТ 34, который устанавливает виды, комплектность и обозначения документов при создании автоматизированных систем (АС). Именно он определяет, какие документы входят в эксплуатационную документацию для АСУ ТП: руководство оператора, руководство системного программиста, описание технологического процесса, формуляр, паспорт и другие. Действует с 1 января 2022 года, заменил ГОСТ 34.201-89.

Ранее использовавшийся РД 50-34.698-90 ("Методические указания. Требования к содержанию документов") утратил силу с 12 февраля 2019 года. Однако его структура и подходы до сих пор применяются на практике как методическая основа — многие проектные организации продолжают опираться на сложившиеся шаблоны, несмотря на отсутствие официального статуса у этого документа.

Также в части технического задания для АС действует ГОСТ 34.602-89 — он остаётся актуальным и широко используется при формировании требований к автоматизированным системам.

ГОСТ 19.101-2024 — виды программных документов

С 30 января 2025 года введён в действие обновленный ГОСТ 19.101-2024 "Единая система программной документации. Виды программ и программных документов", который заменил устаревший ГОСТ 19.101-77. Новый стандарт устанавливает виды программных документов для программного обеспечения (в том числе входящего в состав АСУ ТП), их состав и назначение.

Хотя структура и многие положения ГОСТ 19.101-77 по-прежнему используются как методическая база, при разработке документации для новых проектов следует ориентироваться на актуальный ГОСТ 19.101-2024, особенно если заказчик требует соблюдения ЕСПД.

Отраслевые документы

Для энергетики — РД 153-34.1-35.521-00. Для ГЭС — СТО 17330282.27.140.009-2008. Если ваш проект относится к конкретной отрасли, ищите отраслевые руководящие документы — они часто содержат более детальные требования, чем общие ГОСТы.

На практике организация АСУ ТП в части документации строится на трех уровнях:

• ГОСТы — общая рамка.
• Отраслевые РД — детализация.
• Внутренний корпоративный стандарт — то, что реально работает в вашей компании.

Внешние нормативные акты

Помимо ГОСТов и отраслевых РД, документация АСУ ТП может зависеть от законодательных изменений, которые напрямую влияют на бизнес-процессы. Например, с 1 сентября 2026 года обязательной стала электронная транспортная накладная (ЭТрН). Если ваша система управляет отгрузкой, в руководстве оператора и администратора появятся новые разделы — работа с титулами, интеграция с ГИС ЭПД, настройка электронной подписи. Отслеживайте такие изменения на этапе анализа требований.

Перечень документов: что нужно в любом проекте

Полный перечень зависит от класса АСУ, требований заказчика и отраслевых норм. Но есть набор документов, который встречается в 90% проектов. Разделим их по адресатам.

Для оператора (пользователя)

Руководство оператора. Главный документ, с которым работает человек за пультом. Описывает, как управлять технологическим процессом через АСУ ТП: какие экраны есть, что означают показатели, какие кнопки нажимать в штатном режиме и что делать при аварии.

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

Для системного администратора и программиста

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

Руководство администратора базы данных. Если в АСУ ТП есть база данных (а она есть почти всегда) — нужен отдельный документ по ее администрированию: структура, резервирование, восстановление, оптимизация.

Руководство по восстановлению. Описывает действия при отказе сервера, контроллера или сети связи. Часто его объединяют с руководством системного программиста, но для ответственных объектов лучше выносить в отдельный документ.

Для обслуживающего персонала

Формуляр. Документ, в котором фиксируются все изменения, ремонты, замены оборудования и версии ПО. Нужен для учёта состояния системы.

Паспорт. Содержит основные технические характеристики изделия или системы.

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

Для проектировщиков и разработчиков (если входит в зону ответственности)

Описание алгоритмов. Текстовое или графическое (схемы алгоритмов) описание логики работы системы. Может быть частью пояснительной записки или отдельным документом.

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

Структура ключевых документов: что писать в каждом разделе

Теперь — самое важное. Как написать каждый документ так, чтобы его читали, а не пролистывали.

Руководство оператора

Этот документ — интерфейс между человеком и системой. Его структура должна повторять логику работы оператора.

Обязательные разделы:

• Введение. Назначение системы, состав, краткая характеристика технологического процесса.
• Описание рабочих станций. Как выглядят экраны оператора, какие элементы управления есть, что означают цвета и индикаторы.
• Работа в штатном режиме. Пошаговое описание всех операций, которые выполняет оператор: запуск, останов, изменение режимов, регулирование.
• Работа в аварийных режимах. Что делает система автоматически, что должен делать оператор. Таблица аварийных сигналов с расшифровкой и действиями.
• Архивирование и отчётность. Как оператор может посмотреть историю, сформировать отчёт, распечатать суточную ведомость.
• Действия при сбоях. Что делать, если завис экран, пропала связь с контроллером, не работает принтер.

Как писать:

• Используйте повелительное наклонение: "Нажмите", "Выберите", "Проверьте".
• Каждое действие — отдельный шаг. Не смешивайте несколько действий в одном предложении.
• Скриншоты обязательны.
• Таблицы действий: "Сигнал — Что означает — Что делать".
• Не пишите "В случае возникновения аварийной ситуации необходимо произвести действия согласно регламенту". Пишите: "При мигании красного индикатора нажмите кнопку „Аварийный стоп“".

Руководство системного программиста

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

Обязательные разделы:

• Архитектура ПО. Из каких модулей состоит система, как они взаимодействуют, какие протоколы используются.
• Конфигурационные файлы. Где лежат, что в них настраивается, как редактировать.
• Запуск и остановка системы. Пошаговые инструкции с указанием последовательности (что сначала — база данных или сервер приложений).
• Резервное копирование. Что копировать, как часто, куда. Как восстановить из резервной копии.
• Логирование. Где логи, какие уровни детализации, как читать, что искать при ошибках.
• Обновление ПО. Как установить новую версию, что делать с данными, как откатить.

Как писать:

• Давайте конкретные команды и пути. Не "настройте файл конфигурации", а "отредактируйте файл /etc/app/config.xml, измените параметр ServerAddress".
• Описывайте не только "как", но и "зачем". Системный программист должен понимать последствия своих действий.
• Предупреждайте о рисках. "Внимание: изменение этого параметра приводит к перезагрузке контроллера".

Описание технологического процесса

Этот документ часто пишут технологи, а не техписы. Но если он входит в вашу зону ответственности — запомните главное: вы описываете не "как устроен процесс", а "как процесс отражён в АСУ ТП".

• Какие параметры измеряются и где.
• Какие регулирующие воздействия могут быть.
• Какие блокировки и защиты реализованы.
• Схема АСУ ТП с указанием всех точек измерения и воздействия.

Скрытые сложности: о чём молчат ГОСТы

Теперь — то, с чем вы столкнётесь на практике, но о чём не пишут в стандартах.

Разработчики не дают информацию

Это главная боль техписа в АСУ ТП. Разработчики заняты кодом, им некогда объяснять. Что делать:

• Изучите техническое задание и проектную документацию — там есть 70% ответов.
• Задавайте конкретные вопросы: "Какой параметр в каком файле?", "Какая последовательность запуска?".
• Записывайте всё, что говорят. Через месяц разработчик сам не вспомнит, что имел в виду.

Документация устаревает быстрее, чем вы её пишете

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

• Ведите журнал изменений в каждом документе.
• Храните документацию в системе контроля версий (как код).
• Синхронизируйте версию документа с версией ПО.

Терминологический хаос

Один и тот же объект в разных документах может называться по-разному: "клапан", "задвижка", "регулирующий орган". Создайте глоссарий в начале проекта и согласуйте его со всеми участниками. Это сэкономит месяцы правок.

Юридическая сила и подписи

Эксплуатационная документация для АСУ ТП — это документы, которые подписываются, утверждаются и предъявляются при проверках. Учитывайте:

• Кто утверждает каждый документ.
• Какие грифы согласования нужны.
• Как оформляются изменения (обычно отдельным листом утверждения).

Практические рекомендации для техписа

Соберём всё, что сказано выше, в чек-лист.

До начала работы

• Изучите техническое задание и проектную документацию.
• Узнайте, какие ГОСТы и отраслевые РД требуются по контракту.
• Согласуйте перечень документов с заказчиком и разработчиками.
• Создайте глоссарий.
• Определите, кто будет утверждать каждый документ.

В процессе работы

• Пишите для конкретного читателя: оператор, программист, администратор.
• Используйте активный залог и повелительное наклонение.
• Каждое действие — отдельный шаг.
• Скриншоты и схемы обязательны.
• Предупреждайте о рисках и последствиях.
• Ведите журнал изменений.

Перед сдачей

• Проверьте соответствие версии документа и версии ПО.
• Проверьте все ссылки, номера рисунков и таблиц.
• Убедитесь, что каждый документ подписан и утверждён.
• Сдайте не только тексты, но и исходники (если работали в Word, InDesign или специализированном ПО).

Чек-лист входного контроля эксплуатационной документации АСУ ТП

Используйте этот список для проверки документов перед передачей заказчику или на нормоконтроль.

Следующий виджет может помочь быстро проверить комплект документов перед сдачей.

Заключение

Документация для АСУ ТП — это не формальность и не приложение к проекту. Это документ, от которого зависит безопасность, надёжность и экономическая эффективность производства.

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

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

Инструкция АСУ ТП — это правила о том, как сделать так, чтобы человек, который держит документ в руках, мог выполнить нужное действие в нужный момент.

Начните с малого: возьмите один документ, например руководство оператора, и перепишите его так, чтобы его мог понять человек, не знакомый с проектом. Покажите результат оператору. Спросите, всё ли понятно. Исправьте. Это и есть правильный путь.

Рабочая документация АСУ ТП — это живая система, которая меняется вместе с самой АСУ ТП. И задача техписа сделать так, чтобы она оставалась актуальной и полезной на всём жизненном цикле системы.