Сегодня модно говорить об одной из концепций "умного дома", понимая под ней систему диспетчеризации здания. Однако ничего принципиально нового в таком подходе нет. Уже более десяти лет крупные общественные и коммерческие здания строят только "умными". Все возможные плюсы и минусы такого подхода, казалось бы, известны. Они проанализированы, систематизированы и практически перестали обсуждаться в среде специалистов. А что обсуждать? Открывай учебник и делай, как в примере двадцать один. Но, тем не менее, крупные компании продолжают вкладывать огромные средства в исследования. Над какими проблемами бьются их инженеры? Нам неизвестно. Позволим себе предположить…
На чем строились догадки?
С одной стороны, реально находящееся в разработке оборудование — это
секрет (хотя бы потому, что не стоит упрощать жизнь конкурентам). С другой стороны,
анализ опыта внедрения крупных систем диспетчеризации и предлагаемого уже сейчас
оборудования позволяет увидеть общее направление развития индустрии, а не только
огласить технические характеристики очередного "торжества мысли".
Так можно разглядеть лес за деревьями.
Догадка # 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 демонстрируются следующим примером алгоритмизированного проектного
процесса:
Благодаря применению современного протокола интеграции систем мы получаем сочетание
разумной "изоляции" разнородных систем при полном сохранении гибкости
обмена данными, настроек и модификаций.
Догадка # 3. Связывать кабелем или все-таки СКС?
И LON, и BACnet поддерживают в качестве транспорта TCP/IP. Терминал-серверы
(преобразователи последовательных портов в Ethernet), которые могут быть применены
для перехода с полевых шин в ТСР/IP, дешевеют. Цифровое видео повсеместно вытесняет
аналоговое. А раз так, то не грех использовать для передачи данных TCP/IP, Ethernet
и СКС, а это совершенно иной уровень качества.
Учитывая требования к полосе пропускания со стороны подсистем видеонаблюдения,
для передачи данных с этажа на этаж (вертикальная связь) логично использовать
оптоволокно. Оптоволоконный "хребет" может работать в режиме VPN совместно
с офисной LAN и телефонной сетью. Применение оптоволоконного "хребта"
с высокой надежностью и пропускной способностью позволит вынести серверы в ферму,
даже если они принадлежат разным организациям (например, арендаторам). Это значительно
увеличивает надежность, удешевляет эксплуатацию здания в целом и вообще "правильно"!
Догадка # 4. Рабочее место диспетчера? Диспетчер на каждом рабочем месте!
Далеко не все действия человека в системе диспетчеризации производятся
с рабочего места диспетчера. В типовой системе мы увидим большое количество
пультов корректировки заданной температуры, пультов постановки/снятия с охраны,
домофонов. Эти пульты очень часто оказываются за шкафом (в буквальном смысле)
или на перегородке, которую новый арендатор желал бы убрать. А это — перетяжка
кабеля, переподключение, переналадка, а иногда и вообще серьезные ремонтно-строительные
работы!
Трудно представить себе какое-либо рабочее место в современном офисе без персонального
компьютера, подключенного в LAN. Почему бы не убрать все эти пульты, а органы
управления выполнить в виде программы, а еще лучше — Web-странички, загружаемой
с любого компьютера?
Web-сервер вполне может быть частью ПО контроллера (компания Honeywell, например,
уже предлагает такие контроллеры) или ПО рабочего места диспетчера (также не
является фантастикой). Если дать арендатору доступ к управлению "его автоматикой",
то он сможет не только изменять заданные температуры в помещениях, но и корректировать
расписания режимов "дневной/ночной", обеспечивая дополнительное энергосбережение,
не только ставить/снимать с охраны, но и вносить своих новых сотрудников в списки
доступа в помещения офиса и через центральную проходную, сняв административную
нагрузку с диспетчера, рассматривать своих визитеров в домофон с рабочего места
своего сотрудника и многое другое.
Вот так попытка удешевить решение может привести к скачку функциональности.
Догадка # 5. А что вы слышали о ERP-системах?
Вопрос: Как в типовой системе диспетчеризации задается время перехода
системы кондиционирования в пониженный, экономичный режим?
Ответ: С определенным запасом по отношению к началу и окончанию рабочего дня.
Это как минимум на один час больше, чем реально требуется.
А насколько сложно вычислять необходимое время смены режима автоматически, на
основании данных из системы контроля доступа? Это достаточно просто, если возможен
обмен данными между подсистемами кондиционирования и контроля доступа.
Этот и многие другие пути достижения дополнительной экономии энергии и повышения
комфортности за счет интеграции систем безопасности и инженерных систем хорошо
известны. Вопрос лишь только в том, что такая интеграция еще только-только пробивает
себе дорогу на рынок.
Вопрос: Как в современной системе диспетчеризации производится техническое обслуживание
инженерного оборудования?
Ответ: С определенной периодичностью, в соответствии с графиком сервисного обслуживания.
А как составлялся график сервисного обслуживания? Если и не на основе "справочника
Стеля", то все равно весьма приблизительно. Мы знаем, что в современной
системе диспетчеризации достаточно просто организовать подсчет реальной наработки
двигателей насосов, вентиляторов и других исполнительных механизмов, а по ним
возможно прогнозирование засорения фильтров, смены картриджей и проведения инспекций.
Налицо возможность дополнительной экономии.
Пути сокращения времени, затрачиваемого на обслуживание оборудования за счет
ресурсно-ориентированного графика, построение прогноза потребности в запасных
частях и сменных элементах, прочие свойства из области "планирования ресурсов"
(ERP) также хорошо известны, только находятся в несколько иной области —систем
обработки коммерческой информации. Интеграция с системами обработки коммерческой
информации, как и инженерных систем с системами безопасности, рано или поздно
будет востребована.
Догадка # 6. А кто будет все это проектировать? Пусть этим займутся программы!
Пока речь идет о концепциях, все очень просто и понятно, но как только
разговор перейдет в практическую плоскость, окажется, что в относительно небольшом
здании количество датчиков и исполнительных механизмов достигает тысяч. Перед
тем как предлагать заказчику что-либо, нужно все это просчитать. Прежде чем
приступить к монтажу оборудования, необходимо все согласовать с заказчиком и
смежниками, составить проект, а с учетом того, что и в процессе проектирования,
и по ходу монтажа неизбежно будут происходить изменения, картина мира окажется
не такой уж радостной.
Безусловно, сейчас уже никто из проектировщиков не стоит у кульмана, но и с
универсальными программами инженерной графики объем работы остается очень большим,
да и проблема не совсем в этом. Как показывает практика, одна и та же информация
(например, описание датчика, контроллера или алгоритма управления) дублируется
во многих документах без изменений.
Даже если не набирать все заново, а только копировать текст из одного документа
в другой, бесполезно уходят десятки часов рабочего времени. Напомню, речь идет
о тысячах строк текста.
Для упрощения и удешевления процесса проектирования предназначены специализированные
программные пакеты, например Honeywell Excel Toolkit. При соблюдении относительно
простых правил, применяя данный пакет, можно достичь состояния, когда переданные
заказчику на этапе коммерческого предложения схемы и спецификации автоматически
транслируются не только в проектную документацию, но и в программы для контроллеров,
инструкции по эксплуатации, файлы графических экранов и файлы настроек программного
обеспечения рабочего места оператора.
Функционирует это так:
Пока этот пакет ориентирован на оборудование только одного крупного поставщика.
И при этом БД пакета включает далеко не полный его перечень. Возможно, в ближайшем
будущем задачу пополнения базы данных решат традиционным способом — стандартизацией
формата и online-распространением обновлений.
От редакции:
автор статьи является инженером
проекта компании Honeywell