`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Системы диспетчеризации здания

0 
 

Сегодня модно говорить об одной из концепций "умного дома", понимая под ней систему диспетчеризации здания. Однако ничего принципиально нового в таком подходе нет. Уже более десяти лет крупные общественные и коммерческие здания строят только "умными". Все возможные плюсы и минусы такого подхода, казалось бы, известны. Они проанализированы, систематизированы и практически перестали обсуждаться в среде специалистов. А что обсуждать? Открывай учебник и делай, как в примере двадцать один. Но, тем не менее, крупные компании продолжают вкладывать огромные средства в исследования. Над какими проблемами бьются их инженеры? Нам неизвестно. Позволим себе предположить...

На чем строились догадки?

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


Догадка # 1. Строить из кубиков? А у кого покупать кубики?

Системы диспетчеризации зданияПрактически все поставщики систем автоматизации и диспетчеризации зданий предлагают трехуровневую структуру "низовые элементы -- контроллеры -- рабочее место оператора" (рисунок).

Если говорить о связи "низовые элементы -- контроллеры", то здесь все просто. Сигналы типа "сухого контакта", тока 4--20 мА, напряжения 0--10 В постоянного тока; терморезисторы Pt1000 или Ni1000; остальное -- экзотика. Использование низовых элементов одного производителя с контроллерами другого вполне возможно и не так редко встречается на практике.

Связь "контроллер -- рабочее место оператора" и "контроллер--контроллер" пока не унифицирована. Наиболее широко применяются двухпроводные полевые шины с закрытыми, являющимися собственностью поставщика, протоколами. Наличие технологии OPC (стандартный интерфейс драйверов к ПО рабочего места оператора) ненамного упрощает жизнь. Чтобы интегрировать контроллеры производителя "А" в систему производителя "В", нужно осуществлять дополнительные закупки и у "А" (ПО OPC-сервера), и у "В" (ПО OPC-клиента, расширение лицензии и т. д. и т. п.). При этом на практике гарантии не дают ни "А", ни "В"! Задача же передачи данных с контроллера от производителя "А" в контроллер от производителя "В" вообще не решается.

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

Протокол полевой шины LON (LonTalk) является интеллектуальной собственностью Echelon. Исполь-зование данного протокола на практике основано на применении разработчиком всего пакета интеллектуальной собственности этой компании, включающего как средства аппаратной поддержки (однокристальная реализация шести уровней модели OSI -- чип NEURON), так и программный инструментарий (например, кросс-трансляторы языка Neuron-C). Такой подход позволяет если не гарантировать отсутствие "подводных камней" при объединении устройств от различных производителей, то, по крайней мере, перевести 80% трудностей, традиционных для данного класса задач, в категории тривиальных и "шаблонно решаемых".

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

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

Пересылка данных "контроллер--контроллер" описывается как связь LON-выхода одного контроллера с LON-входом другого контроллера. Для пересылки данных "контроллер -- рабочее место оператора" всегда доступны все LON- входы, выходы и параметры.

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

На сегодняшний день практически все поставщики систем автоматики и диспетчеризации предлагают не только контроллеры, но и датчики и исполнительные механизмы с поддержкой LON. Шина LON постепенно распространяет "зону влияния" от высоких уровней ("контроллер -- рабочее место оператора" и "контроллер--контроллер") до, в -некоторых случаях, уровня "низовые элементы -- контроллер". Такой переход от систем со звездообразной топологией на основе шлюзов к системам, построенным на базе единой полевой шины, может сократить потребности в кабеле. По сути последнее означает, что широкое внедрение унифицированных шин (таких, как LON) ведет не только к унификации решений и взаимозаменяемости оборудования различных поставщиков, но и, возможно, к уменьшению стоимости системы в целом.


Догадка # 2. Крупноблочное строительство

Применение LON, без сомнения, улучшает "интеграционные" показатели проекта. Это быстро развивающаяся технология, которая, судя по всему, составит сильную конкуренцию не только прочим открытым, но и многим закрытым протоколам полевых шин. Но и у нее есть один недостаток. Так, связь между разнородными системами получается "слишком сильной". Отсутствуют механизмы ограничения прав доступа. Объе-ди-нение устройств, относящихся к различным подсистемам "умного дома" (в частности, безопасности и обеспечению комфорта), не только не приветствуется, а иногда и напрямую запрещается действующими нормами.

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

BACnet -- это открытый высоко-уровневый протокол, не претендующий на использование на низких уровнях полевых шин (хотя такое применение и допускается). Задача BACnet -- стандартизация взаимодействия систем. В отличие от LON в BACnet оговариваются процедуры ограничения прав доступа, а также синхронизации календарей, расписаний, предусмотрены различные механизмы передачи тревожных сообщений, но практически не рассматриваются методы защиты от ошибок приема, режимы приемопередатчиков и другие особенности работы канала связи -- дело в том, что основные "шинные уровни" BACnet предусматривают самостоятельную и независимую реализацию всех этих деталей.

Достоинства BACnet демонстрируются следующим примером алгоритмизированного проектного процесса:
  1. Берем мультизонную систему кондиционирования (например, Daikin, Mitsubishi, Carier или иную). Главное, не забыть заказать в ее составе BACnet gateway.
  2. Система пожарной сигнализации Honeywell или Notifier c ее BACnet gateway.
  3. Насосные станции Grundfos, холодильные машины McQuay, котельные Wiessmann.
  4. Основные поставщики систем автоматики и диспетчеризации поддерживают BACnet в своих продуктах ничуть не в меньшей степени, чем LON или свои собственные протоколы.
  5. Объединяем BACnet gateway в локальную сеть Ethernet TCP/IP. Согласуем политику безопасности. Включаем и... все! Полная информация, необходимая для настройки передачи данных из системы в систему и для настройки рабочего места оператора, доступна в режиме online. Все уже работает.
Благодаря применению современного протокола интеграции систем мы получаем сочетание разумной "изоляции" разнородных систем при полном сохранении гибкости обмена данными, настроек и модификаций.


Догадка # 3. Связывать кабелем или все-таки СКС?

И LON, и BACnet поддерживают в качестве транспорта TCP/IP. Терминал-серверы (преобразователи последовательных портов в Ethernet), которые могут быть применены для перехода с полевых шин в ТСР/IP, дешевеют. Цифровое видео повсеместно вытесняет аналоговое. А раз так, то не грех использовать для передачи данных TCP/IP, Ethernet и СКС, а это совершенно иной уровень качества.

Учитывая требования к полосе пропускания со стороны подсистем видеонаблюдения, для передачи данных с этажа на этаж (вертикальная связь) логично использовать оптоволокно. Оптоволоконный "хребет" может работать в режиме VPN совместно с офисной LAN и телефонной сетью. Применение оптоволоконного "хребта" с высокой надежностью и пропускной способностью позволит вынести серверы в ферму, даже если они принадлежат разным организациям (например, арендаторам). Это значительно увеличивает надежность, удешевляет эксплуатацию здания в целом и вообще "правильно"!


Догадка # 4. Рабочее место диспетчера? Диспетчер на каждом рабочем месте!

Далеко не все действия человека в системе диспетчеризации производятся с рабочего места диспетчера. В типовой системе мы увидим большое количество пультов корректировки заданной температуры, пультов постановки/снятия с охраны, домофонов. Эти пульты очень часто оказываются за шкафом (в буквальном смысле) или на перегородке, которую новый арендатор желал бы убрать. А это -- перетяжка кабеля, переподключение, переналадка, а иногда и вообще серьезные ремонтно-строительные работы!

Трудно представить себе какое-либо рабочее место в современном офисе без персонального компьютера, подключенного в LAN. Почему бы не убрать все эти пульты, а органы управления выполнить в виде программы, а еще лучше -- Web-странички, загружаемой с любого компьютера?

Web-сервер вполне может быть частью ПО контроллера (компания Honeywell, например, уже предлагает такие контроллеры) или ПО рабочего места диспетчера (также не является фантастикой). Если дать арендатору доступ к управлению "его автоматикой", то он сможет не только изменять заданные температуры в помещениях, но и корректировать расписания режимов "дневной/ночной", обеспечивая дополнительное энергосбережение, не только ставить/снимать с охраны, но и вносить своих новых сотрудников в списки доступа в помещения офиса и через центральную проходную, сняв административную нагрузку с диспетчера, рассматривать своих визитеров в домофон с рабочего места своего сотрудника и многое другое.

Вот так попытка удешевить решение может привести к скачку функциональности.


Догадка # 5. А что вы слышали о ERP-системах?

Вопрос: Как в типовой системе диспетчеризации задается время перехода системы кондиционирования в пониженный, экономичный режим?

Ответ: С определенным запасом по отношению к началу и окончанию рабочего дня. Это как минимум на один час больше, чем реально требуется.

А насколько сложно вычислять необходимое время смены режима автоматически, на основании данных из системы контроля доступа? Это достаточно просто, если возможен обмен данными между подсистемами кондиционирования и контроля доступа.

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

Вопрос: Как в современной системе диспетчеризации производится техническое обслуживание инженерного оборудования?

Ответ: С определенной периодичностью, в соответствии с графиком сервисного обслуживания.

А как составлялся график сервисного обслуживания? Если и не на основе "справочника Стеля", то все равно весьма приблизительно. Мы знаем, что в современной системе диспетчеризации достаточно просто организовать подсчет реальной наработки двигателей насосов, вентиляторов и других исполнительных механизмов, а по ним возможно прогнозирование засорения фильтров, смены картриджей и проведения инспекций.

Налицо возможность дополнительной экономии.

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


Догадка # 6. А кто будет все это проектировать? Пусть этим займутся программы!

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

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

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

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

Функционирует это так:
  1. При подготовке коммерческого предложения пользователь программы "собирает" из блоков структурную схему системы и функциональные схемы автоматизации, внося в соответствующих полях описательную информацию. На основании включенных в эти документы данных автоматически генерируются спецификации оборудования, описания функций, принципиальные электрические схемы, схемы внешних проводок и другие документы в форме, отвечающей европейским нормам оформления проектной документации. Безусловно, для этого нужна база данных типовых укрупненных узлов, и в пакет она включена. Правда, пока только оборудования, производимого компанией для систем управления кондиционированием, тепло- и холодоснабжением, но у пользователя есть возможность са-мо-стоятельно дополнять и расширять БД.
  2. При работе над проектом удаление/добавление блоков в структурных и функциональных схемах автоматически приводит к пересчету всех связанных, автоматически генерируемых документов. Случай, когда изменения были "забыты", исключается. Также, напомню, в базу данных пользователь может вносить модифицированные блоки, учитывающие особенности применения или пожелания заказчика.
  3. По мере выполнения монтажных работ достаточно выставить отметки готовности этапов, и программа автоматически сгенерирует смету и спецификацию.
  4. Транслятор программ для контроллеров не входит в этот пакет, но на основании автоматически подготовленных данных получение готовой к загрузке программы производится парой щелчков мыши.
  5. Настройки программного обеспечения рабочего места оператора также формируются автоматически. Достаточно просто скопировать соответствующие файлы на его компьютер.
Пока этот пакет ориентирован на оборудование только одного крупного поставщика. И при этом БД пакета включает далеко не полный его перечень. Возможно, в ближайшем будущем задачу пополнения базы данных решат традиционным способом -- стандартизацией формата и online-распространением обновлений.

От редакции:
автор статьи является инженером
проекта компании Honeywell

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

0 
 

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT