OPC(рус)

13. ТехнологИя ОРС

13.1. Общие концепции.
13.1.1. Предпосылки создания

13.1.1.1. Выбор SCADA/HMI по набору поддерживаемых коммуникаций. Один из критериев выбора SCADA программы - список поддерживаемых коммуникаций. Т.е. SCADA с одной стороны, и техническое средство (далее контроллер) с другой, должны поддерживать одинаковый протокол (или протоколы) промышленной сети. Чаще всего выбирают ту сеть, которая уже интегрирована в контроллер. В этом случае при выборе SCADA учитывают наличие данных протоколов в перечне коммуникационных драйверов.

13.1.1.2. Проблемы совместимости SCADA/HMI с контролерами. При интеграции продуктов одного производителя, наличие в SCADA-программе драйверов связи с необходимыми контроллерами – очевидна. Самым сложным является случай, когда необходимо интегрировать средства от нескольких производителей, ряд из которых поддерживают закрытые протоколы. В этой ситуации очень трудно подобрать SCADA-программу, которая бы поддерживала все необходимые протоколы промышленных сетей. Рассмотрим, какие возможные варианты реализации подобной системы.

1. Выбор другой промышленной сети, которая бы поддерживалась со стороны SCADA и контролера. Этот вариант не всегда возможно реализовать.

2. Написание специального драйвера, которого не существует в SCADA, для обеспечения связи с контроллером. Этот вариант требует привлечения программиста достаточно высокого уровня подготовки, наличия открытого программного интерфейса со стороны SCADA-приложения и открытого протокола обмена с контроллером.

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

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

Как видим, одни способы сильно ограничивают реализацию системы, а другие требуют значительных капитальных затрат. Рассмотрим пример.

Пример13.1. ОРС. Выбор SCADA программы.

Задание. Система управления технологическим процессом включает три подсистемы, в каждой из которых используются различные по типу и производителю контроллеры: TSX Premium (Schneider Electric), S7-300 (Siemens), ЛОМИКОНТ Л-110 (Чебоксары) (рис.13.1). Необходимо выбрать SCADA-программу из трех вариантов (Citect 7, Zenon 6, Trace Mode 6), которая б обеспечила связь со всеми подсистемами, учитывая только использование встроенных коммуникаций в ПЛК, и без приобретения дополнительных конвертирующих программных средств.

Решение. При выборе SCADA-программы необходимо проверить перечень коммуникационных драйверов связи для поддержки указанных контроллеров. Необходимые три типа драйверов: UNI-Telway (для TSX Premium), S7-MPI (для S7-300) и драйвер Сеть Ломиконт (для Л-110).

    Протоколы для подключения средств к SCADA-программе реализованы в виде драйверов связи. Понятно, что интерфейс драйверов со стороны SCADA для каждой реализации разный, поэтому драйверы для одной SCADA-программы не подойдут к другой. Поэтому необходимо выбрать ту SCADA, которая имеет все три драйверы. Citect 7 и Zenon 6 поддерживает все коммуникации, кроме ЛОМИКОНТ. SCADA ТМ6 - поддерживает все коммуникации, однако S7-MPI требует наличие драйверов SIMATIC NET и имеет определенные ограничения в использовании. Таким образом, ни одна из перечисленных SCADA-программ не удовлетворяет указанным в условии задачи критериям выбора. Необходимо использование дополнительных программ-конвертеров, рассмотреть возможность выбора другой SCADA, другой сети или написание драйверов связи.
 

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

13.1.1.3. ОРС - как универсальный драйвер связи. Для преодоления этой проблемы, группой крупных компаний было решено создать стандартный интерфейс доступа к данным "драйвера" со стороны программного обеспечения верхнего уровня. Таким образом, любой драйвер со стандартным интерфейсом может быть использован любой SCADA-программой, поддерживающей этот интерфейс. Технология получила название ОРС.


13.1.2. Стандарты ОРС

13.1.2.1. Происхождение. Первая версия стандарта OPC (OPC DA 1.0) разработана группой компаний, которые в 1996 году организовали некоммерческую организацию OPC Foundation (www.opcfoundation.org), занимающаяся ныне развитием и продвижением данной технологии на рынке.

13.1.2.2. Доступные спецификации. В настоящее время стандарт существует в наборе спецификаций, основные из которых:

1) OPC DA (Data Access) - спецификация доступа к данным реального времени;

2) OPC AE (Alarms & Events) - для реализации задач предупредительно-аварийных сигнализаций;

3) OPC HDA (Historical Data Access) - для реализации задач ведения архива и доступа к архивным данным;

4) OPC DX (Data eXchange) - для непосредственного обмена между ОРС-серверами;

5) OPC XML - для обмена данными через интерсети с помощью структур XML на базе WEB-сервисов и SOAP;

6) OPC Batсh - для реализации управления рецептурными задачами.

7) OPC UA (United Architecture) - самый новый платформо-независимый стандарт, который объединяет функции всех приведенных выше спецификаций, но функционирует не на базе СОМ а на WEB-сервисах.

Среди приведенных выше стандартов наибольшую популярность в настоящее время имеет OPC DA 2.0, все остальные встречаются гораздо реже. Стандарт OPC UA является новейшим стандартом, однако пока не нашел широкого потребления. Планируется, что OPC UA в ближайшем будущем вытеснит OPC DA 2.0 и все сопутствующие ему стандарты.

13.1.2.3. Определение ОРС. Изначально технология OPC расшифровывалась как OLE for Process Control и являлась промышленным стандартом взаимодействия между программными средствами в области промышленной автоматизации, который основан на объектной модели COM/DCOM (OLE). Однако, при появлении новых спецификаций, включая XML и UA, которые не базируются на СОМ, слово "OLE" в аббревиатуре перестало соответствовать действительному функциональному содержанию технологии. Поэтому в настоящее время нет официальной расшифровки термина ОРС.

Таким образом будем пользоваться таким понятием: ОРС - это открытая технология связи (OPen Connectivity) в области промышленной автоматизации и управления производством.

13.1.2.4. Общая модель. В общем случае, технология ОРС обеспечивает одному приложению (ОРС-Клиенту) доступ к данным процесса другого приложения (ОРС-Серверу) посредством стандартного набора СОМ-интерфейсов. Рассмотрим эти интерфейсы через призму их использования в системах АСУТП (рис.13.2). Это интерфейсы, описываемые спецификациями OPC DA, OPC A&E и OPC HDA.

13.1.2.5. OPC DA (Data Access). СОМ-интерфейсы ОРСDА стандартизируют доступ ОРСDA-Клиента к данным процесса ОРСDA-Сервера. В свою очередь, приложение ОРС-Сервер, как правило, осуществляет обмен данными с контроллерами или распределенной периферией через специфический, отличный от ОРС, интерфейс. В этом случае, ОРСDA-Сервер предоставляет доступ ОРСDA-Клиенту к данным процесса устройств, с которыми он обменивается, то есть служит в качестве программы-шлюза.

Все перечисленные в задаче 13.1 SCADA-приложения могут быть ОРСDA-Клиентами, поскольку имеют в наличии соответствующий драйвер. Поэтому, приобретя ОРСDA-Сервер с драйвером для ЛОМИКОНТ, можно связать Zenon и Citect с Л-110, а приобретя ОРСDA-сервер с поддержкой S7-MPI, можно полноценно совместить Trace Mode с S7-300. Таким образом в данном случае ОРСDA-Сервер можно назвать универсальным (со стороны SCADA) драйвером связи. Следует отметить, что ряд SCADA-приложений полностью базируются на ОРС (Genesis, Master SCADA).

13.1.2.6. OPC AE (Alarms & Events). ОРСА-Клиент использует ОРСАE-Сервер для контроля за процессом, т.е. за возникновением определенных событий. Эти события настраиваются в пределах Сервера. ОРСАЕ-Клиент соединяется с ОРСАЕ-Сервером и подписывается на получение сообщений о возникновении этих событий. При подписке, ОРСА-Клиент указывает дополнительные критерии фильтрации сообщений. Спецификацией поддерживается возможность квитирования сообщений ОРСА-Клиентом.

 
 
 

13.1.2.7. OPC HDA (Historical Data Access). ОРСHDA-Сервер предоставляет доступ ОРСHDA-Клиенту для получения сохраненных данных. Данный тип Сервера поддерживает два СОМ-объекта:

- OPCHDAServer,  предоставляющий доступ к архивным данным;

- OPCHDABrowser, предоставляющий доступ к списку переменных, хранимых в архиве.

Чтение архивных данных проводиться с использованием 3-х различных механизмов. Первый механизм предполагает считывание архивных данных в определенном временном диапазоне для одной или нескольких переменных, которые определены именами. Количество считанных значений ограничивается Клиентом. Второй механизм предполагает считывание архивных данных по времени их обновления (TimeStamp). Третий механизм позволяет получать статистическую информацию по сохраненным данным. В ОРС HDA интерфейсе предусмотрена возможность вставки, замены или удаления архивных данных.

В следующих подразделах рассматривается только ОРС DA технология.
 

13.1.3. Функционирования ОРС с точки зрения интегратора

Наиболее часто ОРС-технология используется в качестве универсального интерфейса к драйверам контроллеров и периферийных устройств. То есть вместе с контроллером может поставляться специальное приложение - ОРС-Сервер, который предоставляет доступ к переменным этого типа контроллера. То есть, ОРС-сервер с одной стороны обладает драйверами для связи с контроллерами по конкретным протоколам промышленных сетей, а с другой - предоставляет универсальный ОРС-интерфейс для связи с сервером SCADA-программы. В такой системе SCADA будет ОРС-Клиентом.

На рис.13.3 показана упрощенная схема функционирования работы ОРС-технологии в контексте описанной системы. База данных реального времени (БДРВ) SCADA-программы (с условным названием "SamplSCADA"), собирает данные из четырех источников: ПЛК1, ПЛК2, ПЛК3 и ПЛК4. При сборе данных с первых двух контроллеров используются драйверы связи для этих ПЛК, вернее для протоколов промышленных сетей, по которым они соединяются. Данные считываются (или записываются) с ПЛК в БДРВ. Связь с ПЛК3 и ПЛК4 производится через ОРС-Серверы с условными названиями соответственно "Sampl.OPC" и "Exmpl.OPC". Для этой цели используются драйвер ОРС-Клиент. То есть ОРС-Серверы через встроенные драйверы считывают данные с ПЛК и хранят их в своей базе данных реального времени, а SCADA-программа в свою очередь считывает данные из ОРС-Серверов. Запись данных происходит аналогично.

 

Для реализации такой связи пользователь должен:

1.         Настроить OPC-Сервер с помощью специализированного приложения-конфигуратора, поставляемого вместе с ним: создать все необходимые переменные Сервера, то есть дать им имя (ItemID) и указать источники данных в ПЛК, на которые они ссылаются.

2.         В SCADA-программе указать:

-         Название ОРС-сервера, с которым необходимо связаться (ProgID). В нашем примере это будут два сервера "Sampl.OPC" и "Exmpl.OPC". Иногда SCADA предоставляет возможность выбора ProgID из списка зарегистрированных ОРС-Серверов.

-         Для выбранной переменной в качестве источника данных указать его имя на ОРС-Сервере, то есть ItemID, который был создан на 1-м шаге. Как правило ItemID выбирается из списка, который предоставляет Browser на стороне ОРС-Клиента.

Пример 13.2. ОРС. Конфигурация ОРС-серверов и ОРС-клиента (SCADA).

Задание. Настроить ОРС-Серверы (Schneider-Aut.OFS, VIPA.OPC-Server) и SCADA (Citect) для считывания следующих переменных (рис.13.4):

- MW100, отвечающей за температуру с PLC1 (VIPA200) по сети MPI;

- %MW100, отвечающей за давление с PLC2 (TSX Micro) по сети Modbus RTU;

Для связи с контроллерами используются ОРС-Серверы:

- OFS-Servrer от Шнейдер Электрик (ProgID = Schneider-Aut.OFS), поддерживающий ряд протоколов промышленных сетей, в частности Modbus RTU;

 - VIPA OPC-Server от фирмы VIPA (ProgID = VIPA.OPCServer), поддерживающий S7 протоколы сети MPI.

 Решение. ..
1. Конфигурирование OFS. Согласно рис.13.4 на данном OPC сервере необходимо создать переменную с названием "Pressure", источником данных для которой будет переменная %MW100 на PLC2. Для конфигурирования OFS-сервера используется утилита OFS Configuration Tool.

Данные определяются следующим образом (рис.13.5):

- Создается псевдоним, указывающий на адрес конкретного устройства, с которым может обмениваться ОРС-Сервер. В нашем случае псевдоним устройства носит имя PLC2;

- Для созданного псевдонима указывается драйвер связи, адрес устройства и дополнительные параметры, уточняющие местонахождение его в сети; в нашем случае в результате конфигурирования создастся адрес: MODBUS01:1/T;

 - Для созданного псевдонима устройства указывается файл, в котором будут находиться символьные имена и соответствующие им переменные контроллера. В нашем случае выбранный файл PLC2.CSV, в котором сформирована запись:

%MW100          PRESSURE

Согласно правилам именования переменных в OFS, идентификатор нужной переменной будет формироваться следующим образом:

ItemID = Имя_псевдонима_устройства!Имя_переменной

 В нашем случае идентификатор переменной будет- PLC2!PRESSURE.

2. Конфигурирование VIPA-OPC. Конфигурирование для VIPA OPC-Server выполняется с использованием утилиты OPC Editor. Аналогично OFS, на сервере создаются устройства, в рамках которых определяются переменные, однако их порядок и форма несколько отличаются (рис.13.6).

Сначала выбирается драйвер сети (в нашем случае MPI). В рамках сети создается PLC (в нашем случае PLC1), а в пределах устройства указывается название переменной (Tag) и его адрес в ПЛК (TEMPERATURE - MW100) Согласно правилам именования переменных в VIPA OPC идентификатор переменной будет формироваться следующим образом:

ItemID = Имя_PLC/имя_переменной

 В нашем случае идентификатор переменной будет: PLC1/TEMPERATURE
3. Создание проекта для Citect. Все переменные в Citect (VariableTag) создаются в рамках виртуальных устройств (IODevices). Поэтому необходимо создать два IOD
evices, которые будут отвечать за ОРС-Серверы. Для создания IODevices воспользуемся утилитой Express Communication Wizard (рис.13.7). В обоих случаях выбирается драйвер ОРС DA Client. В полях Address указывается имя ОРС-серверов, т.е. их ProgID.

Далее необходимо создать переменные (рис.13.8) с привязкой к созданным IODevices, и в поле адреса указать соответствующие ItemID.

 
 
 

13.2. Принципы функционирования ОРС DA

13.2.1. ОРС модель взаимодействия.

13.2.1.1. Клиент-Серверная модель. Технология ОРС DA базируется на клиент-серверной архитектуре. ОРС-Клиент пользуется услугами ОРС-Сервера, используя СОМ-интерфейсы его объектов. В приведенном на рис.13.9 примере ОРС-Клиентом является SCADA-программа, задачей которой является отображение четырех переменных (%MW100-%MW103), находящихся на ПЛК. OPC-Сервер получает необходимые данные через драйверы связи и сохраняет их в своей базе данных реального времени. Для того чтобы получить доступ к данным ОРС-Сервера, ОРС-Клиент создает для себя ОРС-Group (Group1, Group2), в которых создает ОРС Item (Item1, Item2), ссылающиеся на эти данные.

ОРС-Клиент (OPC Client) - приложение, умеющее пользоваться объектами OPC-Сервера с помощью ОРС-интерфейсов (подмножество СОМ-интерфейсов).

ОРС-Сервер (OPC Server) - приложение, предоставляющее доступ к СОМ-объектам, определенным в спецификации ОРС, с помощью ОРС-интерфейсов.

К одному ОРС-Серверу могут подключиться несколько ОРС Клиентов. Кроме того, одно и то же приложение ОРС-Клиент, может одновременно пользоваться услугами нескольких ОРС-Серверов. То есть ОРС технология является мультиклиентской и мультисерверной.

13.2.1.2. Идентификация ОРС-Сервера. Так как ОРС-Сервер - это СОМ-Сервер, он регистрируется на компьютере под уникальным числовым идентификатором (GUID) и текстовым программным идентификатором (ProgID). То есть, для того чтобы для ОРС-Клиента определить с каким ОРС-сервером на том же ПК ему необходимо соединиться, в большинстве случаев достаточно указать его ProgID.

13.2.1.3. Объекты OPC-Item и идентификация данных. Объект ОРС-Item в пределах ОРС-Сервера предоставляет доступ к источнику данных (далее тег), который идентифицируется уникальным в пределах Сервера идентификатором ItemID. Поэтому, при создании ОРС-Item’а, указывается ItemID необходимого тега. Правила идентификации данных зависят от реализации ОРС-Сервера, а механизм определения их источников (например адрес устройства и переменной в ПЛК) как правило реализуется в конфигураторе этого Сервера. В примере 13.2 мы уже рассмотрели два варианта формирования ItemID, ниже более детально рассмотрены способы идентификации тегов. Здесь только отметим, что весь список ItemID может иметь древовидную иерархическую структуру, что позволяет удобнее использовать этот механизм в проектах с большим количеством данных. Для перемещения по списку/дереву идентификаторов ОРС-Сервер, как правило, содержит объект OPC Browser.

 ОРС-Item принадлежит создавшему его ОРС-Клиенту, и поэтому его не могут использовать несколько ОРС-Клиентов. Тем не менее, есть возможность нскольким ОРС-Item’ам сослаться на одни и те же данные. На рис. 13.9 два Клиента одновременно используют данные из %MW100 и %MW102, однако создают для этого различные OPC-Item. Следует отметить, что источником данных не обязательно является переменная на внешнем устройстве, это могут быть внутренние данные самого Сервера.

С каждым ОРС-Item’ом ассоциируется: текущее значение (Value), отметка времени (Time Stamp) и качество (Quality).

13.2.1.4. Группировка OPC-Item в OPC-Group. OPC-Group - объект ОРС-Сервера, предназначенный для выполнения групповых операций над ОРС-Item’ами. Так как ОРС-Item не может существовать без этого объекта, сначала ОРС-Клиент создает ОРС-Group, а затем в его пределах создает ОРС-Item’ы. В интерфейсе OPC DA 2.0 каждый ОРС-Group, как и всё его наполнение, принадлежит отдельному Клиенту. Механизм группирования позволяет разделять данные по принципу чтения/записи, периодичности операций и активировать/деактивировать обновление переменных.

13.2.2. Механизмы чтения и записи данных процесса

13.2.2.1. Общие подходы. Технология ОРС предоставляет двухсторонний доступ к данным, то есть как для чтения, так и для записи. Механизмы реализации этих сервисов практически одинаковы по принципу, однако имеют свои особенности в разных версиях спецификации ОРС DA. Мы рассмотрим их в контексте 2-й версии этой спецификации, поскольку в настоящее время она является наиболее популярной.

Чтение сводится к решению следующих вопросов:

- Когда на ОРС-Сервере должны восстанавливаться данные с устройств для каждого из ОРС-Item’ов;

- Каким образом о восстановлении данных узнает ОРС-Клиент и как он получит их состояние.

Операции чтения и записи проводятся одновременно для всех Item’ов в пределах ОРС-Group.

13.2.2.2. Синхронное чтение (Sync Read). Инициация процесса обновления переменных на ОРС-Сервере может проводиться самим ОРС-Клиентом. То есть, при необходимости, ОРС-Клиент запрашивает восстановление определенной ОРС-Group. В таком случае Клиент может заморозить выполнение своей программы (потока), пока не дождется результата чтения от ОРС-Сервера. Такой способ называется Синхронным Чтением (Sync Read). На рис.13.10 схематически изображен процесс обмена между ОРС-Клиентом и ОРС-Сервером. При необходимости Клиент запрашивает с помощью вызова метода SyncRead для OPC-Group "myGroup" и ждет пока тот не возвратит ответ.

 13.2.2.3. Асинхронное чтение (Async Read). Механизм синхронного чтения тормозит работу программы (потока) Клиента, поэтому пригоден для чтения небольших объемов данных. Альтернативой ему может быть использование Асинхронного Чтения (Async Read), которое инициирует тоже ОРС-Клиент, однако не ожидает результата обработки. Вместо этого, при окончании процесса чтения, ОРС-Сервер вызывает функцию обратного вызова ОРС-Клиента (обработчик события AsyncReadComplete), в которую передает результат чтения. Для реализации этого механизма необходимо, чтобы в объекте OPC-Group был активирован механизм Подписки (Subscript).

13.2.2.4. Периодическое Чтение с Оповещением (Periodical Read with Notify). При необходимости восстановления данных оба приведенных выше способы требуют от ОРС-Клиента каждый раз проводить запрос к ОРС-Серверу. Однако, часто данные необходимо читать периодически с определенным интервалом времени. Для этого в спецификациях OPC DA используется механизм Периодического Чтения с Оповещением (Periodical Read with Notify). При создании ОРС-Group, Клиент заказывает периодичность обновления Item’ов в рамках этой группы. Через указанные промежутки времени ОРС-Сервер сам обновляет эти данные, а результат хранит в Кеше (Cache). Если данные (Value или Quality) хотя бы для одного ОРС-Item’а в OPC-Group изменились, будет вызвана обратная функция оповещения (Notify), т.е. обработчик события DataChange, в параметрах вызова которого будут переданы новые значения. Для эффективного использования этого механизма для аналоговых переменных можно воспользоваться зоной нечувствительности (Deadband). Необходимо отметить, что в объекте OPC-Group должен быть активирован механизм Подписки и флажок Активности (ACTIVE FLAG). Кроме того, периодически обновляться будут только Активные OPC-Item.

13.2.2.5. Синхронная и асинхронная запись. Операции записи могут проводиться двумя способами: Синхронная Запись (Sync Write) и Асинхронная Запись (Async Write). Их функционирование полностью аналогично как и в операциях чтения (рис.13.11).

 

13.2.3. Идентификаторы ItemID.

13.2.3.1. Способы идентификации данных. ItemID - это уникальный, в пределах OPC-Сервера, символьный идентификатор, который однозначно идентифицирует данные (теги) на этом Сервере. То есть, он не должен указывать с какого устройства берутся данные, а только где они размещаются в Сервере.

Чаще всего ItemID создаются с помощью конфигуратора ОРС-Сервера. Именно там и конфигурируется размещение источника данных. В примере 13.2. таким способом идентифицируются теги на VIPA.OPCServer - "Temperature".

В некоторых реализациях ItemID может создаваться автоматически. В этом случае размещение источника данных, зона нечувствительности, минимум, максимум и другие настройки могут указываться в самой символьной строке идентификатора. Например, символьная строка ItemID "MODBUS01:5!%MW100" в OFS Server (OPC Server от Schneider Electric) означает, что источник данных размещается на шине Modbus у Ведомого с адресом 5, в переменной %MW100.

13.2.3.2. Доступ к списку ItemID (Объект OPCBrowser). Для удобства идентификации источника данных, ОРС-Сервер опционально может поддерживать объект-навигатор OPCBrowser. В версиях ОРС DA 1.0/2.0 и ОРС DA 3.0 реализация механизмов навигации отличается, однако и в первом и во втором случае весь перечень ItemID может формировать плоский список (flat) или иерархическое дерево (hierarchical). Иерархическая структура формируется в виде дерева, пример которого приведен на рис.13.12.

OPCBrowser, как правило, нужен только для ОРС-Клиентов, которые необходимо конфигурировать, например SCADA. В случае его отсутствия, пользователю надо хорошо понимать правила формирования символьной строки ItemID для конкретного ОРС-Сервера, ведь это не оговорено в стандарте. Так например, в строке ItemID с рис.13.12 вместо отделяющих точек могут использоваться другие символы, например "!".

PLC_Difuz

Пример 13.3. OPC. Создание OPCGroup, OPCItem и настройки восстановления, с использованием тестовой программы OPC-Client.

Задание. Необходимо с помощью тестовой программы OFS-Client создать 2 группы в пределах ОFS-Сервера, настроенного по примеру 13.2 со следующими параметрами:

- Первая группа с периодическим чтением и оповещением (период = 1с);

- Вторая группа только для синхронных операций.

Продемонстрировать работу объекта OPC Browser для OFS Server и VIPA-OPC.

Решение. OFS-Client - это тестовая программа ОРС-Клиента, которая поставляется вместе с Сервером OFS от Шнейдер Электрик. С ее помощью можно проверить работу любого ОРС-Сервера. При запуске ОРС-Клиента он предлагает выбрать один из ОРС-Серверов, зарегистрированных на ПК (рис.13.13). В нашем примере мы выбираем Schneider-Aut.OFS.

При подключении к Серверу, создаем ОРС-Group (рис.13.14). Для первой определяем скорость восстановления UpdateRate = 1000 мс, выставляем опцию Active - периодическое чтение, выставляем опцию Notifycation - активация оповещения. На рис.13.14 видно, что можно также настроить зону нечувствительности и источник чтения для группы (Cash или Device). Для второй группы опции Notifycation и Active должны быть отключены. В обоих случаях можно проводить операции синхронного чтения или записи (Read Group/Write Group). Асинхронные операции можно проводить только для первой группы, поскольку только для нее включена функция оповещения (Notifycation). Кроме того для первой группы все Item будут автоматически возобновляться на сервере 1рас / с.
 
 

Окна браузера ОРС-ItemID при подключении к OFS Server и VIPA-OPC изображены соответственно на рис.13.15 и 13.16. Из них видно, что перечень ItemID для обоих Серверов имеет иерархический вид. Выставив опцию Browse Flat можно перейти к плоской форме. Кроме того, браузер автоматически формирует ItemID при его выборе.

 
 
 

13.2.4. Работа ОРС-Клиента с удаленными ОРС серверами

 ОРС-Клиент и ОРС-Сервер на одном и том же ПК запускаются как отдельные Процессы. Обмен данными между этими Процессами происходит по правилам СОМ-технологии. Иногда возникает необходимость в соединении ОРС-Клиента с удаленным ОРС-Сервером, который находится в сети на другом ПК. Для такого соединения используются сервисы DCOM.

На рис.13.17 приведен пример, в котором ОРС-Клиент (SCADA) на ПК1 соединяется с локальным ОРС-Сервером (OPCServer1) и двумя удаленными (OPCServer2 на ПК2 и OPCServer3 на ПК3). Для реализации такого соединения для ОРС-Клиента кроме ProgID необходимо указать размещение ПК с ОРС-Сервером, а также правильно настроить DCOM-конфигуратор. Таким образом необходимо выполнить следующую последовательность:

1. Настроить DCOM Конфигуратор на узле Сервера и Клиента (см. раздел 12).

2. Указать Server Node (Имя узла ОРС Сервера) или его IP-адрес.

3. Указать ProgID Сервера.

Однако связаться с удаленным ОРС с помощью ОРС DA возможно только в случае когда узлы находятся в пределах одного домена или рабочей группы Windows и не разграничиваются брандмауэрами. Последние могут не пропустить пакеты СОМ (порты RPC как правило закрыты для доступа), поэтому для соединения через Интернет необходимо прибегать к изощренным методам. Чтобы решить эту проблему OPC Foundation предлагает технологии OPC XML и OPC UA.
 
 
 
 
Оставить комментарии Вы можете здесь http://pupena-san.blogspot.com
Comments