Кондиционирование Вентиляция Сантехника Отопление
Кондиционирование Вентиляция Сантехника Отопление
СОК СОК
Главное меню
Главная
Новости
СОК онлайн
Рубрики
О журнале
Медиаплан
Реклама
Реклама на сайте
Выставки
Семинары
Контакты
Поиск
Форум
Библиотека
Фотогалерея
Рубрики
Сантехника
Отопление
Кондиционирование
Вентиляция
Энергосбережение
Нормативная База
Объекты
Рекомендуем
Кондиционеры, вентиляция, тепловые насосы.
Тепловые насосы, Телпый пол и Воздушные фильтры
Aqua-Term 2013
Top100+ :: Teplo.com
Системы воздушного отопления
c-o-k.ru
Кондиционеры Daikin

Современный взгляд на построение систем автоматизации зданий Версия для печати Отправить на e-mail
27.04.2007

Автор И. Д. Павлов, ведущий эксперт по системам автоматизации компании «Сименс», департамент «Автоматизация и безопасность зданий», г. Москва

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

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

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

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

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

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

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

❏ транспортный уровень — это топология системы, линии связи, уровень сигналов и система адресации физических устройств;

❏ логический уровень — это система адресации логических элементов, представление информации и собственно организация обмена информации (запрос-ответ, уведомление об изменении и т. д.).

На сегодняшний день можно выделить три основных протокола логического уровня, используемых в системах автоматизации зданий:

❏ Konnex, более известный по своему предшественнику EIB. Данный протокол получил наиболее широкое распространение в системах автоматического управления освещением, приводами жалюзи и всем, что входит в понятие комнатной автоматизации;

❏ LON. Очень распространенный на сегодняшний день протокол каклогического уровня — LonWorks, так и транспортного уровня — LonTalk. Транспортный уровень может быть использован для других протоколов логического уровня;

❏ BACnet. В отличие от первых двух, широко использоваться стал достаточно недавно и является протоколом только логического уровня. В качестве транспортного уровня используется несколько протоколов.

Наиболее распространенная реализация протокола BACnet использует в качестве протокола транспортного уровня Ethernet и TCP/IP. Конечно, по сути своей это два разных протокола, но с точки зрения уровня BACnet все это транспортный уровень, по которому BACnet может осуществлять передачу данных.

В дальнейшем будем называть эту реализацию BACnet на TCP/IP.

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

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

Для сетей связи малого и среднего размера оправдано использование в качестве протокола транспортного уровня протокола LonTalk. Данная реализация позволяет строить сети передачи информации с длиной линии до 900 м без использования дополнительного коммуникационного оборудования. То есть каждый контроллер содержит в себе возможности для подсоединения к сети передачи данных, достаточных для большинства строящихся сейчас офисных зданий.

Трехлетний практический опыт показал, что данная реализация очень удобна для проектов малого и среднего размера, все проблемы, которые возникали, были вызваны исключительно невнимательным чтением документации, и как только все делалось в соответствии с описанием, все тут же начинало работать. Интересна также комбинация двух вышеописанных реализаций протокола BACnet. Организуется несколько сегментов BACnet на Lon-Talk со станциями автоматизации. В каждом сегменте содержится BACnet-маршрутизатор, преобразующий BACnet на LonTalk в BACnet на TCP/IP, и уже к этой сети подсоединяется станция управления и диспетчеризации.

Данная комбинация является удачной альтернативой для объектов среднего и большого размера, по сравнению с использованием только BACnet на TCP/IP.

Еще одна реализация протокола BACnet — использование в качестве протокола транспортного уровня протокола PTP. По сути своей это возможность организации сети BACnet на базе телефонных каналов — как проводных сетей, так и сетей сотовых операторов. Данная реализация может быть использована для организации сети BACnet с удаленными BACnet-сегментами — BACnet/Lon-Talk или BACnet/IP. При реализации поддержки протокола BACnet многие фирмы пошли по пути наименее затратному и наименее же, на мой взгляд, перспективному. Система программирования, а иногда и шина связи между станциями автоматизации остались такими же, как и до поддержки протокола BACnet, и к ним присоединяются разного рода шлюзы BACnet. То есть реализация алгоритмов управления происходит сама по себе, и после реализации этих алгоритмов необходимо совершать дополнительные действия для отображения информации в сети BACnet. При всем уважении этот путь сродни улучшению отечественного автомобиля путем установки в него всевозможных импортных аналогов. Автомобиль становится, конечно, лучше, но при этом иномаркой все-таки не становится. Основным понятием протокола BACnet является так называемая точка данных BACnet. Каждая точка данных имеет как основное значение, например, температура или состояние контакта, так и другие свойства, позволяющие сконфигурировать точку данных и описать ее взаимодействие с другими точками данных. Если говорить об организации среды программирования для контроллеров BACnet, то для этого очень подходит уже упомянутый выше принцип D-MAP. В качестве элементов используются точки данных BACnet, а установление связей между определенными свойствами точек данных позволяет реализовывать те или иные алгоритмы управления.

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

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

Таким образом, для написания программ используется библиотека BACnet - объектов, которые связываются определенным образом для реализации той или иной функциональности. При организации систем диспетчеризации и управления для станций управления BACnet для реализации мониторинга и управления

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

При таком подходе теряется основное преимущество протокола BACnet — возможность оперирования точками данных как стандартными объектами с предсказуемыми реакциями.

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

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

Последнее обновление ( 17.09.2007 )
 
< Пред.   След. >

Будем благодарны, если воспользуетесь одной из этих кнопок: