ЖУРНАЛ «СТА» №1/2008

торый и отрабатывает запрос, обраща- ясь по мере необходимости к нужному серверу (посредством QNX IPC) через подключенную интерфейсную библио- теку. Если возникает необходимость изменить схему отработки того или иного запроса, достаточно внести кор- рективы в соответствующий сценарий Python, поскольку именно он несет специфичную для приложения смыс- ловую нагрузку. Библиотека интерфей- са с сервером и библиотека IPC при этом остаются теми же самыми. На настоящий момент разработано множество интерфейсных библиотек PyDACHS, позволяющих писать сце- нарии Python для работы как с сервера- ми БД, так и с графическими и комму- никационными серверами. Расширенные возможности коммуникаций Одна из слабых сторон ПЛК — их ог- раниченные способности коммуника- ций как на уровне стыков, так и на уровне протоколов. Возможно, именно это как раз и привело разработчиков к мысли использовать PCархитектуру в системах управления. Но если до сих пор ситуация была в известной мере паритетной изза подчинения как «ре- альных», так и виртуальных ПЛК огра- ничениям одного и того же стандарта, то теперь наметился явный перелом в пользу решений на основе виртуаль- ных ПЛК, и вот почему. В 2001 году наконец вышел проект стандарта МЭК 611315, описывающий средства коммуникаций для ПЛК. И тут встал вопрос: а как реализовать предус- мотренные этим стандартом расшире- ния в среде исполнения МЭК 611313? У специалистов компании Steinhoff, как видно из изложенного, ответ был готов, что позволило им без труда за короткий срок реализовать дополнительный мо- дуль расширения, обеспечивающий поддержку самых разнообразных меха- низмов коммуникации. Виртуальные ПЛК в DACHS поддер- живают большой выбор стыков и прото- колов, включая протоколы высокого уровня из области Интернеттехноло- гий, что обеспечивает этим контролле- рам высокий уровень совместимости. В частности, для сопряжения с устройства- ми нижнего уровня АСУ ТП поддержи- ваются разнообразные промышленные сети (Profibus, CAN, LON, ASI, Interbus), сопряжение же с верхними уровнями возможно практически по любому стыку с использованием как QNXсети, так и TCP/IP (в том числе и FTP, HTTP, ODBC, SNMP и т. п.) —работа с соответ- ствующими серверами поддерживается посредством PyDACHS. Кроме того, возможна интеграция вир- туальныхПЛКDACHS со SCADAсисте- мами, работающими под управлением Windows, посредством OPCсервера, по- ставляемого в комплекте со средой про- граммирования МЭК 611313. Коммуникационное аппаратное обеспечение, поддерживаемое в DACHS, насчитывает десятки произ- водителей, в число которых входят Allen Bradley, Echelon, Phoenix Contact, Siemens, Softing, SST и многие другие. Открытые стандарты коммуникаций позволяют использовать в решениях на базе DACHS коммуникационную аппа- ратуру и распределенные УСО от самых различных производителей (Siemens, EntrelecSchiele, и т.д.), но особого вни- мания здесь заслуживает модульная си- стема распреденного вводавывода Wago I/O фирмы Wago. В ней для пере- дачи данных могут использоваться до семи различных вариантов промыш- ленных сетей, причем для перехода с одного типа сети на другой достаточно просто заменить соответствующий ин- терфейсный модуль в узле системы,— конфигурация модулей вводавывода останется прежней. Полезная хитрость использования такой системы в DACHS заключается в том, что, с точки зрения задачи 611313, все системы вводавывода одинаковы, поскольку сервисы, предоставляемые виртуаль- ной машине сетевым сервером (в дан- ном случае — сервером полевой шины), унифицированы и от типа применяе- мой сети не зависят. Таким образом, ес- ли будет необходимо перейти на другую промышленную сеть (например, систе- ма была изначально разработана для CAN, а потом понадобилось добавить поддержку ProfibusDP), достаточно будет сменить интерфейсный сетевой модуль станции Wago I/O, поставить в виртуальный ПЛК другую плату рас- ширения и запустить соответствующий драйвер. Ни система вводавывода, ни задача МЭК 611313 при этом ни в ка- кой модернизации нуждаться не будут. Расширенные интерфейсные возможности Нужен или нет виртуальному ПЛК графический интерфейс пользовате- ля – вопрос спорный. В первую оче- редь это зависит от того, где и в какой роли будет применяться этот виртуаль- ный ПЛК. С другой стороны, коль ско- ро виртуальные ПЛК часто применя- ются там, где интерфейс пользователя нужен — хотя бы в тех же цеховых кон- троллерах — предусмотреть такую воз- можность следует. Модуль расширения, реализующий графическую подсистему виртуального ПЛК в DACHS, также реализован при помощи PyDACHS. Роль графического сервера при этом выполняет кроссплатформенный графический сервер Tilcon (продукт канадской ком- пании Tilcon Software). Сервер Tilcon предоставляет богатый выбор графических примитивов, поз- П Р О Г РАММНО Е ОБ Е С П Е Ч Е НИ Е / РАС П Р Е Д Е Л Е ННЫ Е СИС Т ЕМЫ У П РА В Л Е НИ Я СТА 4/2001 www.cta.ru 57 Рис. 3. Пример графического интерфейса, реализованного с помощью Tilcon