Умное здание начинается не с оборудования и выбора подрядчика, а с проекта —нет, не с того, который рисуют инженеры, а с того, который формулирует требования. Именно этой теме был посвящен вебинар компании Ujin, в рамках которого директор по развитию «Юникорн» Наталья Лунева разобрала, почему проекты умных зданий буксуют и как технический проект АСУЗ снимает неопределенности до начала детального проектирования.
Проблема: здание проектируется раньше, чем определено, что оно должно уметь
Типичная ситуация на рынке выглядит так. Маркетинг формирует обещания продукта. Инженеры проектируют отдельные системы. ГИП раздает задания смежникам. В проект приходят разные вендоры — каждый реализует свою часть. А на этапе интеграции выясняется, что системы должны были обмениваться данными, но это не было заложено в проект.
Последствия предсказуемы: изменения проектной и рабочей документации, дополнительные кабельные линии и оборудование, несовместимые вендоры, несколько отдельных приложений и интерфейсов, ручная работа управляющей компании вместо автоматизированных сценариев. Функционал, обещанный маркетингом, технически не реализован. Интегратор вынужден «сшивать» решения на стройке — и в итоге от функционала отказываются.
Корень проблемы не в плохом оборудовании и не в плохом проектировщике. Он в том, что объект начинает проектироваться до того, как девелопер определил, что именно должно уметь здание, какие сценарии нужны жителю и эксплуатации, какие системы должны работать совместно и какие данные должны передаваться между ними.
Правильный путь: от пользовательского сценария к инженерным требованиям
Ответ на эти вызовы укладывается в простую последовательность. Сначала формируется концепция умного здания — набор сервисов, описанный с точки зрения пользовательского пути. Затем разрабатывается ТП АСУЗ — документ, который переводит бизнес-, пользовательские и эксплуатационные требования девелопера на язык инженерного проектирования. На его основе создается рабочая документация, и только потом выполняются строительно-монтажные и пусконаладочные работы.
Концепция умного здания — это не перечень технологий, а ответы на вопросы о том, что должен видеть и чем управлять резидент, как гость получает доступ, какие события и аварии должна видеть эксплуатация, какие параметры инженерных систем необходимы инженеру. Пользовательский путь определяет сценарии, а сценарии — требования к инженерным системам.
Показательный пример — сценарий протечки.
Датчик реагирует на воду, отправляет сигнал на контроллер, тот передает команду на привод, привод перекрывает клапан, в интерфейсах резидента и УК появляются уведомления, создается заявка. Одна пользовательская функция проходит через несколько инженерных и информационных систем. Именно поэтому проектирование этих систем независимо друг от друга почти неизбежно создает проблемы интеграции.
Что такое ТП АСУЗ и что он фиксирует
Технический проект автоматизированной системы управления зданием — это часть рабочей документации проекта, которая фиксирует состав сервисов умного здания, состав инженерных систем, входящих в контур умного здания, требования к инженерным системам, достаточные для реализации сервисов, требования к платформе и требования к интерфейсам для конкретного объекта.
В результате разработки ТП АСУЗ должны быть определены комплексная модель объекта, состав систем АСУЗ, функциональные требования, архитектура единой цифровой среды, межсистемные связи, требования к интерфейсам и протоколам, пользовательские интерфейсы, требования к диспетчеризации, задания смежным разделам, требования к оборудованию, спецификация и вендор-лист.
ТП АСУЗ — это не еще один инженерный раздел. Это слой требований над инженерными разделами, который заставляет их работать как единую систему. Проектировщик перестает самостоятельно додумывать продукт девелопера: он получает четкие ответы на вопросы, какие системы проектировать, какие функции должна реализовывать каждая система, какие интерфейсы предусмотреть, куда передавать данные, какие задания выдавать смежникам и какие требования нельзя потерять при выборе оборудования.
Когда ТП АСУЗ необходим, а когда можно обойтись без него
Документ нужен не всегда. Без него можно обойтись, если умная функциональность затрагивает только базовые системы — АСКУЭ, СОТ, домофонию, простой СКУД для авто, а вендор-лист объекта соответствует вендор-листу Ujin. Также ТП АСУЗ можно не разрабатывать, если рабочая документация уже идет или закончена, а девелопер не готов на корректировку — тогда подключается то, что можно подключить.
Однако есть ситуации, когда без ТП АСУЗ не обойтись:
• Объекты с несколькими функциональными зонами — жилье, офисы, отель.
• Сложная конфигурация с большим количеством входов и выходов, несколькими корпусами, центральным лобби и разделением потоков
• Объекты высокого класса, где нужно больше, чем базовая умная функциональность: цифровой ресепшн, умный паркинг с контролем занятости и оплатой, умный лифт, биометрия по 572-ФЗ.
• Специфические требования УК с повышенными требованиями к инженерке и запросами на уникальную автоматизацию.
• Получение класса А по методологии ЕРЗ.
Соответствие стадий: где ТП АСУЗ встраивается в проект
Стадии создания АСУЗ регламентированы и включают формирование требований, разработку концепции, разработку технического задания, проектирование системы, разработку рабочей документации, ввод в действие и сопровождение. Эти стадии ложатся на этапы девелоперского проекта следующим образом.
На стадии концепции проекта формируется концепция умного здания. На стадии П — при наличии планировочных решений — разрабатывается ТП АСУЗ, который затем передается проектировщикам для проектирования стадии Р. На стадии РД проводится аудит рабочей документации на соответствие ТП АСУЗ. На стадии монтажа и пусконаладки — аудит СМР и ПНР, проверка на соответствие РД и готовность к подключению. На стадии эксплуатации выполняется сервисное обслуживание инженерных систем и АСУЗ, периодическое тестирование.
Если в договоре на генподряд учтены требования концепции или ТП АСУЗ, умное здание будет построено с высокой вероятностью. Генподрядчик будет осведомлен о том, что ему нужно построить, и включит соответствующие затраты в бюджет. Девелопер избежит допсроков на корректировку документации и увеличение объема работ.
Золотые правила
Логика работы с ТП АСУЗ укладывается в четыре правила. На стадии концепции согласуется функциональность и вендор-лист. На стадии проекта при наличии планировочных решений разрабатывается ТП АСУЗ и передается проектировщикам. На стадии рабочей документации проводится аудит на соответствие ТП АСУЗ. На стадии СМР и ПНР — проверка на соответствие РД и готовность к подключению.
ГОСТы как фундамент
С 2024 года действует серия национальных стандартов, посвященных киберфизическим системам умного дома. ГОСТ Р 71865–2024 определяет архитектуру, ГОСТ Р 71866–2024 — общие технические требования к АСУЗ, ГОСТ Р 71867–2024 — стадии создания АСУЗ, ГОСТ Р 71868–2024 — классы многоквартирных домов. Отдельные документы посвящены требованиям к устройствам, базовому набору оборудования, многоабонентскому домофону и Ethernet-реле. Архитектура, требования, стадии создания и устройства рассматриваются в отдельных ГОСТах, и это создает нормативную рамку для проектирования.
Умное здание начинается с проекта. Технический проект АСУЗ — это инструмент, который позволяет девелоперу перестать проектировать вслепую и получить здание, которое действительно работает как единая система.
