 |
Тригонометрические функции. 9 глава
|
|
|
|
<server>|<topic>!<item> <data>,
где:
<server> – имя DDE-сервера в формате RTM<nnn>, где <nnn> - номер узла, к которому адресован запрос;
<topic> – тема запроса. В режиме ADVISE указывается GET, а в режимах POKE и REQUEST – обозначения атрибутов каналов;
< item> – имя канала;
<data> – посылаемое значение в формате числа с плавающей запятой. Оно присутствует только в режиме POKE.
При запросе реального значения в режиме REQUEST в качестве темы надо указать GET. Для посылки значения из приложения в атрибут ВХОД канала Трейс Моуд (режим POKE) надо задать тему PUT или GET.
Для связи МРВ с другими приложениями, запущенными на удаленных компьютерах, можно использовать механизм NetDDE. Формат запроса в этом случае остается таким же, как описано выше. Однако элементы server и topic формируются иначе.
Имя сервера формируется следующим образом:
\\<NAME>\NDDE$
где
<NAME> - имя компьютера, где работает МРВ.
В качестве темы надо записать RTM<nnn>$, где <nnn> - номер узла, к которому адресован запрос, а в качестве item - имя канала.
Управление обменом по DDE осуществляется каналами подтипа СИСТЕМНЫЙ с дополнением “сеть, DDE”. Для этого используются биты c 6-го по 11-й (считая с 0). Контроль текущего состояния обмена по DDE осуществляется с помощью канала ДИАГНОСТИКА с дополнением к подтипу DDE. Эти каналы подробно описаны ниже.
Дополнение к типу Системный – “Сеть, DDE” – предназначен для управления обменом по сети и DDE и контроль заблокированных функций узлов, находящихся в состоянии резерв. Биты канала показывают отключение следующих функций (при типе канала INPUT):
– 0 – запрет сетевых рассылок;
– 1 – запрет запроса данных каналами подтипа СВЯЗЬ с дополнением к подтипу IN NET;
– 2 – запрет передачи данных каналами подтипа СВЯЗЬ с дополнением к подтипу OUT NET;
|
|
|
– 3 – запрет приема сетевых рассылок;
– 4 – запрет приема от себя;
– 5 – запрет скользящего блока (досылка не изменяющихся значений каналов);
– 6 – запрет передачи данных по DDE от МРВ;
– 7 – запрет приема данных по DDE от внешних приложений;
– 8 – запрет изменения входов каналов по DDE;
– 9 – запрет изменения границ каналов по DDE;
– 10 – запрет изменения шкал каналов по DDE;
– 11 – запрет изменения остальных изменяемых атрибутов каналов по DDE;
– 12 – запрет отсылки времени синхронизации;
– 13 – запрет коррекции по синхронизации;
– 14 – запрет ответа на запросы по IN NET;
– 15 – запрет новых подключений по OPC и графических консолей.
Значения перечисленных битов каналов определяют следующие состояния: 0 – разрешить; 1 – запретить.
При переводе узла в состояние резерв данный канал принимает значение 0х8027. Это означает установку в 1 битов 0, 1, 2, 5, 15 и запрет соответствующих функций. При необходимости изменить набор отключаемых функций надо использовать такие же каналы, но установить для них тип OUTPUT. Чтобы при старте МРВ иметь требуемый набор функций, надо для этих каналов установить требуемое начальное значение и установить флаг Отработать.
Дополнение к типу Диагностика “DDE” – предназначено для контроля состояния обмена по DDE. Значение этого канала определяет следующие ситуации в обмене:
– 0 – нормальная работа;
– 3 – ошибка записи;
– 4 – ошибка чтения;
– 5 – ошибка работы с памятью;
– 7 – ошибка формата;
– 10 – были запрошены несуществующие данные;
– 32 – ошибка времени выполнения операции по причине задержек.
Выступая DDE-клиентом, МРВ выполняет следующие операции:
– принимает данные, посылаемые DDE-серверами, по мере их изменения (режим ADVISE);
– управляет переменными в DDE-серверах (режим POKE);
– запрашивает данные у DDE-серверов (режим REQUEST).
Для обмена данными с DDE-серверами предусмотрен подтип каналов DDE. Его дополнение к подтипу указывает файл конфигурации обмена. Такие файлы должны располагаться в директории проекта. Их имена формируются следующим образом:
|
|
|
DDECNF<n>.CNF
где
<n> – номер от 0 до 7. Он соответствует значению дополнения к подтипу (если дополнение к подтипу DDE0, то n должно быть равно 0, если DDE1, то 1 и т. д.).
Настройки каналов подтипа DDE определяют режим обмена, а также метод и режим формирования запросов у DDE-сервера.
Формат файла конфигурации DDE-обмена имеет текстовый формат и содержит следующую информацию:
server topic0 [format_item]
topic1
….
где
server – имя DDE-сервера;
topic<n> – название темы (до 256 тем, которые выбираются настройкой канала D (см. ниже));
format_item – формат элемента item.
Формат item может отсутствовать. В этом случае для канала надо выбрать режим использования в качестве item его имени.
Строка описания элемента item может содержать тексты и форматы вывода чисел в нотации языка Си. При формировании DDE запроса item будет состоять из текстов и вставленных в него чисел в указанном формате. Величины чисел определяются значением настроек канала. Например, в запросе данных от OLE/DDE менеджера фирмы SIEMENS при связи по PROFIBUS DP формат элемента item выглядит следующим образом:
Slave<aaa>EB<bbb>
где
<aaa> - три цифры определяющие номер устройства в сети PROFIBUS;
<bbb>- три цифры определяющие номер запрашиваемой переменной на указанном устройстве;
Формат элемента item при этом выглядит следующим образом: Slave%.3dEB%.3d
Каналы подтипа DDE имеют шесть настроек. Следующий рисунок демонстрирует настройку каналов данного подтипа.
Первая настройка называется режим. Она используется для задания режима обмена. Он выбирается из списка, содержащего следующие пункты:
REQ/POKE[data] – обмен в режиме REQUEST для каналов типа INPUT и POKE для каналов типа OUTPUT;
REQ/POKE[data/r] – обмен в режиме REQUEST для каналов типа INPUT и POKE для каналов типа OUTPUT с добавлением в конце передачи данных символа /r;
REQ/POKE[data/n] – обмен в режиме REQUEST для каналов типа INPUT и POKE для каналов типа OUTPUT с добавлением в конце передачи данных символа /n;
ADVISE – обмен в режиме ADVISE (только для каналов типа INPUT).
Следующая настройка (формат) определяет метод формирования элемента item в запросе. Метод выбирается из списка, содержащего следующие пункты:
|
|
|
имя – в качестве item используется имя канала;
2 параметра – в строке описания формата элемента item может присутствовать до двух полей вставки чисел. Значение первого числа определяется величинами настроек A и B (младший и старший байт соответственно), а второго – C;
3 параметра – в строке описания формата элемента item может присутствовать до трех полей вставки чисел. Значения первого, второго и третьего чисел определяются величинами настроек A, B и C соответственно.
Лекция №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); |
|
|
|
