Лекция №8.

Тема: “Основы технологии COM.Обзор технологии OPC. Основные понятия и определения. Краткий обзор объектов и интерфейсов в технологии OPC. Интерфейсы и их методы объекта OPCServer, OPCGroup, EnumOPCItemAttributes. Поддержка технологии OPC в системе TraceMode. Настройка обмена по OPC. Файл конфигурации”.

8.1 Основы технологии COM

Первыми попытками решить эту непростую задачу были буфер обмена, разделяемые файлы и технология динамического обмена данными (Dynamic Data Exchange, DDE). После чего была разработана технология связывания и внедрения объектов (Object Linking and Embedding, OLE). Первоначальная версия OLE 1 предназначалась для создания составных документов. Эта версия была признана несовершенной и на смену ей пришла версия OLE 2. Новая версия позволяла решить вопросы предоставления друг другу различными программами собственных функций. Данная технология активно внедрялась до 1996 года, после чего ей на смену пришла технология ActiveX, которая включает в себя автоматизацию (OLE-автоматизацию), контейнеры, управляющие элементы и Web-технологию.

COM (Component Object Model) – это объектная модель компонентов, данная технология является базовой для технологий ActiveX и OLE. Технологии OLE и ActiveX – всего лишь надстройки над данной технологией. Технология COM является базовой по отношению к OLE и ActiveX и применяется при описании API и двоичного стандарта связи объектов различных языков и сред программирования. COM предоставляет модель взаимодействия между компонентами и приложениями.

Ниже перечислены основные термины, которыми оперирует технология COM.

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

2. COM-интерфейс применяется для объединения методов COM-объекта. Интерфейс позволяет клиенту правильно обратиться к COM-объекту, а объекту – правильно ответить клиенту. Названия COM-интерфейсов начинаются с буквы I. Клиент может не знать, какие интерфейсы имеются у COM-объекта. Для того чтобы получить их список, клиент использует базовый интерфейс IUnknown, который есть у каждого COM-объекта.

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

4. COM со-классы (coclass) – это классы, которые содержат один или более COM-интерфейс. Вы можете не обращаться к COM-интерфейсу непосредственно, а получать доступ к COM-интерфейсу через со-класс. Со-классы идентифицируются при помощи идентификаторов класса (CLSID).

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

6. Технология DCOM (Distributed COM) – это распределенная COM-технология. Она применяется для предоставления средств доступа к COM-объектам, расположенным на других компьютерах в сети. Операционные системы Windows NT 4 и Windows 98 имеют встроенную поддержку DCOM.

7. Каждый COM-объект имеет счетчик ссылок. Данный счетчик содержит число процессов, которые в текущий момент времени используют COM-объект. Под процессом здесь подразумевается любое приложение или DLL, которые используют COM-объект. Счетчик ссылок на COM-объект нужен для того, чтобы высвобождать процессорное время и оперативную память, занимаемую COM-объектом, в том случае, когда он не используется. После создания и обращения к COM-объекту счетчик ссылок увеличивается на единицу. Всякий раз, когда новое приложение подключается к COM-объекту – счетчик увеличивается. Когда процесс отключается от COM-объекта – счетчик уменьшается. При достижении счетчиком нуля память, занимаемая COM-объектом, высвобождается.

8. Часть данных, использующаяся совместно несколькими приложениями, называется OLE-объектом. Те приложения, которые могут содержать в себе OLE-объекты, называются OLE-контейнерами (OLE container). Приложения, имеющие возможность содержать свои данные в OLE-контейнерах, называются OLE-серверами (OLE server).

При создании COM-приложения необходимо обеспечить следующее: COM-интерфейс, COM-сервер, COM-клиент.

Рассмотрим эти составляющие COM-приложения более подробно.

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

Рисунок 1 – COM-интерфейс.

Для примера, каждый COM-объект всегда поддерживает основной COM-интерфейс IUnknown, который применяется для передачи клиенту сведений о поддерживаемых интерфейсах.

Ключевыми аспектами COM-интерфейсов являются следующие:

• однажды определенные, интерфейсы не могут быть изменены. Таким образом, вы можете возложить на один интерфейс определенный набор функций. Дополнительную функциональность можно реализовать с помощью дополнительных интерфейсов;

• по взаимному соглашению, все имена интерфейсов начинаются с буквы I, например IPersist, IMalloc;

• каждый интерфейс гарантированно имеет свой уникальный идентификатор, который называется глобальный уникальный идентификатор (Globally Unique Identifier, GUID). Уникальные идентификаторы интерфейсов называют идентификаторами интерфейсов (Interface Identifiers, IIDs). Данные идентификаторы обеспечивают устранение конфликтов имен различных версий приложения или разных приложений;

• интерфейсы не зависят от языка программирования. Вы можете воспользоваться любым языком программирования для реализации COM-интерфейса. Язык программирования должен поддерживать структуру указателей, а также иметь возможность вызова функции при помощи указателя явно или неявно;

• интерфейсы не являются самостоятельными объектами, они лишь обеспечивают доступ к объектам. Таким образом, клиенты не могут напрямую обращаться к данным, доступ осуществляется при помощи указателей интерфейсов;

• все интерфейсы всегда являются потомками базового интерфейса IUnknown.

8.2 Обзор технологии OPC. Основные понятия и определения.

Технология связывания и внедрения объектов для систем промышленной автоматизации OPC (OLE for Process Control) предназначена для обеспечения универсального механизма обмена данными между датчиками, исполнительными механизмами, контроллерами, устройствами связи с объектом и системами представления технологической информации, оперативного диспетчерского управления, а также системами управления базами данных. Производители аппаратных средств, пользуясь спецификацией OPC, имеют возможность разрабатывать единственный сервер OPC для обеспечения единственного и наиболее общего способа организации доступа к данным и передачи в адрес приложений-клиентов различных производителей программного обеспечения для промышленной автоматизации. OPC основана на модели распределенных компонентных объектов Microsoft DCOM и устанавливает требования к классам объектов доступа к данным и их специализированным (custom) интерфейсам для использования разработчиками клиентских и серверных приложений. Для обмена данными с приложениями-клиентами (Application), разработка которых ведется на языках типа MS Visual Basic, а также с популярными приложениями типа MS SQL, Oracle. Спецификация OPC содержит дополнительные (но необязательные для реализации) требования к интерфейсу OLE-автоматизации (OLE Automation).

Хотя OPC, в первую очередь предназначен для того, чтобы обратиться к данным от сервера, возможно использование OPC интерфейсов для многих применений. На нижнем уровне они могут получать данные от физических устройств в SCADA-системы, или от SCADA-систем во внешние приложения (рисунки 8.1 и 8.2). Архитектура позволяет использовать OPC-сервер, для доступа к данным от различных OPC-серверов.

Р исунок 8.1 – Отношения OPC клиента и сервера.

Рисунок 8.2 – Отношения между OPC клиентом и сервером.

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

OPC-сервер состоит из нескольких объектов: сервер (server), группа (group) и элемент (item). Объект-сервер хранит информацию об OPC-сервере и служит контейнером для объектов-групп. Объект-группа хранит информацию о себе и обеспечивает механизм для содержания и логической организации объектов-элементов. OPC группы предоставляют средство клиентам, для организации данных.

Опираясь на объектную технологию COM/DCOM, стандарт OPC фиксирует определенную модель взаимодействия между клиентом и сервером.

Базовым понятием этой модели является элемент данных (Item). Элементы OPC представляют доступ к источникам данных в пределах сервера. Элемент – это не источник данных он только логически связан с ним. Под элементом следует понимать простое определение адреса данных, а не фактический физический источник данных, на которые ссылается адрес. Каждый элемент данных имеет: значение, время последнего обновления (timestamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа: булево, целое, с плавающей точкой или строкой (так называемый OLE VARIANT). Время представляется со 100 наносекундной точностью (FILETIME Win32 API). Реальная точность измерения времени обычно бывает хуже и, в общем случае, зависит от реализации сервера и аппаратуры. Качество – это код, содержащий в себе грубую оценку: UNCERTAIN (не определено), GOOD (хорошее) и BAD (плохое). В случае BAD также содержится расшифровка, например QUAL_SENSOR_FAILURE – ошибка датчика.

Следующим, вверх по иерархии, является понятие группы элементов (OPC Group). Группа создается OPC-сервером по требованию клиента, который затем может добавлять в группу элементы (Items). Существует два типа групп: общедоступные (public) и частные (private). Общедоступные используются для доступа различных клиентов, частные для единственного клиента. В пределах каждой группы клиент может определить один или более элементов. Клиентом для группы задается частота обновления данных, и все данные в группе сервер старается обновлять и передавать клиенту с данной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся требуемой частотой обновления. Для каждого клиента всегда создается своя группа (кроме публичных групп), даже если состав элементов и частоты обновления совпадают. Отсоединение клиента приводит к уничтожению группы.

Рисунок 8.3 – Отношение элемент-группа.

Элементы в группе (рисунок 8.3) это своего рода клиентские ссылки на некие реальные переменные (тэги), находящиеся на сервере или в физическом устройстве. Понятие тэга спецификацией OPC не определяется, но подразумевается неявно. Элементы в группу клиент добавляет по имени, и эти имена являются именами соответствующих тэгов. Клиент может либо знать нужные имена заранее, либо запросить список имен тэгов у сервера. Для запроса имен тэгов служит интерфейс IOPCBrowseServerAddressSpace, с помощью которого сервер описывает клиенту свое “пространство имен”, организованное, в общем случае, иерархически. Пример полного имени тэга: Устройство1.Модуль5.АналоговыйВход3. При добавлении элемента в группу, клиент всегда указывает полное имя. Группы, создаваемые клиентом, не обязаны совпадать (и, как правило, не совпадают) с подразделами пространства имен сервера, элементы в группу добавляются “в разнобой”. Единственное, что их объединяет – это общая частота обновления и синхронность отправки клиенту.

На верхней ступеньке иерархии понятий находится сам OPC-сервер. Из всех перечисленных понятий (OPC-группа, OPC-элемент) он единственный является COM-объектом, все остальные объекты доступны через его интерфейсы, которые он предоставляет клиенту.

8.3 Краткий обзор объектов и интерфейсов в технологии OPC

П риложение OPC-клиента присоединяется к OPC-серверу через специализированный (custom) интерфейс или интерфейс автоматизации (automation). OPC-серверы должен включать специализированный интерфейс и опционально предоставляют интерфейс автоматизации. Объект OPC-сервера обеспечивает доступ (чтение/запись) или присоединение к набору источников данных. OPC-клиент соединяется с OPC-сервером через интерфейсы (рисунок 9). Объект OPC-сервер обеспечивает функциональные возможности OPC клиенту для создания и управления объектами группы. Эти группы позволяют клиентам организовывать данные для доступа. Группа может быть активизирована и дезактивирована как структурная единица. Группа также обеспечивает клиенту возможность “подписаться” на список элементов таким образом, что по изменению их значений, элементы клиенту будет об этом сообщено.

Рисунок 9 – Стандартные объекты: OPC-сервер и OPC-группа.

Все специализированные интерфейсы можно разделить на группы по их принадлежности к объектам.

Таблица 1 – Специализированные интерфейсы и их методы.

Объект	Интерфейс
OPCServer	IOPCServer IOPCServerPublicGroups (опционально) IOPCBrowseServerAddressSpace (опционально) IOPCItemProperties (версия 2.0 и выше) IConnectionPointContainer (версия 2.0 и выше) IOPCCommon (версия 2.0 и выше) IPersistFile (опционально)
OPCGroup	IOPCGroupStateMgt IOPCPublicGroupStateMgt (опционально) IOPCASyncIO2 (версия 2.0 и выше) IOPCAsyncIO IOPCItemMgt IConnectionPointContainer (версия 2.0 и выше) IOPCSyncIO IDataObject
EnumOPCItemAttributes	IEnumOPCItemAttributes

8.3.1 Интерфейсы и их методы объекта OPCServer

Интерфейс IOPCCommon:

HRESULT	SetLocaleID ( dwLcid )
HRESULT	GetLocaleID ( pdwLcid )
HRESULT	QueryAvailableLocaleIDs ( pdwCount, pdwLcid )
HRESULT	GetErrorString ( dwError, ppString)
HRESULT	SetClientName (szName)

Интерфейс IOPCServer:

HRESULT	AddGroup(szName, bActive, dwRequestedUpdateRate, hClientGroup, pTimeBias, pPercentDeadband, dwLCID, phServerGroup, pRevisedUpdateRate, riid, ppUnk)
HRESULT	GetErrorString(dwError, dwLocale, ppString)
HRESULT	GetGroupByName(szName, riid, ppUnk)
HRESULT	GetStatus(ppServerStatus)
HRESULT	RemoveGroup(hServerGroup, bForce)
HRESULT	CreateGroupEnumerator(dwScope, riid, ppUnk)

Интерфейс IConnectionPointContainer:

HRESULT	EnumConnectionPoints( IEnumConnectionPoints ppEnum);
HRESULT	FindConnectionPoint( REFIID riid, IConnectionPoint ppCP);

Интерфейс IOPCItemProperties:

HRESULT	QueryAvailableProperties(szItemID,pdwCount, ppPropertyIDs, ppDescriptions, ppvtDataTypes );
HRESULT	GetItemProperties(szItemID,dwCount,pdwPropertyIDs,ppvData, ppErrors );
HRESULT	LookupItemIDs( szItemID, dwCount, pdwPropertyIDs, ppszNewItemIDs, ppErrors );

Интерфейс IOPCBrowseServerAddressSpace:

HRESULT	QueryOrganization(pNameSpaceType );
HRESULT	ChangeBrowsePosition(dwBrowseDirection, szString );
HRESULT	BrowseOPCItemIDs( dwBrowseFilterType, szFilterCriteria, vtDataTypeFilter, dwAccessRightsFilter, ppIEnumString );
HRESULT	GetItemID( szItemDataID, szItemID );
HRESULT	BrowseAccessPaths( szItemID, ppIEnumString );

Интерфейс IOPCServerPublicGroups:

HRESULT	GetPublicGroupByName(szName, riid, ppUnk);
HRESULT	RemovePublicGroup(hServerGroup, bForce);

Интерфейс IPersistFile:

HRESULT	IsDirty();
HRESULT	Load(pszFileName, dwMode);
HRESULT	Save(pszFileName, fRemember);
HRESULT	SaveCompleted( pszFileName);
HRESULT	GetCurFileName( ppszFileName);