opc технология что это
На днях пришлось крепко повозиться с настройкой вызова удалённого сервера по протоколу OPC DA 2.05a, и эта информация бы очень пригодилась, знай я её заранее.
1. Что такое OPC DA и в частности OPC DA 2.05a
В общем случае OPC — это набор открытых протоколов, регламентирующих взаимодействие между собой различных объектов автоматизации, таких как SCADA-системы, к примеру. OPC DA (Data Access) — это один из таких протоколов, он обеспечивает обмен данными с устройствами или программными компонентами. В моем случае по этому протоколу нужно было периодически забирать данные со SCADA-системы. И самое важное — OPC DA работает на базе технологии COM, так что взаимодействие с OPC сервером по сути сводится к взаимодействию с COM сервером.
2. Какие есть библиотеки
Бинарники от Opc Foundation
Компоненты от Advasol
Библиотека OPCDOTNET
Библиотека от энтузиаста на codeproject.com. Ничего не могу сказать, но именно её код использовал мой предшественник, который реализовал локальное взаимодействие с OPC сервером. Судя по тому, что написано в статье, она как раз для локального взаимодействия и предназначена. Плюсы — доступные исходники, наличие тестового клиента, отсутствие зависимостей.
3. Можно ли написать код без использования библиотек
В принципе, ничего сложного в этом нет, если вы имели опыт взаимодействия с COM/DCOM приложениями. А тем, кто как и я, не особо разбирается в этих технологиях, могу порекомендовать писать код, поглядывая на декомпилированные исходники библиотеки от OPC Foundation. По сути, для взаимодействия с OPC сервером достаточно всего лишь сделать интеропы на необходимые интерфейсы, получить их и дергать методы.
4. Проблемы
— Тестовый клиент не подключается с ошибкой RPC сервер недоступен — проверьте доступность портов, порта номер 135 как минимум (основной порт DCOM).
— Access Denied — придется повозиться с настройкой как сервера, так и клиента. См. ссылки внизу
— CLSID is not registered — проверьте, установлен ли у вас Core Components, возможно их не хватает. Либо проверьте Target Platform сборки, осуществляющей интероп. Может быть, там AnyCPU а должно быть x86.
— CoCreateInstanceEx возвращает валидный COM объект, но при касте его к COM интерфейсам вываливается Access Denied (0x80070001). С этой проблемой я возился полдня. Эта штука происходит, когда для доступа к серверу необходимо указать юзера и пароль. Вы вызываете CoCreateInstanceEx, заполнив перед этим SERVER_INFO, и вам приходит ссылка на объект. Однако следующие вызовы QueryInterface не сохраняют параметров доступа, которые вы указали при получении объекта, и это приводит к Access Denied. Решение — вызвать магическую функцию CoInitializeSecurity, которая установит дефолтные параметры безопасности для COM-вызовов. Код:
При вызове этой функции может случиться ошибка RPC_E_TOO_LATE. Эта ошибка возникает обычно из-за хост-процесса Visual Studio, который неявно вызывает CoInitializeSecurity при старте. Для решения проблемы достаточно отключить использование хост-процесса в настройках проекта.
5. Ссылки по теме
OPC Training Institute — сайт с множеством отлично оформленных статей, которые помогают в случае проблем. Например, как настроить DCOM, какие возможные причины ошибки RPC server is not available итд. Требует регистрации, регистрация бесплатна.
Туториалы по настройке DCOM — еще 1 хорошо оформленный туториал для настройки.
Opc технология что это
OPC (OLE for Process Control) – промышленный стандарт, созданный консорциумом производителей оборудования и программного обеспечения при участии Microsoft. Этот стандарт описывает интерфейс обмена данными между устройствами управления технологическими процессами. Главной целью его создания было предоставление разработчикам систем диспетчеризации некоторую независимость от конкретного типа контроллеров и устройств ввода-вывода. OPC основывается на технологии OLE/COM/DCOM компании Microsoft.
Основные причины создания OPC
Довольно много программ-клиентов может получать данные из различных источников и делать их доступными для драйверов независимых разработчиков. Но при этом возникают следующие проблемы:
Производители оборудования стараются решить эту проблему с помощью разработки дополнительных драйверов. Однако эти попытки встречают сильное сопротивление разработчиков систем диспетчеризации, которые должны, в этом случае, усложнять свои клиентские протоколы.
OPC проводит четкую разграничительную линию между производителями оборудования и разработчиками драйверов. Данная технология предоставляет механизм сбора данных из различных источников и передачу этих данных любой клиентской программе независимо от типа используемого оборудования.
OPC был разработан для обеспечения доступа клиентской программы к нижнему уровню технологического процесса в наиболее удобной форме. Широкое распространение технологии OPC в промышленности имеет следующие преимущества:
Стандарт обмена данными OPC базируется на распространенной общепринятой схеме Клиент-Сервер. Эта архитектура позволяет подключить множество клиентов к одному серверу. И наоборот, данный стандарт позволяет использовать одному клиенту различные ОРС-серверы.
SCADA-программы диспетчеризации являются OPC-клиентами, получающими данные технологического процесса из OPC-серверов. OPC-серверы опираются на коммуникационный протокол представленного оборудования. Соединение с OPC-серверами происходит либо локально в пределах одного компьютера, либо через сеть, что расширяет возможности в построении топологии сбора данных при помощи OPC-серверов.
Типы спецификаций OPC
Стандарт OPC был создан на базе спецификаций OPC. В настоящее время получили наибольшее распространение следующие спецификации:
Сейчас в разработке находятся еще две специфиации: OPC Data Access 3.0 и OPC XML.
В спецификации OPC Data Access необходимо следить за использованием версии данной спецификации: сервер OPC Data Access 1.0 может общаться только с клиентом OPC Data Access 1.0 client. Поэтому удобней, если OPC-сервер поддерживает несколько версий OPC-спецификации.
VDBOPC-сервер является OPC-сервером, обеспечивающим доступ OPC-клиентов к данным согласно спецификаций OPC DA 1.0 и 2.0, OPC AE 1.1. При этом он также является OPC-клиентом, который имеет возможность получать данные из OPC-серверов устройств ввода-вывода согласно спецификаций OPC DA 1.0 и 2.0, OPC AE 1.1.
Разработка ОРС-модулей
С точки зрения программирования, существует несколько языков программирования для написания клиентской программы: C/C++, Visual Basic, Delphi и т.д. Чтобы соответствовать современным требованиям к средам разработки, спецификации OPC содержат два различных подхода к написанию OPC-клиента. Для внедрения его в программу, написанную на C/C++, используется Custom interface, а для программ на Visual Basic, используйте Automation Interface. В основном, OPC-серверы пишутся на C/C++.
Для установки надежного соединения между OPC-сервером и OPC-клиентом, написанными на разных языках, используется OPC Automation Wrapper. Он организует взаимосвязь между OPC-сервером, написанным на C/C++ и приложением на Visual Basic.
Операционные системы
Один из необходимых компонентов для работы OPC-коммуникаций – COM и его сетевая версия DCOM. DCOM – стандартный компонент для операционных систем Windows98, Windows NT 4.0, Windows 2000 и WindowsXP. Для работы в Windows95 DCOM нужно установить. Перечисленные операционные системы позволяют передавать данные в рамках одного компьютера или через локальную сеть.
В Windows CE сетевые возможности появились в версии 3.0. Сейчас стандарт OPC был разработан и для операционной системы Linux.
Связь OPC-сервера с процессом
Первый шаг в конфигурации OPC-клиента – установить на компьютер OPC-сервер (локальный или сетевой). При установлении связи OPC-клиента с OPC-сервером, технология COM предоставляет механизм сканирования доступных OPC-серверов на указанном компьютере, что позволяет быстро установить соединение с OPC-сервером. Это сканирование называется OPC server browsing.
Второй шаг – это связать данные из конфигурации OPC-сервера с конфигурацией OPC-клиента. Обеспечивается это с помощью загрузки данных (item browsing), которая поддерживается и OPC-сервером и OPC-клиентом. После этого необходимо связать переменные базы данных OPC-клиента с переменными OPC-сервера. Если OPC-сервер или OPC-клиент не поддерживают загрузку данных, конфигурирование OPC-клиента превращается в довольно длительную работу. В этом случае связывание данных обеспечивается вручную согласно документации на OPC-сервер по правилам именования и расположения данных внутри сервера.
OPC-сервер
OPC (OLE for Process Control) — семейство программных технологий, предоставляющих единый интерфейс для управления объектами автоматизации и технологическими процессами. Многие из OPC протоколов базируются на Windows-технологиях: OLE, ActiveX, COM/DCOM. Такие OPC протоколы, как OPC XML DA и OPC UA являются платформенно-независимыми.
Создание и поддержку спецификаций OPC координирует международная некоммерческая организация OPC Foundation, созданная в 1994 году ведущими производителями средств промышленной автоматизации.
Девиз OPC: открытые коммуникации по открытым протоколам.
Содержание
Стандарты
OPC DA (Data Access)
Это основной и наиболее востребованный стандарт. Описывает набор функций обмена данными в реальном времени с ПЛК, РСУ, ЧМИ, ЧПУ и другими устройствами.
OPC AE (Alarms & Events)
Предоставляет функции уведомления по требованию о различных событиях: аварийные ситуациии, действия оператора, информационные сообщения и другие.
Предоставляет функции шагового и рецептурного управления технологическим процессом (в соответствии с стандартом S88.01)
OPC DX (Data eXchange)
Предоставляет функции организации обмена данными между OPC-серверами через сеть
OPC HDA (Historical Data Access)
В то время как OPC Data Access предоставляет доступ к данным изменяющимся в реальном времени, OPC Historical Data Access предоставляет доступ к уже сохраненным данным.
Определяет функции организации прав доступа клиентов к данным системы управления через OPC-сервер.
OPC XML-DA (XML-Data Access)
Предоставляет гибкий, управляемый правилами формат обмена данными через HTTP.
OPC UA (Unified Architecture)
Новая спецификация, которая не основана на технологии Microsoft COM, что предоставляет кросс-платформенную совместимость.
Назначение
Стандарт OPC разрабатывался с целью сократить затраты на создание и сопровождение приложений промышленной автоматизации. В начале 90-ых у разработчиков промышленного ПО возникла потребность в универсальном инструменте обмена данными с устройствами разных производителей или по разным протоколам обмена данными.
Суть OPC проста — предоставить разработчикам промышленных программ универсальный фиксированный интерфейс (то есть набор функций) обмена данными с любыми устройствами. В то же время разработчики устройств предоставляют программу, реализующую этот интерфейс (набор функций).
Версии
На данный момент используется OPC версии 3.0, однако наиболее распространенной версией пока является 2.05a. Недавно разработанный стандарт OPC UA (Unified Architecture) унифицирует набор функций для обмена данными, регистрации событий, хранения данных, обеспечения безопасности данных.
OPC Version 2.05a
Наиболее широко используемая. В этом стандарте помимо синхронного обмена данными, введена поддержка асинхронного обмена данными. Асинхронный обмен данных позволяет продолжать выполнение программы без ожидания ответа устройства. Этот метод снижает нагрузку на сеть и должен быть рекомендован как основной. Получение данных реализуется с помощью callback-функции пользовательской программы, которая вызывается в момент прихода ответа от устройства.
OPC Unified Architecture
Инструментарий
Чаще всего для создания приложений с поддержкой OPC используют языки программирования C++, C# или Visual Basic.
Уровни управления
Исходя из области применения OPC-серверов в АСУ предприятия различают несколько уровней управления:
Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или даже «соседу».
Возможные области применения OPC-серверов в АСУ предприятия
Если имеется оборудование, например плата АЦП, управляемая через драйвер на компьютере с Windows или другой ОС, поддерживающей DCOM, то это самый главный кандидат на реализацию OPC-сервера непосредственно поверх драйвера.
Замена устройства не потребует изменения остальных приложений: OPC-сервер изменяется, но сам OPC-интерфейс поверх него остается прежним.
При наличии устройства, управляемого через какой-нибудь сетевой протокол, вполне возможна реализация OPC-сервера, получающего данные по этому протоколу. Единственная особенность — следует предусмотреть механизмы восстановления связи в случае сбоев.
Несколько более сложной будет схема при работе управляющих приложений на компьютере, не поддерживающем DCOM. В этом случае применим двухкомпонентный OPC-сервер. На стороне ОС, не поддерживающей COM, устанавливается сетевой модуль, который, с одной стороны, связан с приложением(ями), а с другой — через сеть с OPC-сервером. Заметим, что сетевой модуль может быть стандартным, как, например, ISaNet в системе ISaGRAF. В этом случае необходимо разработать только OPC-сервер. Иногда сетевой модуль создается специально для OPC-сервера. Возможна даже реализация, при которой этот модуль не ориентирован на конкретное приложение, а предоставляет некоторый API-интерфейс для любых приложений, желающих обслуживаться с помощью OPC. Так действует OPC-сервер для операционной системы полевой шины, такой, как Profibus или fieldbus-сети, а OPC-сервер будет взаимодействовать с этой сетью через драйвер адаптера. В Internet можно найти немало таких примеров.
Идея подобной схемы достаточно очевидна. Сеть полевой шины работает в жестком реальном времени, а OPC предоставляет менее требовательный шлюз к этой сети из приложений более высокого уровня.
Можно назвать много других мест применения OPC: для работы с базами данных в качестве вспомогательных или промежуточных OPC-серверов и т. д. Технология DCOM не очень пригодна для глобальных сетей. Поэтому для привлечения к OPC-технологии Internet-технологий возможен такой путь: расширение Web-сервера является OPC-клиентом, собирающим данные от OPC-серверов. А на стороне клиентов запускается динамическая html- или xml-страница, получающая данные от этого Web-сервера. Ее можно сделать даже OPC-сервером для других приложений.
Полезность применения OPC с точки зрения интеграции достаточно прозрачна и вытекает из самой сути OPC. Это стандарт на интерфейс обмена данными с оборудованием. Первое преимущество — если вы заменяете какой-нибудь компонент, то нет нужды корректировать другое ПО, так как даже при замене драйвера поверх него работает OPC. Второе — если вы хотите добавить в систему новые программы, нет необходимости предусматривать в них драйверы устройств, кроме OPC-клиента, разумеется. Ну и так далее.
Состояние дел
В настоящее время общепризнанным стандартом является только спецификация DA OPC, а остальные спецификации только начинают завоевывать себе место под солнцем. Не все спецификации завершены, по крайней мере, с точки зрения интерфейса автоматизации (например, для ОРС-Batch уже существует версия 2.0 custom-интерфейса, и только 1.0 — для интерфейса автоматизации. Для некоторых других спецификаций тоже существует отставание интерфейсов автоматизации от custom-интерфейсов; для ОРС Security спецификации на интерфейс автоматизации вообще не существует).
Соответственно широкое распространение получил лишь стандарт OPC DA. Можно сказать, что сейчас действительно очень многие производители снабжают свои продукты OPC DA серверами. Чего нельзя сказать о других спецификациях.
Среди программ высокого уровня аналогичная картина. Спросом пользуется лишь OPC DA. Все известные
Из операционных систем технологию DCOM поддерживают следующие:
В других распространенных операционных системах поддержки DCOM нет.
Перспективы
Итак, в настоящее время картина далеко не идеальна. Еще довольно много оборудования и ПО не охвачено OPC-технологиями. Даже технологией DA. Но нам представляется, что сейчас в мире налицо некий бум OPC, по крайней мере, в отношении опять же DA. Думается также, что Microsoft рано или поздно доведет все до желаемого уровня по всем направлениям. Тем более что альтернативных вариантов пока нет. Мы имеем в виду не COM/DCOM, а именно спецификации на обмен технологическими данными. Поскольку для COM/DCOM замена как раз имеется — CORBA. Это действительно изначально платформенно-независимая технология взаимодействия приложений. Но это не обмен технологическими данными, реализующий более высокий уровень абстракции. Кстати, заметим, что на рынке имеются OPC-шлюзы к CORBA (это возможно, как и к любому другому протоколу).
Однако, несмотря на такие планы, организация OPC Foundation своей политикой сдерживает развитие стандарта. Документация с описанием интерфейсов доступна только членам данной организации. Членство стоит от нескольких тысяч долларов, что недоступно не только для разработчиков-одиночек, но даже для многих организаций. Этим и объясняется популярность OPC DA, документация по данному интерфейсу долгое время была доступна свободно. Как результат многие фирмы, не желающие связываться с довольно капризной технологией, имеющие в штате хороших программистов нижнего уровня и работающие с ограниченной номенклатурой контроллеров используют для своих SCADA-пакетов технологию CORBA.
Заключение
Технология OPC предлагает стандарты для обмена технологическими данными, в которые заложены самые широкие возможности. Учитывая большой авторитет вовлеченных в данную деятельность фирм, можно ожидать, что технология OPC будет набирать силу. Это перспективная технология для интеграции разнородных систем. Хотя процесс становления еще далеко не завершен и есть много проблем, которые предстоит решить.
Opc server что это такое
Опубликована в журнале Automatizace, No. 10/2000
Эта статья посвящена обзору технологии OPC. Она описывает основные понятия данной технологии, причины ее разработки и описывает архитектуру и спецификации ОРС.
1. Что такое OPC?
OPC (OLE for Process Control) – промышленный стандарт, созданный консорциумом всемирно известных производителей оборудования и программного обеспечения при участии Microsoft. Этот стандарт описывает интерфейс обмена данными между устройствами управления технологическими процессами. Главной целью было предоставить разработчикам систем диспетчеризации некоторую независимость от конкретного типа контроллеров. OPC основывается на технологии OLE/COM/DCOM компании Microsoft, Inc.
2. Основные причины создания OPC?
Довольно много программ-клиентов может получать данные из различных источников и делать их доступными для драйверов независимых разработчиков. Но при этом возникают следующие проблемы:
Производители оборудования стараются решить эту проблему с помощью разработки дополнительных драйверов. Однако эти попытки встречают сильное сопротивление разработчиков систем диспетчеризации, которые должны, в этом случае, усложнять свои клиентские протоколы.
OPC проводит четкую разграничительную линию между производителями оборудования и разработчиками драйверов. Данная технология предоставляет механизм сбора данных из различных источников и передачу этих данных любой клиентской программе вне зависимости от типа используемого оборудования. Это позволяет разработчикам сосредоточиться на производительности и оптимизации работы серверной части, которая отвечает за сбор данных.
3. Преимущества технологии OPC
OPC был разработан для обеспечения доступа клиентской программы к нижнему уровню технологического процесса в наиболее удобной форме. Широкое распространение технологии OPC в промышленности имеет следующие преимущества:
4. Стандарты и спецификации OPC, OPC Foundation
Разработку стандартов OPC, их описание, поддержку и пропаганду взяло на себя OPC Foundation, добровольная международная организация, расположенная в Boca Raton, Флорида, США. Сейчас организация насчитывает более 250 членов, в число которых входят компании, занимающие лидирующие позиции в разработке программ для мониторинга, визуализации и диспетчеризации, а также других приложений для управления технологическими процессами, такие как Honeywell, Fisher-Rosemount, Siemens, Wonderware, Intellution и другие. Microsoft, Inc. также является членом OPC Foundation, принимая участие в разработке новых спецификаций. Компания Merz, s.r.o. – единственный представитель Чехии в OPC Foundation.
5. Архитектура OPC
Стандарт обмена данными OPC базируется на распространенной общепринятой схеме Клиент-Сервер. Эта архитектура позволяет подключить множество клиентов к одному серверу. И наоборот, данный стандарт позволяет использования одним клиентом различных ОРС-серверов.
Рисунок 2: Архитектура OPC-клиент/ OPC-сервер в промышленной информационной системе.
5.1. Применение OPC в промышленных информационных системах.
В центральной части иллюстрации ( Process Management ) показаны еще три компьютера. На этих компьютерах установлен OPC-клиент – программа диспетчеризации – SCADA HMI ( Supervisory Control And Data Acquisition Human Machine Interface ). Соединение с OPC-серверами происходит через локальную сеть (LAN), что расширяет возможности в построении топологии сбора данных при помощи OPC-серверов.
OPC-серверы опираются на коммуникационный протокол представленного оборудования (например, ПЛК). Не смотря на попытки увеличить в коммуникациях долю стандартных протоколов (Profibus, Interbus, CANBus и т.д.), сейчас трудно сказать, на основании чего лучше строить системы обмена данными: на базе специфических протоколов производителей оборудования или более стандартных протоколов полевых шин. По этой причине номенклатура OPC-серверов практически копирует номенклатуру наиболее популярных систем автоматического управления.
5.2. Типы спецификаций OPC
Стандарт OPC был создан на базе спецификаций OPC. В настоящее время получили наибольшее распространение следующие спецификации:
Сейчас в разработке находятся еще две специфиации:
Рисунок 2 демонстрирует пример связи OPC-сервера и OPC-клиента при использовании одной OPC спецификации. Однако в спецификации OPC Data Access необходимо следить за использованием версии данной спецификации: сервер OPC Data Access 1.0 может общаться только с клиентом OPC Data Access 1.0 client. Поэтому удобней, если OPC-сервер поддерживает несколько версий OPC-спецификации.
5.3. Написание ОРС-модулей на разных языках программирования
5.4. OPC и Internet
В настоящее время, OPC Foundation разрабатывает новую спецификацию – OPC XML. Ее цель – разработать гибкий и удобный интерфейс для обмена данными через OPC, используя XML (Extensible Markup Language) в приложениях Internet/Intranet. Функции XML позволяют очень легко записывать любые структуры данных и, в то же время, передавать данные в виде XML-файлов, удобных для пересылки через Internet.
5.5. OPC и управление дозированием
OPC Batch – другая спецификация OPC, которая уже широко применяется в автоматике. Ее используют для посылки пропорций дозирования в технологические процессы и отслеживания выполнения этих пропорций (лабораторные системы, дозаторы, весовые системы и т.п.). Очень важный факт состоит в том, что каждый OPC Batch сервер (клиент) одновременно является OPC Data Access 2.0 сервером (клиентом). Другими словами, OPC Batch сервер (клиент) включает в себя, кроме спецификации OPC Batch, также и спецификацию OPC Data Access 2.0, включая некоторые дополнительные интерфейсы (например, загрузка переменных).
6. Операционные системы
Один из необходимых компонентов для работы OPC-коммуникаций – COM и его сетевая версия DCOM. DCOM – стандартный компонент для операционных систем Windows NT 4.0, Windows 2000 и Windows 98. Для работы в Windows 95 DCOM нужно установить. Все эти операционные системы позволяют передавать данные в рамках одного компьютера или через локальную сеть. В Windows CE сетевые возможности появились в версии 3.0. Сейчас стандарт OPC был разработан и для операционной системы Linux.
7. Связь OPC-сервера с процессом
Динамическое добавление данных/Dynamic adding of items предоставляет еще более удобную методику конфигурирования OPC-клиента. С ее помощью можно создавать (или удалять) и сразу же устанавливать связь с новыми источниками данных в OPC-сервере, не останавливая ни сервер, ни клиент. В настоящее время, эта функция реализована всего в нескольких OPC серверах (клиентах), но удобство, которая она предоставляет при конфигурировании OPC-клиента, должно привести к ее широкому распространению.
8. Заключение
Какое же будущее у технологии OPC? OPC-сервера включаются в оборудование все большего числа производителей. В то же время, увеличивается число разработчиков систем диспетчеризации, которые поддерживают сбор данных через OPC-сервер с помощью собственных OPC-клиентов. И если так пойдет и дальше, то технология OPC постепенно станет всемирным стандартом для обмена данными в промышленных информационных системах.
9. Дополнительная информация
[1] Каталог продукции / Спецификации OPC, март 2000. CD-ROM, OPC Foundation
[2] http://www.opcfoundation.org/
[3] http://www.opceurope.org/
Опубликовано в журнале Automatizace, No. 10/2000
OPC — набор спецификаций стандартов. Каждый стандарт описывает набор функций определенного назначения. Текущие стандарты:
OPC DA (Data Access)
Это основной и наиболее востребованный стандарт. Описывает набор функций обмена данными в реальном времени с ПЛК, РСУ, ЧМИ, ЧПУ и другими устройствами.
OPC AE (Alarms & Events)
Предоставляет функции уведомления по требованию о различных событиях: аварийные ситуациии, действия оператора, информационные сообщения и другие.
Предоставляет функции шагового и рецептурного управления технологическим процессом (в соответствии с стандартом S88.01)
OPC DX (Data eXchange)
Предоставляет функции организации обмена данными между OPC-серверами через сеть
OPC HDA (Historical Data Access)
В то время как OPC Data Access предоставляет доступ к данным изменяющимся в реальном времени, OPC Historical Data Access предоставляет доступ к уже сохраненным данным.
Определяет функции организации прав доступа клиентов к данным системы управления через OPC-сервер.
OPC XML-DA (XML-Data Access)
Предоставляет гибкий, управляемый правилами формат обмена данными через HTTP.
OPC UA (Unified Architecture)
Новая спецификация, которая не основана на технологии Microsoft COM, что предоставляет кросс-платформенную совместимость.
Назначение
Стандарт OPC разрабатывался с целью сократить затраты на создание и сопровождение приложений промышленной автоматизации. В начале 90-ых у разработчиков промышленного ПО возникла потребность в универсальном инструменте обмена данными с устройствами разных производителей или по разным протоколам обмена данными.
Суть OPC проста — предоставить разработчикам промышленных программ универсальный фиксированный интерфейс (то есть набор функций) обмена данными с любыми устройствами. В то же время разработчики устройств предоставляют программу, реализующую этот интерфейс (набор функций).
Версии
На данный момент используется OPC версии 3.0, однако наиболее распространенной версией пока является 2.05a. Недавно разработанный стандарт OPC UA (Unified Architecture) унифицирует набор функций для обмена данными, регистрации событий, хранения данных, обеспечения безопасности данных.
OPC Version 2.05a
Наиболее широко используемая. В этом стандарте помимо синхронного обмена данными, введена поддержка асинхронного обмена данными. Асинхронный обмен данных позволяет продолжать выполнение программы без ожидания ответа устройства. Этот метод снижает нагрузку на сеть и должен быть рекомендован как основной. Получение данных реализуется с помощью callback-функции пользовательской программы, которая вызывается в момент прихода ответа от устройства.
OPC Unified Architecture
Инструментарий
Чаще всего для создания приложений с поддержкой OPC используют языки программирования C++, C# или Visual Basic.
Уровни управления
Исходя из области применения OPC-серверов в АСУ предприятия различают несколько уровней управления:
Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или даже «соседу».
Возможные области применения OPC-серверов в АСУ предприятия
Если имеется оборудование, например плата АЦП, управляемая через драйвер на компьютере с Windows или другой ОС, поддерживающей DCOM, то это самый главный кандидат на реализацию OPC-сервера непосредственно поверх драйвера.
Замена устройства не потребует изменения остальных приложений: OPC-сервер изменяется, но сам OPC-интерфейс поверх него остается прежним.
При наличии устройства, управляемого через какой-нибудь сетевой протокол, вполне возможна реализация OPC-сервера, получающего данные по этому протоколу. Единственная особенность — следует предусмотреть механизмы восстановления связи в случае сбоев.
Несколько более сложной будет схема при работе управляющих приложений на компьютере, не поддерживающем DCOM. В этом случае применим двухкомпонентный OPC-сервер. На стороне ОС, не поддерживающей COM, устанавливается сетевой модуль, который, с одной стороны, связан с приложением(ями), а с другой — через сеть с OPC-сервером. Заметим, что сетевой модуль может быть стандартным, как, например, ISaNet в системе ISaGRAF. В этом случае необходимо разработать только OPC-сервер. Иногда сетевой модуль создается специально для OPC-сервера. Возможна даже реализация, при которой этот модуль не ориентирован на конкретное приложение, а предоставляет некоторый API-интерфейс для любых приложений, желающих обслуживаться с помощью OPC. Так действует OPC-сервер для операционной системы полевой шины, такой, как Profibus или fieldbus-сети, а OPC-сервер будет взаимодействовать с этой сетью через драйвер адаптера. В Internet можно найти немало таких примеров.
Идея подобной схемы достаточно очевидна. Сеть полевой шины работает в жестком реальном времени, а OPC предоставляет менее требовательный шлюз к этой сети из приложений более высокого уровня.
Можно назвать много других мест применения OPC: для работы с базами данных в качестве вспомогательных или промежуточных OPC-серверов и т. д. Технология DCOM не очень пригодна для глобальных сетей. Поэтому для привлечения к OPC-технологии Internet-технологий возможен такой путь: расширение Web-сервера является OPC-клиентом, собирающим данные от OPC-серверов. А на стороне клиентов запускается динамическая html- или xml-страница, получающая данные от этого Web-сервера. Ее можно сделать даже OPC-сервером для других приложений.
Полезность применения OPC с точки зрения интеграции достаточно прозрачна и вытекает из самой сути OPC. Это стандарт на интерфейс обмена данными с оборудованием. Первое преимущество — если вы заменяете какой-нибудь компонент, то нет нужды корректировать другое ПО, так как даже при замене драйвера поверх него работает OPC. Второе — если вы хотите добавить в систему новые программы, нет необходимости предусматривать в них драйверы устройств, кроме OPC-клиента, разумеется. Ну и так далее.
Состояние дел
В настоящее время общепризнанным стандартом является только спецификация DA OPC, а остальные спецификации только начинают завоевывать себе место под солнцем. Не все спецификации завершены, по крайней мере, с точки зрения интерфейса автоматизации (например, для ОРС-Batch уже существует версия 2.0 custom-интерфейса, и только 1.0 — для интерфейса автоматизации. Для некоторых других спецификаций тоже существует отставание интерфейсов автоматизации от custom-интерфейсов; для ОРС Security спецификации на интерфейс автоматизации вообще не существует).
Соответственно широкое распространение получил лишь стандарт OPC DA. Можно сказать, что сейчас действительно очень многие производители снабжают свои продукты OPC DA серверами. Чего нельзя сказать о других спецификациях.
Среди программ высокого уровня аналогичная картина. Спросом пользуется лишь OPC DA. Все известные
Из операционных систем технологию DCOM поддерживают следующие:
В других распространенных операционных системах поддержки DCOM нет.
Перспективы
Итак, в настоящее время картина далеко не идеальна. Еще довольно много оборудования и ПО не охвачено OPC-технологиями. Даже технологией DA. Но нам представляется, что сейчас в мире налицо некий бум OPC, по крайней мере, в отношении опять же DA. Думается также, что Microsoft рано или поздно доведет все до желаемого уровня по всем направлениям. Тем более что альтернативных вариантов пока нет. Мы имеем в виду не COM/DCOM, а именно спецификации на обмен технологическими данными. Поскольку для COM/DCOM замена как раз имеется — CORBA. Это действительно изначально платформенно-независимая технология взаимодействия приложений. Но это не обмен технологическими данными, реализующий более высокий уровень абстракции. Кстати, заметим, что на рынке имеются OPC-шлюзы к CORBA (это возможно, как и к любому другому протоколу).
Однако, несмотря на такие планы, организация OPC Foundation своей политикой сдерживает развитие стандарта. Документация с описанием интерфейсов доступна только членам данной организации. Членство стоит от нескольких тысяч долларов, что недоступно не только для разработчиков-одиночек, но даже для многих организаций. Этим и объясняется популярность OPC DA, документация по данному интерфейсу долгое время была доступна свободно. Как результат многие фирмы, не желающие связываться с довольно капризной технологией, имеющие в штате хороших программистов нижнего уровня и работающие с ограниченной номенклатурой контроллеров используют для своих SCADA-пакетов технологию CORBA.
Заключение
Технология OPC предлагает стандарты для обмена технологическими данными, в которые заложены самые широкие возможности. Учитывая большой авторитет вовлеченных в данную деятельность фирм, можно ожидать, что технология OPC будет набирать силу. Это перспективная технология для интеграции разнородных систем. Хотя процесс становления еще далеко не завершен и есть много проблем, которые предстоит решить.
OPC – это набор повсеместно принятых спецификаций, предоставляющих универсальный механизм обмена данными в системах контроля и управления. Аббревиатура OPC традиционно расшифровывается как OLE for Process Control. OLE – Object Linking and Embedding (связывание и встраивание объектов).
OPC – это набор повсеместно принятых спецификаций, предоставляющих универсальный механизм обмена данными в системах контроля и управления. Аббревиатура OPC традиционно расшифровывается как OLE for Process Control. OLE – Object Linking and Embedding (связывание и встраивание объектов).
OPC-сервер – программа, получающая данные во внутреннем формате устройства или системы и преобразующая эти данные в формат OPC. OPC-сервер является источником данных для OPC-клиентов. По своей сути OPC-сервер – это некий универсальный драйвер физического оборудования, обеспечивающий взаимодействие с любым OPC-клиентом.
OPC-клиент – программа, принимающая от OPC-серверов данные в формате OPC.
Технология OPC определяет интерфейс между OPC-клиентом и OPC-серверами.
Что это дает для пользователя?
Таким образом, OPC-технология обеспечивает независимость потребителей от наличия или отсутствия драйверов или протоколов, что позволяет выбирать оборудование и программное обеспечение, наиболее полно отвечающее реальным потребностям бизнеса.