Современный взгляд на построение систем автоматизации зданий

Развитие систем автоматики за последние 10 лет выявило две четко-выраженные тенденции.
Первая - это стремление сократить время необходимое на реализацию алгоритмов управления, пусконаладочных работ и операций, необходимых при сервисном обслуживании и эксплуатации.
Вторая - это стремление большинства фирм производителей автоматики поддерживать стандартные протоколы обмена информацией.
Сокращение времени на разработку приложений достигается за счет использования инструмента для написания программ, который основывается на принципе D-MAP. Если говорить простым языком это среда программирования, которая состоит из неких элементов, реализующих те или иные функции, и имеющих те или иные свойства которые можно задавать или просматривать. Взаимодействие же между элементами описывается при помощи сопоставления некого свойства одного элемента некому свойству другого элемента. Сопоставления, чаще всего отображается в графическом виде, при помощи соединительных линий. Бесспорным достоинством такого способа программирования является сокращение времени разработки программ. А создание библиотек, из заранее соединенных элементов, реализующих ту или иную функциональность, сводит программирование контроллеров к детской игре в кубики.
При организации систем автоматики на крупных и средних объектах, важную роль играет возможность создания системы управления, для чего необходимо наладить обмен информацией между станциями автоматизации (контроллерами), управляющими системами технологического оборудования и станцией управления, реализованной чаще всего на базе персонального компьютера.

• Share

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

• Share

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

Можно выделить три основных протокола логического уровня, используемых в системах автоматики зданий.
Konex, более известный по своему предшественнику EIB. Данный протокол получил наиболее широкое распространение в системах автоматического управления освещением, приводами жалюзи и всем что входит в понятие комнатной автоматизации.
LON. Определяет протокол как логического уровня, называемый также LonWorks и протокол транспортного уровня называемый также LonTalk. Очень распространенный на сегодняшний день протокол. Транспортный уровень этого протокола может быть использован для других протоколов логического уровня
BACNet. В отличие от первых двух, широко использоваться стал достаточно недавно и является протоколом только логического уровня. В качестве транспортного уровня используется несколько протоколов.
Наиболее распространенная реализация протокола BACNet использует в качестве транспортного уровня протокол Ethernet и TCP/IP. Конечно по сути своей это два разных протокола, но с точки зрения уровня BACNet все это транспортный уровень, по которому BACNet может осуществлять передачу данных. В дальнейшем будем называть эту реализацию BACNet на TCP/IP.
У этой реализации имеется ряд преимуществ. Во-первых, используется большинством производителей как основная реализация, иногда правда и единственная. Во-вторых, накоплен колоссальный опыт по организации TCP/IP сетей разного размера, так как данный протокол является основным для организации локальных сетей для персональных компьютеров. В-третьих, для протокола TCP/IP в последнее время широкое распространение получило использование волоконно-оптических линий связи. Эти линии связи лишены такого недостатка, как ограниченность длины одного сегмента и обладают высокой помехозащищенностью.
Наряду с достоинствами данная реализация имеет ряд недостатков. Во-первых, длина линии между двумя активными устройствами, при использовании витой пары не может превышать 100 метров. Во-вторых, для организации связи даже двух станций автоматизации или станции автоматизации со станцией диспетчеризации и управления необходимо использовать дополнительное коммуникационное оборудование. Исключением для двух станций является возможность связи в пределах одного сегмента без использования дополнительного коммуникационного оборудования.
Для сетей связи малого и среднего размера, оправдано использование в качестве протокола транспортного уровня протокола LonTalk. Данная реализация позволяет строить сети передачи информации с длиной линии до 900 метров без использования дополнительного коммуникационного оборудования. То есть, каждый контроллер содержит в себе достаточные возможности для подсоединения к сети передачи данных размера достаточного для большинства строящихся сейчас офисных зданий.
Трехлетний практический опыт показал, что данная реализация очень удобна для проектов малого и среднего размера, все проблемы, возникающие с коммуникацией, были вызваны исключительно невнимательным чтением документации, как только все делалось в соответствии с описанием, все тут же начинало работать.

• Share

Интересна также комбинация двух вышеописанных реализаций протокола BACNet. Организуется несколько сегментов BACNet на LonTalk со станциями автоматизации. В каждом сегменте содержится BACNet маршрутизатор, преобразующий BACNet на LonTalk в BACNet на TCP/IP и уже к этой сети подсоединяется станция управления и диспетчеризации. Данная комбинация, является удачной альтернативой для объектов среднего и большого размера, по сравнению с использованием только BACNet на TCP/IP.
Еще одна реализация протокола BACNet это использование в качестве протокола транспортного уровня протокола PTP. По сути своей это возможность организации сети BACNet на базе телефонных каналов, как проводных сетей, так и сетей сотовых операторов. Данная реализация может быть использована для организации BACNet сети с удаленными BACNet сегментами BACNet/LonTalk или BACNet/IP.
Основным понятием протокола BACNet является так называемая BACNet точка данных. Каждая точка данных имеет как основное значение, например температура или состояние контакта, так и другие свойства позволяющие сконфигурировать точку данных и описать ее взаимодействие с другими точками данных.
Если говорить об организации среды программирования для контроллеров BACNet, то для этого очень подходит уже упомянутый выше принцип D-MAP. В качестве элементов используется BACNet точки данных, а установление связей между определенными свойствами точек данных позволяет реализовывать те или иные алгоритмы управления.
Основой программы является BACNet точки данных стандартных типов, большинство из них представляют собой точки данных связанные с физическими точками ввода вывода и большая часть функциональности по управлению и мониторингу реализована непосредственно в этих стандартных BACNet объектах.
Помимо этого в контроллерах существует еще несколько стандартных типов точек данных необходимых для реализации мониторинга управления. Наиболее характерные из них это объекты по реализации временных программ, по организации уведомления об аварийных ситуациях и объекты позволяющие запоминать изменения значений по времени.

• Share

Для реализации алгоритмов управления в системах программирования создаются BACNet объекты пользовательских типов, реализующих функции, например PI регулятора или гистерезиса, а также прочие функции стандартные при программировании систем автоматики, и не имеющие стандартного типа в BACNet протоколе. Эти элементы пользовательских типов могут быть как отображены в BACNet, так и скрыты.
Таким образом, для написания программ, используется библиотека BACNet объектов, которые связываются определенным образом для реализации той или иной функциональности.

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

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