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