Линия запущена, смена видит зеленые статусы, акт уже хочется подписать. В этот момент легко считать, что заказчику достаточно отдать архив проекта и пару PDF. Через полгода картина меняется: специалист подрядчика недоступен, в шкафу заменили модуль, пароль от инженерной станции ищут в переписке, а на вопрос «какая ревизия реально работает?» отвечают тремя разными файлами.
Пуск заканчивается не тогда, когда оборудование впервые отработало цикл, а когда эксплуатация может безопасно обслужить, восстановить и изменить систему без угадывания. Для этого нужен паспорт объекта АСУ ТП: не торжественная папка на полке, а управляемый комплект сведений о том, что установлено, как настроено, что проверено и к кому обращаться при отклонении.
Короткий ответ
После пуска заказчику передают утвержденный baseline объекта: исполнительную документацию, исходные и загрузочные проекты, сетевую карту, ревизии оборудования и ПО, правила доступа, резервные копии, протоколы испытаний, состав ЗИП и контакты поддержки. У каждого файла должны быть версия, дата, владелец, статус as-built и понятное место хранения.
Главный принцип прост: паспорт должен позволить другому квалифицированному инженеру принять дежурство без звонка автору проекта.
Почему одних исходников недостаточно
Исходники отвечают на вопрос «как написана логика», но почти не отвечают на вопросы эксплуатации. Какой именно архив загружен в контроллер? На каком порту шкафа находится инженерное подключение? Какая резервная копия проверена восстановлением? Где лежит актуальная схема после переноса датчика? Кто выдаст временный доступ в выходной день?
Если ответы живут только в голове наладчика, объект формально передан, но фактически остается зависимым от одного человека. Особенно больно это проявляется после небольшой доработки: схему поправили на бумаге, проект обновили на ноутбуке, а паспорт остался в состоянии первого пуска. В результате следующая диагностика начинается не с причины отказа, а с восстановления истории.
Паспорт решает эту задачу только в связке с документооборотом: каждый согласованный change request должен заканчиваться обновлением затронутых листов, ревизии проекта и реестра конфигурации.
12 документов и артефактов для передачи
Ниже - минимальный комплект для объекта АСУ ТП после ввода в эксплуатацию. Его можно расширять под отрасль и договор, но сокращать стоит лишь осознанно, с записью о принятом риске.
У списка есть важная логика. Первые четыре позиции описывают что построено и чем управляется. Пункты 5-8 фиксируют какая версия считается эталонной и как к ней вернуться. Пункты 9-12 отвечают за доказательство приемки и жизнь объекта после отъезда пусконаладки.
Как оформить паспорт, чтобы им пользовались
Огромная папка без навигации редко становится рабочим инструментом. Удобнее передавать комплект в двух формах: подписанный PDF-пакет для фиксации состояния и структурированный электронный каталог с файлами, которые понадобятся инженеру.
Пример оглавления электронного комплекта:
00_Passport_Register/
01_AsBuilt_Drawings/
02_Equipment_Software_Licenses/
03_Projects_Approved_Baseline/
04_Revisions_ChangeLog/
05_Network_Map/
06_Access_Regulation/
07_Backup_Restore/
08_FAT_SAT/
09_Runbook_Alarms/
10_Spares/
11_Support_Warranty/
Для каждой папки в ведомости передачи указывают: название файла, ревизию, дату, ответственного за актуализацию, статус утверждения и контрольную сумму там, где это важно для загрузочных архивов. В файлах проекта не должно быть загадочных названий вроде final_new_last_ok; принятую сборку именуют по объекту, ревизии и дате.
As-built: фиксировать не красивую схему, а установленный объект
Исполнительный комплект собирают после пусковых изменений. Если на объекте поменяли клемму, перенесли сигнал, добавили защитный аппарат или заменили устройство эквивалентом, это уже не замечание карандашом на распечатке. Изменение должно попасть в схему, ведомость оборудования и, при влиянии на алгоритм, в ревизию проекта.
Хорошая проверка перед подписью проста: инженер заказчика берет случайный сигнал или устройство на шкафу и проходит путь от маркировки на месте до схемы и экрана диагностики. Если путь обрывается на «это наладчик помнит», комплект еще не стал as-built.
Карта сети: передать маршрут к диагностике
Сетевая карта нужна не только администратору. Она помогает техслужбе понять, где заканчивается шкаф, как инженерная станция получает доступ, какие подключения зарезервированы и что нельзя менять во время ремонта соседнего узла.
В карту включают физическую топологию и адресный план, назначение портов, перечень оборудования связи, сетевые настройки, согласованные сервисные подключения и владельца изменений. Секреты доступа в карту не вписывают: карта показывает архитектуру, а доступ выдается по отдельному регламенту.
Пароли: передается регламент, а не файл passwords.xlsx
Передача доступа - один из самых частых провалов сдачи. Оставить заказчику один административный логин в письме так же опасно, как не передать его вовсе. В паспорте фиксируют роли: оператор, инженер эксплуатации, администратор, сервис подрядчика. Для каждой роли указывают владельца, способ выдачи, условия временного повышения прав и порядок отзыва.
Сами пароли, ключи и резервные коды должны передаваться через согласованное защищенное хранилище или процедуру приема секретов. После сдачи административные секреты ротируют, факт смены записывают в журнал, а аварийный доступ проверяют так же практично, как резервное восстановление. В паспорте остается регламент и отметка о выполнении, но не открытая таблица с секретами.
Ревизии и протоколы: какая сборка действительно принята
Проект, переданный заказчику, должен совпадать с тем, который прошел испытания и работает на объекте. Для этого в baseline связывают четыре вещи: архив проекта, ревизию, протокол испытаний и фактически загруженную конфигурацию. Если после испытаний исправляли замечание, его либо проверяют повторно и включают в новую ревизию, либо честно оставляют открытым с ответственным и сроком.
Границы заводских и объектовых испытаний, сценарии и шаблон протокола подробно разобраны в статье «FAT и SAT без формализма: как принимать систему автоматизации так, чтобы не ловить сюрпризы на пуске». Для паспорта важен итог: в папке не просто два подписанных файла, а связь «что тестировали - на какой ревизии - с каким результатом».
ЗИП и контакты: документы, которые нужны в самый неудобный момент
Ведомость ЗИП иногда воспринимают как приложение к поставке, хотя для эксплуатации это один из самых практичных листов. Нужны не только наименования запасных изделий, но и точное исполнение, допустимая замена, количество в резерве, место хранения и ответственный за пополнение. Запасная позиция, которую невозможно найти в ночную смену, помогает только на бумаге.
Контакты поддержки оформляют так же предметно. Не «телефон инженера Ивана», а каналы регистрации заявки, время реакции, контакты по уровням эскалации, состав диагностических материалов для обращения и границы гарантийных работ. Люди меняются; рабочая процедура должна пережить замену людей с обеих сторон.
Документооборот после передачи: паспорт должен оставаться живым
Паспорт устаревает после первой же доработки, если для него не назначен владелец. Заказчику и интегратору полезно согласовать короткое правило: изменение объекта считается закрытым только после обновления затронутых документов.
Минимальный цикл изменения выглядит так:
1.Оформить заявку с причиной, границами и ответственными.
2.Сделать резервную копию принятого baseline до вмешательства.
3.Выполнить изменение и проверку по согласованному сценарию.
4.Обновить проект, as-built, карту сети или runbook - только те части, которых изменение касается.
5.Присвоить новую ревизию, внести запись в журнал и передать утвержденный комплект владельцу объекта.
Этот порядок кажется лишней бюрократией ровно до первого спорного простоя. С журналом и ревизиями видно, было ли изменение согласованным, что можно откатить и на какой версии система работала стабильно.
Бренд-блок: СТАБУР в составе передаваемого комплекта
Для объекта на оборудовании СТАБУР в паспорт удобно включить ссылки на каталог программируемых логических контроллеров и раздел документации: паспорта изделий, руководства и актуальные материалы должны находиться рядом с проектным baseline, а не искаться заново после пуска. При замене компонента эксплуатация сверяет обозначение и документацию с реестром переданного объекта, а изменение фиксирует новой ревизией.
Вопросы, которые стоит задать до подписи акта
Можно передать только PDF и архив исходников?
Нет, если заказчик должен эксплуатировать объект самостоятельно. Без сетевой карты, регламента доступа, backup/restore, протоколов и ЗИП архив исходников остается частью решения, но не паспортом эксплуатации.
Нужно ли помещать пароли в паспорт?
Нет. В паспорт входит матрица ролей, процедура выдачи и ротации, указание на защищенное хранилище и отметка о передаче. Секреты нельзя хранить в открытом документе комплекта.
Что делать, если после SAT нашли и исправили ошибку?
Создать новую ревизию, обновить затронутые документы, повторить относящийся к исправлению сценарий проверки и связать его результат с новой принятой сборкой.
Кто отвечает за актуальность паспорта после гарантии?
Владелец должен быть назван при передаче: обычно это служба АСУ ТП заказчика, а подрядчик актуализирует материалы в рамках заказанных доработок и сопровождения.
Обсуждение