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

    

Окончание. Начало в PC Week/RE, N 32/ 2001.

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 (DA), предназначенный для поставки оперативных данных от оборудования и/или к оборудованию (термин ОРС часто используют как синоним ОРС DA). Для DA реализованы спецификации как пользовательского интерфейса, так и интерфейса автоматизации. В качестве функционального интерфейса последний ничем не отличается от пользовательского, за исключением того, что не позволяет одновременно работать с несколькими OPC-серверами и к нему добавлен упомянутый выше COM-интерфейс IDispatch, обязательный в OLE Automation. Это позволило OPC Foundation издать “обертку” (wrapper) в виде dll, преобразующую один интерфейс в другой. Таким образом, разработчик ОРС-сервера заботится только о Custom-интерфейсе, а если клиент предпочитает интерфейс автоматизации, он использует эту библиотеку в качестве переводчика.

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

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

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

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

Типичный инструментарий представляет собой библиотеку, состоящую из OPC-объектов выбранной спецификации. Разработчику же, например, OPC-сервера предлагается некий набор вызовов, достаточно простых (read, write+), которые необходимо “прицепить” к своему оборудованию для доступа к его данным. Для тех, кто знает объектное программирование, заметим, что эти функции могут быть реализованы как виртуальные функции некоторого класса, их нужно перегрузить в своем приложении. Так устроен, например, инструментарий фирмы FactorySoft (www.factorysoft.com).

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

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

- нижний уровень - полевые шины (fieldbus) и отдельные контроллеры;

- средний уровень - цеховые сети;

- уровень АСУ ТП - уровень работы систем типа SCADA;

- уровень АСУП - уровень приложений управления ресурсами предприятия.

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

Опишем подробнее “места работы” OPC-сервера.

Возможные области применения OPC-серверов в АСУ предприятия

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

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

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

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

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

Идея подобной схемы достаточно очевидна. Сеть полевой шины работает в жестком реальном времени, а 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 уже существует версия 2.0 custom-интерфейса, и только 1.0 - для интерфейса автоматизации. Для некоторых других спецификаций тоже существует отставание интерфейсов автоматизации от custom-интерфейсов; для ОРС Security спецификации на интерфейс автоматизации вообще не существует).

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

Среди программ высокого уровня аналогичная картина. Спросом пользуется лишь OPC DA. Все известные нам SCADA-продукты являются OPC-клиентами, например Wonderware InTouch, CiTect (Ci Technologies), а многие из них и 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 предлагает стандарты для обмена технологическими данными, в которые заложены самые широкие возможности. Учитывая большой авторитет вовлеченных в данную деятельность фирм, можно ожидать, что технология OPC будет набирать силу. Это перспективная технология для интеграции разнородных систем. Хотя процесс становления еще далеко не завершен и есть много проблем, которые предстоит решить.

С авторами статьи можно связаться по телефону: (095) 742-6828 или по e-mail: ikutsev@rtsoft.msk.ru или grigoriev@rtsoft.msk.ru.

Версия для печати