opc foundation что это
Opc foundation что это
Welcome to the World of OPC
In today’s complex economy, information is the key to business success and profitability. OPC technologies were created to allow information to be easily and securely exchanged between diverse platforms from multiple vendors and to allow seamless integration of those platforms without costly, time-consuming software development. This frees engineering resources to do the more important work of running your business. Today, there are more than 4,200 suppliers who have created more than 35,000 different OPC products used in more than 17 million applications. The estimate of the savings in engineering resources alone is in the billions of dollars.
OPC News
The OPC Foundation and CESMII launches the UA Cloud Library
The UA Cloud Library makes it easier than ever to find, share, explore, and use OPC UA Information Models by applications, end-users, and standards bodies. Scottsdale, AZ – December 8th, 2021 – The OPC Foundation announced the launch of the globally available UA Cloud Library co-developed with the Clean Energy and Smart Manufacturing Innovation Institute […]
OPC Foundation’s Field Level Communications Initiative reaches significant milestone and celebrates premiere
20 companies showcase cross-vendor interoperability of OPC UA FX specifications with the first live multi-vendor demo Scottsdale, AZ – December 8th, 2021 – Three years after its launch, the OPC Foundation’s Field Level Communications (FLC) initiative has completed the second release candidate of the OPC UA FX (Field eXchange) specifications and has started the review […]
The OPC Foundation Takes Ownership of the MDIS Sub-Sea Standard
As an OPC Foundation specification, MDIS is now freely available for market adoption and the MDIS working group is open to all interested OPC Foundation members. Scottsdale, AZ – December 08th, 2021 – The OPC Foundation (OPCF) is proud to announce that it consolidated and took over the MCS-DCS Interface Standardisation (MDIS) specification ownership. Effective […]
General Assembly Meeting 2021 & Public Press Conference
The OPC Foundation General Assembly Meeting 2021 will announce the results of the Board of Directors’ election, reports on budget, technical and marketing overview and provide first technical and marketing insights for 2022. Wed Dec 8th, 2021 – at 10:00 AM – 11:00 AM EST (4:00 PM – 5:00 PM CET) Please register here Agenda: OPC […]
OPC UA is recognized as “the most important interoperability technology in today’s industrial landscape” by the ARC Advisory Group
A new ARC report examines the critical role OPC UA serves globally as the core data interoperability standard in process and discrete manufacturing industries and beyond Scottsdale, AZ – June 15, 2021 – The OPC Foundation is pleased to announce that the ARC Advisory Group published a report entitled “OPC UA Momentum Continues to Build.” […]
На днях пришлось крепко повозиться с настройкой вызова удалённого сервера по протоколу 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 Foundation в 1996 г. Перед ее создателями стояла задача собрать и привести к общему знаменателю целый «зоопарк» уже существующих и находящихся в разработке протоколов. Несмотря на первоначальный скепсис производителей ряда SCADA-систем, технология оказалась революционной. Приняв технологию OPC, разработчики SCADA избавились от необходимости поддерживать сотни драйверов для различных устройств, а производители оборудования, разработав OPC-сервер, обрели уверенность в том, что их продукт может применяться пользователями любых SCADA.
Бурное распространение OPC пришлось на начало 2000-х годов. Технология активно развивалась: появились стандарты для обмена архивными данными и сообщениями, все производители SCADA-систем реализовали поддержку технологии OPC, а наличие OPCсервера к приборам стало само собой разумеющимся.
Однако сегодня можно смело утверждать, что «классическая» OPC (стандарты OPC DA и OPC HDA) доживает свой век: унификация различных протоколов была с блеском решена на технологиях, которые в настоящий момент уже устарели. Дело в том, что OPC DA и OPC HDA базируются на технологии Microsoft DCOM. В 1996 г. Windows была доминирующей операционной системой: Apple находилась в шаге от банкротства, а Linux была нишевым продуктом, использовавшимся преимущественно в серверах и требовавшим высокой квалификации для обслуживания. По этой причине привязка к технологии DCOM (на тот момент современной) была для OPC Foundation логичным, а возможно, даже единственным вариантом. В то время Internet только начинал появляться на предприятиях и был медленным и дорогим средством коммуникации, поэтому необходимости в поддержке работы по сети не было.
Однако за 20 лет в ИТ-отрасли произошли радикальные изменения. В настоящее время Windows больше не является самой популярной ОС, хотя и остается главной на десктопных компьютерах. Процессоры стали быстрее, и теперь ОС может обслуживать и дешевый контроллер. Развитие Internet, в том числе мобильного, позволило удаленно подключать различные объекты и собирать с них данные. Кроме того, добавились и новые вызовы: на системы управления ТП начались хакерские атаки, что привело к необходимости шифрования и аутентификации. К новой реальности «классическая» OPC оказалась не готова.
Для актуализации технологии OPC организация OPC Foundation инициировала создание нового стандарта, по сути, с нуля. Теперь за основу брались открытые кроссплатформенные технологии без привязки к DCOM. Новая редакция получила название OPC UA — Unified Architecture («унифицированная архитектура»). OPC UA сохранила все достижения «классической» OPC, но при этом лишена ее недостатков.
OPC UA обладает следующими преимуществами [1, 2].
• Полностью кроссплатформенный стандарт. На первый взгляд это кажется несущественным, так как большинство SCADA-систем все равно остаются (и останутся) работать на ОС Windows. Однако с появлением кроссплатформенности исчезла необходимость в существовании OPC-сервера как отдельного приложения
на компьютере, поскольку теперь большинство контроллеров уже имеют встроенную ОС и производитель может установить OPC-сервер непосредственно в контроллер. Для получения тегов из контроллера больше не требуется настраивать отдельное приложение, достаточно задать в SCADA-системе параметры подключения к контроллеру, и весь список переменных (в том числе архивных) будет получен и добавлен в проект. Таким образом, построение проекта существенно ускоряется.
• Легкость удаленного подключения. Любой разработчик АСУ с содроганием вспоминает процесс подключения удаленного «классического» OPC-сервера к SCADA-системе: для получения данных от другого компьютера необходимо было настроить DCOM по специальной инструкции. Вряд ли найдется хоть один специалист, которому удалось это сделать с первого раза. А настройка серверных редакций ОС Windows еще более сложная, в ряде случаев заканчивающаяся неудачей. В OPC UA такой проблемы в принципе нет. Все, что нужно, — это открыть разрешение в файрволе на нужный TCP-порт. Если удаленный компьютер находится во внутренней сети, недоступной SCADA, то и это не становится проблемой. Задача решается переадресацией порта. А при работе через Internet обмен можно вести как через VPN, так и через публичный IPадрес. Теперь подключение удаленных OPC не вызывает никаких проблем.
• Шифрование и аутентификация. К сожалению, к новым вызовам, требующим повышенной безопасности передачи данных, пока не готов ни один промышленный протокол: все они разработаны в конце 1990-х годов (или даже ранее) и не имеют никакой защиты. Технология OPC UA в этом вопросе является исключением: в ней применяются несколько вариантов шифрования и аутентификации. Это позволяетвести передачу данных через Internet, не беспокоясь за их сохранность.
• Унификация данных. В «классической» OPC существуют несколько стандартов для каждого варианта использования: OPC DA — для текущих данных, OPC HDA — для архивных и т. д. В OPC UA все стандарты объединены: текущие данные, архивные данные, сообщения — все это передается через один сервер, по единому интерфейсу.
В России технологию OPC первой среди отечественных разработчиков применила компания ИнСАТ. SCADA-система MasterSCADA полностью базируется на стандарте OPC, все переменные проекта наследуют атрибуты и значения OPC-тегов. Также первой в России компания ИнСАТ выпустила инструментарий для разработки OPC-серверов — MasterOPC Toolkit, ставший «движком» для многих OPC-серверов.
В лидерах компания ИнСАТ оказалась и с OPC UA — она первой обеспечила полный комплекс продуктов с поддержкой данной технологии. В 2015 г. компания выпустила MasterSCADA 3.7 с поддержкой OPC UA клиента, а также MultiProtocol MasterOPC — сервер с поддержкой OPC UA сервера [3]. В 2016 г. была запущена MasterSCADA 3.8 с поддержкой OPC UA сервера, то есть SCADA теперь может не только получать данные по UA, но и отдавать их.
В новейшем продукте — платформе MasterSCADA 4D — также реализована полная поддержка OPC UA. При этом она предназначена для работы как на компьютерах, так и на контроллерах. Это означает, что OPC UA сервер будет функционировать непосредственно на контроллере и передавать данные напрямую UAклиентам. На данный момент исполнительная система MasterSCADA 4D уже портирована на контроллеры Trei, Wago, Fastwell, ОВЕН и др.
На сегодняшний день не все компании — разработчики контроллеров способны реализовать OPC UA серверы для собственных изделий. Компания ИнСАТ максимально облегчает для них указанную задачу. Для этого в Multi-Protocol MasterOPC сервер добавлена возможность создания собственных драйверов. Достаточно написать небольшую библиотеку с реализацией необходимого протокола, чтобы появилась возможность передачи данных как по OPC DA и HDA, так и по OPC UA.
На протяжении еще долгого времени будет оставаться актуальной задача подключения удаленных OPC DA/HDA серверов. Как уже было отмечено, в «классической» OPC это очень трудоемкий процесс с непредсказуемым результатом. Для решения данной проблемы уже давно существует специальный класс продуктов — OPC-туннели. Подобные продукты выпускают фирмы Matrikon, Kepware, Cogent. Компания ИнСАТ также разработала аналогичный продукт — MasterOPC Tunneler. Однако у зарубежных производителей обмен между частями туннеля реализован по внутреннему протоколу, а в MasterOPC Tunneler — через OPC UA. Физически он представляет собой Multi-Protocol MasterOPC с двумя плагинами: OPC DA Client и OPC UA Client.
Таким образом, на компьютер с целевыми OPC-серверами ставится Multi-Protocol с плагином OPC DA Client, работающим в режиме OPC UA сервера, а на компьютер с целевой SCADA-системой — MultiProtocol с плагином OPC UA Client. Рассмотрим плюсы такого решения.
Первое ключевое преимущество состоит в возможности создания произвольной архитектуры туннеля (рис. 1).
Кроме того, если SCADA-система уже имеет встроенный UA-клиент, то необходимость в одном плагине просто отпадает. В этом случае архитектура упрощается — остается только один Multi-Protocol MasterOPC с плагином OPC DA Client (рис. 2).
Это позволяет гибко подобрать структуру ПО под каждую конкретную задачу и, учитывая, что каждый плагин лицензируется отдельно и стоит существенно дешевле аналогов, помогает к тому же максимально оптимизировать затраты. При этом на любом узле сети, на котором установлен Multi-Protocol MasterOPC, возможно подключение не только OPC-серверов, но и различных устройств по протоколам SNMP, Profinet, IEC60870-5-104, BacNET, а также разнообразных счетчиков коммерческого учета. В итоге Multi-Protocol MasterOPC превращается в многофункциональный коммуникационный хаб с огромными возможностями и безграничной гибкостью.
При анализе тенденций развития современных технологий появляется уверенность в том, что OPC UA, как и в свое время «классическая» OPC, произведет революцию в обмене данными посредством промышленных сетей, обеспечив пользователям удобство, надежность и безопасность.
СОДЕРЖАНИЕ
История
После более чем трех лет работы над спецификациями и еще одного года для реализации прототипа в 2006 году была выпущена первая версия унифицированной архитектуры.
Инновации
Хотя исходная привязка к COM / DCOM помогла OPC хорошо распространяться, у нее было несколько недостатков:
Эти недостатки, а также ряд других соображений подтолкнули к решению разработать новый независимый стек для OPC UA, который заменяет COM / DCOM. Основными характеристиками этого коммуникационного стека были:
Клиентское программное обеспечение может проверить, какие профили поддерживает сервер. Это необходимо для получения информации, если сервер поддерживает только функции DA или дополнительно AE, HDA и т. Д. Кроме того, можно получить информацию о том, поддерживает ли сервер данный профиль. Новые и важные особенности OPC UA:
Протоколы
Характеристики
Спецификация OPC UA состоит из нескольких частей и состоит из следующих частей:
Кроме того, также доступны часть 100 «Устройства» и часть 200 «Промышленная автоматизация». Они основаны на основном наборе спецификаций и добавляют новые общие определения, которые затем используются в различных сопутствующих спецификациях. Например, и OPC UA для анализирующих устройств, и OPC UA для машинного оборудования строятся непосредственно на части 100.
В отличие от спецификаций на основе COM, спецификации UA не являются чисто прикладными спецификациями. Они описывают типичные внутренние механизмы UA, которые обрабатываются через стек связи и обычно представляют интерес только для тех, кто переносит стек на конкретную цель или тех, кто хочет реализовать свой собственный стек UA.
Разработчики приложений OPC UA кодируют API OPC UA и поэтому в основном используют документацию по API. Тем не менее, части 3, 4 и 5 могут быть интересны разработчикам приложений.
Обсуждение
Спецификация протокола OPC UA состоит из 14 документов общим объемом 1250 страниц. Из-за этой сложности существующие реализации обычно являются неполными. Кроме того, наличие нескольких форматов сериализации, а также возможность выборочной реализации определенных сервисов, таких как PubSub, в конечном итоге приводят к большой неоднородности точек подключения OPC UA. В этих условиях, наконец, трудно разрабатывать клиентские приложения, независимые от конкретной реализации каждого сервера. В этом смысле OPC UA не выполняет своих обещаний по обеспечению хорошей совместимости систем. Обычно это можно увидеть в производственных и инфраструктурных проектах, интегрирующих различные технологии ПЛК, каждая из которых поставляется с различной и ограниченной реализацией протокола OPC UA.
Спецификация все еще развивается, последний том 14 документа спецификации датирован 6 февраля 2018 года, а первая публикация стандарта OPC UA датируется 2006 годом.
В результате, несмотря на значительные маркетинговые усилия по поддержке его принятия, OPC UA на данном этапе можно рассматривать как попытку стандартизации, а не как установленный стандарт.
Стек связи UA
Архитектура приложения UA, независимо от того, является ли оно серверной или клиентской частью, структурирована по уровням.
Некоторые части соответствуют прежним COM-прокси / заглушкам и предоставляются OPC Foundation. Уровень переносимости новый; он упрощает перенос стека UA ANSI C на другие целевые платформы. Уровень портов для Windows и Linux также предоставляется OPC Foundation.
Безопасность UA
Встроенные типы данных
Стандарт OPC UA определяет 25 встроенных типов данных:
API OPC UA
Реализация C ++ / C
Реализация на Java
Реализация JavaScript и Typescript
Реализация Python
Реализация Rust
Rust для OPC UA предоставляет API и примеры для реализации клиента и серверов OPC UA вплоть до уровня встроенного профиля. Сюда входит поддержка шифрования, подписок и набора узлов по умолчанию.
Реализация TypeScript / JavaScript
Реализация tcl
IEC 62541
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-технология обеспечивает независимость потребителей от наличия или отсутствия драйверов или протоколов, что позволяет выбирать оборудование и программное обеспечение, наиболее полно отвечающее реальным потребностям бизнеса.