Середина ночи, пусконаладка на химическом заводе. Монтажники подключили последний кабель, наладчик тянется к ноутбуку, чтобы прошить ПЛК. И тут выясняется, что схема подключения из проекта не совпадает с тем, что реально смонтировано: кто-то на объекте поменял местами два провода и не внёс изменение в документацию. Теперь нужно вручную прозванивать 200 каналов, а сроки сдачи объекта горят.
Знакомая история? Для большинства инженеров АСУ ТП - абсолютно. Плохая документация не просто раздражает. Она съедает время, деньги и нервы на каждом этапе: при монтаже, при пусконаладке, при эксплуатации, при модернизации через пять лет, когда никого из разработчиков уже не найдёшь.
Поэтому разберём тему без воды: что входит в техническую документацию на АСУ ТП, зачем нужен каждый документ, как это регулируется стандартами - и почему 80% команд всё равно делают документацию плохо.
Зачем вообще нужна техническая документация
Прежде чем лезть в ГОСТы и перечни документов, стоит ответить на вопрос, который часто задают молодые инженеры: а нельзя ли просто сделать систему и не тратить время на бумаги?
Нельзя. И вот почему.
Система АСУ ТП живёт 15-25 лет. За это время персонал сменяется несколько раз. Люди, которые писали программу для ПЛК, уходят. Приходят другие - и единственное, что у них есть, это документация. Если её нет или она неактуальна, система постепенно превращается в "чёрный ящик": работает, но никто не понимает почему, и никто не рискует трогать.
Есть и более прагматичный аргумент. На объектах, подпадающих под действие технических регламентов или законодательства о критической информационной инфраструктуре (187-ФЗ), отсутствие корректной документации - это прямой путь к проблемам с регуляторами. Надзорные органы проверяют документацию, а не только железо.
И наконец, чисто экономически: час опытного инженера стоит дорого. Когда этот инженер тратит три часа, пытаясь понять, что делает конкретный блок программы, вместо того чтобы прочитать об этом в документации за пять минут - это прямые потери.
Нормативная база: в каком лесу стандартов мы живём
Прежде чем погрузиться в содержание документов, нужно понять, какими стандартами всё это регулируется. В России для АСУ ТП это прежде всего комплекс ГОСТ 34, а также ГОСТ 21 (строительная часть проектов).
ГОСТ 34.201-2020 - основной документ, устанавливающий виды, комплектность и обозначение документов при создании автоматизированных систем. Он введён в действие с 1 января 2022 года и заменил предыдущую редакцию 1989 года. Именно этот ГОСТ определяет перечень документов, которые нужно разработать на каждой стадии создания системы: от технического задания до рабочей документации.
Параллельно работает ГОСТ 21.408-2013, регулирующий правила выполнения рабочей документации автоматизации технологических процессов. Это стандарт именно строительной части: как оформлять схемы, планы расположения, спецификации.
В международном контексте главным ориентиром служит IEC/IEEE 82079-1 редакции 2019 года - это основной международный стандарт для технической документации любого типа продукции, от бытовой техники до сложных промышленных систем. Он заменил более ранний DIN EN 62079 и охватывает принципы создания инструкций по применению для всего спектра продуктов, включая программное обеспечение и промышленные системы управления.
Для программного обеспечения действует отдельная группа стандартов ISO 26511-26515. И отдельно - стандарты безопасности: ANSI Z535.6 регулирует требования к предупреждающим надписям и знакам в документации для американского рынка.
Важный практический момент: конкретный состав документов всегда должен быть определён в техническом задании на разработку системы. ГОСТ даёт перечень и правила, но обязательность каждого конкретного документа согласовывается между заказчиком и разработчиком.
Структура документации: от ТЗ до инструкции оператора
Документация на АСУ ТП не однородна. Она создаётся последовательно, по стадиям жизненного цикла системы, и каждая стадия имеет свой комплект документов.
Техническое задание: документ, который определяет всё остальное
Всё начинается с технического задания. ТЗ - не просто бюрократическая бумага, это контракт между заказчиком и разработчиком, зафиксированный в инженерных терминах. В нём описывается, что система должна делать, в каких условиях работать, каким требованиям соответствовать и как будет проверяться соответствие этим требованиям.
Хорошее ТЗ на АСУ ТП содержит перечень автоматизируемых функций с указанием алгоритмов, требования к надёжности и доступности системы, требования к протоколам обмена данными (Modbus RTU, Modbus TCP, OPC UA, PROFIBUS, HART - в зависимости от задачи), перечень входных и выходных сигналов с их типами и диапазонами, требования к аппаратной платформе, к программному обеспечению, к метрологии и к человеко-машинному интерфейсу.
Плохое ТЗ описывает всё это размыто или не описывает вовсе. Результат предсказуем: на этапе сдачи системы заказчик говорит "это не то, что я имел в виду", а разработчик говорит "но мы сделали всё по ТЗ". И оба правы.
Проектная документация: архитектура системы на бумаге
На стадии технического проекта разрабатывается то, что принято называть проектной документацией - документы, описывающие архитектуру и принципиальные решения системы. Ключевые из них - функциональная схема автоматизации (ФСА, она же P&ID в международной практике) и структурная схема АСУ ТП.
P&ID - это, пожалуй, самый важный документ в проекте АСУ ТП. На нём изображается технологическое оборудование, трубопроводы, все приборы КИПиА с их тегами, связи между ними и логические обозначения по стандарту ГОСТ 21.208 или ISA 5.1. Пусконаладчик на объекте работает именно с P&ID: он смотрит, какой прибор на каком трубопроводе стоит, какой тег ему присвоен, в какой контроллер заходит сигнал.
Тег прибора - это не просто номер. Это код, который несёт смысловую нагрузку: тип измеряемого параметра, тип прибора, номер позиции. Например, FT-101 означает Flow Transmitter позиция 101. Именно этот тег связывает физический прибор на трубопроводе с переменной в программе ПЛК и с тегом в SCADA. Если теговые обозначения в разных документах не совпадают - начинается путаница.
Рабочая документация: что реально нужно монтажнику и наладчику
Рабочая документация - это уровень детализации, при котором можно начинать монтаж и пусконаладку. Именно здесь живут документы, с которыми инженеры работают руками.
Принципиальные электрические схемы показывают, как подключаются приборы и исполнительные механизмы к шкафам управления. Это не та схема, которая "в целом показывает архитектуру" - это чертёж с конкретными клеммами, конкретными обозначениями проводников, конкретными позиционными обозначениями каждого элемента.
Кабельный журнал перечисляет все кабельные соединения объекта: откуда идёт кабель (адрес шкафа и клеммника), куда идёт (аналогично), тип кабеля, его длина, обозначение на бирке. Хороший кабельный журнал позволяет найти любой кабель на объекте за минуту. Плохой - это таблица, которую заполнили формально и забыли обновить.
Один из наиболее практичных документов, который часто недооценивают, - сводная ведомость сигналов (Signal List). Это таблица, в которой для каждого канала ввода-вывода прописано: программный тег, тип сигнала (DI/DO/AI/AO), адрес в ПЛК (модуль и канал), адрес клеммы в кроссовом шкафу, тег прибора на P&ID, диапазон и единицы измерения. Если такой документ сделан грамотно и актуален - наладчик может проверить любой канал, не открывая программу. Именно такой сквозной документ, в котором прослеживается вся цепочка сигнала от поля до программы, делает пусконаладку предсказуемой, а не авантюрой.
Схемы внешних проводок (или схемы соединений) показывают, как именно соединяются шкафы управления между собой и с полевыми приборами - с указанием клемм, экранирования, заземления.
Эксплуатационная документация: то, с чем живут годами
Проектная документация нужна, чтобы систему создать. Эксплуатационная нужна, чтобы с ней работать каждый день. И если с проектной документацией у большинства интеграторов хоть что-то есть, то эксплуатационная нередко оказывается слабым местом.
Эксплуатационная документация по ГОСТ 34.201 включает несколько ключевых документов. Формуляр - документ, фиксирующий состав системы, характеристики, гарантийные обязательства и историю эксплуатации. Руководство оператора - то, что человек на пульте использует ежедневно: описание SCADA-мнемосхем, алгоритмов управления, действий в нештатных ситуациях. Руководство системного администратора - для технического персонала: настройка сети, резервное копирование конфигураций, замена оборудования.
В международной практике требования к эксплуатационной документации стандарт IEC/IEEE 82079-1 формулирует так: информация для применения продукта должна быть необходима для его безопасного использования и полезна для эффективного применения. Это значит, что документ должен быть написан для конкретного читателя - не для абстрактного "специалиста", а для оператора с конкретным уровнем квалификации, который будет использовать систему в конкретных условиях.
На практике руководство оператора часто пишут те же люди, которые разрабатывали систему. И они пишут его с точки зрения разработчика - то есть описывают внутреннюю логику, а не то, что нужно оператору. Оператору не нужно знать, как устроен алгоритм ПИД-регулирования. Ему нужно знать: что делать, если насос не запускается; куда смотреть, если давление в контуре вышло за уставку; в каком порядке запускать систему после планового останова.
Именно это различие - между документацией "как работает" и документацией "что делать" - определяет, будут ли люди вообще читать руководство или оставят его пылиться на полке.
Паспорт на шкаф управления: документ, который не любят делать и без которого нельзя
Отдельная история - паспорт на шкаф управления. Каждый шкаф управления с ПЛК, который поставляется на объект, должен сопровождаться паспортом и руководством по эксплуатации. Это требование ГОСТ 2.601 на эксплуатационные документы и, применительно к промышленному оборудованию, неотъемлемая часть сдаточной документации.
В паспорте шкафа должны быть: наименование и обозначение изделия, перечень комплектующих с указанием производителя и серийных номеров, технические характеристики (диапазон питающего напряжения, потребляемая мощность, степень защиты IP, климатические условия эксплуатации), схема подключения, гарантийные обязательства.
Производители промышленных контроллеров, разумеется, поставляют документацию на своё оборудование. Паспорт, руководство по эксплуатации, описание протоколов обмена данными - это стандартная часть поставки любого серьёзного производителя. Для интегратора, собирающего систему на базе конкретного ПЛК, это значит, что документацию на нижний уровень можно включить по ссылке, сосредоточившись на описании прикладной части - программы и конфигурации.
Где документация ломается: типичные провалы
Если говорить честно о том, что происходит на практике, а не о том, как должно быть в теории, картина получается неприятная.
Первая и самая частая проблема - документация создаётся один раз и не обновляется. В ходе монтажа обнаруживается, что кабель удобнее провести иначе - и прокладывают иначе, но в схему не вносят. Заказчик просит добавить три датчика - добавляют, но в P&ID не рисуют. Через год система работает, а документация описывает что-то другое. Пусконаладка по такой документации превращается в лотерею.
Вторая проблема - несогласованность документов между собой. Тег прибора в P&ID, в ведомости сигналов и в программе ПЛК написан по-разному. Адрес клеммы в кабельном журнале не совпадает с принципиальной схемой. Это происходит, когда несколько специалистов работают над документацией независимо и никто не проверяет согласованность на финальном этапе.
Третья проблема - документация не соответствует реальному получателю. Инструкция для оператора написана как технический отчёт для проектировщика. Руководство системного администратора предполагает знание внутренней архитектуры системы, которой у него нет. Документ формально существует, но реально не помогает.
Четвёртая - контроль версий. На предприятиях, где нет централизованной системы управления документацией, в обороте одновременно гуляет три версии одного и того же чертежа. Монтажники работают по старой, наладчики принесли новую, а в архиве лежит промежуточная.
Все эти проблемы хорошо известны в отрасли. По данным ряда отраслевых исследований, от 30 до 40% инициатив по стандартизации АСУ ТП дают эффект ниже ожидаемого именно из-за проблем с документацией и управлением изменениями - не из-за технических ошибок в коде или железе.
Как сделать документацию, которую будут читать
Несколько принципов, которые работают на практике.
Первое - определите состав документов в техническом задании до начала работ. Не "по умолчанию", не "стандартный набор", а конкретный перечень с указанием формата, кто отвечает за каждый документ и когда он должен быть готов.
Второе - электронные базы тегов. Сразу пропишите в ТЗ требование поставлять актуальную электронную базу тегов в читаемом формате (CSV, Excel) вместе с проектной документацией. Это позволяет автоматически проверять согласованность тегов между P&ID, ведомостью сигналов и программой ПЛК.
Третье - фотографии как часть документации. Это звучит нестандартно, но работает. Фотогалерея собранного шкафа управления (вид спереди, вид сзади, детали подключения разъёмов) позволяет пусконаладчику на объекте быстро принять шкаф и найти нужный элемент. Особенно полезно для нестандартных разъёмов и специфичных компонентов - снимок с габаритными размерами исключает ошибки монтажа.
Четвёртое - сквозная нумерация каналов. Когда один и тот же канал имеет одинаковый идентификатор во всех документах - от P&ID до программного тега и адреса в кроссовом шкафу - поиск любого сигнала занимает секунды, а не часы.
Пятое - структура документов должна отражать структуру задач. Руководство оператора пишется не в логике "как устроена система", а в логике "что оператор делает в каждой ситуации": запуск, штатная эксплуатация, аварийный останов, плановое обслуживание.
Цифровая документация: куда движется отрасль
Международный стандарт VDI 2770 создаёт рамку для передачи документации производителей оборудования в IT-системы операторов промышленных объектов. Суть проста: документация на каждый компонент системы сопровождается в машиночитаемом формате, что позволяет подгружать её автоматически в системы управления технической документацией предприятия.
Европейская концепция цифрового паспорта продукта, которая разрабатывается в рамках нескольких директив ЕС, идёт дальше: предполагается, что к 2030 году значительная часть промышленного оборудования будет поставляться с цифровым паспортом, содержащим всю техническую информацию в структурированном виде.
Для инженера АСУ ТП это означает постепенный переход от PDF-документов в папках к интерактивным системам документирования, где информация о приборе, кабеле или программном блоке связана между собой и с реальным оборудованием. Ряд SCADA-платформ и MES-систем уже сейчас позволяет хранить документацию привязанной к тегам - щёлкнул на тег в SCADA, открылось руководство по прибору.
Это будущее. Но пока оно не наступило повсеместно - бумаги и PDF никуда не делись, и делать их надо правильно.
Коротко о главном: FAQ для быстрого поиска
Что входит в состав технической документации на АСУ ТП? Техническая документация на АСУ ТП включает несколько групп документов: предпроектную (техническое задание, технико-экономическое обоснование), проектную (функциональные схемы автоматизации P&ID, структурные схемы), рабочую (принципиальные электрические схемы, кабельные журналы, ведомости сигналов, монтажные схемы) и эксплуатационную (руководство оператора, руководство администратора, паспорт системы). Состав определяется ГОСТ 34.201-2020 и конкретизируется в техническом задании.
Какой стандарт регулирует техническую документацию на АСУ ТП в России? Основной стандарт - ГОСТ 34.201-2020, введённый в действие с 1 января 2022 года. Для строительной части проектов применяется ГОСТ 21.408-2013. Международный аналог - IEC/IEEE 82079-1 редакции 2019 года, устанавливающий принципы подготовки информации для применения любых продуктов.
Что такое P&ID и зачем она нужна? P&ID (Piping and Instrumentation Diagram) - функциональная схема автоматизации, на которой изображены технологическое оборудование, трубопроводы, все приборы КИПиА с тегами и связи между ними. Это главный рабочий документ пусконаладчика: именно P&ID связывает физический прибор на объекте с его тегом в программе ПЛК и с переменной в SCADA.
Почему документация на АСУ ТП устаревает и как этого избежать? Документация устаревает, когда изменения в физической системе не вносятся в чертежи. Основной способ борьбы - установить процедуру управления изменениями: любое физическое изменение на объекте должно сопровождаться обновлением документации с указанием даты и ответственного. Электронные базы тегов и системы контроля версий значительно упрощают этот процесс.
Нужна ли специальная документация на программу ПЛК? Да. На программное обеспечение ПЛК разрабатывается отдельная документация по ГОСТ 19.101: описание программы, руководство программиста, текст программы. Отдельно должны храниться резервные копии скомпилированных проектов с историей версий - это критично для быстрого восстановления после аппаратного отказа.
Вместо заключения
Техническая документация - это не то, что делается "потому что так надо по ГОСТу". Это инфраструктура знаний о системе, которая позволяет её эксплуатировать, обслуживать и развивать на протяжении всего жизненного цикла.
Плохая документация не проявляет себя сразу. Она даёт о себе знать через два года, когда нужно добавить три датчика и никто не понимает, куда тянуть кабели. Или через пять лет, когда ПЛК вышел из строя и нужно восстановить конфигурацию - а резервной копии нет, и что было в программе, никто не помнит.
Производители промышленных контроллеров, серьёзно относящиеся к своим продуктам, поставляют полный комплект документации: паспорт, руководство по эксплуатации, описание протоколов. Это снимает часть нагрузки с интегратора. Но прикладная часть - программа, конфигурация, ведомость сигналов, кабельный журнал - всегда остаётся задачей команды, которая систему создаёт.
И её качество определяет, будет ли система понятной тем, кто с ней будет работать через десять лет.