Применение стандартов информационных технологий в индустрии АСУ зданий
Необходимая «открытость» для пользователя системы автоматического контроля и управления оборудованием зданий (АСУ зданий) может быть обеспечена только в том случае, если в коммерческих предложениях и заказах будут использоваться нейтральные функциональные спецификации, основанные на определениях из международных стандартов, таких как ISO (FDIS) 16484.
Применение стандартов информационных
технологий в индустрии АСУ зданий
Необходимая «открытость» для пользователя системы автоматического контроля и управления оборудованием зданий (АСУ зданий) может быть обеспечена только в том случае, если в коммерческих предложениях и заказах будут использоваться нейтральные функциональные спецификации, основанные на определениях из международных стандартов, таких как ISO (FDIS) 16484. Однако такие спецификации или применение стандартных, международно признанных протоколов для конкретных решений все же не гарантируют, что устройство, изготовленное фирмой А, может быть заменено устройством, поставляемым фирмой Б. Для этого необходима дальнейшая стандартизация конструкций и функциональности устройств и систем.
Реферат
В статье представлены современные тенденции развития АСУ зданий. Исследовано влияние стандартных протоколов и веб-технологий, наиболее перспективные из них (по мнению автора) анализируются подробнее. Рассмотрен реальный статус различных стандартных протоколов в международных организациях по стандартизации. Изложена точка зрения автора на перспективы развития АСУ зданий в ближайшие несколько лет.
ТЕНДЕНЦИИ И ЗАДАЧИ НА БУДУЩЕЕ ДЛЯ АСУ ЗДАНИЙ
Технические средства должны как можно полнее удовлетворять потребности бизнес-процессов при условии снижения затрат на эксплуатацию и обслуживание. Ограниченность бюджета и проблемы охраны окружающей среды повышают требования к управлению энергопотреблением. Растущие запросы по комфорту и сервису приводят к необходимости совершенствовать средства управления. У каждого предприятия имеются собственные уникальные требования к оборудованию зданий. При этом решающее значение имеет выбор правильного технического решения системы управления.
Настало время изменить наш взгляд на управление оборудованием зданий. Только согласованная структура управления, в которой взаимодействуют различные системы, способна устранить все препятствия на пути к прогрессу. Общий интерфейс, открытость, системные стандарты, веб-технологии и интеграция – вот предпосылки успеха.
Ниже приводится перечень обычных требований заказчиков:
- Снижение первоначальных затрат.
- Использование в АСУ здания существующей инфраструктуры информационных и коммуникационных систем.
- Единый пользовательский интерфейс для управления всеми инженерными системами здания (ОВК, освещение, лифты, пожарная сигнализация, доступ и др.).
- Независимымость от поставщиков на случай будущей реконструкции системы.
- Снижение затрат на эксплуатацию, обслуживание и энергоснабжение.
- Мобильное управление зданием в любое время, из любого места, без задержек.
- Малоквалифицированный персонал выдвигает требование «очевидного» (интуитивно понятного) управления.
- Наличие центров технической поддержки, обслуживающих множество зданий в определенном территориальном районе.
- Возрастающие требования по комфорту и сервису.
- Снижение энергопотребления.
БАЗОВЫЕ ТЕХНОЛГИИ
Системные стандарты для АСУ зданий
Основные затраты связаны с усилиями, направленными на создание полномасштабной автоматической системы управления зданием. Стоимость системы находится в прямой зависимости от типа и количества выполняемых функций. Точки ввода/вывода обеспечивают только прием или подачу сигналов. Чтобы избежать ненужного риска на этапах заключения договора, его выполнения и оплаты, необходимо пользоваться стандартной терминологией. Свободная и честная конкуренция между подрядчиками, в том числе внедряющими новые решения, возможна только в случае использования единого языка для всех участников. В 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.
Коммуникационные стандарты IT и веб-технологий для АСУ зданий |
СТАНДАРТЫ: ЧТО? ГДЕ? ПОЧЕМУ?
Эффективно – значит выгодно
Комплексная система управления позволяет повысить эффективность и упростить обслуживание здания, что в свою очередь означает снижение расходов и рост прибылей. Вместо использования ряда специализированных устройств группа эксплуатации здания может выполнять все действия на операторских рабочих местах с единым оформлением, при этом затраты на обучение и подготовку сводятся к минимуму, также снижается вероятность ошибочных действий. Противопожарные и охранные системы, разумеется, посылают сигналы бригадам пожарников и охранников. Однако, если информация обо всех инженерных системах здания сводится на одно или несколько операторских рабочих мест, объединенных локальной сетью с однотипным пользовательским интерфейсом, то сигналы о неполадках и авариях могут быть обнаружены и обработаны без задержки, и это будет способствовать лучшей защите людей и имущества.
Предпосылки для системной интеграции
Устойчивая и надежная связь – одно из условий системной интеграции. Для того чтобы успешно реализовать эффективную интеграцию, протоколы и функции должны быть тщательно описаны. В случае интеграции систем от разных поставщиков совершенно необходимо согласование права и ответственности, координация действий. Тем не менее, при внедрении системной интеграции имеются практические ограничения:
- Объединение различных концепций затруднительно, требует значительных затрат времени и энергии. Это вряд ли оправдывается для единичного внедрения!
- При разграничении зоны ответственности и при отсутствии координации изменений в подсистемах возникают почти непреодолимые трудности для системной интеграции.
Для преодоления этих ограничений вырабатываются стандарты взаимодействия, в которых описываются базовые функции по обслуживанию систем ОВК, освещения, безопасности и т. д. Эти базовые функции, определенные как объекты, затем замещаются сервисными устройствами или системами с использованием сетей связи с соответствующими маршрутами, шлюзами и т. д. Интеграция будет успешной лишь в том случае, если стандартные протоколы используются повсеместно, в каждой системе. Это позволит избежать сложных преобразований и слишком большой потери функциональности. Стандартизация информации на этапе разработки, монтажа и сдачи систем в эксплуатацию также позволит снизить затраты, повысить надежность и
расширить функциональные возможности интегрированных систем!
Обычные области применения АСУ в зданиях: воздух, вода, освещение и солнцезащита, отопление, охлаждение, вентиляция, распределение энергии, охрана и безопасность, холодильники, внутренний транспорт и вспомогательные системы.
Интеграция играет ключевую роль в снижении эксплуатационных затрат и позволяет нам рассматривать обслуживание здания как единый процесс.
ЧТО ДОЛЖНО БЫТЬ РЕШЕНО С ПОМОЩЬЮ ОТКРЫТЫХ КОММУНИКАЦИОННЫХ СТАНДАРТОВ ДЛЯ АСУ ЗДАНИЙ?
Хотелось бы остановиться на некоторых концептуальных моментах, которые следует принимать во внимание при выборе протокола для АСУ зданий.
Привлекаемые к работе партнеры, решая, какой из стандартных протоколов отвечает выдвинутым условиям, должны рассмотреть различные вопросы. Главные из них приводятся ниже.
Данные. Обработка как простых, так и сложных структур данных, необходимых для текущей работы, а именно:
- Обмен данными между устройствами.
- Мониторинг и управление вводом, выводом, настройкой, аварийной сигнализацией.
- Планирование по времени.
- Группировка/перегруппировка в режиме on-line.
- Отслеживание направления изменения данных /ведение архива.
- Резервное копирование/восстановление.
Доступ к данным должен быть объектно-ориентированным.
Службы. Наличие служб для старта системы, работы в сети и резервного копирования/восстановления.
Линии связи. Возможность независимой работы с различными типами линий связи, в соответствии с современными сетевыми стандартами и кабельными системами, используемыми в IT&CT.
Развитие. Наличие возможности расширения для последующих обновлений.
***
Европейский комитет по стандартизации должен был рассмотреть и проанализировать более 100 пунктов для отбора протоколов, рекомендуемых в качестве стандартных.
Источник: Michael Newman, ASHRAE |
BACnet ПРОТИВ LonMark
Если мы приложим вышеупомянутые критерии к системам BACnet и LonMark, то получим данные, приведенные в табл. А.
LonMark
Мы говорим о LonMark, так как протокол LonTalk® является собственным продуктом корпорации Echelon Inc и входит в состав их семейства программных продуктов LonWorks®. Предопределенные шаблоны LonMark обеспечивают функциональность для устройств, устанавливаемых на объекте: обмен данными и взаимодействие между устройствами на одной сборной шине, мониторинг текущего состояния параметров, таких как температура и простые функции управления, например, включить и выключить свет и т. п. Устройство для выполнения этих функций выполнено на одном чипе (транссиверы Neuron® и LonWorks® работают с различными типами линий связи, в том числе с недорогими кабелями кат. 4.) Кроме того, имеется сравнительно большое число изготовителей (около 180), среди которых можно выбрать поставщика для оборудования зданий, но возможности продукта с точки зрения взаимодействия с другими должны быть проверены системным интегратором. Все это позволяет считать продукты на базе LonWorks перспективными для использования в местных сетях, на уровне объекта. Но «обычные» датчики и регуляторы дешевле – даже если не принимать в расчет стоимость всей системы и ее проектирования.
EIB/KONNEX
Применение стандартного и международно признанного протокола для конкретного объекта еще не гарантирует, что устройство изготовителя А может быть заменено устройством изготовителя Б. Для этого необходима дальнейшая стандартизация конструкции и функций устройств. Шаг в этом направлении был сделан в концепции EIB для применения в зданиях. Каждое из более 5 000 устройств EIB поставляется вместе с дискетой, содержащей соответствующие данные для параметризации, которые могут быть использованы нейтральным программным средством ETS фирмы EIBA (продано 11 000 лицензий) – в комбинации, определяемой пользователем (EIBA – Европейская ассоциация по монтажу каналов связи; Брюссель, Бельгия). Работают 65 сертифицированных учебных центров и 15 национальных организаций EIBA. По всему миру выполнено более 70 000 проектов.
В настоящее время рынок предъявляет такое разнообразие вариантов использования, что всеобъемлющая процедура тестирования едва ли экономически оправдана. Проводить тестирование проще и дешевле для менее сложных устройств (имеются в виду устройства EIB), уровень функциональности которых определен через «межсетевые стандарты». Функциональные блоки EIB не только описывают семантику функций на английском языке, но также определяют доступ к службам, ассоциированным с этими функциями. При этом используются начальные уставки регулирующих устройств.
Коммуникационный протокол EIB входит в состав стандарта ANCI EIA 776.1-5 и включает 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.
ОРС – связь стандартных протоколов и Microsoft |
ОРС – НОВАЯ АЛЬТЕРНАТИВА?
ОРС, т. е. «OLE для регулирования технологических процессов», коммуникационный стандарт на базе OLE/COM-технологии, который дает такие же преимущества для программных и аппаратных средств управления промышленными процессами, как применение стандартного драйвера принтера для текстового редактора.
Основанная на технологиях Microsoft OLE, COM (объектная модель компонентов) и DCOM (распределенная объектная модель), ОРС состоит из стандартных интерфейсов, свойств и методов, предназначенных для использования в АСУ технологических процессов (АСУ ТП).
Технологии OLE/COM определяют, каким образом отдельные стандартные компоненты могут взаимодействовать и совместно использовать данные. ОРС обеспечивает стандарт взаимодействия для производственной автоматики, когда каждая система и каждый драйвер коммуникационных сетей может действовать свободно (устанавливать связи). При наличии такого стандарта связь и взаимодействие между различными системами, от заводских до офисных систем управления, становятся более простыми и открытыми.
ОРС – что сюда не вошло?
ОРС не является новой стандартной коммуникационной шиной или универсальным протоколом; это определение взаимодействия, разработанное различными фирмами промышленной автоматики и Microsoft. Сложные структуры данных в ОРС пока не определены полностью, они зависят от конкретных приложений. В отношении драйверов решение также принимается поставщиком.
НЕКОТОРЫЕ АКТУАЛЬНЫЕ ЗАДАЧИ ПОЛЬЗОВАТЕЛЕЙ, РЕШАЕМЫЕ С ПОМОЩЬЮ ВЕБ-ТЕХНОЛОГИЙ
Веб-технологии присутствуют почти везде. Интернет предоставляет следующие возможности, которые можно использовать в АСУ зданий:
- Глобальная связь.
- Обеспечение международных корпораций информацией по управлению зданиями на всех территориях.
- Простота пользования.
- Доступ в любое время, отовсюду, немедленно.
- Использование наиболее прогрессивных технологий.
- Совместимость с информационными системами.
- Простое и недорогое программное обеспечение для клиентов.
Кроме того, веб-технология облегчает поддержку и обновление программного обеспечения, так как это делается централизованно. Последнее, но немаловажное обстоятельство – интернет предлагает новые сервисы и открывает новые возможности для бизнеса.
Актуальные задачи пользователя, решаемые с помощью веб-технологий |
ВСТРОЕННЫЙ ВЕБ-СЕРВЕР ПРОТИВ СЕРВЕРА ПРИЛОЖЕНИЙ
Веб-технология может быть встроена почти в любое устройство, начиная от малых систем с DDC-контроллерами до больших серверов приложений. Будем ли мы в дальнейшем нуждаться в обычных станциях управления или их полностью вытеснят встроенные системы?
Давайте посмотрим, где функциональность АСУ зданий может быть реализована при помощи веб-технологий (рисунок внизу).
Очевидно, для небольших простых прикладных задач, где функциональность сводится к управлению оборудованием по графику, подаче аварийных сигналов, выявлению простых тенденций и созданию отчетов, встроенных веб-серверов будет вполне достаточно. Для более сложных и/или распределенных систем, где есть централизованные функции, такие как навигация по рабочим местам, обработка диспетчером аварийных сигналов, оценка данных, оформление счетов, ведение статистики, информационная поддержка управления и т. п., необходим централизованный сервер приложений.
Встроенные веб-системы и серверы приложений взаимно дополняют друг друга. Функциональность и управление данными распределяются по автономным серверам в сетях интранет/интернет.
Рисунок (увеличить) Реализация функциональности АСУ зданий при помощи веб-технологий |
СЕРВЕР ПРИЛОЖЕНИЙ — ЦЕЛЕВЫЕ ГРУППЫ
Серверы приложений будут обращаться к следующим целевым группам.
Сервер приложений – решения
Этот сервер в основном поддерживает следующие технические и технологические решения:
Эксплуатация |
- Отчеты - Обработка аварийных сигналов - Оптимизация производства - Безопасность - Освещение - ОВК - Средства доступа - Системы автоматики по помещениям Обработка данных- Отчеты - Оценка энергетических показателей - Контроль потребления (сырья, энергоресурсов) - Оценка технологических параметров - Выявление тенденций - Оформление счетов - Оценка ошибок и регистрация работы систем Техническое обслуживание и специальные сервисы- Библиотеки приложений - Пользовательские решения и программы - Документация online - База знаний (информация о системных правилах, установках, допущениях и т. п.) - Информация о профилактическом обслуживании - Поддержка/горячая линия Платформа интеграции- Интеграция на уровне эксплуатации - Интеграция подсистем через стандартные коммуникационные протоколы и интерфейсы (BACnet, EIB/KNX, LONMARK, OPC…) - Обмен данными между бизнеспроцессами пользователя, оборудованием офиса и т. д. |
ОБЩАЯ АРХИТЕКТУРА СИСТЕМЫ
В традиционных станциях управления на основе MS Windows бизнес-логика и представление реализованы на едином аппаратном средстве, обычно на персональном компьютере. В современных веб-технологиях бизнес-логика и слой представлений разделены. Для просмотра и текущей работы необходим только интернет-браузер, который установлен на множестве клиентских рабочих мест. Ядро системы с бизнес-логикой, где имеются функции маршрутизации аварийных сигналов, архив данных/отслеживание тенденций и др., реализовано на выделенной машине – сервере приложений.
Технологические данные в реальном времени обрабатываются специализированными DDC-контроллерами, оптимизированными для управления различными системами в зданиях.
Для хранения технологических и конструкторских данных на управленческом уровне используются стандартные СУБД, предпочтительно ведущие IT-стандарты SQL/MSDE.
Рисунок (увеличить) Общая архитектура системы |
ВЫТЕСНИТ ЛИ ВЕБ-ТЕХНОЛОГИЯ BACnet?
Коммуникационный протокол между веб-сервером и клиентом использует ведущие интернет-технологии для конечных пользователей HTML, DHTML, XML, SOAP, NET-framework. Эти стандарты IT оптимизированы для специфических задач: передавать данные, необходимые для представления от «толстых» клиентов (нагруженных программным обеспечением) к «тонким» (простым) клиентам через сетевые брандмауэры по сетям интранет/интернет.
Для связи между подсистемами и сервером приложений необходима дополнительная функциональность АСУ – архив данных/отслеживание тенденций, обработка аварийной сигнализации, планирование и т. п. Здесь правильным выбором будет BACnet. Только BACnet в настоящее время предоставляет эту функциональность в открытом стандартном формате, обеспечивая взаимодействие между различными системами. Поэтому нам необходимы и BACnet, и Интернет!
Рисунок (увеличить) АСУ – основа для технического управления зданием |
ВЫВОДЫ
- В дальнейшем будут развиваться нейтральные, функционально-ориентированные АСУ зданий, основанные на международных стандартах.
- Частные коммуникационные протоколы утратят значимость.
- В будущем останется ограниченное количество стандартов в области коммуникаций и интерфейсов.
- В качестве протоколов хорошим потенциалом обладают BACnet, EIB/KNX, LonMark , в качестве метода – ОРС.
- Веб-технология будет использоваться на уровне эксплуатации.
- Как встроенные серверы, так и серверы приложений будут играть значительную роль для обеспечения распределенной функциональности и управления данными в географически протяженных сетях.
- Сетевые технологии с очень хорошим потенциалом на будущее: HTML, DHTML, XML, SOAP, NET-framework.
- BACnet, ОРС и Интернет – это взаимно дополняющие друг друга технологии.
- Распределение функций – наилучшее решение для воспроизведения на каждом уровне.
- Возрастающая интеграция всех технических решений для всех служб здания.
- Решения «под ключ» от одного поставщика.
- Провайдеры серверов приложений будут предлагать новые пути оптимизации эксплуатации и управления зданием.
И не забудьте: мы попытались объяснить, в каком направлении развивается индустрия АСУ зданий, – но, как всегда, окончательное решение остается за рынком!
Статья опубликована в журнале “АВОК” за №4'2002
Статьи по теме
- Автоматизированные системы коммерческого учета, производства, распределения и потребления
Энергосбережение №6'2006
Подписка на журналы