Лучшие методики взаимодействия открытых систем на BACnet

Дэвид Фишер, президент компании PolarSoft Inc. - разработчик программного обеспечения для BACnet, оказывающей консультационные услуги и проводящей обучение. Автор статьи являлся членом комитета ASHRAE-135P и активно принимал участие в развитии протокола BACnet с момента его появления.

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

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

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

Но легко сказать: "Я хочу открытую систему" и далеко непросто обеспечить такое взаимодействие. В этом случае Вам придется делать определенный выбор и закладывать возможность взаимодействия систем при проектировании и спецификации оборудования. Описывая способность к взаимодействую системы, в которой Вы нуждаетесь, Вы также можете пользоваться подходом "отталкиваясь от самой низкой себестоимости" и остановиться на некотором уровне управления взаимодействием подсистем, ежедневных операциях и уровне поддержки всей системы.

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

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

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

На моей практике самая лучшая попытка стандартизировать открытые системы и технологии - это международный стандарт ISO 16484-5, более известный как стандарт ANSI/ASHRAE 135-2008 "BACnet - протокол обмена данными для автоматизации зданий и систем управления". Данный стандарт содержит определения, известные как BIBBs (BACnet Interoperability Building Blocks - BACnet блоки совместной работы систем здания). Эти определения (BIBBs) успешно применяются при проектировании и спецификациях открытых систем. Так как способность к взаимодействию частей системы автоматизации может зависеть от десятков или даже сотен стандартных действий различных типов, и некоторые экспертные организации требуют более детально описывать комплексную модель автоматизации здания.

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

Вот несколько причин, почему методологии по взаимодействию открытых систем на BACnet стоят того, чтобы вкладывать в них деньги:

Стоимость внедрения взаимодействия различных подсистем здания (открытых технологий) минимизирована за счет использования на базе протокола BACnet систем управления, механического оборудования и соответствующих компонентов. BACnet гарантирует независимость от закрытых протоколов и технологий частных производителей.
Обучение персонала - всегда проблема для владельцев зданий, которые вынуждены сочетать оборудование и технологии от разных производителей. Однако, системы, базирующиеся на протоколе, вроде BACnet (особенно те, что используют этот протокол на разных уровнях автоматизации), имеют много сходных черт и это позволяет объединять обучение по техническим системам от разных производителей.
Поддержка и сервис, также как и в случае с обучением, намного сложнее и дороже, когда приходится сталкиваться с системами от различных производителей, работающими раздельно. Но использование стандарта BACnet может обеспечить значительные преимущества в этом вопросе, так как всегда существуют средства диагностики и решения технических проблем от сторонних компаний, также занимающихся протоколом BACnet.
Дополнительная интеграция систем здания всегда была очень затратной и проблемной частью проектов. Однако, стандарты вроде BACnet в значительной степени упростили задачи интеграции. Многие задачи, которые ранее требовали дополнительных технических решений и работы по интеграции, сейчас решаются через функциональность, изначально заложенную в протокол BACnet, а также используя дополнительные решения от сторонних компаний.
Расширяемость САиУЗ всегда вызывала трудности, когда не было возможности (или минимальная возможность) интеграции. Легче было оставить системы от различных производителей работать раздельно, но выбирая открытые технологии взаимодействия систем на базе протокола BACnet, проектировщик может существенно улучшить гибкость общей системы в плане расширения ее опций и возможностей в будущем.
Внутрисистемную оптимизация получить очень сложно или совсем невозможно без проектирования открытых систем способных к взаимодействию.

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

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

Возврат к списку