СПКД123 / СПДК / Задачи АСУТП / Лекция 12. Технология ОРС

Лекция 12. Технология OPC

Содержание лекции:

• Введение. Цели создания, преимущества OPC

• Архитектура OPC. Типичные сценарии взаимодействия клиента и сервера

• Разработка сервера и клиента. Реализуемые интерфейсы и их методы

1. Введение. Цели создания, преимущества OPC

По мере развития систем промышленной автоматизации, оборудования разных производителей становилось всё больше, для каждого из них требовалось своё, уникальное программное обеспечение. В 1990 гг. у разработчиков систем промышленной автоматизации возникла необходимость в разработке универсального программного обеспечения для обмена данными с устройствами разных производителей. Для реализации этой цели была создана организация OPC Foundation, объединяющая множество независимых производителей оборудования и программных средств автоматизации. В результате появилась спецификация, определяющая правила для создания подобного рода ПО – спецификация OPC (OLE for Process Control).  Создателями спецификации рассматриваются три уровня представления информации и управления на производственном предприятии: полевой, технологический, хозяйственный. Устройства полевого оборудования (контроллеры, интеллектуальные датчики) являются источниками данных для ДП АСУТП – систем технологического управления (SCADA-систем), которые, в свою очередь, передают данные системам автоматизации производственно-хозяйственной деятельности и учета. Различные звенья этой структуры выпускаются различными производителями и поддерживают различные протоколы передачи данных. Это привело к тому, что к концу 90-х гг. каждая тиражируемая SCADA-система поставляется с набором драйверов для получения данных от устройств системы телемеханики по 10-20 наиболее распространенным протоколам и дополнительно предоставляет средства и интерфейс для разработки системным интегратором дополнительных модулей опроса с устройствами, поддерживающими нестандартные протоколы передачи данных. Доступ к данным своих БД SCADA-системы часто предоставляют или с использованием нестандартных серверов, или по спецификациям ODBC или NetDDE, плохо подходящим для передачи технологической информации. Исходя из этого, обеспечение универсального интерфейса передачи технологических данных являлось насущной задачей. Повсеместное внедрение стандарта OPC позволит производителю устройства – источника данных разработать сервер, а поставщику программного решения сбора данных – клиента только для одного протокола (см. Рис. 12.1).  Преимуществами OPC являются иерархическое пространство имен, простая объектная модель, прозрачность локального/сетевого взаимодействия, поддержка различных режимов передачи данных. OPC в настоящее время безусловно является наиболее развитой и перспективной технологией информационного взаимодействия. Недостатком OPC является отсутствие кросс-платформенной поддержки: и OPC-клиент, и OPC-сервер могут функционировать только на платформе Windows, т.к. это программная технология, основанная на механизме удалённого вызова процедур с использованием стека DCOM.  Рис. 12.1. Технология OPC в производстве OPC – это набор спецификаций стандартов: OPC Data Access определяет интерфейсы передачи оперативных технологических данных, OPC Alarm & Events стандартизует передачу сообщений-тревог, OPC Historical Data Access – передачу ретроспектив технологических данных, прорабатываются также стандарты OPC Batch, OPC Security и др. Далее мы будем рассматривать спецификацию OPC Data Access Server 2.0 – именно обеспечение доступа (чтения и записи) данных является основной задачей информационного стыка. 

2. ^ Архитектура OPC. Типичные сценарии взаимодействия клиента и сервера

OPC (OLE for Process Control) является расширением технологии Microsoft COM/DCOM для приложений реального времени. OPC – это больше, чем протокол передачи данных, это – протокол (технология) объектного взаимодействия. На рис. 12.2 показана объектная модель OPC-сервера. С концептуальной точки зрения, программа – OPC-сервер заключает в себе сущности трех типов: сервер, группа, элемент. Объект «сервер» (OPCServer) реализует механизм COM/DCOM соединений и выполняет роль контейнера для объектов типа «группа» (OPCGroup), каждый из которых, в свою очередь, содержит множество элементов (OPCItem) и обрабатывает запросы OPC-клиентов. Прямого доступа клиента к элементам не предусматривается.  Рис. 12.2. Объектная модель OPC-сервера. Вообще, понятие группы является центральным при рассмотрении взаимодействия сервера и клиента. При инициализации OPC-клиент создает на сервере свои «частные» (private) группы, в которые добавляет элементы, значения которых ему требуется считать (имена и параметры элементов заданы у клиента; узнать возможные пользователь может, просмотрев с помощью этого же или другого клиента адресное пространство сервера), и настраивает их свойства – индивидуальные параметры коммуникации (см. табл. 12.1). Стандарт OPC также предусматривает возможность создания «общих» (public) групп, доступных всем клиентам, подсоединенным к серверу. Однако при подключении к такой общей группе сервер создает копию группы для отдельного использования каждым клиентом. Т.о., группы используются сервером для разграничения взаимодействия с каждым из клиентов. Каждый элемент (OPCItem) является объектом, содержащим значение одного из поддерживаемых сервером типов данных (обычно целочисленные, с плавающей точкой, строковые) и свойства – метку времени (timestamp), достоверность (quality) и др. Табл. 12.1. Свойства OPC-группы.

Спецификация OPC Data Access определяет четыре механизма взаимодействия OPC-клиента и OPC-сервера:

• Синхронные вызовы – при получении запроса на чтение или запись набора значений процедура обработки запроса сервера не возвращает управление, пока запрос не будет выполнен.

• Асинхронные вызовы – возврат управления из процедуры обработки запроса происходит немедленно; после чего сервер выполняет требуемую передачу данных клиенту.

• Обновление – при получении запроса сервер в асинхронном режиме передает значения сигналов (элементов) из определенного при инициализации взаимодействия набора.

• Подписка – сервер спонтанно, без запроса со стороны клиента, передает клиенту значения сигналов из определенного набора при их изменении.

Первые два способа взаимодействия классифицируются как механизмы периодической выборки (polling): клиентe для получения значений от сервера каждый раз требуется передать управляющую информацию (идентификаторы сигналов). Третий и четвертый способы рассматриваются как механизмы обратного вызова (callback): сначала клиент выполняет инициализацию, после чего взаимодействие сводится только к передаче данных; при этом сервер обладает всей необходимой информацией для инициирования транзакции. Для иллюстрации сказанного рассмотрим отличия сценариев взаимодействия OPC-клиента и OPC-сервера при различных механизмах коммуникации. При выполнении синхронного чтения последовательность действий следующая:

1. Клиент подсоединяется к серверу.

2. Клиент создает на сервере объекты OPCGroup, устанавливает их атрибут Active.

3. Клиент создает объекты OPCItem в этих группах, устанавливает их атрибут Active.

4. Клиент выполняет запрос синхронного чтения значений одного или нескольких OPCItem.

5. Сервер возвращает запрошенные значения.

При асинхронном чтении первые три действия клиента те же, что и при синхронном, далее выполняются следующие операции:

4. Клиент создает на сервере «возвратное соединение» (callback connection).

5. Клиент выполняет запрос асинхронного чтения значений одного или нескольких OPCItem.

6. Сервер возвращает запрошенные значения после выполнения других, более приоритетных операций.

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

1. Клиент подсоединяется к серверу.

2. Клиент создает на сервере объекты OPCGroup, устанавливает их атрибуты Active, Enable, UpdateRate, Deadband.

3. Клиент создает объекты OPCItem в этих группах, устанавливает их атрибут Active.

4. Клиент создает на сервере «возвратное соединение».

5. Циклически, с частотой UpdateRate проверять, не изменились ли текущие значения элементов от в последний раз сообщенных клиенту, для изменившихся – передать клиенту измененные значения.

3. ^ Разработка сервера и клиента. Реализуемые интерфейсы и их методы

Разработчик OPC сервера должен реализовать, во-первых, логику взаимодействия с источником данных (OPC-сервер скрывает протокол обмена, но должен взаимодействовать с сетью технологических контроллеров или базой данных ИС по их оригинальным протоколам); во-вторых, описываемые стандартом интерфейсы взаимодействия с OPC-клиентом. Объект OPCServer должен реализовывать следующие интерфейсы:

• IUnknown – общий интерфейс, реализуемый любым OLE-объектом 

• IOPCCommon – функции настройки коммуникации в сессии «клиент-сервер»

• IOPCServer – интерфейс позволяет клиенту создавать/удалять свои группы элементов

• IConnectionPointContainer – функции доступа клиента к информации о соединениях

• IOPCItemProperties – функции для информирования клиента о возможных свойствах 

• IOPCServerPublicGroup – функции управления общими группами

• IOPCBrowseServerAddressSpace – интерфейс для выполнения клиентом операций по «просмотру» иерархически организованного адресного пространства сервера.

• IPersistFile – позволяет клиенту сохранять и загружать различные конфигурации сервера.

Объект OPCGroup должен реализовывать следующие интерфейсы:

• IUnknown – общий интерфейс, реализуемый любым OLE-объектом 

• IOPCItemMgt – функции добавления, удаления и управления поведением элементов группы

• IOPCGroupStateMgt – управление состоянием группы, режимом обновления данных

• IOPCPublicGroupStateMgt – создание и определение состояния общей группы

• IOPCSyncIO – функции синхронного чтения/записи

• IOPCAsyncIO2 – функции асинхронного чтения/записи

• IConnectionPointContainer – функции доступа клиента к информации о соединениях

• IEnumOPCItemAttributes – позволяет клиенту работать со списком элементов группы, получать значения атрибутов элементов.

Методы рассмотренных интерфейсов сведены в табл. 12.2, 12.3. Таблица 12.2. Интерфейсы объекта OPCServer и их методы.

Таблица 12.3. Интерфейсы объекта OPCGroup и их методы.

Разработка OPC-клиента также предполагает как реализацию логики взаимодействия с получателем считываемых данных, так и интерфейса IOPCDataCallback для получения данных от сервера как результата выполнения асинхронного чтения или подписки на измененные данные. Для реакции на запрос сервера о закрытии соединений требуется реализовать интерфейс IOPCShutdown. Для OPC-клиента, как и для любого COM-приложения, обязательна реализации интерфейса IUnknown. Таблица 12.4. Интерфейсы OPC-клиента и их методы.