ТЕНДЕНЦИИ И ЗАДАЧИ НА БУДУЩЕЕ ДЛЯ АСУ ЗДАНИЙ
Технические средства должны как можно полнее удовлетворять потребности бизнесциклов при условии снижения затрат на эксплуатацию и обслуживание. Ограниченность бюджета и проблемы охраны окружающей среды повышают требования к управлению энергопотреблением. Растущие запросы по комфорту и сервису приводят к необходимости совершенствовать средства управления. У каждого предприятия имеются собственные уникальные требования к оборудованию зданий. При этом решающее значение имеет выбор правильного технического решения системы управления.

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

Ниже приводится перечень обычных требований заказчиков:

Снижение первоначальных затрат.

Использование в АСУ здания существующей инфраструктуры информационных и коммуникационных систем.

Единый пользовательский интерфейс для управления всеми инженерными системами здания (ОВК, освещение, лифты, пожарная сигнализация, доступ и др.).

Независимымость от поставщиков на случай будущей реконструкции системы.

Снижение затрат на эксплуатацию, обслуживание и энергоснабжение.

Мобильное управление зданием в любое время, из любого места, без задержек.

Малоквалифицированный персонал выдвигает требование «очевидного» (интуитивно понятного) управления.

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

Возрастающие требования по комфорту и сервису.

Снижение энергопотребления.

БАЗОВЫЕ ТЕХНОЛГИИ
Системные стандарты для АСУ зданий
Основные затраты связаны с усилиями, направленными на создание полномасштабной автоматической системы управления зданием. Стоимость системы находится в прямой зависимости от типа и количества выполняемых функций. Точки ввода/вывода обеспечивают только прием или подачу сигналов. Чтобы избежать ненужного риска на этапах заключения договора, его выполнения и оплаты, необходимо пользоваться стандартной терминологией. Свободная и честная конкуренция м. подрядчиками, в том числе внедряющими новые решения, возможна только в случае использования единого языка для всех участников. В CEN/TC247WG3 разработан ряд стандартов для общепонятного описания оборудования и его функциональности. Такое описание функций помогает, в том числе при системной интеграции, определить задачи каждой системы и подсчитать затраты на установку систем. Эта работа была принята соответствующей комиссией ISO–TC205.

Коммуникационные стандарты для АСУ зданий
Стандартные коммуникационные протоколы, такие как BACnet, EIB/KNX, LONMARK и др., и стандартные интерфейсы типа OPC (OLE для контроля технологических циклов) позволяют обеспечить согласованный обмен информацией м. устройствами, программами и системами разных производителей. Коммуникационные стандарты являются необходимым предварительным условием для эффективной и недорогой интеграции подсистем от различных поставщиков.

Современное состояние IT и вебтехнологий
Информационная техника (IT) и вебтехнологии широко применяются в АСУ зданий. Это позволяет обеспечить «плавный» (без потерь) обмен данными м. АСУ офиса и бизнесциклами. При этом могут быть использованы существующие инфраструктуры, такие как LAN/WAN (локальная и расширенная компьютерные сети), что позволяет сократить расходы на прокладку кабелей и открывает принцип. возможность для более гибких решений. Вебтехнология дает дополнительные преимущества – удобство поддержки и обновления программного обеспечения в центре при использовании простых и недорогих клиентских рабочих мест (требуется только интернетбраузер). Вот некоторые из самых значимых ITтехнологий: Ethernet, TCP/IP, Int@net, Web, OLE/COM, XML, SOAP.

СТАНДАРТЫ: ЧТО? ГДЕ? ПОЧЕМУ?
Эффективно – значит выгодно
Комплексная система управления позволяет повысить эффективность и упростить обслуживание здания, что означает снижение расходов и рост прибылей. Вместо использования ряда специализированных устройств группа эксплуатации здания может выполнять все действия на операторских рабочих местах с единым оформлением, при этом затраты на обуч. и подготовку сводятся к минимуму, также снижается вероятность ошибочных действий. Противопожарные и охранные системы, разумеется, посылают сигналы бригадам пожарников и охранников. Однако, если информация обо всех инженерных системах здания сводится на одно или несколько операторских рабочих мест, объединенных локальной сетью с однотипным пользовательским интерфейсом, то сигналы о неполадках и авариях могут быть обнаружены и обработаны без задержки, и это будет способствовать лучшей защите людей и имущества.

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

Объединение различных концепций затруднительно, требует значительных затрат времени и энергии. Это вряд ли оправдывается для единичного внедрения!

При разграничении зоны ответственности и при отсутствии координации изменений в подсистемах возникают фактически непреодолимые трудности для системной интеграции.

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

расширить функциональные возможности интегрированных систем!

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

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

ЧТО ДОЛЖНО БЫТЬ РЕШЕНО С ПОМОЩЬЮ ОТКРЫТЫХ КОММУНИКАЦИОННЫХ СТАНДАРТОВ ДЛЯ АСУ ЗДАНИЙ?
Хотелось бы остановиться на некоторых концептуальных моментах, которые следует принимать во внимание при выборе протокола для АСУ зданий.

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

Данные. Обработка как простых, так и сложных структур данных, необходимых для текущей работы, а именно:

Обмен данными м. устройствами.

Мониторинг и управление вводом, выводом, настройкой, аварийной сигнализацией.

Планирование по времени.

Группировка/перегруппировка в режиме online.

Отслеживание направления изменения данных /ведение архива.

Резервное копирование/восстановление.

Доступ к данным должен быть объектноориентированным.

Службы. Наличие служб для старта системы, работы в сети и резервного копирования/восстановления.

Линии связи. принцип. возможность независимой работы с различными типами линий связи, в соответствии с современными сетевыми стандартами и кабельными системами, используемыми в IT&CT.

Развитие. Наличие возможности расширения для последующих обновлений.

***

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

BACnet ПРОТИВ LonMark
Если мы приложим вышеупомянутые критерии к системам BACnet и LonMark, то получим данные, приведенные в табл. А.

LonMark
Мы говорим о LonMark, так как протокол LonTalk® является собственным продуктом корпорации Echelon Inc и входит в состав их семейства программных продуктов LonWorks®. Предопределенные шаблоны LonMark обеспечивают функциональность для устройств, устанавливаемых на объекте: обмен данными и взаимодействие м. устройствами на одной сборной шине, мониторинг текущего состояния параметров, таких как температура и простые функции управления, например, включить и выключить свет и т. п. Устройство для выполнения этих функций выполнено на одном чипе (транссиверы Neuron® и LonWorks® работают с различными типами линий связи, в том числе с недорогими кабелями кат. 4.) Кроме того, имеется сравнительно большое число изготовителей (около 18 , среди которых можно выбрать поставщика для оборудования зданий, но возможности продукта с точки зрения взаимодействия с другими должныбыть проверены системным интегратором. Все это позволяет считать продукты на базе LonWorks перспективными для использования в местных сетях, на уровне объекта. Но «обычные» датчики и регуляторы дешевле – даже если не принимать в расчет стоимость всей системы и ее проектирования.

EIB/KONNEX
Применение стандартного и международно признанного протокола для конкретного объекта так же не гарантирует, что устройство изготовителя А может быть заменено устройством изготовителя Б. Для этого необходима дальнейшая стандартизация конструкции и функций устройств. Шаг в этом направлении был сделан в концепции EIB для применения в зданиях. Каждое из более 5 000 устройств EIB поставляется вместе с дискетой, содержащей соответствующие данные для параметризации, которые могут быть использованы нейтральным программным средством ETS фирмы EIBA (продано 11 000 лицензий) – в комбинации, определяемой пользователем (EIBA – Европейская ассоциация по монтажу каналов связи; Брюссель, Бельгия). Работают 65 сертифицированных учебных центров и 15 национальных организаций EIBA. По всему миру выполнено более 70 000 проектов.

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

Коммуникационный протокол EIB входит в состав стандарта ANCI EIA 776.15 и включает CEBus – трассировщик EIB.

ASHRAE (Американское общество инженеров по отоплению, охлаждению и кондиционированию воздуха) присвоило EIB уникальный идентификатор (ID) поставщика для BACnet. Этот ID поставщика должен быть использован при встраивании устройств EIB в BACnet. В документе ISO/TC205 WG3, приложение H.5 (проектирование АСУ зданий), описано распределение в объектной модели BACnet функциональных блоков EIB, которые входят в спецификацию объектов интерфейса межсетевой модели EIS (межсетевой стандарт EIBA), согласно определению EIBA.

В соответствии с проектом слияния три европейские ассоциации EIBA, BCI, EHSA в марте 2001 года объединились в ассоциацию Konnex, а протоколы «EIB», «BatBus» и «ENS» превратились в протокол «KNX» (Konnex).

BACnet
В большинстве других протоколов с целью обеспечения открытости и совместимости некоторая часть функций АСУ зданий опущена. Это такие функции, которые необходимы для развитых систем управления зданием: «выявление тенденций/архив», «планировка по времени», «резервное копирование/восстановление», «телеуправление», «распределение аварийных сигналов» и др. BACnet решает все эти задачи. Кроме того, BACnet поддерживает, с достаточной гибкостью, современную сетевую технологию IT, например, Ethernet и IP (Интернетпротокол), так как это необходимо в настоящее время в условиях широкого использования информационных технологий.

BACnet является наилучшим выбором для систем верхнего уровня, которым требуется широкая функциональность и полная ITсовместимость.

ЕВРОПЕЙСКАЯ СТАНДАРТИЗАЦИЯ
После того как мы проанализировали основные положения, на основе которых принимается решение о выборе того или иного стандартного протокола для АСУ здания, надо посмотреть на положение дел со стандартизацией а Европе, так как здесь открытые коммуникационные системы появились раньше, чем гделибо еще. Внедрение началось в Германии в 1984 году с протокола IBM FACN, за ним последовал FND в 1987 году.

Как мы видим, здесь использован не единственный коммуникационный стандарт – для каждого «уровня функциональности» системы есть набор различных стандартных протоколов с разной функциональностью и своими преимуществами. Поскольку в начале цикла стандартизации (1990 г.) существовало более 20 различных протоколов, было решено сократить их количество до трех на каждый функциональный уровень. На рисунке вверху показан результат если не компромисса, то консенсуса. К счастью, экспериментальные стандарты принимаются не более чем на 5 лет, затем они должны пересматриваться. FND был отменен как стандарт в 2001 году, но он все так же есть как «частный» документ. Эксперты в CEN решили, что отношение к остальным протоколам будет складываться в зависимости от отношения к ним на рынке.

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

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

На уровне объекта (местные устройства) потенциалом развития обладают как EIB/KNX, так и LonMark. EIB, BATibus и EHS близки к тому, чтобы превратиться в единый новый стандарт: KONNEX (KNX), EIBA присоединилась к ассоциации Konnex, включающей более сотни изготовителей с более чем семью тысячами наименований выпускаемых продуктов.

LonMark хорошо приспособлен для применения на уровне объекта, при достаточно сложных местных устройствах и ограниченных требованиях к гибкости компоновки системы.

KONNEX (KNX) будет оптимальным для стандартных решений – эффективен по затратам, прост и удобен для монтажа.

МЕЖДУНАРОДНАЯ СТАНДАРТИЗАЦИЯ
АСУ зданий находится в ведении комитета WG3 ISO/TC205 «Проектирование окружающей среды зданий». Сюда включено аппаратное обеспечение, функциональность, приложения, коммуникации, тестирование, проектирование и монтаж систем. есть только один протокол без привязки к определенному уровню: BACnet как ANSI/ASHRAE 135.

Ожидается, что функциональные блоки EIB/KONNEX, которые являются частью спецификации объектов интерфейса EIB, войдут в спецификацию BACnet в сочетании с объектами BACnet. Кроме того, планируется в 2002 году провести первый международный опрос – документ для голосования, подготовленный сентябрьским совещанием 2001 года, был задержан изза ограничений на поездки. Опрос ISO будет проведен параллельно среди европейских стран, так что в результате можно ожидать, что у нас будет один стандартный протокол для АСУ зданий.

BACnet, EIB/KNX, LonMark и др.
– ЧТО ГДЕ ИСПОЛЬЗОВАТЬ
Итак, что где применять? Принимая во внимание все вышеизложенное, картина становится яснее. Для АСУ рабочих помещений, когда установлено множество регулирующих устройств, связанных м. собой и взаимодействующих, – EIB/KNX, позволяющее мастеру принимать решение на месте, LonMark – для более сложных инженерных систем. И то и другое является недорогим эффективным решением, обеспечивающим необходимые функции.

Для машинных залов требуемая функциональность шире – этим требованиям в наибольшей степени отвечает стандарт BACnet. Для BACnet так же, как и для других систем, необходимо выбирать наиболее эффективные по физическим характеристикам линии связи. Для задач управления в дополнение к высокой функциональности BACnet нам необходимы средства IT, так что здесь требуемые задачи будут решены с помощью BACnet на Ethernet/IP.

ОРС – НОВАЯ АЛЬТЕРНАТИВА?
ОРС, т. е. «OLE для регулирования технологических циклов», коммуникационный стандарт на базе OLE/COMтехнологии, который дает такие же преимущества для программных и аппаратных средств управления промышленными циклами, как применение стандартного драйвера принтера для текстового редактора.

Основанная на технологиях Microsoft OLE, COM (объектная модель компонентов) и DCOM (распределенная объектная модель), ОРС состоит из стандартных интерфейсов, свойств и методов, предназначенных для использования в АСУ технологических циклов (АСУ ТП).

Технологии OLE/COM определяют, каким образом отдельные стандартные компоненты могут взаимодействовать и совместно использовать данные. ОРС обеспечивает стандарт взаимодействия для производственной автоматики, когда каждая система и каждый драйвер коммуникационных сетей может действовать свободно (устанавливать связи). При наличии такого стандарта связь и взаимодействие м. различными системами, от заводских до офисных систем управления, становятся более простыми и открытыми.

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

НЕКОТОРЫЕ АКТУАЛЬНЫЕ ЗАДАЧИ ПОЛЬЗОВАТЕЛЕЙ, РЕШАЕМЫЕ С ПОМОЩЬЮ ВЕБТЕХНОЛОГИЙ
Вебтехнологии присутствуют фактически везде. Интернет предоставляет следующие возможности, которые можно использовать в АСУ зданий:

Глобальная связь.

Обеспечение международных корпораций информацией по управлению зданиями на всех территориях.

Простота пользования.

Доступ в любое время, отовсюду, немедленно.

Использование наиболее прогрессивных технологий.

Совместимость с информационными системами.

Простое и недорогое программное обеспечение для клиентов.

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

ВСТРОЕННЫЙ ВЕБСЕРВЕР ПРОТИВ СЕРВЕРА ПРИЛОЖЕНИЙ
Вебтехнология может быть встроена фактически в любое устройство, начиная от малых систем с DDCконтроллерами до больших серверов приложений. Будем ли мы в дальнейшем нуждаться в обычных станциях управления или их полностью вытеснят встроенные системы?

Давайте посмотрим, где функциональность АСУ зданий может быть реализована при помощи вебтехнологий (рисунок внизу).

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

Встроенные вебсистемы и серверы приложений взаимно дополняют друг друга. Функциональность и управление данными распределяются по автономным серверам в сетях интранет/интернет.

СЕРВЕР ПРИЛОЖЕНИЙ — ЦЕЛЕВЫЕ ГРУППЫ
Серверы приложений будут обращаться к следующим целевым группам.

Сервер приложений – решения
Этот сервер в основном поддерживает следующие технические и технологические решения:

ОБЩАЯ АРХИТЕКТУРА СИСТЕМЫ
В традиционных станциях управления на основе MS Windows бизнеслогика и представление реализованы на едином аппаратном средстве, обычно на персональном компьютере. В современных вебтехнологиях бизнеслогика и слой представлений разделены. Для просмотра и текущей работы необходим только интернетбраузер, который установлен на множестве клиентских рабочих мест. Ядро системы с бизнеслогикой, где имеются функции маршрутизации аварийных сигналов, архив данных/отслеживание тенденций и др., реализовано на выделенной машине – сервере приложений.

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

Для хранения технологических и конструкторских данных на управленческом уровне используются стандартные СУБД, предпочтительно ведущие ITстандарты SQL/MSDE.

ВЫТЕСНИТ ЛИ ВЕБТЕХНОЛОГИЯ BACnet?
Коммуникационный протокол м. вебсервером и клиентом использует ведущие интернеттехнологии для конечных пользователей HTML, DHTML, XML, SOAP, NETframework. Эти стандарты IT оптимизированы для специфических задач: передавать данные, необходимые для представления от «толстых» клиентов (нагруженных программным обеспечением) к «тонким» (простым) клиентам через сетевые брандмауэры по сетям интранет/интернет.

Для связи м. подсистемами и сервером приложений необходима дополнительная функциональность АСУ – архив данных/отслеживание тенденций, обработка аварийной сигнализации, планирование и т. п. Здесь правильным выбором будет BACnet. Только BACnet в настоящее время предоставляет эту функциональность в открытом стандартном формате, обеспечивая взаимодействие м. различными системами. Поэтому нам необходимы и BACnet, и Интернет!

ВЫВОДЫ
В дальнейшем будут развиваться нейтральные, функциональноориентированные АСУ зданий, основанные на международных стандартах.

Частные коммуникационные протоколы утратят значимость.

В будущем останется ограниченное количество стандартов в области коммуникаций и интерфейсов.

В качестве протоколов хорошим потенциалом обладают BACnet, EIB/KNX, LonMark , в качестве метода – ОРС.

Вебтехнология будет использоваться на уровне эксплуатации.

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

Сетевые технологии с весьма хорошим потенциалом на будущее: HTML, DHTML, XML, SOAP, NETframework.

BACnet, ОРС и Интернет – это взаимно дополняющие друг друга технологии.

Распределение функций – наилучшее решение для воспроизведения на каждом уровне.

Возрастающая интеграция всех технических решений для всех служб здания.

Решения «под ключ» от одного поставщика.

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

И не забудьте: мы попытались объяснить, в каком направлении развивается индустрия АСУ зданий, – но, как всегда, окончательное решение остается за рынком!