ЖУРНАЛ СТА №3/1999

объектов, позволяющая приложению манипулировать удаленными про- граммными объектами, точнее, вызы- вать те или иные функции (методы) этих объектов так, как будто объекты находятся «рядом». Объект может нахо- диться и в самом деле рядом (в адрес- ном пространстве приложения) – тогда это просто COM. Если же объект находится в другой программе на том же компьютере или на другом узле сети, то это DCOM – Distributed (распределенная) COM. В распределенном случае (DCOM) вызов любой функции объекта перехватыва- ется специальным агентом-посредни- ком, так называемой proxy/stub DLL, ко- торая выполняет роль представителя объекта у обратившегося к нему клиен- та. Proxy/stub DLL упаковывает парамет- ры функции (marshaling - транспорти- ровка) и передает вызов операционной системе, которая (возможно, по сети) доставляет вызов по назначению, то есть заставляет реальный объект выпол- нить заданную функцию. Результат за- тем возвращается (примерно по той же цепочке) приложению-клиенту. Удобст- во использования DCOM состоит в том, что приложение-клиент совершенно не обязано знать, где реально находится объект – о степени удаленности объек- та оно может судить только по увеличе- нию расхода времени на вызов функ- ции. OPC-взаимодействие основано на клиент-серверной схеме. OPC-клиент (например, SCADA), вызывая опреде- ленные функции объекта OPC-сервера, подписывается на получение опреде- ленных данных с определенной часто- той. В свою очередь, OPC-сервер, опро- сив физическое устройство, вызывает известные функции клиента, уведомляя его о получении данных и вручая сами данные. Таким образом, при OPC-взаи- модействии используются как прямые COM-вызовы (от клиента к серверу), так и обратные (callback, от сервера к кли- енту). Это надо учитывать при настрой- ках безопасности DCOM в Windows NT: если клиент «видит» данные, но не полу- чает их, значит, скорее всего, система безопасности NT блокировала обрат- ные вызовы. Стандарт OPC, в отличие, например, от устаревшего DDE (Dynamic Data Ex- change), хотя и основан на универсаль- ном фундаменте – COM/DCOM, разра- батывался специально для использова- ния в промышленной автоматизации, поэтому он имеет вполне содержатель- ную концептуальную сторону, то есть, на самом деле, свою проблемно-ориен- тированную модель взаимодействия, которая и реализована через совокуп- ность COM-интерфейсов. Эта концеп- туальная сторона в известной степени независима и представляет самый боль- шой интерес, особенно для пользовате- ля-непрограммиста, для которого тон- кости реализации СОМ-интерфейсов не столь важны. В принципе, основные идеи OPC могли бы быть реализованы и с помощью других объектных техноло- гий (получилось бы что-нибудь вроде CORBA for Process Control, например), однако распространенность Windows- платформ предопределила выбор в пользу стандартов Microsoft. Концепция стандарта OPC Стандарт состоит из трех основных спецификаций: 1)доступ к данным реального времени (Data Access); 2)обработка тревог и событий (Alarms & Events); 3)доступ к историческим данным (Historical Data Access). OPC-серверов, соответственно, тоже может быть три вида, хотя не возбраня- ется совмещать все эти функции в од- ном. OPC-серверы физических уст- ройств обычно являются только серве- рами данных (Data Access Servers). Сер- веры тревог и исторические чаще всего «паразитируют» на серверах данных. Сервер тревог формирует определен- ные логические переменные, называе- мые состояниями (conditions), имея в качестве исходной информации некую переменную (тег), полученную от сер- вера данных. Состояния изменяют свое значение, если переменная, например, вышла за допустимые границы. Об из- менении состояния сервер тревог опо- вещает клиентов, посылая им событие (тревогу), а клиент возвращает серверу подтверждение, что он тревогу воспри- нял. Впрочем, могут существовать со- стояния, не связанные с каким-либо па- раметром и управляемые сервером тре- вог по собственному усмотрению (на- пример, если сервер тревог напрямую взаимодействует с аппаратурой, он мо- жет устанавливать или снимать состоя- ние неисправности). Серверы истори- ческих данных получают от серверов данных параметры в реальном времени и архивируют их, а затем предоставля- ют эти данные другим приложениям (например, для построения графиков трендов). Центральное место среди специфи- каций OPC занимает доступ к данным реального времени (DataAccess). Это са- мая старая и отработанная специфика- ция, в настоящее время действует ее вторая версия. Базовым понятием этой специфика- ции является элемент данных (Item). Каждый элемент данных (то есть факти- чески – параметр технологического процесса) имеет значение, время по- следнего обновления (timestamp) и признак качества, определяющий сте- пень достоверности значения. Значе- ние может быть практически любого скалярного типа: булево, целое, с плава- ющей точкой и т.п. – или строкой (на самом деле это так называемый OLE VARIANT). Время представляется с 100- наносекундной точностью (на самом деле это FILETIME Win32 API). Качест- во—это код, содержащий в себе грубую оценку достоверности параметра — UNCERTAIN, GOOD и BAD (не определе- но, хорошее и плохое), а на случай пло- хой оценки — еще и расшифровку, на- пример, QUAL_SENSOR_FAILURE – не- исправность датчика. Следующим вверх по иерархии явля- ется понятие группы элементов (OPC Group). Группа создается OPC-сервером по требованию клиента, который затем может добавить в группу элементы (Items). Для группы клиентом задается частота обновления данных, и все дан- ные в группе сервер старается обнов- лять и передавать клиенту с заданной частотой. Отдельно стоящих вне груп- пы элементов быть не может. Клиент может создать для себя на сервере не- сколько групп, различающихся требуе- мой частотой обновления. Группа (кро- ме так называемых публичных групп) всегда создается для каждого клиента своя, даже если состав элементов и час- тоты обновления совпадают. Отсоеди- нение клиента приводит к уничтоже- нию созданных для него групп. Элементы в группе – это своего рода клиентские ссылки на некие реальные переменные (теги), находящиеся на сервере или в физическом устройстве. Понятие тега спецификацией OPC не определяется, но подразумевается неяв- но. Элементы в группу клиент добавляет по имени, и эти имена, разумеется, на самом деле являются именами соответ- ствующих тегов. Клиент может либо знать нужные имена заранее (если он такой умный), либо запросить список имен тегов у сервера. Для запроса имен тегов служит интер- фейс IOPCBrowseServerAddressSpace, с помощью которого сервер описывает клиенту свое «пространство имен», ор- ганизованное в общем случае иерархи- чески. Пример полного имени тега: Устройство_1. Модуль_2. Аналоговый Вход_3 (в качестве разделителя используется ОБЗОР ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ 29 3/99