As-built после доработки шкафа: Как не потерять правду между схемой и объектом

После пуска шкаф редко остается музейным экспонатом. На объекте добавляют один датчик, переносят сигнал на соседний канал I/O, меняют реле, подтягивают перемычку, временно заводят питание через свободную клемму, уточняют уставку, переклеивают маркировку. Работы небольшие, производство остановили ненадолго, механизм снова включился - и кажется, что история закрыта.

Проблема начинается позже. Через месяц другой инженер открывает схему, видит один канал, а в шкафу сигнал сидит на другом. В кабельном журнале жила числится резервной, но по ней уже идет реальный сигнал. В проекте ПЛК старый комментарий, на двери шкафа новая бирка, в паспорте объекта тишина. В этот момент документация перестает быть помощником и становится ловушкой.

Разберем as-built как рабочий инструмент эксплуатации, а не как бюрократический ритуал. Здесь не будет пересказа ГОСТов и требований к комплекту исполнительной документации. Речь о том, какие следы должна оставить доработка шкафа, чтобы следующий наладчик нашел фактическое состояние объекта, а не красивую версию прошлого.

As-built после доработки шкафа - это синхронизация факта на объекте со схемой, кабельным журналом, паспортом объекта и резервной копией проекта ПЛК/HMI. Фиксировать нужно не только крупную модернизацию, но и перенос клеммы, замену канала I/O, новую перемычку, занятую резервную жилу, измененную уставку, реле или маркировку. Минимальный набор следов: фото до и после, red-line или ревизия схемы, запись в журнале изменений, обновленный кабельный журнал, актуальный проект с версией, запись в паспорте объекта и понятное согласование. Временная правка тоже должна иметь владельца, срок и условие возврата. Если изменение нельзя найти по документам через полгода, его нельзя считать закрытым.

Расхождение почти никогда не выглядит драматично в момент работ. Никто не говорит: “Сейчас мы создадим будущую диагностическую проблему”. Обычно звучит проще: “Перекинем на свободный вход, старый канал подозрительный”, “Поставим другое реле, такое есть на складе”, “Уставку пока поднимем, технолог просит”, “Перемычку оставим до планового ремонта”, “Маркировку потом поправим”.

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

Особенно быстро теряется правда в местах, где сходятся несколько дисциплин. Электрик меняет клемму и считает, что “по электрической части все понятно”. Наладчик переносит сигнал в проекте ПЛК и уверен, что “в комментарии написал”. Технолог просит уставку и фиксирует ее в своем журнале. Проектировщик потом получает три разных следа и пытается восстановить одну картину.

As-built нужен именно для этой стыковки. Он не делает работу более “бумажной”. Он оставляет нормальную дорогу от шкафа к схеме, от схемы к проекту, от проекта к эксплуатации.

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

К доработкам стоит относить перенос сигнала на другой канал I/O, изменение номера клеммы, замену промежуточного реле на другой тип или с другой схемой контактов, добавление или снятие перемычки, замену кабеля, использование резервной жилы, изменение точки подключения экрана, перенос питания, смену автомата или предохранителя по цепи, корректировку маркировки, изменение уставки, изменение логики блокировки, обновление проекта ПЛК или HMI.

Отдельно стоит выделить “временные” решения. Временная перемычка, обход неисправного входа, временный кабель, временная уставка или временное отключение сигнала часто живут дольше, чем планировали. Если такая правка не описана, она перестает быть временной и превращается в скрытое состояние объекта.

Хороший вопрос после любой мелкой работы: сможет ли человек без участия исполнителя понять, что изменилось, почему, когда и где это отражено? Если ответ “ну мы ему расскажем”, значит as-built еще не закрыт.

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

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

Фотографии должны быть связаны с номером заявки, датой, шкафом, листом схемы или позицией оборудования. Папка “фото шкафа новые” живет недолго. Набор “2026-06-18_ШУ-2_заявка-145_перенос-DI-17” живет лучше, потому что его можно найти.

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

На объекте не всегда есть возможность сразу открыть CAD-проект и выпустить новую ревизию. Поэтому нормальная практика - сделать red-line: отметить изменение на распечатке или PDF, указать дату, исполнителя, причину и номер заявки. Это рабочий промежуточный след, а не финальная документация.

Red-line должен отвечать на три вопроса: что было, что стало и где это должно появиться в новой ревизии. Например: “DI-12 перенесен с X3:14 на X3:18, старый канал выведен из работы, причина - нестабильное состояние входа, заявка 145”. Или: “Реле K17 заменено на тип с другой нумерацией контактов, схема контактов проверена, лист Э3-12 требует обновления”. Без таких деталей отметка превращается в красную линию ради красной линии.

После этого правка должна попасть в актуальную КД. Важно не только нарисовать новый провод. Нужно обновить обозначение клеммы, номер канала, перечень элементов, кабельный журнал, таблицу сигналов, комментарии в проекте ПЛК/HMI и, если нужно, инструкцию эксплуатации. Одно изменение в шкафу часто имеет пять отражений в документах.

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

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

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

Паспорт объекта отвечает на другой вопрос: какое состояние системы считать действующим. В него стоит заносить не каждую фотографию, а итоговую информацию: что изменено, по какой заявке, какая ревизия КД стала актуальной, какая версия проекта ПЛК/HMI загружена, какие уставки или режимы изменены, какие временные решения остаются открытыми.

Паспорт особенно важен после пуска. Первичная документация часто отражает “как должно было быть”, а объект после SAT уже показывает “как получилось после наладки”. Если этот разрыв не закрыть, следующая модернизация начнется с раскопок.

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

В идеале у проекта есть версия в Git или хотя бы дисциплинированный архив с понятным именем. Коммит или архив должен говорить не “финал новый”, а что произошло: “перенос DI насоса Н-2 на канал 17, заявка 145, обновлена диагностика обрыва”. Тег релиза или номер сборки должен совпадать с записью в паспорте объекта и актом выполненных работ.

Это особенно важно для отката. Если после доработки механизм ведет себя нестабильно, нужно быстро понять, какая версия была загружена до изменений и какая после. Без резервной копии проект может оказаться на инженерном ноутбуке, который уехал на другой объект. Плохой способ хранить историю, прямо скажем.

Для CODESYS 3.5, MasterSCADA 4D и других сред принцип один: исходник проекта, экспорт для просмотра, список изменений и резерв загруженной версии должны быть доступны тем, кто отвечает за объект. Не обязательно строить сложный DevOps. Достаточно, чтобы версия была однозначной, восстановимой и связанной с фактом на шкафу.

Согласование не должно превращать замену клеммы в заседание комитета. Но у изменения должен быть владелец и понятный круг людей, которые понимают последствия.

Если правка касается только маркировки или уточнения документации, обычно достаточно ответственного за эксплуатацию и специалиста, который ведет КД. Если меняется цепь питания, клемма, реле или кабель, нужен профильный электрик или служба, отвечающая за шкаф. Если переносится канал I/O или меняется логика, участвует инженер АСУ ТП. Если затронута блокировка, защита, аварийная сигнализация или уставка, нужен владелец процесса, а иногда и служба промышленной безопасности.

Главное - согласовать не “бумагу”, а смысл. Кто понимает риск? Кто подтверждает, что механизм можно запускать? Кто отвечает за обновление схемы? Кто закрывает временную правку? Кто принимает итоговый as-built?

Плохой признак - когда каждый участник сделал свой кусок, но никто не отвечает за целое состояние объекта. В as-built всегда должен быть один ответственный за закрытие изменения, даже если работы выполняли несколько людей.

Временная правка - это не все, что сделали быстро. Это изменение с ограниченным сроком, понятной причиной, оцененным риском и планом возврата или перевода в постоянное решение.

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

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

Самая надежная временная правка - та, которую неудобно забыть. У нее есть заявка, метка в журнале, напоминание на закрытие, отметка в паспорте объекта и red-line в КД.

Этот чек-лист не требует отдельной папки на каждую переставленную жилу. Он требует, чтобы изменение не осталось одиноким фактом внутри шкафа. Если артефакт не применим, это можно отметить. Если применим, но отсутствует, доработка еще не закрыта.

Главный враг as-built - не отсутствие формальной папки, а несколько параллельных “истин”. Схема лежит в одном месте, фото - в телефоне, проект ПЛК - на ноутбуке подрядчика, кабельный журнал - в Excel у наладчика, паспорт объекта - в PDF без обновления. Все это существует, но вместе не работает.

Лучше держать простую структуру: объект, шкаф, заявка, дата, ревизия. У изменения должен быть один номер, по которому находятся фото, схема, запись в журнале, проект и паспорт. Тогда даже простой файловый архив начинает работать как система.

Нужно договориться, что считается источником правды. Для схемы это актуальная КД, для кабелей - кабельный журнал, для проекта - репозиторий или утвержденный архив, для состояния объекта - паспорт. Если кто-то меняет данные в одном месте, он обязан запустить обновление связанных документов. Не лично все перерисовать ночью, а передать изменение тому, кто отвечает за этот документ.

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

Да, если маркировка участвует в поиске сигнала или обслуживании. Иначе схема, бирка и журнал начнут спорить между собой, а спорить с наклейкой на клемме обычно бесполезно.

Можно, если есть временный след: фото, red-line, заявка, ответственный и срок закрытия. Нельзя оставлять “потом” без владельца.

Начинать не с тотальной перерисовки, а с инвентаризации критичных цепей: питание, защиты, аварии, основные I/O, кабели, которые часто обслуживают. После этого выпускать ревизию по приоритетам.

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

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

•Паспорт объекта АСУ ТП после пуска: что передать заказчику;

•КД для АСУ ТП на объекте: какие листы реально нужны наладчику;

•Git для проекта ПЛК: минимальная практика версионирования.