Игорь Куцевич, Антон Григорьев

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-сервер

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

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

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

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

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

OPC-стандарты

- 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-интерфейсов для обработки прав доступа к данным, программирование на Си++.

(Продолжение следует)