TADетали:
Может ли лоскутная автоматика стать основой интеллектуального здания

Ожидание и реальность

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

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

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

Зоопарк систем и его последствия

При изучении существующей инфраструктуры функционирующего объекта мы чаще всего имеем дело с «кусочными» локальными системами.

Рассмотрим пример с двумя системами управления климатом в помещении:
1. Локальная система автоматизации вентиляционных установок, главной задачей которой является поддержание температуры приточного воздуха в воздушном канале (не в помещении);
2. Локальная система управления кондиционированием в здании, с пультами управления температурой в помещении.

Назначением обеих систем является поддержание комфортной температуры в помещении. В первой системе управление температурой приточного воздуха осуществляется по заданному алгоритму системы управления локальной автоматики (погодозависимый график, расписания) – исходной информацией для регулирования температуры являются своего рода константы, а не пользовательские данные. Во второй системе управление температурой в помещении происходит путем ее настройки с пульта управления кондиционером, исходя из комфорта пользователей. Михаил Рожков, PARMA TG: Большинство наших BPM-проектов выходят за рамки отдельных процессов и организаций 3.4 т

Что происходит: пользователь, желая охладить помещение в жаркий день, устанавливает пультом температуру на кондиционере в 18 градусов по Цельсию, а в это время работает алгоритм системы автоматизации вентиляции на поддержание температуры приточного воздуха в 22 градуса. Что получаем: оборудование данных систем работает безостановочно, `перебивая` друг друга, и при этом не удовлетворяет потребностям пользователей: пока одна система пытается снизить температуру, другая не дает снизить меньше заданной константы.

Вот несколько причин, почему так может произойти:

• не реализован информационный обмен между системами;
• нет единого источника исходной температуры в помещении;
• нет единой точки настройки температуры в помещении;
• нет продуманного алгоритма совместной работы двух систем.

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

Комплексное решение или локальная автоматизация?

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

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

Таким образом, внедрение локальных систем автоматики оправдано в случае, если система является специализированной, функционал ее узко направленный, и она никак не связана с другими системами и фактически не участвует в общей структуре взаимодействия.

Нельзя просто так взять и собрать пазлы из разных коробок

Как мы писали в первой статье, в ИЗ различные инженерные системы, которые работают с процессами поддержания микроклимата, обеспечения ресурсами и информационные системы (системы передачи данных, системы верхнего уровня) не просто сосуществуют, но сообща служат целям конечного пользователя. И это взаимодействие определяется тщательно разработанными сценариями.

В том же случае, когда локальные системы автоматизации уже созданы, учета потребностей смежных систем, единой концепции автоматизации здания нет, а возможности интеграции ограничены, сделать здание «умным» может быть невозможно. Но в то же время мы окружены большим количеством давно построенных зданий, которые оборудовались инженерными системами десятилетия назад – и заказчики хотят их эффективно эксплуатировать, используя все возможности современных технологий. Возникает следующее противоречие: если локальные системы автоматики уже давно функционируют, но не позволяют создать качественную интегрированную систему, то складывается такая ситуация, когда отказаться от всех или даже некоторых систем уже неразумно, но и не использовать преимущества единой системы неправильно. Что делать?

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

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

Автоматизированная система управления зданием (далее – АСУЗ), в свою очередь — это комплексный организационно-технический организм, обеспечивающий выработку решений на основе автоматизации инженерных систем и информационных процессов. В сфере ИЗ, как правило, АСУЗ представляет собой элементы инженерной(ых) системы(м), дополненные системой информационной. Визуализируя, мы получаем картину из пазлов, где элементы системы – это пазлы, имеющие четкое место и взаимодействие со своими ближайшими соседями.

Как подойти к автоматизации существующих объектов

При работе с фрагментами разных инженерных систем здания (в том числе систем локальной автоматики) требуется полноценный профессиональный анализ того, как работают данные системы, какими данными оперируют, чем управляют и как они построены технически. В большинстве случаев для того, чтобы «подружить» их, могут потребоваться абсолютно разные решения: от обеспечения информационного обмена между ними до замены технического решения полностью. Иными словами, в любом из этих случаев необходимо потратить дополнительные ресурсы на их адаптацию для работы в одной «упряжке». Стоит ли говорить о том, что такой подход – не одно и тоже, что создание ИЗ с нуля, и необходимо подходить к этому здраво и грамотно? В этом могут помочь опытные специалисты, способные как сформулировать требования к системе, так и внедрить ее.

Так, чтобы зоопарк решений функционировал как единый комплекс, нужно:

1. Сформулировать требования к системе: какие данные хотим получить, как их использовать и чем управлять;
2. Изучить состояние существующей инфраструктуры здания и систем: архитектуру, состав, документацию, взаимодействие со смежными системами и способы взаимодействия;
3. Проработать решение по созданию единой системы, замене или доработке существующих локальных систем.

Заключение

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

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

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