ЖУРНАЛ СТА 1/2012

цесс создания OPC-сервера. На рынке достаточно широко представлены ком- плекты разработчика, так называемые конструкторы OPC, с помощью кото- рых, как из кубиков, можно собрать нужный вам сервер, не прибегая к изу- чению OPC-технологии. Если вы гото- вы выложить от нескольких тысяч до десятков тысяч евро за один из таких инструментов и намерены создать, по крайней мере, несколько OPC-серве- ров для различных устройств, то этот путь, вероятно, оптимальный. Понят- но, что и в этом случае, если конечной целью является создание единственно- го OPC-сервера, затраты могут оказать- ся неоправданно высокими. Имеется также возможность созда- ния OPC-сервера с помощью про- грамм-заготовок, к числу которых от- носятся, например, UniOPC Server фирмы FASTWEL или MasterOPC Ser- ver (разработчик ЗАО «ИнСАТ»). В обоих случаях при сравнительно не- больших затратах (около 500 у. е.) вы получаете продукт, реализующий функ- ции OPC-сервера, совместимого со спецификацией OPC DA 2.0, к которо- му необходимо самостоятельно на- писать лишь драйвер конкретного про- токола связи. Однако следует иметь в виду, что лицензионные соглашения на такого рода полуфабрикаты пред- усматривают создание только одного экземпляра конечного продукта. Так что, если требуется несколько экзем- пляров одного и того же OPC-сервера, общие расходы могут превысить стои- мость конструктора, с помощью кото- рого можно создавать неограниченное число OPC-серверов. Все рассмотренные варианты имеют целью реализовать доступ к данным OPC стандартным способом, то есть добиться, чтобы для устройств всех типов (точнее, для всех разновидно- стей протоколов) имелись соответ- ствующие OPC-серверы (рис. 1). Между тем, у разработчиков АСУ ТП, сделавших выбор в пользу SCADA GENESIS32 компании ICONICS, име- ется ещё один метод решения пробле- мы интеграции в систему нестандарт- ных устройств, практически не тре- бующий затрат. D ATA W OR X32 В КАЧЕСТВЕ УНИВЕРСАЛЬНОГО OPC- СЕРВЕРА Благодаря наличию в составе семей- ства продуктов GENESIS32 компонен- та DataWorX32, представляющего со- бой, по сути, универ- сальный OPC-сервер с открытым процедур- ным интерфейсом, имеется возможность подключения к систе- ме внешних, независи- мо разработанных ком- понентов. Поставлен- ная в своё время перед одним из авторов статьи задача создания такого внешнего ком- понента для связи с УСО опиралась на сле- дующие предпосылки: ● OPC-сервер для уст- ройства, в том числе встроенный, содер- жит скан-программу, осуществляющую непрерывно по- вторяющийся опрос (поллинг) теку- щего состояния элементов информа- ционного поля, – необходимо вы- полнить сравнение очередных значе- ний этих элементов с их предыдущи- ми значениями и передать потреби- телям информации только те дан- ные, которые изменились на заранее регламентированную величину; ● OPC-сервер DataWorX32 обеспечива- ет возможность свободного конфи- гурирования дерева тегов, каждый из которых может быть доступен для записи со стороны OPC-клиента. Естественным решением, вытекаю- щим из этих положений, было созда- ние такого OPC-клиента, который, с одной стороны, должен выполнять функции, специфичные для интегри- руемого устройства, то есть осуществ- лять считывание и запись данных в соответствии с протоколом (скан-про- грамма), а с другой стороны, будучи клиентом DataWorX32, производить периодическое обновление массивов значений тегов сервера, который, в свою очередь, обеспечит публикацию этих тегов, открывая их для доступа со стороны остальных OPC-клиентов SCADA-системы (рис. 2). Дополнительным требованием к соз- данию такого OPC-клиента являлось использование среды разработки, не поддерживающей OPC Custom-интер- фейс. Возможность применения таких ин- струментов для получения доступа к OPC-серверам с поддержкой специфи- кации OPC DA 2.0 предусмотрена раз- работчиками стандарта OPC с помо- щью так называемой «обёртки» (в виде библиотеки DLL), преобразующей OPC Custom-интерфейс в интерфейс OLE-автоматизации (последняя вер- сия – OPC DA Auto Wrapper 2.05а; вер- сия 2.02 доступна для бесплатного скачивания с Интернет-ресурсов Gray- box без каких-либо ограничений на использование данного продукта). Использование «обёртки» позволило создать необходимый OPC-клиент средствами VB6. При этом от програм- миста требовался лишь опыт работ с OLE-автоматизацией, что существенно сократило сроки разработки проекта. А РХИТЕКТУРА OPC- КЛИЕНТА Архитектура OPC-клиента представ- лена на рис. 3. Программа имеет модульную струк- туру и состоит из следующих основных узлов: 1)интерфейсный модуль; 2)модуль обработки команд; 3)очередь запросов; 4)таймер; 5)модуль визуализации; 6)модуль конфигурации; 7)модуль OPC. Первые пять модулей реализованы в виде компонентов ActiveX Control, выполняемых в отдельных программ- ных потоках. Таким образом, приложе- ние в целом является многопоточ- ным. Библиотека OPC-автоматизации («обёртка») импортирована в основной поток программы. Модуль конфигурации представляет собой процедуру основного потока, считывающую конфигурационную ин- формацию из внешнего файла при старте приложения. Основное содер- жание файла конфигурации – таблица П РОГ Р АММНОЕ ОБ Е СП Е Ч Е НИЕ / ИНС Т Р УМЕ Н Т АЛ Ь НЫЕ СИС Т ЕМЫ 89 СТА 1/2012 www.cta.ru Модуль визуализации DataWorX32 Модуль ОРС Очередь запросов Интегрируемое устройство Модуль конфигурации Модуль обработки команд Интерфейсный модуль Таймер Рис. 3. Архитектура OPC-клиента, выполняющего функции взаимодействия с УСО © СТА-ПРЕСС