Инженерно-технический центр «МИКС»

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

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

Если говорить о связи "низовые элементы -- контроллеры", то здесь все просто. Сигналы типа "сухого контакта", тока 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) ведет не только к унификации решений и взаимозаменяемости оборудования различных поставщиков, но и, возможно, к уменьшению стоимости системы в целом.

Применение 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. Все уже работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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