Промышленный стандарт opc ole for process control как средство интеграции систем управления

Обновлено: 09.01.2025

OPC - это аббревиатура от OLE for Process Control, т. е. OLE для управления процессами. Если принять это во внимание и попробовать прокомментировать название статьи, то придется сказать, что ключевыми словами для понимания изложения являются технология Microsoft OLE и интеграция. Точнее, “спрятанное” под термином OLE понятие COM.

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

1) Автоматизация. Это, конечно, собственно автоматизация (например, производства). Но это также и OLE-автоматизация (даже без приставки OLE). И еще это интерфейс автоматизации, который объясняется далее.

2) Интерфейс. Это, разумеется, интерфейс в общепринятых смыслах (их несколько). Но это также интерфейсы объектов COM и еще интерфейсы серверов (например, интерфейс автоматизации).

А теперь к делу.

Что же мы понимаем под интеграцией? Предположим, в результате огромных усилий программистов создана сложная комплексная система, охватывающая автоматизацию на всех уровнях предприятия, начиная от самого нижнего - управления датчиками и исполнительными механизмами и заканчивая уровнем управления предприятием, вплоть до представления обобщенных данных завода у директора. Реализована ли в данном случае концепция интеграции? В полном смысле нет. Здесь интеграция подразумевает не единую глобальную систему как таковую, а прежде всего взаимодействие всех уровней ПО между собой (разумеется, это не исключает объединения их в цельную систему). Фактически речь идет о том, что различные программные системы, созданные с помощью различных средств, установленных на различных платформах, работающих на разных компьютерах, умеют “договариваться”. То есть они знают, как запросить друг у друга данные и как послать друг другу “указания”. По большому счету интеграция сводится к конфигурированию “высоких договаривающихся сторон”.

Для того чтобы договориться, необходимо установить общий язык. И этот язык должны принимать хотя бы де-факто, а лучше де-юре все программные участники интеграции. Можно привести множество примеров всего, что употребляется с ключевыми словами “интерфейс”, “протокол”, “API”, “язык” и пр. Создаются комитеты, комиссии, организации, форумы, выпускаются спецификации, стандарты, и во многом последнее десятилетие проходит под знаком обеспечения возможностей интегрирования в той или иной области. Все крупнейшие компании увлечены этим потенциально очень прибыльным процессом, вдохновленные в том числе и поражающими воображение успехами интеграции.

Экскурс в COM/DCOM

Не осталась в стороне от этого процесса и корпорация Microsoft. Мы не будем здесь касаться борьбы Microsoft за Internet. О ее результатах хорошо известно. Но у Microsoft есть еще одна глобальная интеграционная тенденция, и о ней необходимо сказать несколько слов.

Итак, COM - Component Object Model (модель составных объектов) и ее сетевое расширение DCOM - Distributed COM (распределенная COM) - это технология, введенная первоначально Microsoft для интеграции различных офисных приложений в Windows. Интеграция подразумевала использование объектов одного приложения, например таблицы Excel, в другом приложении, например в редакторе Word. Все это известно под аббревиатурой OLE. Начиная с версии OLE 2.0 в ее основу была положена модель COM.

Первоначально название COM не “выставлялось напоказ”, было скрыто от широких масс. Но постепенно COM пронизала все варианты Windows 9.x/NT/CE. Достаточно упомянуть такие ее производные, как ActiveX (OLE-автоматизация) или OLE DB, не говоря уже о самой офисной OLE. Эта технология все больше и больше увлекала Microsoft. И вот в Windows 2000 к COM добавляются некоторые компоненты (транзакции, безопасность, очереди и др.), она преобразовывается в COM+ и объявляется главной, “склеивающей” технологией программирования в архитектуре DNA (Distributed interNet Application - распределенные приложения Internet), а связанные с этим технологии объединяются под общим названием Component Services (сервисы компонентов).

Обо всем этом сейчас уже написано достаточно много. Нам же в первую очередь нужно понять основные положения, связанные с нынешним состоянием технологии COM.

Модель COM оперирует объектами, очень похожими на объекты в объектно-ориентированных языках программирования типа Си++. Но сама технология COM не является языком программирования. Она только регламентирует поведение своих объектов. Нам нужно знать, что объект после создания предоставляет свою функциональность вызвавшему процессу, а после использования - уничтожается.

Объекты COM передают свою функциональность через интерфейсы. Интерфейс в COM (не путать с тем, что обычно понимается под словом “интерфейс”) объединяет группу взаимосвязанных функций, предоставляемых объектом. Главная особенность интерфейсов COM заключается в их “публичности”. Интерфейсы используются после того, как они “опубликованы”, и после этого их нельзя изменять никогда (имеются в виду прототипы и набор функций интерфейса, но не их реализация, которая вполне может изменяться). Если необходима новая версия интерфейса, издается новый интерфейс при сохранении старого. Этим обеспечивается совместимость при обновлении и модернизации объектов. И это первый шаг на пути к интеграции.

Именно интерфейс, вернее указатель на него, является тем, с чем работает вызывающий процесс (читай - программист). Объект может предоставлять несколько интерфейсов. Чтобы получить указатель на любой интерфейс, нужно воспользоваться функцией QueryInterface обязательного для всех COM-объектов интерфейса IUnknown. Указатель на этот интерфейс передается инициирующему процессу при создании объекта.

Объект COM - сторона пассивная. Он лишь передает через интерфейсы свои функции. В этом смысле употребляется термин COM-сервер. Запрашивающая программа соответственно называется COM-клиент. Но это не исключает того, что обе программы одновременно могут быть и COM-серверами, и COM-клиентами. Забегая вперед, скажем, что именно здесь скрыт ключ к пониманию того, что OPC-сервер может поставлять данные “по подписке”, т. е. сам инициализировать обмен с OPC-клиентом при их обновлении.

Чтобы создать объект, нужно знать, где он находится. В Windows для этого используется регистрация объектов в системном реестре. И не только их. В реестре регистрируются также интерфейсы и кое-что другое. При этом каждый COM-предмет регистрации имеет уникальный в полном смысле этого слова идентификатор, называемый GUID (Globally Unique Identifier - глобально уникальный идентификатор; иногда используется название UUID - Universally Unique Identifier). Присваивает идентификаторы своим COM-детищам их создатель, используя, например, программу GUIDGEN.EXE. Заметим также, что многие COM-объекты могут (а ActiveX просто обязаны) саморегистрироваться.

Вопросы, затрагиваемые здесь, очень важны для понимания всего излагаемого. Объекты COM должны быть достаточно независимыми. Они зачастую, если не сказать в большинстве случаев, находятся вне программы COM-клиента, а могут быть запущены также и на другом компьютере. Это имеет далеко идущие последствия.

Даже на одном компьютере разные приложения Windows функционируют в своих собственных адресных пространствах. Это означает, что требуется кто-то для передачи вызовов из одного процесса в другой, так как простое создание или уничтожение объекта в другом адресном пространстве вовсе не тривиальное дело.

В COM эти и другие проблемы решаются с помощью специальных библиотек, таких, как OLE32.DLL. С одной стороны, эти библиотеки предоставляют функции для работы с объектами. Например, вызов CoCreateInstance создает объект. С другой стороны, активизируемые специальные компоненты выполняют диспетчерские функции, в частности упаковку и передачу параметров вызываемым методам объектов (так называемый marshalling). В связи с этим упомянем два важных модуля: заместитель (proxy) и заглушка (stub). Они функционируют в адресном пространстве COM-клиента и COM-сервера соответственно и обеспечивают прозрачность вызовов. Механизм таков: COM-клиент вызывает функцию COM-интерфейса, которую ему подсовывает заместитель. Тот передает вызов заглушке через RPC. А заглушка вызывает функцию COM-сервера.

Для нас важно следующее. Поддерживающие компоненты автоматизируют работу с COM-объектами и делают ее прозрачной для COM-клиента (с его точки зрения объект находится в его собственном адресном пространстве). И это третий шаг на пути к интеграции.

А необходимость некоего программного обеспечения напоминает о том, что это прежде всего технология Microsoft и добиться полной платформной независимости совсем не просто.

Без сетевых решений разговора об интеграции в настоящее время можно даже и не начинать. В COM по этому поводу существует DCOM - расширение COM, позволяющее добираться до объектов на других компьютерах. Важно то, что с точки зрения программирования ничего не меняется: DCOM - это системный сервис, делающий COM прозрачным в локальных сетях. И это четвертый шаг к интеграции. Но с тем же очевидным недостатком: DCOM должен присутствовать в операционной системе.

Еще одно существенное замечание. Сервис DCOM базируется на RPC. А это очень сильно затрудняет его использование в глобальных сетях. Требуются специальные программные компоненты и изощренное сетевое администрирование, чтобы добиться взаимодействия через DCOM в глобальных сетях. Увы! Шаг на пути к интеграции оказывается несколько короче, чем хотелось бы.

Чтобы использовать объект, необходимо знать, как он устроен, вернее, как устроены его интерфейсы. Для этого они должны быть опубликованы, например, в виде официальной документации, или стандарта. Таким образом, вырисовываются две возможности:

1) вы разрабатываете некий COM-объект, “украшаете” его и его интерфейсы GUID, снабжаете документацией (если это объект ActiveX, то официальная документация может и не понадобиться: на программном уровне общаться с распространяемым вами через Internet объектом будете только вы сами) и передаете в виде бинарного кода;

2) вы намечаете какую-либо проблему, изучаете ее, возможно, даже собираете “тусовку” под названием Foundation или Committee и издаете стандарт, подробно описывающий объекты, призванные решать данную проблему. Реализацию вы оставляете другим. Если дело стоящее, желающие найдутся. Именно это можно сказать об OPC!

Использовать COM-объекты должны COM-клиенты. Но они могут быть разными, если мы говорим об интеграции. И они могут применять разные языки программирования, не исключая скриптовых типа Visual Basic. Технология COM предусматривает две возможности. Либо вы программируете на Си++ и описываете интерфейсы с помощью предоставляемых с документацией h- и c-файлов. Тогда говорят о Custom-интерфейсе (не путать с COM-интерфейсами!). Либо вы используете для скриптовых запросов так называемую автоматизацию (OLE Automation). В этом случае для доступа к функциям объекта имеется специальный COM-интерфейс IDispatch, который COM-объект обязан поддерживать, предоставляя интерфейс автоматизации (опять не путать с COM-интерфейсами!). Не вдаваясь в подробности, скажем, что при этом никакие компилируемые файлы не нужны, но нужна так называемая библиотека типов.

Программирование COM было бы нелегким занятием, если бы не предоставляемые средства. Процесс программирования упрощенно выглядит так. С помощью Си-подобного языка MIDL (Microsoft Interface Definition Language - язык определения интерфейсов) вы описываете интерфейсы. С помощью компилятора MIDL.EXE они преобразовываются в описанные выше файлы, в том числе и в библиотеку типов. А далее используется библиотека ATL (Active Template Library - библиотека активных шаблонов), умеющая интерпретировать эти файлы и многое другое, связанное с COM и ActiveX.

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

Как уже отмечалось, технология OPC реализована и продолжает реализовываться по второй схеме предоставления объектов - путем разработки стандартов. OPC Foundation определяет направления исследований и организует комитеты, которые делают следующее:

- создают спецификации COM-интерфейсов и COM-объектов;

- присваивают объектам GUID;

- оформляют все в виде стандартов и публикуют;

- генерируют или создают вспомогательные файлы: idl-, h- и c-файлы для Custom-интерфейса; библиотеки типов для интерфейса автоматизации; заместители и заглушки для поддержки межпроцессного взаимодействия;

- разрабатывают вспомогательные компоненты, например утилиту opcenum, позволяющую OPC-клиенту “увидеть” список всех OPC-серверов локальной сети;

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

Практически все является общедоступным: зайдя на сайт, вы можете скачать то, что вас интересует, или заполнить небольшую анкету и бесплатно получить компакт-диск со всеми имеющимися материалами. Но кое-что, например демопрограммы, все-таки предоставляется только членам организации. Кстати, стоимость членства зависит от вашего бизнеса и колеблется от $100 в год для университетов и непрофильных организаций до $10 000 в год для крупных фирм с оборотом более 100 млн. долл.

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

Кто же использует OPC? Первая категория - производители оборудования автоматизации, или OEM. Предполагается, что тот, кто создает, например, плату сбора данных, снабжает ее не только драйвером, но и реализует OPC-сервер, работающий с этой с платой через драйвер или даже напрямую. Тем самым OEM-производитель предоставляет стандартный доступ к своей плате.

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

Что необходимо сделать производителю, если он решил обеспечить свой продукт стандартным интерфейсом? Сначала он должен получить нужную спецификацию и прилагаемые программные компоненты, затем изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-сервера, и наконец посадить самого опытного программиста за Visual Studio, который с помощью ATL-библиотеки реализует требуемые интерфейсы, а значит, и OPC-сервер. Это все. Можно только добавить, что если он не хочет использовать самого опытного программиста, ему придется купить какой-нибудь комплект инструментальных средств (Toolkit). Но об этом далее.

- OPC Common Definitions and Interfaces - общие для всех OPC-спецификаций интерфейсы.

- Data Access Custom Interface Standard - спецификация COM-интерфейсов для обмена оперативными данными, программирование на Си++.

- Data Access Automation Interface Standard - спецификация COM-интерфейсов для обмена оперативными данными, программирование на языках типа Visual Basic.

- OPC Batch Custom Interface Specification - спецификация COM-интерфейсов конфигурирования оборудования, программирование на Си++.

- OPC Batch Automation Interface Specification - спецификация COM-интерфейсов для конфигурирования оборудования, программирование на языках типа Visual Basic.

- OPC Alarms and Events Custom Interface Specification - спецификация COM-интерфейсов для обслуживания событий (event) и нештатных ситуаций (alarm), программирование на Си++.

- OPC Alarms and Events Automanion Interface Specification - спецификация COM-интерфейсов для обслуживания событий и нештатных ситуаций, программирование на языках типа Visual Basic.

- Historical Data Access Custom Interface Standard - спецификация COM-интерфейсов для работы с хранилищами данными, программирование на Си++.

- Historical Data Access Automanion Interface Standard - спецификация COM-интерфейсов для обслуживания событий и нештатных ситуаций, программирование на языках типа Visual Basic.

- OPC Security Custom Interface - спецификация COM-интерфейсов для обработки прав доступа к данным, программирование на Си++.

История создания и развитие

До появления стандарта 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 при проектировании систем автоматизации исключает конфликты доступа к оборудованию. Становится возможным использовать несколько OPC-клиентов для получения данных из одного источника.

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

Это вызвано тем, что решение о самостоятельном выпуске OPC-сервера всегда связано с большим риском. OPC-сервер – это достаточно сложный в реализации программный продукт, требующий от разработчиков высокого уровня квалификации.
Большинство фирм, разрабатывающих продукты на базе OPC-технологий длительное время, знают о многих подводных камнях, которые необходимо обходить при создании OPC-сервера. Поэтому прогнозируемая экономия средств от самостоятельной разработки для многих производителей оборудования в реальности оборачивается дополнительными расходами и подпорченной репутацией.

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

Применение OPC

Обычно технологию OPC применяют для обмена данными между контроллерами и SCADA системой, но также возможна организация сложных систем на разных уровнях АСУ ТП.

OPC состоит из двух частей: OPC клиента и OPC сервера. ПО OPC сервера через драйверы устройств по полевым шинам опрашивает различные устройства. ПО OPC клиента обычно встроено в SCADA систему и предназначено для получения данных с OPC сервера.

На предприятии можно выделить несколько уровней АСУ:

Нижний уровень - полевые шины (fieldbus) и отдельные контроллеры;
Средний уровень - цеховые сети;
Уровень АСУ ТП - уровень работы систем типа SCADA;
Уровень АСУП - уровень приложений управления ресурсами предприятия, ERP, MES.

Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или соседнему устройству.

Стандарт OPC UA

OPC UA (Unified Architecture) – это современный стандарт, описывающий передачу данных в промышленных сетях. Он обеспечивает защищенную и надежную коммуникацию между устройствами, являясь при этом аппаратно- и платформо-независимым, что позволяет обеспечить обмен данными между устройствами с разными операционными системами.

Сильными сторонами OPC UA является объектно-ориентированная информационная модель, которая позволяет «просматривать» данные (в стиле web-браузера), и сервис ориентированная архитектура (SOA). Если раньше приходилось использовать несколько OPC серверов: OPC DA для данных в реальном времени, OPC HDA для истории и OPC AE для событий, то теперь все это и многое другое доступно в одном стандарте OPC UA. Вместо дерева тегов, теперь вводится понятие узлов или объектов. Каждый узел включает в себя переменные, методы и другие структуры данных реального объекта.

Реализована обратная совместимость с OPC DA через специальную оболочку (wrapper) и proxy-модуль. Для передачи данных через маршрутизаторы и межсетевые экраны OPC DA требовал использовать промежуточное ПО, OPC UA же работает без прослойки. Спецификация OPC UA включает в себя несколько частей, которые описывают логику работы серверов и клиентов. Детальная версия спецификации доступна в стандарте IEC 62541.

OPC-сервер для CAN (Controller Area Network)

Fastwel CAN OPC Server является приложением Windows, обеспечивающим обмен данными с узлами сети CAN через интерфейс OPC Data Access. Текущая версия сервера подключается к сетям CAN посредством любых CAN-адаптеров фирмы IXXAT (через программный интерфейс VCI V2) и/или адаптера PCAN-USB фирмы PEAK Systems Technik.

Fastwel CAN OPC Server:

Fastwel CAN OPC Server поддерживает интерфейс OPC Data Access 2.0 и может использоваться совместно с различными пакетами программ класса SCADA/HMI.

Предоставляемая демонстрационная версия позволяет до приобретения лицензии ознакомиться с функциональными возможностями сервера, в том числе в конкретном проекте, без ограничений времени работы и количества тегов. Единственным ограничением является отсутствие возможности сохранения и загрузки конфигурации сервера.

Пример OPC UA сервера

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 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.

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-8K, I-87K и корзины Наверх к оглавлению

ОРС сервер

OPC (OLE for Process Control) – набор повсеместно принятых спецификаций, предоставляющих универсальный механизм обмена данными в системах контроля и управления.
OPC технология обеспечивает независимость потребителей от наличия или отсутствия драйверов или протоколов, что позволяет выбирать оборудование и программное обеспечение, наиболее полно отвечающее реальным потребностям бизнеса.

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

Суть 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 позволяет организовать коммуникацию между оборудованием от разных производителей и гарантировать непрерывное получение данных в режиме реального времени.

Nano Embedded Device Server: подходит для самых маленьких датчиков;
Micro Embedded Device Server: подходит для недорогих ПЛК;
Embedded UA Server: подходит для более мощных ПЛК и пограничных шлюзов;
Standard UA Server: полноценная реализация, поддерживающая все функции.

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:

Input Register (входной регистр) - объект, доступный только для чтения и представляющий 16-разрядное значение из области выходных данных подчиненного узла сети Modbus.
Holding Register (выходной регистр) - объект, доступный для записи и чтения, и представляющий 16-разрядное значение в области входных данных подчиненного узла сети Modbus.
Discrete Input (дискретный вход) - объект, доступный только для чтения и представляющий битовое поле в области выходных данных подчиненного узла Modbus.
Coil (дискретный выход) - объект, доступный для записи и чтения, и представляющий битовое поле в области входных данных подчиненного узла Modbus.

Fastwel Modbus OPC Server:

Позволяет пользователям создавать, сохранять и редактировать конфигурационную информацию, описывающую подчиненные узлы Modbus и объекты данных в узлах, подлежащие чтению и записи.
Предоставляет OPC-клиентам возможность обмениваться данными с узлами сети Modbus.
Оптимизирует операции чтения и записи групп регистров и входов/выходов, имеющих смежные адреса в адресном пространстве каждого подчиненного устройства сети.
Обеспечивает прямое и обратное преобразование сетевых данных в типы Integer, Long, Float, Bit, Word и String.

Fastwel Modbus OPC Server поддерживает интерфейс OPC Data Access 2.0 и может использоваться совместно с различными пакетами программ класса SCADA/HMI.

Универсальный OPC-сервер

Fastwel UniOPC Server является приложением Windows, обеспечивающим доступ через интерфейс OPC Data Access к нестандартному оборудованию, не имеющему специализированных OPC-серверов. Адаптация сервера к конкретному оборудованию требует программирования со стороны пользователя на языке C++, однако трудоемкость кодирования в части обеспечения OPC-доступа значительно ниже, чем в большинстве универсальных пакетов, предназначенных для разработки OPC-серверов. В то же время UniOPC имеет некоторые ограничения, поэтому, прежде чем принимать окончательное решение, рекомендуется внимательно ознакомиться с бесплатной демо-версией, позволяющей создать и протестировать полнофункциональный проект до покупки лицензии.

Разработанный на базе UniOPC конкретный OPC-сервер состоит из универсальной оболочки (исполняемого файла), реализующей OPC-интерфейсы, и написанной пользователем динамической библиотеки (DLL), которая снабжает сервер данными. Несколько примеров таких DLL разной степени сложности включены в комплект поставки сервера, поэтому при написании своего кода рекомендуется взять за основу один из этих примеров.

Со стороны пользовательской DLL UniOPC позволяет:

Определить структуру иерархического пространства тегов
Публиковать значения тегов
Управлять качеством и временными метками (timestamp) тегов
Осуществлять запись тегов, вызывая пользовательские функции обратного вызова (callback) в DLL.

Со стороны графического интерактивного интерфейса пользователя UniOPC позволяет:

Просматривать иерархическое пространство тегов
Наблюдать значения, временнные метки и признаки качества тегов в реальном времени
Сохранять и восстанавливать конфигурацию сервера.

Сервер поддерживает следующие типы данных:

Логические (да/нет)
Целые числа (32р)
Числа с плавающей точкой (float 32р)
Строки символов (со стороны DLL - ASCII)

Разработка пользовательской DLL производится в среде Microsoft Visual C++ (в комплект поставки входят проекты для VC++ 6.0). Разработка в других средах (например, Borland C++) и на других языках программирования (например, Pascal и Assembler) в принципе допустима.

Fastwel UniOPC Server поддерживает интерфейс OPC Data Access 2.0 и может использоваться совместно с различными пакетами программ класса SCADA/HMI.

Просто о стандартах OPC DA и OPC UA

OPC (аббр. от англ. Open Platform Communications, ранее англ. OLE for Process Control) – это набор программных технологий, которые предоставляют единый интерфейс для управления различными устройствами и обмена данными. Спецификации OPC были разработаны международной некоммерческой организацией OPC Foundation, которую создали в 1994 году ведущие производители средств промышленной автоматизации. Целью создания OPC было предоставить инженерам универсальный интерфейс для управления различными устройствами.

Реализовав поддержку OPC-клиента, разработчики SCADA систем избавились от необходимости поддерживать сотни драйверов для различных устройств, а производители оборудования, добавив OPC-сервер, обрели уверенность в том, что их продукт может применяться пользователями любых SCADA систем.

Технология OPC включает несколько стандартов, которые описывают набор функций определенного назначения. Текущие стандарты:

Самое широкое распространение получил стандарт OPC DA, но у него есть существенный недостаток. Во времена его разработки он был построен на современных Windows-технологиях: OLE, ActiveX, COM/DCOM, но с тех пор в отрасли прошли изменения и большое распространение получили другие ОС и технологии. Поэтому технологию OPC сделали платформонезависимой и разработали стандарт OPC UA (Unified Architecture) на открытых кроссплатформенных технологиях.

Применение OPC

Нижний уровень - полевые шины (fieldbus) и отдельные контроллеры;
Средний уровень - цеховые сети;
Уровень АСУ ТП - уровень работы систем типа SCADA;
Уровень АСУП - уровень приложений управления ресурсами предприятия, ERP, MES.

Просто о стандартах OPC DA и OPC UA

Перспективы

Можно с уверенностью сказать, что, хотя стандарт OPC DA все еще широко применяется, но уже не удовлетворяет современным требованиям автоматизации. Он основан на устаревших технологиях, сложен в настройке и не соответствует современным стандартам безопасности. На смену ему пришел современный стандарт OPC UA с возможностью шифрования данных и построения единых систем передачи данных от датчиков до Облака. Совместное использование OPC UA с TSN позволяет значительно расширить возможности технологии для передачи данных в реальном времени. Конечно не стоит сейчас же бежать и избавляться от OPC DA, но можно постепенно модернизировать существующие системы и переходить на OPC UA через специальные оболочки (wrapper) и proxy-модули.

Минусы применения OPC

Конечно у любой хорошей технологии есть свои минусы. Например, разработчики SCADA Trace Mode 6 из компании АдАстра Рисерч Груп, выделяют типовые ошибки в проектировании АСУ ТП .

Злоупотребление OPC-технологиями
Неоправданное применение WEB-технологий в АСУ ТП
Применение протоколов реального времени в телемеханических задачах

Например, вы узнали о хорошей технологии OPC и стремитесь заменить все протоколы нижнего уровня только на OPC. Но конвертация промышленных протоколов Modbus, Profibus и любых других на ПК будет занимать дополнительное время и тратить ресурсы компьютера. Тесты показали, что SCADA система работает в 2 раза быстрее напрямую с промышленными протоколами, чем через промежуточный OPC сервер. Конечно, есть системы где процесс не нужно контролировать в реальном времени, но это нужно учитывать при проектировании АСУ ТП.

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

Если система отправляет данные через Интернет в Облако, то наличие слабого шифрования может стать потенциальной уязвимостью и целью для атак хакеров, что ставит под сомнение безопасность всей АСУ ТП.

Работа OPC DA сервера

OPC DA сервер обеспечивает обмен данными (запись и чтение) между клиентской программой (обычно SCADA системой) и конечными устройствами. Данные в OPC представляют собой переменную Тег с некоторыми свойствами. Переменная может быть любого типа, допустимого в OLE: различные целые и вещественные типы, логический тип, строковый, дата, массивом и т. д. Свойства могут быть обязательными, рекомендуемыми и пользовательскими.

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

Дополнительно могут быть указаны необязательные свойства: диапазон изменения значения, единица измерения и другие пользовательские параметры.

Синхронный режим: клиент посылает запрос серверу и ждет от него ответ.
Асинхронный режим: клиент отправляет запрос и сразу же переходит к выполнению других задач. Сервер после обработки запроса посылает клиенту уведомление и тот забирает предоставленные данные.
Режим подписки: сервер отсылает клиенту только те теги, которые изменились. Для того, чтобы шум данных не был принят за их изменение, вводится понятие "мертвой зоны", которая слегка превышает максимально возможный размах помехи.
Режим обновления данных: клиент вызывает одновременное чтение всех активных тегов. Активными называются все теги, кроме обозначенных как "пассивные". Такое деление тегов уменьшает загрузку процессора обновлением данных, принимаемых из физического устройства.

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

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

Каждый стандарт ОРС описывает набор функций определенного назначения. В зависимости от потребностей, могут использоваться различные спецификации 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)

OPC UA (Unified Architecture)

Новая спецификация разрабатывалась более пяти лет и является огромным шагом вперед. В течение ближайших пятнадцати лет она должна постепенно вытеснить используемые сейчас спецификации OPC.
OPC UA совмещает в себе функционал ранее созданных спецификаций DA, А.Е. и HDA и обладает рядом дополнительных преимуществ. Новая спецификация обеспечивает возможность работы с серверами данных через сеть Internet и полную кросс-платформенную совместимость.
На настоящий момент происходит окончательная доработка спецификации, и создаются первые экспериментальные разработки.

Уровни управления АСУ предприятия

Исходя из области применения OPC-серверов в АСУ предприятия различают несколько уровней управления:

нижний уровень — полевые шины (fieldbus) и отдельные контроллеры;
средний уровень — цеховые сети;
уровень АСУ ТП — уровень работы систем типа SCADA;
уровень АСУП — уровень приложений управления ресурсами предприятия.

Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные 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. Кроме того, новая спецификация дает возможность организации передачи информации через сеть интернет.

Читайте также: