Что такое opc hda
Что такое opc hda
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 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 DA и OPC UA
OPC (аббр. от англ. Open Platform Communications, ранее англ. OLE for Process Control) – это набор программных технологий, которые предоставляют единый интерфейс для управления различными устройствами и обмена данными. Спецификации OPC были разработаны международной некоммерческой организацией OPC Foundation, которую создали в 1994 году ведущие производители средств промышленной автоматизации. Целью создания OPC было предоставить инженерам универсальный интерфейс для управления различными устройствами.
Реализовав поддержку OPC-клиента, разработчики SCADA систем избавились от необходимости поддерживать сотни драйверов для различных устройств, а производители оборудования, добавив OPC-сервер, обрели уверенность в том, что их продукт может применяться пользователями любых SCADA систем.
Технология OPC включает несколько стандартов, которые описывают набор функций определенного назначения. Текущие стандарты:
OPC DA (Data Access)— наиболее распространённый стандарт. Описывает набор функций обмена данными в реальном времени с ПЛК, РСУ, ЧМИ, ЧПУ и другими устройствами.
OPC HDA (Historical Data Access)предоставляет доступ к уже сохраненным данным и истории.
OPC AE (Alarms & Events)— предоставляет функции уведомления по требованию о различных событиях: аварийные ситуации, действия оператора, информационные сообщения и другие.
OPC Batch— предоставляет функции шагового и рецептурного управления технологическим процессом.
OPC DX (Data eXchange)— предоставляет функции организации обмена данными между OPC-серверами через сеть Ethernet. Основное назначение — создание шлюзов для обмена данными между устройствами и программами разных производителей.
OPC Security— определяет функции организации прав доступа клиентов к данным OPC-сервера.
OPC XML-DA (XML-Data Access)— предоставляет гибкий, управляемый правилами формат обмена данными через XML, SOAP и HTTP.
OPC Complex Data— дополнительные спецификации к OPC DA и XML-DA, которые позволяют серверам работать со сложными типами данных, такими как бинарные структуры и XML-документы.
OPC Commands— набор программных интерфейсов, который позволяет ОРС клиентам и серверам идентифицировать, посылать и контролировать команды, исполняемые в контроллере или модуле ввода-вывода.
OPC UA (Unified Architecture)— последняя по времени выпуска спецификация, которая основана не на технологии Microsoft COM, что предоставляет кроссплатформенную совместимость.
Самое широкое распространение получил стандарт OPC DA, но у него есть существенный недостаток. Во времена его разработки он был построен на современных Windows-технологиях: OLE, ActiveX, COM/DCOM, но с тех пор в отрасли прошли изменения и большое распространение получили другие ОС и технологии. Поэтому технологию OPC сделали платформонезависимой и разработали стандарт OPC UA (Unified Architecture) на открытых кроссплатформенных технологиях.
Применение OPC
Обычно технологию OPC применяют для обмена данными между контроллерами и SCADA системой, но также возможна организация сложных систем на разных уровнях АСУ ТП.
OPC состоит из двух частей: OPC клиента и OPC сервера. ПО OPC сервера через драйверы устройств по полевым шинам опрашивает различные устройства. ПО OPC клиента обычно встроено в SCADA систему и предназначено для получения данных с OPC сервера.
На предприятии можно выделить несколько уровней АСУ:
Нижний уровень — полевые шины (fieldbus) и отдельные контроллеры;
Средний уровень — цеховые сети;
Уровень АСУ ТП — уровень работы систем типа SCADA;
Уровень АСУП — уровень приложений управления ресурсами предприятия, ERP, MES.
Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или соседнему устройству.
Работа OPC DA сервера
OPC DA сервер обеспечивает обмен данными (запись и чтение) между клиентской программой (обычно SCADA системой) и конечными устройствами. Данные в OPC представляют собой переменную Тег с некоторыми свойствами. Переменная может быть любого типа, допустимого в OLE: различные целые и вещественные типы, логический тип, строковый, дата, массивом и т. д. Свойства могут быть обязательными, рекомендуемыми и пользовательскими.
Текущее значение переменной, ее тип и права доступа (чтение и/или запись).
Качество переменнойзависит от выхода измеряемой величины за границы динамического диапазона, отсутствии данных, ошибки связи и других параметров. Обычно принимает значения: хорошее/плохое/неопределенное и дополнительная информация.
Метка временисообщает о времени, когда переменная получила данное значение.
Частота опроса переменной OPC-серверомзадает время обновления значения переменной.
Описание переменной, которое содержит информацию для пользователя о том, что представляет собой эта переменная.
Дополнительно могут быть указаны необязательные свойства: диапазон изменения значения, единица измерения и другие пользовательские параметры.
Для чтения данных из ОРС сервера можно использовать различные режимы:
Синхронный режим: клиент посылает запрос серверу и ждет от него ответ.
Асинхронный режим: клиент отправляет запрос и сразу же переходит к выполнению других задач. Сервер после обработки запроса посылает клиенту уведомление и тот забирает предоставленные данные.
Режим подписки: сервер отсылает клиенту только те теги, которые изменились. Для того, чтобы шум данных не был принят за их изменение, вводится понятие «мертвой зоны», которая слегка превышает максимально возможный размах помехи.
Режим обновления данных: клиент вызывает одновременное чтение всех активных тегов. Активными называются все теги, кроме обозначенных как «пассивные». Такое деление тегов уменьшает загрузку процессора обновлением данных, принимаемых из физического устройства.
Клиент получает данные от ОРС сервера либо из буфера, либо сразу из конечного устройства. Чтение из буфера выполняется быстрее, но данные в нем могут устареть к моменту чтения. ОРС сервер периодически обновляет данные, запрашивая информацию у конечных устройств.
Запись данных в конечное устройство осуществляется в синхронном или асинхронном режимах без промежуточной буферизации. В синхронном режиме клиент осуществляет запись данных и ждет пока не получит подтверждение о выполнении команды от конечного устройства. Этот процесс может занимать много времени, в течении которого клиент находится в ожидании. Асинхронный режим позволяет клиенту отправить запрос серверу и заниматься другими задачами. После окончания записи сервер отправит клиенту уведомление.
Примеры OPC DA сервера
Для примера возьмём SCADA систему Trace Mode 6, в которой реализована функция OPC DA сервера. Trace Mode 6 можно поставить на ПК, либо сразу на контроллер.
SCADA Trace Mode 6 может опрашивать различные модули ввода-вывода и управлять контроллерами по стандартным промышленным протоколам типа: Modbus, МЭК 60870-5-104, HART и другим. Но промышленные протоколы не предназначены для обмена данными между SCADA и ERP, MES системами. Тут придет на помощь стандарт OPC DA, который позволит собрать различные данные с исполнительных модулей SCADA. OPC DA сервер для получения данных с Trace Mode доступен как отдельный модуль, так и в составе модулей OPC МРВ+ или OPC ДокМРВ+.
Также Trace Mode 6 может выступать в качестве OPC клиента и получать данные с OPC DA серверов различных производителей. Например, есть видео урок подключения Trace Mode 6 к NAPOPC DA Server – это OPC DA сервер от компании ICP DAS.
NAPOPC DA Server – это бесплатный OPC DA сервер для опроса модулей ввода-вывода ICP DAS. Его можно установить на ПК, либо прямо контроллеры ICP DAS с ОС:
Windows 10 — XP-9781-IoT
Windows WES — XP-9781-WES7
Windows CE 6.0 — XP-8731-CE6
Windows CE 5.0 — WP-8841-EN
NAPOPC DA Server позволяет опрашивать модули: I-7000, M-7000, ET-7000, I-8K, I-87K и корзины RU-87Pn.
Стандарт OPC UA
OPC UA (Unified Architecture) – это современный стандарт, описывающий передачу данных в промышленных сетях. Он обеспечивает защищенную и надежную коммуникацию между устройствами, являясь при этом аппаратно- и платформо-независимым, что позволяет обеспечить обмен данными между устройствами с разными операционными системами.
Сильными сторонами OPC UA является объектно-ориентированная информационная модель, которая позволяет «просматривать» данные (в стиле web-браузера), и сервис ориентированная архитектура (SOA). Если раньше приходилось использовать несколько OPC серверов: OPC DA для данных в реальном времени, OPC HDA для истории и OPC AE для событий, то теперь все это и многое другое доступно в одном стандарте OPC UA. Вместо дерева тегов, теперь вводится понятие узлов или объектов. Каждый узел включает в себя переменные, методы и другие структуры данных реального объекта.
Обмен данными теперь происходит через бинарные структуры и XML документы. В дополнение к модели клиент/сервер становится доступна модель издатель/подписчик. Также стандарт определяет механизм для поддержки резервирования (если один клиент станет не доступным, то его заменит другой) и быстрого восстановления связи в случае сбоя. Передача данных происходит через транспортный слой TCP, HTTP/SOAP или HTTPS. Вместо механизмов контроля прав доступа Windows, в OPC UA реализована поддержка цифровых сертификатов и возможность шифрования передаваемых данных.
Реализована обратная совместимость с OPC DA через специальную оболочку (wrapper) и proxy-модуль. Для передачи данных через маршрутизаторы и межсетевые экраны OPC DA требовал использовать промежуточное ПО, OPC UA же работает без прослойки. Спецификация OPC UA включает в себя несколько частей, которые описывают логику работы серверов и клиентов. Детальная версия спецификации доступна в стандарте IEC 62541.
Пример OPC UA сервера
Примером OPC UA сервера может стать набор ПО MX-AOPC UA Suite от компании MOXA. В MX-AOPC UA Suite входит 3 программы:
Server – для получения данных с Modbus устройств
Viewer – для просмотра тегов и состояния сервера (Viewer встроен в Server)
Logger – для ведения истории изменения данных, а также интеграции с базами данных и Облачными решениями
В первую очередь MX-AOPC UA Server ориентирован на модули ввода-вывода MOXA, т.к. там реализована функция Active Tag, но также поддерживается подключение сторонних устройств по протоколам Modbus RTU и Modbus TCP. ФункцияActive Tagпозволяет обновлять состояние каналов сразу после их изменения, не дожидаясь команды со стороны сервера.
MX-AOPC UA Logger позволяет отправлять данные в Облако Microsoft Azure и базы данных Microsoft SQL Server, MySQL, Oracle, Microsoft Office 2003 Access или Excel через ODBC.
В MX-AOPC UA реализована защита данных через шифрование ключом Basic128Rsa15 и подтверждение сертификатом X509.
Минусы применения OPC
Конечно у любой хорошей технологии есть свои минусы. Например, разработчики SCADA Trace Mode 6 из компании АдАстра Рисерч Груп, выделяют типовые ошибки в проектировании АСУ ТП.
К ошибкам можно отнести:
Неоправданное применение WEB-технологий в АСУ ТП
Применение протоколов реального времени в телемеханических задачах
Например, вы узнали о хорошей технологии OPC и стремитесь заменить все протоколы нижнего уровня только на OPC. Но конвертация промышленных протоколов Modbus, Profibus и любых других на ПК будет занимать дополнительное время и тратить ресурсы компьютера. Тесты показали, что SCADA система работает в 2 раза быстрее напрямую с промышленными протоколами, чем через промежуточный OPC сервер. Конечно, есть системы где процесс не нужно контролировать в реальном времени, но это нужно учитывать при проектировании АСУ ТП.
К недостаткам также можно отнести сложность настройки OPC сервера и необходимость ручной привязки тысячи тегов. Кроме того, OPC-сервер не всегда поставляется бесплатно и чаще всего на каждый ПК придется покупать отдельную лицензию.
Если система отправляет данные через Интернет в Облако, то наличие слабого шифрования может стать потенциальной уязвимостью и целью для атак хакеров, что ставит под сомнение безопасность всей АСУ ТП.
OPC UA для работы в реальном времени
OPC UA over TSN— для поддержки работы в реальном времени технология OPC UA (вместо модели клиент/сервер) может использовать модель издатель/подписчик совместно с технологией TSN (Time-Sensitive Networking).
Модель клиент/сервер хорошо работает в случае подключения точка-точка, но если устройств становится много, то появляются задержки в обновлении данных. Модель издатель/подписчик обеспечивает связь от одного ко многим и от многих ко многим. Сервер отправляет свои данные в сеть (публикация) и каждый клиент может получить эти данные (подписка).
Технология Ethernet с TSN дополняет существующие средства Ethernet в том, что касается обеспечения качества обслуживания трафика (QoS), включая выделение полосы пропускания, синхронизацию, гарантию низких значений задержки и обеспечения резервирования. Данные, которые передают различные устройства по Ethernet сети, представляют собой потоки. Ethernet коммутаторы с TSN позволяют выделить для каждого потока свою полосу пропускания и обеспечить его передачу в реальном времени. Несколько потоков можно объединить (это называется сетевой конвергенцией) и организовать их передачу по одной сети в режиме реального времени. Получается без технологии TSN по одной Ethernet сети можно передавать только один протокол реального времени, а с TSN несколько.
Объединение технологий OPC UA over TSN позволяет организовать коммуникацию между оборудованием от разных производителей и гарантировать непрерывное получение данных в режиме реального времени.
OPC Foundation планирует использовать OPC UA не только для передачи данных между контроллерами и SCADA системой, но и на полевом уровне от датчиков и IoT устройств к контроллерам, а также от локальных систем в Облако. Для этого планируют разбить стандарт OPC UA на 4 части в зависимости от производительности устройства и необходимых ему возможностей.
Nano Embedded Device Server: подходит для самых маленьких датчиков;
Micro Embedded Device Server: подходит для недорогих ПЛК;
Embedded UA Server: подходит для более мощных ПЛК и пограничных шлюзов;
Standard UA Server: полноценная реализация, поддерживающая все функции.
ОРС сервер
Назначение ОРС
OPC (OLE for Process Control)
OPC (OLE for Process Control) – набор повсеместно принятых спецификаций, предоставляющих универсальный механизм обмена данными в системах контроля и управления.
OPC технология обеспечивает независимость потребителей от наличия или отсутствия драйверов или протоколов, что позволяет выбирать оборудование и программное обеспечение, наиболее полно отвечающее реальным потребностям бизнеса.
Стандарт OPC разрабатывался с целью сократить затраты на создание и сопровождение приложений промышленной автоматизации. В начале 1990 года у разработчиков промышленного ПО возникла потребность в универсальном инструменте обмена данными с устройствами разных производителей или по разным протоколам обмена данными.
Суть OPC проста — предоставить разработчикам промышленных программ универсальный фиксированный интерфейс (то есть набор функций) обмена данными с любыми устройствами. В то же время разработчики устройств предоставляют программу, реализующую этот интерфейс (набор функций).
Версии ОРС
На данный момент последней версией спецификации OPC DA является версия 3.0, однако наиболее распространенной пока является версия 2.05a. Недавно разработанный стандарт OPC UA (Unified Architecture) унифицирует набор функций для обмена данными, регистрации событий, хранения данных, обеспечения безопасности данных.
OPC DA Version 2.05a
Наиболее широко используемая. В этом стандарте помимо синхронного обмена данными, введена поддержка асинхронного обмена данными. Асинхронный обмен данных позволяет продолжать выполнение программы без ожидания ответа устройства. Этот метод снижает нагрузку на сеть и должен быть рекомендован как основной. Получение данных реализуется с помощью callback-функции пользовательской программы, которая вызывается в момент прихода ответа от устройства.
OPC Unified Architecture
Спецификация OPC UA совмещает все преимущества предыдущих спецификаций и открывает новые горизонты для применения OPC-технологий. В частности, благодаря тому, что произошел отказ от использования COM-интерфейса, обеспечивается кросс-платформенная совместимость. Новый стандарт уже изначально позволяет обеспечить более высокий уровень безопасности данных, чем OPC DA. Кроме того, новая спецификация дает возможность организации передачи информации через сеть интернет.
Стандарты ОРС
Каждый стандарт ОРС описывает набор функций определенного назначения. В зависимости от потребностей, могут использоваться различные спецификации OPC. Самыми распространенными являются спецификации OPC DA и OPC HDA.
OPC DA (Data Access)
Обеспечивает обмен текущими данными. На основе данной спецификации создано большинство существующих на сегодняшний день OPC-серверов.
OPC HDA (Historical Data Access)
Предоставляет доступ к историческим данным. Использование этой спецификации позволяет представить архивные данные в универсальном формате как в простых системах визуализации, так и в сложных SCADA-системах.
OPC AE (Alarms & Events)
Спецификация создана для контроля за различными событиями, например, выходом значения за какие то границы, обрыве сигнала, действиями операторов т.д..
OPC Batch
Применяется в задачах управления технологическими последовательностями (в соответствии со стандартом S88.01)
OPC DX (Data eXchange)
Была разработана для создания механизмов обмена данными между оборудованием и программным обеспечением различных производителей. Основное назначение данной спецификации обеспечить возможность создания шлюзов.
OPC Security
Предоставляет инструмент для разграничения прав доступа клиентов к информации через OPC-сервер.
OPC XML-DA (XML-Data Access)
Позволяет производить обмен данными через HTTP.
OPC UA (Unified Architecture)
Новая спецификация разрабатывалась более пяти лет и является огромным шагом вперед. В течение ближайших пятнадцати лет она должна постепенно вытеснить используемые сейчас спецификации OPC.
OPC UA совмещает в себе функционал ранее созданных спецификаций DA, А.Е. и HDA и обладает рядом дополнительных преимуществ. Новая спецификация обеспечивает возможность работы с серверами данных через сеть Internet и полную кросс-платформенную совместимость.
На настоящий момент происходит окончательная доработка спецификации, и создаются первые экспериментальные разработки.
Уровни управления АСУ предприятия
Исходя из области применения OPC-серверов в АСУ предприятия различают несколько уровней управления:
Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или даже «соседу».
История создания и развитие
До появления стандарта OPC, если производитель оборудования выпускал новое устройство, всем разработчикам клиентских приложений, кто хотел бы обеспечить работу с данным оборудованием, также приходилось выпускать новый клиентский драйвер. Тысячи людей, работающих над созданием систем автоматизации технологических процессов, были заняты обеспечением поддержки того или иного оборудования для выпускаемых ими SCADA (Supervisory, Control And Data Acquisition) или HMI (Human Machine Interface) систем. Справедлива и обратная ситуация, когда производитель оборудования, не имея достаточного авторитета, был вынужден сам договариваться с несколькими известными разработчиками программного обеспечения о включении драйвера его оборудования в комплект поставки той или иной SCADA-системы. При невозможности последнего варианта производителю приходилось самому писать программное обеспечение или заказывать его у специализированной фирмы, тем самым распыляя свои силы и уменьшая область применения выпускаемых им приборов.
Разработка стандарта OPC стала важным шагом, призванным, с одной стороны позволить разработчикам оборудования и SCADA-систем сконцентрировать свои усилия на улучшении основного функционала выпускаемых ими продуктов, а с другой – обеспечить масштабируемость и взаимозаменяемость программных и аппаратных средств для конечного пользователя.
Однажды созданный OPC-сервер позволяет подключать устройство к широкому кругу программного обеспечения, поддерживающего спецификацию OPC. Таким образом, интегратор становится независим от производителей оборудования, а производитель оборудования больше не зависит от разработчиков программного обеспечения.
Зарождением стандарта OPC необходимо считать начало 90-х годов, когда группа называющая себя WinSEM (Windows in Science, Engineering and Manufacturing) и объединяющая компании, работающие в сфере автоматизации промышленных процессов, поставила задачу выработать унифицированные стандарты, позволяющие использовать OLE в задачах контроля промышленных процессов. Дело в том, что до появления в 1992 году OLE 2.0 стандартным механизмом обмена данными между приложениями Windows был DDE (Dynamic Data Exchange). К сожалению, данный механизм не предусматривал обмена через сеть и отличался низкой пропускной способностью, что было критичным для многих приложений, нуждавшихся в низких временных задержках.
В марте 1995 года появился первый документ, в котором были определены ключевые спецификации будущей OPC-технологии. После публикации документа дальнейшие работы над ним продвигались достаточно неспешно, в то же время, потребность в новой технологии уже стояла достаточно остро. Тогда из WinSEM выделилось пять компаний, поставивших перед собой задачу разработать первый вариант нового стандарта и передать его на открытое рассмотрение. В 1996 году была выпущена первая версия спецификации OPC. В течение 1996 года проводится ряд семинаров в США, Англии и Японии, в ходе которых заинтересованных разработчиков знакомят с предлагаемым стандартом.
Учитывая мнение большинства компаний, работающих в сфере промышленной автоматизации, было принято решение о том, что контроль и развитие спецификации OPC должен управляться независимой некоммерческой организацией. Такой организацией стала OPC Foundation, презентация которой состоялась на выставке ISA 1996 в Чикаго. Окончательная редакция спецификации OPC DA (Data Access) версии 1.0A появилась в 1997 году. Затем в 1998 году разрабатывается спецификация OPC AE версии 1.0 и OPC DA версии 2.0.
Развитие OPC-технологии
Сегодня сложно встретить SCADA-систему без поддержки хотя бы OPC DA спецификации. В состав OPC Foundation, организации координирующей разработку и поддержку технологии OPC, входит около 450 организаций. При этом разработкой OPC-серверов занимаются не только члены OPC Foundation, но и множество других разработчиков (необходимо отметить, что все описания стандартов OPC, примеры программного кода, а также документы, касающиеся разрабатываемых стандартов доступны только организациям, входящих в состав OPC Foundation).
Подводя итоги, можно еще раз выделить основные преимущества от применения OPC-технологий.
Многие производители оборудования понимают выгоды от создания OPC-серверов для своих приборов. Появляется все большее количество разнообразных цифровых устройств, поставляемых с OPC-серверами. К сожалению, необходимо констатировать факт, что многие из этих OPC-серверов не способны обеспечить все преимущества, которые дает использование OPC-технологий. Можно даже привести примеры, когда такие OPC-серверы показывают неустойчивую работу и плохую совместимость с некоторыми широко распространенными SCADA-системами уважаемых компаний.
Это вызвано тем, что решение о самостоятельном выпуске OPC-сервера всегда связано с большим риском. OPC-сервер – это достаточно сложный в реализации программный продукт, требующий от разработчиков высокого уровня квалификации.
Большинство фирм, разрабатывающих продукты на базе OPC-технологий длительное время, знают о многих подводных камнях, которые необходимо обходить при создании OPC-сервера. Поэтому прогнозируемая экономия средств от самостоятельной разработки для многих производителей оборудования в реальности оборачивается дополнительными расходами и подпорченной репутацией.
В целом, можно смело говорить о том, что технология OPC уже стала мировым стандартом в области автоматизации технологических процессов. С каждым годом все большее количество оборудования поставляется с OPC-серверами. Сама технология OPC находится в процессе постоянного совершенствования и оптимизации, новые версии стандарта расширяют сферу применения продуктов, поддерживающих спецификации OPC и, если в современном мире наличие у прибора OPC-сервера является опциональным, то вероятно в ближайшие десять лет это станет правилом хорошего тона.
Универсальный OPC-сервер
Fastwel UniOPC Server является приложением Windows, обеспечивающим доступ через интерфейс OPC Data Access к нестандартному оборудованию, не имеющему специализированных OPC-серверов. Адаптация сервера к конкретному оборудованию требует программирования со стороны пользователя на языке C++, однако трудоемкость кодирования в части обеспечения OPC-доступа значительно ниже, чем в большинстве универсальных пакетов, предназначенных для разработки OPC-серверов. В то же время UniOPC имеет некоторые ограничения, поэтому, прежде чем принимать окончательное решение, рекомендуется внимательно ознакомиться с бесплатной демо-версией, позволяющей создать и протестировать полнофункциональный проект до покупки лицензии.
Разработанный на базе UniOPC конкретный OPC-сервер состоит из универсальной оболочки (исполняемого файла), реализующей OPC-интерфейсы, и написанной пользователем динамической библиотеки (DLL), которая снабжает сервер данными. Несколько примеров таких DLL разной степени сложности включены в комплект поставки сервера, поэтому при написании своего кода рекомендуется взять за основу один из этих примеров.
Со стороны пользовательской DLL UniOPC позволяет:
Со стороны графического интерактивного интерфейса пользователя UniOPC позволяет:
Сервер поддерживает следующие типы данных:
Разработка пользовательской DLL производится в среде Microsoft Visual C++ (в комплект поставки входят проекты для VC++ 6.0). Разработка в других средах (например, Borland C++) и на других языках программирования (например, Pascal и Assembler) в принципе допустима.
Fastwel UniOPC Server поддерживает интерфейс OPC Data Access 2.0 и может использоваться совместно с различными пакетами программ класса SCADA/HMI.
Предоставляемая демонстрационная версия позволяет до приобретения лицензии ознакомиться с функциональными возможностями сервера, в том числе в конкретном проекте, без ограничений времени работы и количества тегов. Единственным ограничением является отсутствие возможности сохранения и загрузки конфигурации сервера.
OPC-сервер для CAN (Controller Area Network)
Fastwel CAN OPC Server является приложением Windows, обеспечивающим обмен данными с узлами сети CAN через интерфейс OPC Data Access. Текущая версия сервера подключается к сетям CAN посредством любых CAN-адаптеров фирмы IXXAT (через программный интерфейс VCI V2) и/или адаптера PCAN-USB фирмы PEAK Systems Technik.
Сервер может применяться в сетях CAN с произвольными протоколами прикладного уровня, основанными на передаче данных реального времени широковещательными сообщениями, а также поддерживает следующие типы коммуникационных объектов, определенные спецификацией DS-301 CANopen Application Layer and Communication Profile specification:
Fastwel CAN OPC Server:
Fastwel CAN OPC Server поддерживает интерфейс OPC Data Access 2.0 и может использоваться совместно с различными пакетами программ класса SCADA/HMI.
Предоставляемая демонстрационная версия позволяет до приобретения лицензии ознакомиться с функциональными возможностями сервера, в том числе в конкретном проекте, без ограничений времени работы и количества тегов. Единственным ограничением является отсутствие возможности сохранения и загрузки конфигурации сервера.
OPC-сервер для сетей Modbus RTU/ASCII (поверх RS-485) и Modbus TCP
Fastwel Modbus OPC Server является приложением Windows, обеспечивающим программный доступ к узлам сетей Modbus RTU/ASCII и Modbus TCP через интерфейс OPC Data Access. Сервер реализует функции мастера протоколов Modbus RTU/ASCII и Modbus TCP, выполняя операции чтения и записи данных между компьютером, на котором он установлен, и подчиненными узлами сети. Сервер предоставляет возможность одновременного обмена данными с подчиненными узлами сетей Modbus RTU/ASCII и Modbus TCP, и поддерживает следующие типы объектов прикладного уровня протокола Modbus:
Fastwel Modbus OPC Server:
Fastwel Modbus OPC Server поддерживает интерфейс OPC Data Access 2.0 и может использоваться совместно с различными пакетами программ класса SCADA/HMI.
Предоставляемая демонстрационная версия позволяет до приобретения лицензии ознакомиться с функциональными возможностями сервера, в том числе в конкретном проекте, без ограничений времени работы и количества тегов. Единственным ограничением является отсутствие возможности сохранения и загрузки конфигурации сервера.