Проект АСУЗ — это момент, когда всё ещё дёшево. Любая недоговорённость, которая осталась в документах, после сдачи превращается в работы за отдельные деньги или в ограничение, с которым эксплуатация живёт годами.
Мы читаем проекты перед стройкой и видим одни и те же дыры. Ниже то, что стоит проверить самому, до подписания технического задания.
1. Есть ли раздел про то, как системы работают вместе
Разделы проекта пишут разные люди: отопление и вентиляция отдельно, пожарная сигнализация отдельно, слаботочка отдельно. Раздела «как это работает вместе» обычно нет вообще.
Причём очевидные вещи как раз сделают: вентиляцию при пожаре остановят, потому что этого требуют нормы. Проблемы начинаются там, где норматива нет, а жизнь есть. Вот три вопроса, которые стоит задать проектировщику до подписания ТЗ.
Как вентиляция вернётся в работу после пожара
Остановить установки — полдела. Спросите, каким образом они возвращаются в рабочее состояние. Если ответ «вручную на контроллере каждой установки», прикиньте, сколько их в здании: на школе это полсотни, на поликлинике больше шестидесяти. Обойти все венткамеры после каждой сработки, в том числе ложной, никто не будет, и про часть установок просто забудут. Выяснится это зимой, когда в крыле станет холодно.
В проекте должно быть написано: кто и как восстанавливает режим, можно ли это сделать командой из диспетчерской, и как проверяется, что в работу вернулись все установки, а не половина.
Когда примут меры: до аварии или после
Если температура калорифера или обратного теплоносителя ползёт вниз третий день, это видно заранее. Вопрос в том, доходит ли это знание до того, кто принимает решение.
Когда наружу отдаётся только «авария или не авария», меры примут после остановки установки. Когда передаются значения и тренды, а в системе заданы пороги предупреждения до аварийного, выехать можно до того, как здание осталось без приточки.
В проекте должно быть: передача аналоговых значений, а не только дискретных аварий; пороги предупреждения отдельно от аварийных; и кому именно уходит предупреждение.
Хватит ли мощности теплового пункта на вентиляцию
Отдельный разговор — баланс. Калориферы вентиляции по проекту требуют определённой мощности, тепловой пункт выдаёт свою. Если это никто не свёл, зимой теплоносителя на калориферы не хватает: установки не выходят на уставку, срабатывает защита от обмерзания, и они висят в аварии. В итоге их просто выключают на зиму, потому что иначе они постоянно встают по риску разморозки водяного калорифера.
Попросите показать расчёт: какая мощность нужна потребителям в пиковом режиме, что даёт тепловой пункт, что происходит при самой низкой расчётной температуре.
Общее правило: по каждому такому сценарию в проекте должно быть видно, кто инициатор сигнала, по какому протоколу он передаётся, какой именно сигнал и что считается подтверждением, что сценарий отработал.
2. Перечень сигналов по каждой системе
Это самый полезный документ во всём проекте и чаще всего он отсутствует. Нужна таблица: система, оборудование, параметр, тип (аналог, дискрет, уставка), кто отдаёт и куда.
Как выглядит нормально заведённая вентустановка:
Здесь видно режим, температуры наружного, приточного и вытяжного воздуха, положение заслонок, работу рекуператора и насоса, уставки и аварии. А бывает, что наружу отдаётся только «работает или нет».
Отдельно проверьте наработку оборудования. Без неё эксплуатация не видит, идёт ли чередование насосов и когда ехать на обслуживание.
Это реальный объект, школа №39. Насос с нулевой наработкой подведёт ровно тогда, когда встанет основной.
3. Протоколы и открытость оборудования
Проверьте, что в проекте указаны конкретные протоколы обмена, а не «предусмотреть возможность интеграции». Нужны: протокол, перечень регистров или объектов, документация производителя и условия её получения.
Отдельный вопрос — закрытые шлюзы. Если система отдаёт данные только в своё облако или только в свой пульт, в здании появляется ещё один изолированный экран, а эксплуатация получает то, от чего вы уходили.
4. Согласованность смежных разделов
Разделы проверяют по отдельности, а работают они вместе. Типовой пример: повысительная насосная станция выдаёт минимум 5 бар, а оборудование теплового пункта и калориферы вентиляции заложены на 2,5–3 бара. Каждый раздел корректен, вместе получается либо постоянная работа на завышенном давлении, либо тактование насосов и гидроудары.
Поэтому полезно задать проектировщикам прямой вопрос: какие параметры одного раздела влияют на другой и кто это свёл. Подробнее мы разбирали это в статье о том, почему умное здание не работает после сдачи.
5. Диспетчеризация как отдельный раздел и ответственный за результат
Проверьте, что в проекте есть раздел диспетчеризации, а не упоминание о ней внутри слаботочки. В нём должны быть: архитектура сбора данных, серверная часть, каналы связи, резервирование, права доступа и перечень рабочих мест.
И главный организационный вопрос: кто отвечает за то, что системы заработают вместе. Если такого исполнителя в проекте нет, им по факту станет эксплуатация, причём после сдачи.
6. Требования эксплуатации
Позовите тех, кто будет обслуживать здание, до того, как ТЗ подписано. Спросите, что им нужно видеть каждый день, какие отчёты они сдают, по каким параметрам принимают решения. Это бесплатно сейчас и дорого потом.
Минимум, который стоит зафиксировать: состав инцидентов и их приоритеты, сроки реакции, кто получает уведомления, какие журналы и отчёты выгружаются.
7. Как будем принимать
Пропишите в ТЗ процедуру приёмки по сценариям, а не по наличию оборудования. То есть не «смонтировано согласно проекту», а «при подаче сигнала пожара лифты опустились, вентиляция остановилась, двери разблокировались, событие появилось в диспетчерской с указанием зоны».
Прогон занимает часы. Он находит то, что иначе всплывёт через месяц эксплуатации, когда подрядчики уже разъехались.
Короткий список для распечатки
- Есть раздел о совместной работе систем и три сценария: пожар, отказ ИТП, потеря связи.
- Есть таблица сигналов по каждой системе, включая аварии, уставки и наработку.
- Указаны протоколы, регистры и условия получения документации.
- Проверена согласованность смежных разделов: давления, температуры, расходы, режимы.
- Диспетчеризация выделена в отдельный раздел, назначен ответственный за совместную работу.
- Требования эксплуатации собраны до подписания ТЗ.
- Приёмка описана как прогон сценариев.
Если нужна пара глаз со стороны
Мы делаем экспертизу проекта АСУЗ: проверяем протоколы, перечни сигналов, точки стыковки и сценарии до того, как по проекту построят. Оборудование не продаём, поэтому заключение зависит только от того, что будет работать.
