OPC – это набор повсеместно принятых спецификаций, предоставляющих универсальный механизм обмена данными в системах контроля и управления. Технология OPC определяет интерфейс между OPC-клиентом и OPC-серверами.
OPC-сервер – программа, получающая данные во внутреннем формате устройства или системы и преобразующая эти данные в формат OPC. OPC-сервер является источником данных для OPC-клиентов. По своей сути OPC-сервер – это некий универсальный драйвер физического оборудования, обеспечивающий взаимодействие с любым OPC-клиентом.
OPC-клиент – программа, принимающая от OPC-серверов данные в формате OPC.
Таким образом, OPC-технология обеспечивает независимость потребителей от наличия или отсутствия драйверов или протоколов, что позволяет выбирать оборудование и программное обеспечение, наиболее полно отвечающее реальным потребностям бизнеса.
Что это дает для производителя оборудования?
Универсальный механизм интеграции производимого им оборудования в любую систему, поддерживающую технологию OPC.
До создания OPC-технологии производителю промышленного оборудования приходилось создавать и поддерживать множество драйверов для наиболее распространенных систем автоматизации (или договариваться с производителями этих систем). Применение OPC-технологии позволяет отказаться от создания драйверов и заменяет их одним универсальным OPC-сервером, многократно сокращая затраты на разработку и дальнейшее сопровождение. При этом обеспечивается возможность подключения любой системы автоматизации, наиболее подходящей клиенту, а не только одной из нескольких наиболее распространенных.
Все функции ОРС-сервера описываются спецификациями этой технологии и соответствующими стандартами.
Существует довольно широкий набор интерфейсных ОРС-стандартов:
· общие стандарты для всех ОРС-спецификаций;
· для обмена оперативными данными с приложениями на C++ и Visual Basic;
· для обслуживания событий (event) и внештатных ситуаций (alarm);
· для работы с базами данными;
· для обработки прав доступа к данным и др.
Основной стандарт, называемый DA (Data Access), описывает передачу оперативных данных от оборудования или к оборудованию. По этому стандарту ОРС-клиент может взаимодействовать с ОРС-серверами от одного или нескольких производителей. Объекты ОРС-сервера напоминают обычные СОМ-объекты.
ОРС Data Access-сервер необходим для работы со встроенной системой и состоит из нескольких объектов: сервера (рис. 1.11), группы (рис. 1.12) и элемента данных (рис. 1.13).
Рисунок 1.11 — Стандартный OPC-объект — сервер
Рисунок 1.124 — OPC-группа
Рисунок 1.13 — OPC-элемент
Объект-сервер поддерживает информацию о сервере и служит контейнером для объектов-групп.
Объект-группа поддерживает информацию о самой себе и предоставляет механизм для включения и логической организации объектов-элементов. ОРС-группы создают клиентам возможность организовывать данные. Например, группа может выводить элементы на экран монитора оператора или представлять их в сообщении. Группы могут обслуживать разных клиентов.
Данные можно читать и писать. ОРС-клиент может сконфигурировать скорость, с которой ОРС-сервер будет обновлять данные клиента.
Существуют два типа групп: public и local (или private). Тип public служит для деления групп между многими клиентами, тип local предназначен для одного клиента. В пределах группы клиент определяет один или больше ОРС-элементов.
Орс-элементы устанавливают связи с источниками данных в пределах сервера. Из позиций специального интерфейса ОРС-элемент недоступный для ОРС-клиента, как объект. Иначе говоря, не существует внешнего интерфейса, который был бы определен для ОРС-элемента. Все виды доступа к ОРС-элементам осуществляются с помощью ОРС-групп, которые содержат ОРС-элементы.
Элементы-переменные не служат источниками данных, они представляют собой лишь соединение с ними. ОРС-элемент следует рассматривать не как физический источник данных, на который ссылается адрес, а как что-то специфицирующее адреса данных.
Таким образом, основной единицей данных в OPC служит переменная (item). Переменные могут быть любого типа, допустимого в OLE, – целой, вещественной, логической, строчной, датой и др. Кроме того, переменная может быть массивом.
К обязательным свойствам переменной относятся: значение (Value), тип (Type), качество переменной (Quality), метка времени (Time Stamp), права доступа (чтение, запись), частота опроса ОРС-сервером и описание переменной (назначение).
Качество предполагает, что в источниках данных возможны отказы, поэтому корректное значение переменной не всегда известно ОРС-серверу и поэтому клиент сообщает серверу о качестве переменной – хорошее, плохое, неопределенное.
Метка времени сообщает, когда переменная получила конкретное значение и качество.
Частота опроса определяет интервал чтения переменной.
Описание переменной представляет собой строчное значение, которое содержит информацию для пользователя о назначении переменной.
Существуют три способа получения ОРС-клиентом данных от ОРС-сервера: синхронное чтение, асинхронное чтение и подписка.
При синхронном чтении клиент посылает серверу запрос со списком переменных, которые его интересуют, и ждет, пока сервер его выполнит.
При асинхронном чтении клиент посылает серверу запрос, а сам продолжает работать. Когда сервер выполнил запрос, клиент получает сообщение.
В случае подписки клиент передает серверу список переменных, которые его интересуют, а сервер потом регулярно присылает клиенту информацию об изменениях значений переменных со списка. Эти списки в терминологии ОРС называют группами. Каждый клиент может поддерживать одновременно много групп с разной скоростью восстановления.
Следует учесть, что технология ОРС регламентирует только интерфейс между ОРС-клиентами и ОРС-серверами, но не устанавливает способ получения этих данных от оборудования. Однако существуют некоторые модели взаимодействия с оборудованием, когда, например, можно не обращаться для получения данных к ОРС-серверу прямо, а получить их со своего внутреннего буфера (кэша).
Переменные в ОРС-сервере могут быть сформированы или в простой список, или в «дерево», напоминающее «дерево» файлов на диске. Есть соответствующие интерфейсы для навигации по этому дереву. Предусмотрены также возможности оповещения завершения работы ОРС-сервера, запроса информации о самом сервере и запроса списка зарегистрированных групп.
Соответствующие интерфейсы предлагают ОРС-клиентам некоторые механизмы, которые сообщают о возникновении специфицированных событий или аварийных ситуаций. Они предоставляют ОРС-клиентам услуги, которые позволяют идентифицировать события и условия, а также получать текущий статус.
Кроме серверов, которые осуществляют доступ к данным DA, существуют серверы доставки сообщений типа «alarms» и «events». В ОРС alarm определяют как нерегулярную ситуацию, которая представляет собой особый случай условий. Условие (condition) — это поименованное состояние событийного ОРС-сервера или одного из его вложенных объектов. Примерами условий могут служить HighAlarm, HighHighAlarm, Normal, LowAlarm, и LowLowAlarm.
В отличие от alarm событие (event) является заметной ситуацией, которая имеет значение для ОРС-сервера и заинтересованных ОРС-клиентов. Событие может быть, а может и не быть ассоциировано с условием. Например, переходы с HighAlarm в Normal есть события, ассоциированные с условиями.
Интерфейс ОРС-сервера предлагает методы, которые позволяют ОРС-клиенту задавать следующие сервисы:
· устанавливать типы событий, которые поддерживает ОРС-сервер;
· подписываться на специфические события для того, чтобы ОРС-клиенты могли получать сообщение об этих событиях;
· осуществлять доступ к условиям и управлять условиями, создаваемыми ОРС-сервером.
Спецификации ОРС всегда содержат два набора интерфейсов: интерфейсы пользователя (Custom Interfaces) и интерфейсы автоматизации (Automation Interfaces). Последние имеют доступ к приложениям, написанным на Visual Basic (рис. 1.14).
Рисунок 1.14 — Разновидности OPC-интерфейсов
Спецификации ОРС определяют, что собой представляют интерфейсы, но не как выглядит проект. Поэтому нужно специфицировать ожидаемое поведение интерфейсов, которые используются клиентскими приложениями. При разработке ОРС-сервера следует выбрать частоту передачи данных по выделенному каналу, а также устройства, ответственные за сбор данных.
ОРС-серверы нуждаются в разработке специальных (пользовательских) интерфейсов, а как опцию могут иметь интерфейсы автоматизации. В некоторых случаях интерфейс автоматизации создается с помощью специальной DLL-оболочки интерфейса пользователя (рис. 1.15).
Рисунок 1.15 — Типичная архитектура OPC
Таким образом, клиентское ОРС-приложение взаимодействует с ОРС-сервером через специфицированный разделяемый интерфейс и специальный интерфейс пользователя или интерфейс автоматизации. Эти интерфейсы решают проблему открытого управления, т.е. обеспечивают совместимость и интерактивность разнообразных локальных устройств.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
9.4. Орс-серверная технология
OPC (OLE for Process Control)–это стандарт взаимодействия между программными компонентами системы сбора данных и управления (SCA-DA), основанный на объектной модели COM/DCOM фирмы Microsoft [16]. ОРС– это интерфейсная программная среда, с помощью которой одни при-ложения могут читать или записывать данные в другие приложения, обме-ниваться событиями, оповещать друг друга о нештатных ситуациях (тре-вогах), осуществлять доступ к данным, зарегистрированным в архивах (так называемые «исторические» данные).
Эти приложения могут распо-лагаться как на одном компьютере, так и могут быть распределенными по сети, при этом независимо от фирмы поставщика стандарт OPС, признан-ный и поддерживаемый всеми ведущими фирмами производителями SCA-DA систем и оборудования, обеспечит их совместное функционирование. В технологии ОРС различают ОРС — сервер и ОРС — клиент.
ОРС – се-рвер поставляет данные, ОРС- клиент потребляет данные. OPC-серверы это универсальное интерфейсное программное средст-во, которое разрабатывается и поставляется производителем оборудования и которое позволяет любому OPC клиенту взаимодействовать с этим обо-рудованием в унифицированном режиме записи и чтения данных.
Обо-рудование или сеть, для которого есть OPC-сервер, может использоваться вместе со SCADA системой, поддерживающей ОРС технологи. 9.4.1. OPC-технология предназначена для использования там, где ус-тановлен Microsoft DCOM (Windows NT/2000). Это могут быть АРМ диc-петчера, операторов или УСО на базе индустриальных компьютеров. Для таких устройств промышленные шины представляются в виде OPC-серве-ров.
Реализация OPC основана на объектной модели COM/DCOM фирмы Microsoft: COM – это Component Object Model, – модель многокомпонентных объектов, позволяющая приложению вызывать те или иные функции этих объектов так, как будто объекты находятся «рядом» (в адресном прост-ранстве). DCOM – Distributed (распределенная) COM.
Это тогда, когда объект находится в другой программе на том же РС или на другом РС одной локальной вычислительной сети. В DCOM вызов любой функции объекта перехватывается специальным агентом посредником, так называемой pro-xy/stub DLL, которая выполняет роль представителя объекта у обратив-шегося к нему клиента.
Proxy/stub DLL «упаковывает» параметры функ-ции и передает вызов операционной системе, которая доставляет его по назначению и заставляет реальный объект выполнить заданную функ-цию. Затем результат возвращается приложению клиенту. Удобство испо-льзования DCOM состоит в том, что приложение клиент совершенно не обязано знать, где реально находится объект.
О степени удаленности объекта оно может судить только по увеличению расхода времени на вызов функции. 9.4.2. O
PC технология основана на клиент-серверной схеме. OPC клиент (например, — SCADA), вызывает определенные функции объекта OPC – сервера, подписывается на получение определенных данных с зада-нной периодичностью.
В свою очередь OPC-сервер, опросив физическое устройство, вызывает известные функции клиента, уведомляя его о полу-чении данных и вручая сами данные. Таким образом, при OPC взаимодей-ствии используются как прямые COM вызовы (от клиента к серверу), так и обратные (callback, от сервера к клиенту) в соответствии с рис. 9.6.
Вызов функциОРС-сервера, подписка на данные 
Вызов функций ОРС-клиента, передача данных 
Рис. 9.6 Клиент — серверное взаимодействие 1) В соответствии со стандартом ОРС состоит из трех основных спецификаций: – доступа к данным реального времени (Data Access); – обработки тревог и событий (Alarms – доступа к историческим данным (Historical Data Access).
Эти три вида ОРС серверов могут быть самостоятельными, но могут быть совмещены и в одном ОРС. OPC серверы физических устройств обычно являются только серверами данных — ОРС-Data Access (DА). Сер-веры тревог и доступа к историческим данным используют ОРС-DA.
Сервер доступа к данным ОРС-DA отвечает за обеспечение к дос-тупу данных реального времени и по этой причине он занимает централь-ное место среди спецификаций OPC. Настолько центральное, что часто под термином ОРС понимается ОРС-DA.
Сервер тревог формирует определенные логические переменные, называемые состояниями (conditions), имея в качестве исходной информа-ции некую переменную (тег), полученную от ОРС- DA. Состояния изменя-ют свое значение, если переменная, например, вышла за допустимые гра-ницы.
Об изменении состояния сервер тревог оповещает клиентов, посы-лая им событие (тревогу), а клиент возвращает серверу подтверждение, что он тревогу воспринял. Сервер исторических данных получает от ОРС-DA параметры в реальном времени и архивирует их, а затем предоставляют эти данные другим приложениям (например, для построения графиков трендов).
2) Основной структурные единицей данных в ОРС является перемен-ная (Item)- элемент данных. Каждый элемент данных (т.е. фактически – параметр технологичес-кого процесса) имеет значение, время последнего обновления (timestamp) и признак качества, определяющий степень достоверности значения.
Значение переменной Item может быть любого типа, допустимого в OLE: различные целые и вещественные числа, логические данные, строка, массив и т.п. Время последнего обновления данных фиксируется и пред-ставляется с точностью до 0.1 мкс.
Данные сопровождаются признаком ка-чества — это код, содержащий в себе грубую оценку достоверности: не оп-ределено/хорошо/плохо, а на случай плохой оценки — еще и расшифров-ку, например, – неисправность датчика. Следующий уровень понятия — группы элементов (OPC Group).
Груп-па элементов создается OPC- сервером по требованию клиента, который затем может добавить в группу новые элементы элементы (Items). Клиент для OPC Group задает частоту обновления данных, сервер обновляет и передает клиенту данные OPC Group с заданной частотой. Элементов, которые стояли бы отдельно вне группы, быть не может.
Клиент может создать для себя на сервере несколько групп, разли-чающихся требуемой частотой обновления. Группа создается для каждого клиента своя, даже если состав элементов и частоты обновления совпа-дают. Отсоединение клиента приводит к уничтожению созданных для него групп.
Элементы в группе – это своего рода клиентские ссылки на некие реальные переменные (теги), находящиеся на сервере или в физическом устройстве. Понятие тега спецификацией OPC не определяется, но подразуме-вается неявно. Элементы в группу клиент добавляет по имени, и эти имена являются именами соответствующих тегов.
Клиент может либо знать нуж-ные имена заранее, либо запросить список имен тегов у сервера. Для за-проса имен тегов служит интерфейс IOPCBrowseServerAddressSpace, с по-мощью которого сервер описывает клиенту свое «пространство имен», организованное в общем случае иерархически. Пример полного имени тега: Устройство_1. Модуль_2. Аналоговый Вход_3 (точка используется в качестве разделителя).
При добавлении элемента в группу клиент всегда указывает это пол-ное имя. Заметим, что группы, создаваемые клиентом на сервере, не обяза-ны совпадать (и, как правило, не совпадают) с подразделами пространства имен сервера, элементы в группу добавляются вразнобой. Единственное, что их объединяет, – это общая частота обновления и синхронность от-правки клиенту.
Наконец, на верхней ступеньке иерархии понятий находится сам OPC-сервер. Из всех перечисленных составляющих: OPC элемент, OPC-группа и ОРС — сервер только последний является COM объектом, а все остальные объекты доступны только через его интерфейсы, которые он предоставляет клиенту.
3) Синхронизация взаимодействия в ОРС при обмене данными между клиентом и сервером может осуществляться в двух режимах — синх-ронном и асинхронном. При асинхронном варианте обмена сервер сам оповещает клиента об изменившихся значениях данных, на которые подписался клиент (с часто-той, заданной клиентом при создании группы).
При синхронном клиент осуществляет инициативное чтение или за-пись данных. Запись может быть только синхронной. 9.4.3. Пример использования ОРС в АРМ- оператора к которому подключена промышленная сеть (Profibus-DP) с 2-мя УСО представлена на рис.9.7. 
Рис. 9.7.
Одномастерная система с ОРС-сервером АРМ-оператора (на рис.9.7 – рабочая станция) выполнено на базе индустриального РС (IPC). В IPC установлена мастер-карта, которая – с одной стороны: в качестве MS осуществляет управление промышле-нной сетью Profibus-DP, включающей в себя два УСО, обеспечивающих взаимодействие с объектом, – с другой стороны: в качестве модуля устанавливается в интерфейсный канал IPC ( шина ISA или PCI) и обеспечивает подключение промыш-ленной сети к компьютеру.
Общеизвестно, что подключение к компьютеру внешнего устройства осуществляется с помощью драйвера. В данном случае в качестве внеш-него устройства выступает промышленная сеть Profibus-DP, а функцию драйвера выполняет Profibus OPC-сервер. Взаимодействие оператора с IPC осуществляется с использованием HMI/SCADA, поддерживающей OPC-технологию.
Прикладная программа взаимодействия с УСО сосредоточена в круге со стрелкой: «Цикл управ-ления». Круговая стрелка как раз и подчеркивает циклический характер управления. Логически потоки в сети Profibus делятся на три основных цикла.
1) Цикл ввода/вывода выполняется под управлением УСО (ведомого узла SL): происходит автоматический опрос модулей ввода, установленных в УСО, и строится таблица последних значений, готовых к передаче в сеть. Одновременно с этим происходит передача выходным модулям УСО но-вых значений, полученных из сети.
Длительность этого цикла зависит от количества модулей и, как правило, измеряется единицами милисекунд. 2) Цикл сетевого обмена в шине реализуется по инициативе MS: MS формирует пакеты, содержащие данные для модулей вывода каждого из SL, и принимает от них пакеты.
Цикл сетевого обмена осуществляется без участия центрального процессора рабочей станции и начинается сразу после подачи напряжения питания на сетевую карту и сетевые УСО. При взаимодействии с каждым УСО MS берет данные из определенного поля адресов специальной памяти. В эту же память после каждого цикла обмена по сети помещаются новые значения, полученные от каналов ввода.
Для того чтобы MS мог распознать, какие из участков своей памяти передать каждому из абонентов и, соответственно, какую длину пакета ожидать в ответ и что это будет обозначать, такая сеть изначально должна быть однократно сконфигурирована с помощью специальной программы. В результате работы программа-конфигуратор настраивает ведущего и ведомых участников взаимодействия и сохраняет информацию о пара-метрах сети в энергонезависимой памяти всех узлов.
Такая дисциплина работы Profibus PD не допускает “горячего” (на ходу) изменения числа участников сети и даже состава их модулей ввода/вывода, но зато обеспечивает высокую скорость обмена. 3) Цикл управления внутри рабочей станции. Эта работа возлагается на центральный процессор. Он работает с так называемым образом процес-са, который находится в памяти сетевой карты. Процессору требуется считать из памяти информацию о входных каналах, осуществить над ней необходимые преобразования и выдать управляющие воздействия, занеся в определенные ячейки памяти новые данные.
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net
Новые технологии работы с данными ОРС
В статье рассмотрены основные преимущества работы SCADA-систем с данными ОРС, особенности и некоторые недостатки существующих протоколов передачи данных. Иллюстрация возможностей и решений осуществляется на базе новой версии пакета GENESIS32 V9 фирмы Iconics.
В ЗАКЛАДКИ
Технология OPC
Сравнительно давно в АСУ ТП обмен данными между программами и устройствами осуществляется с использованием стандарта OPC. Стандарт разработан ассоциацией OPC Foundation. По сути стандарт является аналогом технологии Plug-n-Play для программного обеспечения в сфере промышленной автоматизации. В настоящее время в ассоциации более 500 членов, и поддержка стандарта осуществляется всеми крупными производителями аппаратных и программных средств АСУ ТП и промышленными ассоциациями.
Технология OPC позволяет различным программным модулям, разработанным самостоятельно или другими компаниями, взаимодействовать друг с другом через унифицированный интерфейс. Стандарт OPC описывает два типа интерфейсов для приложений. Первый тип интерфейса предназначен для обмена большими объёмами информации при высокой пропускной способности.
Это специализированный интерфейс OLE custom interface. Второй тип интерфейса – OLE Automation interface – позволяет получать доступ к данным более простым способом. Он предназначен для использования в программах, написанных на языках Visual Basic (VB) и Visual Basic для приложений (VBA).
Основным объектом данной технологии является OPC-сервер, который отвечает за получение данных, запрошенных клиентом, от соответствующего устройства управления процессом. На каждом сервере имеется некоторое количество OPC-групп, объединяющих наборы данных, запрос на получение которых поступил от клиента.
Группы на сервере могут быть доступны нескольким клиентам одновременно или только одному клиенту. OPC-группа содержит набор OPC-элементов, в которых хранятся данные, поступившие от соответствующего устройства управления процессами. Клиент может произвольно объединять элементы в группы. Схематично это изображено на рис. 1.
В основе стандарта ОРС лежит технология DCOM (Distributed Component Object Model). Эта технология, встроенная в Windows, предназначена для организации взаимодействия между различными приложениями, в том числе и между приложениями, работающими на разных компьютерах. В настоящее время DCOM является основным средством взаимодействия программ в системе. Благодаря этой технологии между программами происходит двусторонний обмен, который позволяет не только клиенту вызывать функции сервера, но и серверу вызывать функции клиента.
Но при передаче данных на большие расстояния, что безусловно необходимо для АСУ ТП, DCOM имеет серьёзные недостатки. Один из главных недостатков — неприспособленность для работы в глобальной сети Интернет. Основная причина — это применение межсетевых экранов, или брандмауэров, которые защищают компьютер от несанкционированного доступа извне.
Защита организована таким образом, что весь обмен по сети проходит через брандмауэр. Сетевой экран анализирует передаваемые пакеты, и если информация не соответствует настройкам системы безопасности, их прохождение блокируется. Технология DCOM может использовать различные транспортные протоколы для передачи данных, но преимущественно применяется TCP/IP.
Обычно брандмауэры настраивают таким образом, чтобы максимально ограничить количество портов для выхода в глобальную сеть. Порты, используемые DCOM, чаще всего не являются разрешёнными для обмена данными, и открытие их существенно ослабляет защищённость от несанкционированного доступа.
Для решения этой проблемы можно использовать технологию туннелинга (tunneling) TCP, с помощью которой осуществляется передача данных через стандартный 80-й порт брандмауэра. Этот порт обычно используется для передачи данных по HTTP-протоколу (протокол передачи гипертекста), и поэтому он, как правило, открыт. Но для осуществления туннелинга и передачи данных требуется установка специального программного обеспечения, входящего в Windows, COM Internet Services и IIS web-сервер (Internet Information Server).
Успешный доступ через DCOM происходит в том случае, когда компьютеры находятся в одном домене или в одной рабочей группе, что указывает на возможность использования туннелинга TCP соответствующим образом настроенными брандмауэрами в пределах одного домена. Кроме проблем, связанных с передачей данных, существуют проблемы с аутентификацией клиента.
Туннелинг OPC
Учитывая данные сложности, ОРС-сообщество за последние 5 лет разработало универсальный ОРС-сервер (OPC UA) для систем HMI/SCADA. Технология OPC UA позволяет обеспечить надёжную связь клиентов, доступ к серверам данных через локальные вычислительные сети и Интернет, защищённое использование web-служб (http://www.opcfoundation.org).
Фирма Iconics входит в число основателей ОРС-сообщества, давно и успешно работает в области создания приложений, базирующихся на ОРС-технологии. В новой версии SCADA-системы GENESIS32 V9 Iconics используется встроенная поддержка технологии OPC UA и туннелинг OPC (компонент DataWorX32).
Новая технология туннелинга OPC включена во все модификации DataWorX32 V9 и позволяет связывать удалённый OPC-сервер с локальными клиентами устойчивым и безопасным способом. Туннелинг OPC основан на мощной коммуникационной платформе GenBroker™, которая обеспечивает высокоэффективную и устойчивую связь, заменяя протокол DCOM Microsoft. Функциональная схема туннелинга OPC представлена на рис. 2.
Все OPC совместимые приложения-клиенты могут обмениваться данными с локальными устройствами или по сети. Кроме того, обмен может осуществляться более чем с одним сервером OPC одновременно.
Любое приложение-клиент OPC может обмениваться данными с любым OPC-сервером данных (OPC DA), OPC-сервером тревог и событий (OPC A
15. OPC-технология
Урок 3 Что такое ОРС сервер Multi Protocol MasterOPC Server
Туннелинг OPC в DataWorX32 V9 полностью совместим с OPC-стандартом, не нарушает систему сетевой защиты IT, поддерживает связь по LAN, WAN и Интернет со всеми атрибутами встроенной безопасности и полностью поддерживает открытые стандарты промышленности и протоколы, такие как:
- OPC доступа к данным (DA 3.0);
- OPC тревог и событий;
- OPC доступа к историческим данным;
- OPC единой архитектуры (UA);
- протоколы связи TCP/IP и XML.
Группировка, архивация и резервирование данных OPC
Одной из важных характеристик пакета DataWorX32 является инструмент группировки OPC-тегов и построения мостов данных. Допустим, нам необходимо использовать данные ОРС-серверов с двумя различными протоколами. Для этого в конфигураторе DataWorX32 указываем в каталоге Bridging навигатора источники данных ОРС-серверов, настраиваем тип регистра и свойства данных. Затем запускаем на исполнение, и ОРС-теги различных протоколов становятся сгруппированными и доступными для приложений, являющихся ОРС-клиентами.
Другой важной характеристикой DataWorX32 является возможность группировки ОРС-данных различных ОРС-серверов. Схема механизма группировки показана на рис. 3.
Часто в очень больших проектах различные приложения-клиенты OPC обращаются к одним и тем же OPC-серверам. Например, в экранной форме GraphWorX32 необходимо отображать уровень жидкости в резервуаре, в AlarmWorX32 нужно контролировать и сигнализировать о состоянии того же самого значения уровня жидкости, в TrendWorX32 давать его графическое представление и т.п. Это приводит к увеличению загрузки OPC-сервера, поскольку одни и те же данные будут запрашиваться неоднократно.
Таким образом, когда многие клиенты запрашивают данные от сервера OPC, DataWorX32 проводит мониторинг OPC-серверов и группирует данные по запросам клиентов. Часто требуется оптимизировать работу, выполняемую серверами ввода/вывода на низком уровне (например для увеличения скорости архивации). DataWorX32 может выступать «посредником» между клиентами и серверами и позволяет оптимизировать этот процесс. Это наиболее выгодно, когда приходится взаимодействовать с удалёнными серверами по сети.
Новый DataWorX32 — единственный продукт, который поддерживает три самых важных OPC-стандарта (DA, Ahttps://www.cta.ru/articles/po/instrumentalnye-sistemy/125105/» target=»_blank»]www.cta.ru[/mask_link]