Главная Пресс-центр Статьи и публикации Стандарт OPC путь к интеграции разнородных систем, PCWeek №32, 2001

Стандарт OPC путь к интеграции разнородных систем, PCWeek №32, 2001

И. В. Куцевич, А. Б. Григорьев, ЗАО РТСофт

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

Введение

OPC это аббревиатура от OLE for Process Control, или OLE для Управления Процессами. Если принять это во внимание и попробовать прокомментировать название статьи, то придётся сказать, что ключевыми словами для понимания изложения являются технология Microsoft OLE (Object Linking and Embedding связывание и встраивание объектов) и интеграция. Точнее, спрятанное под термином OLE понятие COM. Если не считать, конечно, Управление Процессами.

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

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

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

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

Интеграция

Когда мы говорим об интеграции, что мы понимаем под этим термином? Предположим, в результате огромных усилий программистов создана сложная комплексная система, охватывающая автоматизацию на всех уровнях предприятия, начиная от самого нижнего управления датчиками и исполнительными механизмами и заканчивая уровнем управления предприятием, вплоть до обобщённой картинки завода у директора предприятия. Реализована ли в данном случае концепция интеграции? В общем случае нет. Интеграция подразумевает не единую глобальную систему как таковую, а, прежде всего, взаимодействие различных уровней программного обеспечения между собой1. Фактически, речь идёт о том, что различные программные системы, созданные с помощью различных средств, установленных на различных платформах, работающих на разных компьютерах, умеют договариваться. То есть, они знают, как запросить друг у друга данные и как послать друг другу указания. По большому счёту, интеграция сводится к конфигурированию высоких договаривающихся сторон.

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

Экскурс в COM/DCOM

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

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

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

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

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

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

Интерфейсы объектов

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

Доступ к объектам

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

Обмен в COM

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

Регистрация

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

Регистрация делает доступной информацию о расположении объектов всем приложениям. И это второй шаг на пути к интеграции.

Обслуживание объектов

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

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

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

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

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

Удалённые объекты

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

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

Предоставление объектов

Чтобы использовать объект, необходимо знать, как он устроен, вернее, как устроены его интерфейсы. Для этого они должны быть опубликованы. Например, в виде официальной документации. Или в виде стандарта. Таким образом, вырисовывается две возможности. Либо вы разрабатываете некий COM-объект, украшаете его и его интерфейсы GUID, снабжаете документацией7 и распространяете в виде бинарного кода. Либо вы намечаете какую-либо проблему, изучаете её, возможно, даже собираете некую тусовку, называемую Foundation или Committee, и издаёте стандарт, подробно описывающий объекты, призванные решать данную проблему. Реализацию вы оставляете другим. Если дело стоящее, желающие найдутся. Именно это можно сказать об OPC!

Использование объектов

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

Реализация объектов

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

OPC в свете COM

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

Историческая справка

Сравнительно недавно, в 1994 г., под эгидой Microsoft, была создана организация OPC Foundation (http://www.opcfoundation.org). Как определяет сама OPC Foundation, её целью является разработка и поддержка открытых промышленных стандартов, регламентирующих методы обмена данными в реальном времени между клиентами на базе PC и ОС8 Microsoft. Сейчас эта организация насчитывает более 220 членов, включая почти всех ведущих поставщиков контрольно-измерительного и управляющего оборудования для АСУ ТП. Достаточно назвать такие фирмы, как Siemens, Schneider Automation, Rockwell Software, Wonderware, Intellution, Ci Technologies, не говоря уже о самой Microsoft.

Технология

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

разрабатывают спецификации COM-интерфейсов и COM-объектов;
присваивают им GUID;
оформляют всё в виде стандартов и опубликовывают;
генерируют или создают вспомогательные файлы: idl-, h- и c-файлы для Custom-интерфейса; библиотеки типов для интерфейса автоматизации; заместители (proxy) и заглушки (stub) для поддержки межпроцессного взаимодействия;
разрабатывают вспомогательные компоненты, например, утилиту opcenum, позволяющую OPC-клиенту увидеть список всех OPC-серверов локальной сети;
ну и, конечно, развивают деятельность по рекламе и популяризации, включая демонстрационные программы и оценку производительности.

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

В настоящее время имеются следующие OPC-стандарты.

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

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

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

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

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

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

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

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

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

OPC-сервер (потребители снизу)

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

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

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

OPC-клиент (потребители сверху)

Правила игры заданы OPC-сервер поставляет данные, OPC-клиент потребляет. Этим задаётся вторая категория пользователей спецификаций OPC. И к ней относятся в первую очередь те, кто реализует программное обеспечение более высокого уровня. Например, поставщик SCADA-пакета. Или чего-то   близкого по назначению.

Что же должен сделать производитель верхнего ПО, если он задался целью обеспечить свой продукт стандартным интерфейсом? Он должен получить нужную спецификацию и прилагаемые программные компоненты. Затем он должен изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-клиента. И, наконец, он должен посадить достаточно опытного программиста за Visual Studio, и тот с помощью ATL-библиотеки реализует требуемые интерфейсы, а значит и OPC-клиент для Custom-интерфейса. Можно использовать Visual Basic или, скажем, Delphi, и тогда будет создан OPC-клиент для интерфейса Автоматизации (если таковая реализована для данной спецификации). По-прежнему, сэкономить на квалификации программиста можно, используя Toolkit.

Остальные потребители

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

OPC Data Access

Чтобы лучше почувствовать, что такое OPC, рассмотрим подробнее главный, по большому счёту, стандарт. Будем называть его сокращённо DA.

Стандарт DA предназначен для поставки оперативных данных от оборудования и/или к оборудованию. Для стандарта DA реализованы спецификации как Custom-интерфейса, так интерфейса Автоматизации. С точки зрения функциональных интерфейсов, последний ничем не отличается от Custom, кроме того, что не позволяет одновременно работать с несколькими OPC-серверами и добавлен упоминавшийся выше COM-интерфейс IDispatch, обязательный в OLE Automation. Это позволило OPC Foundation издать обёртку (wrapper) в виде dll, преобразующую один интерфейс в другой.

Второе замечание. Стандарт DA имеет две версии интерфейсов: 1.0 и 2.0. Как мы уже знаем, с точки зрения COM, это самостоятельные спецификации. OPC-клиент предварительно запрашивает, может ли он работать с нужным ему COM-интерфейсом в используемом OPC-сервере. С точки зрения функциональности, в версии 2.0 механизм уведомления клиента приведён к стандартному механизму COM/DCOM, что упрощает программирование.

Более интересно рассмотреть, с чем работает DA.

Данные

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

Свойства

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

Получение данных

Существует три основных способа получения OPC-клиентом данных от OPC-сервера: синхронное чтение, асинхронное чтение и подписка. При синхронном чтении клиент посылает серверу запрос со списком интересующих его переменных и ждёт, когда сервер его выполнит. При асинхронном чтении клиент посылает серверу запрос, а сам продолжает работать. Когда сервер выполнил запрос, клиент получает уведомление (через интерфейс соответствующего COM-объекта, реализованного в клиенте!). И, наконец, в случае подписки клиент передаёт серверу список интересующих его переменных, а сервер затем регулярно присылает клиенту информацию об изменившихся переменных из этого списка (опять же, через интерфейс соответствующего COM-объекта клиента!). Эти списки в терминологии OPC называются группами. Каждый клиент может поддерживать одновременно много групп с разной скоростью обновления.

Запись данных

Ничем не отличается от чтения, за исключением того, что нет записи по подписке.

Источники данных

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

Организация данных

Переменные в OPC-сервере могут быть упорядочены либо в простой список, либо в дерево, напоминающее дерево файлов на диске (только вместо термина папка в OPC говорят ветвь). И есть соответствующие интерфейсы для навигации по этому дереву. Можно, в частности, в любой момент запросить дерево переменных, поддерживаемых OPC-сервером. Если оборудование допускает, дерево может изменяться динамически. Впрочем, если быть до конца точными, интерфейс, необходимый для просмотра дерева, объявлен в OPC-спецификации как необязательный. Тем не менее, он настолько удобен, что практически все OPC-серверы его реализуют.

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

Инструментарий

Как уже было сказано, чтобы написать OPC-сервер или OPC-клиент, нужно только взаимодействие с OPC Foundation (OPC-спецификации) и Microsoft (Visual C++ и пр.). Но

Проблемы

Есть очень много сложных вопросов, которые придётся решить при программировании OPC-интерфейсов.

Во-первых, само программирование COM не такое уж незатейливое, даже с применением ATL. Есть в чём поразбираться.

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

И, в-третьих, есть вопросы системного уровня, которыми нужно владеть. Очень схематично: фабрики класса (новый COM-термин!), заглушки и заместители, апартаменты (новый COM-термин!), асинхронный обмен, многозадачность, синхронизация, память Кстати, последний вопрос весьма актуальный, так как в COM допускается сплошь и рядом в OPC используется) выделение памяти в сервере, а удаление её возлагается на клиента. Малейшая неточность, и пойдут трудно устранимые утечки памяти. А, учитывая, что OPC-сервер обычно должен работать стационарно, рано или поздно крах системы неизбежен.

Toolkit

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

OPC и интеграция

Теперь настало время взглянуть на OPC с точки зрения главной темы статьи. На рис.1 представлена схема, иллюстрирующая возможные применения OPC-серверов в АСУ предприятия. Мы различаем несколько уровней управления:

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

Рис.1 Возможные применения OPC-серверов в АСУ предприятия


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

Разновидности OPC-серверов

Перечислим несколько детальнее, где может найти себе работу OPC-сервер.

OPC поверх драйвера

Если имеется оборудование, например плата АЦП, управляемая через драйвер на компьютере с Windows или другой ОС, поддерживающей COM/DCOM, то это самый главный кандидат на то, чтобы непосредственно поверх драйвера был реализован OPC-сервер.

Замена устройства не потребует изменения остальных приложений: драйвер изменился, но OPC-интерфейс поверх него остался прежний.

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

OPC для ОС

Несколько более сложная схема, когда некоторые управляющие приложения работают на компьютере, где не поддерживается COM/DCOM. В этом случае возможна реализация двухкомпонентного OPC-сервера. На стороне ОС, не поддерживающей COM, устанавливается сетевой модуль, который с одной стороны связан с приложением (ями), а с другой стороны связан через сеть с OPC-сервером. Заметим, что сетевой модуль может быть стандартным, как, например, ISaNet в системе ISaGRAF. Тогда необходимо разрабатывать только OPC-сервер. По такому принципу создан, например, OPC-сервер ISaGRAF от фирмы РТСофт (www.rtsoft.ru). Другая разновидность сетевой модуль создаётся специально для OPC-сервера. Возможна даже реализация, когда этот модуль не ориентирован на конкретное приложение, а предоставляет некоторый API-интерфейс для любых приложений, желающих обслуживаться с помощью OPC. Пример такого решения OPC-сервер для операционной системы OS-9, разработанный в компании РТСофт (www.rtsoft.ru).

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

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

И другие применения OPC

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

Технология DCOM, как уже говорилось, не работает в глобальных сетях. Поэтому для привлечения к OPC-технологии Internet-технологий можно набросать такой путь. Расширение web-сервера является OPC-клиентом, собирающим данные от OPC-серверов. А на стороне клиентов запускается динамическая html- или xml-страница, получающая данные от этого web-сервера. Её можно сделать даже OPC-сервером для других приложений.

Выгоды

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

Состояние

Всё, что излагалось до сих пор, либо объясняло технологию, либо описывало возможности. Каково же действительное состояние дел?

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

Но на деле всё несколько не так.

Спецификации

В настоящее время полностью завершённой являются только спецификация DA OPC. Другие спецификации ещё дорабатываются, по крайней мере, с точки зрения интерфейса Автоматизации (для Batch OPC доступна бета-версия интерфейса Автоматизации, для остальных спецификаций нет ещё даже бета-версий).

Производители оборудования

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

Программы высокого уровня

Здесь картина аналогична предыдущей. Спросом пользуется лишь DA OPC. Все известные нам SCADA-продукты являются OPC-клиентами. Например, Wonderware InTouch, CiTect (Ci Technologies). Многие SCADA-продукты являются также OPC-серверами. Например, Citect. Другое ПО подвержено влиянию OPC в гораздо меньшей степени.

Операционные системы

В настоящее время технологию COM/DCOM поддерживает следующие операционные системы:

все Windows, начиная с Windows 95. Это обеспечивается самой компанией Microsoft;
большинство Unix-подобных ОС, включая Linux; поддерживается фирмой GE Software;
ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver; имеется поддержка OPC, встроенная в систему разработки Tornado.

В других операционных системах, насколько нам известно, поддержки COM/DCOM нет. Это не очень отрадный факт, поскольку разработчиков систем автоматизации в первую очередь интересуют ОС реального времени.

Перспективы

Итак, в настоящее время картина далеко не идеальна. Ещё довольно много оборудования и ПО не охвачено OPC-технологиями. Даже технологией DA. Но нам представляется, что сейчас в мире налицо некий бум OPC, по крайней мере, в отношении, опять же, DA. Думается также, что Microsoft рано или поздно доведёт всё до желаемого уровня по всем направлениям. Тем более что альтернативы пока нет. Мы имеем в виду не COM/DCOM, а именно спецификации на обмен технологическими данными. Поскольку для COM/DCOM альтернатива как раз имеется CORBA. Это действительно изначально платформенно-независимая технология взаимодействия приложений. Но это не обмен технологическими данными, реализующий более высокий уровнем абстракции. Кстати, заметим, что на рынке имеются OPC-шлюзы к CORBA (это возможно, как и к любому другому протоколу, о чём говорилось выше).

Заключение

Технология OPC предлагает стандарты для обмена технологическими данными, в которые заложены самые широкие возможности. Учитывая большой авторитет вовлечённых в эту деятельность фирм, включая саму Microsoft, можно ожидать, что технология OPC будет набирать силу. И это перспективная технология для использования её в интеграции разнородных систем. Хотя процесс становления ещё далеко не завершён и есть много проблем, которые предстоит решить.

21.04.2014