Автор И. Д. Павлов, ведущий эксперт по системам автоматизации компании «Сименс», департамент «Автоматизация и безопасность зданий», г. Москва Н аблюдая за развитием систем автоматизации в течение последних 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-объектам напрямую. |