Интеграция устройств с нестандартным протоколом в SCADA GENESIS32

О проблемах интеграции

Одной из основных задач системного интегратора при создании АСУ ТП является организация информационного взаимодействия системы с технологическими объектами. Устройствами сопряжения с объектами контроля и управления (УСО) являются чаще всего контроллеры, имеющие стандартный интерфейс связи с верхним уровнем. Как правило, разработчик системы старается выбрать в качестве УСО контроллеры со стандартным протоколом. Это особенно актуально в том случае, когда ядром проектируемой АСУ ТП является SCADA-система, базирующаяся на технологии OPC, которая позволяет каждому OPC со­вместимому клиентскому приложению получать доступ к любому устройству управления, у которого есть OPC со­вместимый сервер. В этом случае ин­теграция УСО в АСУ ТП сводится к при­менению OPC-сервера, поддерживающего ис­поль­­зуемый контроллером протокол.

Практически для всех широко распространённых протоколов, признанных стандартными, имеются OPC-серверы различных производителей. Раз­работкой OPC-серверов для разнообразных устройств заняты несколько сотен фирм, входящих в состав организации OPC Foundation, а также немалое количество компаний, не являющихся её членами.

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

Это объясняется тем, что создание OPC-сервера не является тривиальной задачей. OPC-сервер – это достаточно сложный в реализации программный продукт, требующий от разработчиков высокого уровня квалификации. По­этому самостоятельная разработка OPC-серверов – скорее удел организаций, специализирующихся на разработке такого рода продуктов и имеющих достаточный опыт в этом. Если же работы по созданию OPC-сервера – редкий эпизод в деятельности компании, то кажущаяся простота решения проблемы на деле оборачивается для неё дополнительными затратами и потерей репутации.

К сожалению, невозможно заполучить OPC-сервер с полностью открытыми исходными кодами. Полные спе­цификации с описанием интерфейсов доступны только членам организации OPC Foundation, а само членство стоит дорого (от нескольких тысяч долларов). Неудивительно поэтому стремительное насыщение рынка программных продуктов инструментальными пакетами, упрощающими процесс создания 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, имеется ещё один метод решения проблемы интеграции в систему нестандартных устройств, практически не требующий затрат.

DataWorX32 в качестве универсального 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-автоматизации («обёртка») импортирована в основной поток программы.

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

Интерфейсный модуль осуществляет низкоуровневую проверку на корректность входного потока данных, после чего передаёт их в модуль обработки команд и, наоборот, получая данные от модуля обработки команд, выдаёт их в линию связи в формате, определяемом настройками интерфейса. Модуль об­работки команд является контейнером интерфейсного модуля, разгружая тем самым основной поток от необходимости выступать в качестве посредника «ди­алога» между этими компонентами.

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

Завершив обработку ответа на запрос, модуль обработки команд считывает очередную команду из очереди запросов.

Очередь запросов представляет собой кольцевую структуру, состоящую в об­щем случае из регулярных (непрерывно повторяющихся) команд, с помощью которых выполняется сканирование те­кущих данных. После удачного вы­пол­нения каждой команды (приёма или пе­редачи данных) указатель перемещается на следующую команду. Осо­бен­ностью очереди является возможность вставки в неё нерегулярных ко­манд в произ­вольную позицию, определяемую приоритетом команды, с последующим её удалением после успешного завершения. Нерегулярные команды фор­ми­руются в результате взаимодействия с пользователем SCADA посредством его воздействия на теги специальной OPC-группы, на которые данное приложение подписано как обычный OPC-клиент.

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

Модуль визуализации не является обязательным, но чрезвычайно полезен в процессе эксплуатации для визуальной диагностики состояния как самого OPC-клиента, так и интегрируемого устройства, а также для возможности изменения на лету параметров настройки устройства, если это позволяет протокол. Основной поток приложения не имеет средств интерактивного взаимодействия.

Модуль OPC, строго говоря, модулем не является, а представляет собой на­бор интерфейсных функций, предоставляемых библиотекой OPC-автоматизации («обёрткой»), размещённых в основном потоке программы.

OPC-клиент, созданный в соответствии с описанной структурой для интеграции контроллеров SupeRTU-1 производства ЗАО «СовТИГаз», показал устойчивую работу в течение не­скольких лет на одном из технологических объектов ООО «Газпром трансгаз Сара­тов», не требуя каких-либо доработок. Более того, разработанный для использования совместно с GENESIS32 v6.1, он благополучно продолжает функционировать в составе SCADA 9-й версии, а благодаря новой функциональности – OPC-туннелингу – может быть размещён на любом узле сети. Скорость обновления данных, полученных таким способом, определяется в основном возможностями ин­тегрируемого устройства и линии связи с ним.

Заключение

К ограничению данного метода мож­но отнести проблему управления свойством «качество» OPC-тегов Data­WorX32 со стороны OPC-клиента, так как в со­ответствии со спецификацией OPC DA 2.0 это свойство имеет статус read-only. Для преодоления этого ограничения потребовалось использование в паре с тегом, содержащим значение, дополнительного тега качества. Следует заметить, что одной из последних до­ступных спецификаций стандарта OPC DA является версия 3.0 (GENESIS32 v9.x её поддерживает), основным отличием ко­торой от версии 2.0 является возможность записи в OPC-сервер не только значений параметров, но и признаков качества, однако авторы не располагают информацией о существовании «обёртки» для этой версии.

В заключение авторы выражают надежду, что описанная концепция окажется полезной разработчикам сис­тем управления на базе SCADA GENESIS32, обеспечивая альтернативный метод интеграции устройств, не требующий лишних затрат и чрезмерных усилий. ●

E-mail: Yva23@mail.ru