Стандарта ОРС

На российском рынке систем авто­матизации технологических процессов с некоторой задержкой относительно общих тенденций развития информационных систем начинает формиро­ваться совершенно новый класс за­дач — интеграционные, связанные с объединением потоков информации от разнородных локальных систем сбора данных и управления технологически­ми объектами. Решению подобных за­дач препятствуют многочисленные трудности, во-первых, связанные с не­совместимостью локальных систем (по форматам данных, до поддерживае­мым интерфейсам и протоколам обме­на), во-вторых, в большинстве случаев речь идёт об объединении территори­ально распределённых систем, и здесь на первый план выходят вопросы орга­низации передачи данных, редко встречающиеся при внедрении локальных систем.

Те же вопросы, связанные с организацией передачи данных, возникают и при необходимости проектирования любой территориально (географичес­ки) распределённой АСУ ТП.

Кроме того, при построении мас­штабных систем сбора данных и управ­ления достаточно часто встречаются задачи, для которых не находится оп­тимального решения в рамках предла­гаемых одним поставщиком программ­но-аппаратных средств, и вновь возни­кают проблемы совместимости разно­родного оборудования и программного обеспечения.

Промышленно развитые страны столкнулись с этими вопросами значи­тельно раньше, что и вызвало к жизни появление первого единого стандарта для организации сбора и передачи данных в системах промышленной авто­матизации — ОРС, позволяющего, с одной стороны, полностью решить проблему несовместимости интерфей­сов и протоколов обмена данными при объединении разнородных АСУ ТП и с другой стороны, дающего заказчику возможность свободного выбора обо­рудования и программного обеспече­ния АСУ ТП без жёстких привязок к частнофирменным решениям. Про­цесс обмена информацией с техноло­гическими устройствами происходит внутри ОРС-серверов — программ, по­ставляемых как производителями обо­рудования, так и независимыми разра­ботчиками. (На разработке ОРС-серве­ров специализируются многие компа­нии, например Automated Solutions, Kepware, Matrikon, Cybtec и другие.)

Сложности, появляющиеся при соз­дании территориально (географичес­ки) распределённых проектов, связанные с организацией каналов передачи данных как от поставщиков данных (контроллеров, УСПД, УСО), так и между иерархическими уровнями системы, зачастую разделенными сотнями километров. В большинстве случаев существующие каналы связи не отличаются качеством и надёжностью, а построение спе­циализированных линий переда­чи данных невозможно по эконо­мическим причинам. Это значит, что программное обеспечение, отвечающее за обмен информа­цией между объектами системы, должно уметь устойчиво переда­вать достаточно большие объёмы информации по низкоскоростным линиям, автоматически реагировать на часто возникающие коллизии и разрывы связи, самостоятельно осуществлять выбор наиболее коротких маршрутов передачи данных в случаях, когда имеющиеся каналы передачи перестают работать и появляются новые. Сложности системы передачи данных можно оценить на примере рис.31.

Рис. 31 Пример распределенной системы передачи данных

ОРС (OLE for Process Control) - это стандарт взаимодействия между про­граммными компонентами системы сбора данных и управления (SCADA), основанный на объектной модели COM/DCOM фирмы Microsoft. Через интерфейсы ОРС одни приложения могут читать или записывать данные в другие приложения, обмениваться событиями, оповещать друг друга о нештатных ситуациях (тревогах), осуществлять доступ к данным, зарегистрированным в архивах (так называемые «исторические» данные). Эти приложения могут располагаться как на одном компьюте­ре, так и быть распределенными по сети, при этом независимо от фирмы поставщика стандарт OLE for Process Control, признанный и поддерживае­мый всеми ведущими фирмами-производителями SCADA-систем и оборудования, обеспечит их совместное функционирование. Особый класс ОРС-приложений представляют собой ОРС-сер­веры конкретных аппаратных уст­ройств - они поставляются многими производителями аппаратуры (а также независимыми производителями, но в этом случае они, как правило, не бесплатные). ОРС-сервер создает своего рода абстракцию аппаратуры, позволяя любому ОРС-клиенту записывать и считывать данные с устройства. Устройство, для которого есть ОРС-сервер, может использоваться вместе с любой со­временной SCADA-системой.

Реализация ОРС основана на объектной модели COM/DCOM фирмы Microsoft. COM — это Component Object Model - модель многокомпонентных объектов, позволяющая приложению манипулировать удаленными про­граммными объектами, точнее, вызы­вать те или иные функции (методы) этих объектов так, как будто объекты находятся «рядом». Объект может нахо­диться и в самом деле рядом (в адрес­ном пространстве приложения) - тогда это просто СОМ.

Если же объект находится в другой программе на том же компьютере или на другом узле сети, то это DCOM -Distributed (распределенная) СОМ. В распределенном случае (DCOM) вызов любой функции объекта перехватыва­ется специальным агентом-посредником, так называемой proxy/stub DLL, которая выполняет роль представителя объекта у обратившегося к нему клиента.

Proxy/stub DLL упаковывает парамет­ры функции (marshaling - транспорти­ровка) и передает вызов операционной системе, которая (возможно, по сети) доставляет вызов по назначению, то есть заставляет реальный объект выпол­нить заданную функцию. Результат затем возвращается (примерно по той же цепочке) приложению-клиенту. Удобст­во использования DCOM состоит в том, что приложение-клиент совершенно не обязано знать, где реально находится объект - о степени удаленности объекта оно может судить только по увеличе­нию расхода времени на вызов функ­ции.

ОРС-взаимодействие основано на клиент-серверной схеме. ОРС-клиент (например, SCADA), вызывая опреде­ленные функции объекта ОРС-сервера, подписывается на получение опреде­ленных данных с определенной часто­той. В свою очередь, ОРС-сервер, опро­сив физическое устройство, вызывает известные функции клиента, уведомляя его о получении данных и вручая сами данные. Таким образом, при ОРС-взаимодействии используются как прямые СОМ-вызовы (от клиента к серверу), так и обратные (callback, от сервера к кли­енту). Это надо учитывать при настрой­ках безопасности DCOM в Windows NT: если клиент «видит» данные, но не полу­чает их, значит, скорее всего, система безопасности NT блокировала обрат­ные вызовы.

Стандарт ОРС, в отличие, например, от устаревшего DDE (Dynamic Data Ex­change), хотя и основан на универсаль­ном фундаменте - COM/DCOM, разра­батывался специально для использова­ния в промышленной автоматизации, поэтому он имеет вполне содержатель­ную концептуальную сторону, то есть, на самом деле, свою проблемно-ориентированную модель взаимодействия, которая и реализована через совокуп­ность СОМ-интерфейсов. Эта концеп­туальная сторона в известной степени независима и представляет самый большой интерес, особенно для поль­зователя-непрограммиста, для которо­го топкости реализации СОМ-интер­фейсов не столь важны. В принципе, основные идеи ОРС могли бы быть реа­лизованы и с помощью других объект­ных технологий (получилось бы что-нибудь вроде CORBA for Process Control, например), однако распространен­ность Windows-платформ предопреде­лила выбор в пользу стандартов Microsoft.

Стандарт состоит из трех основных спецификаций:

1) доступ к данным реального времени (Data Access);

2) обработка тревог и событий (Alarms & Events);

3) доступ к историческим данным(Historical Data Access).

ОРС-серверов, соответственно, тоже может быть три вида, хотя не возбраня­ется совмещать все эти функции в од­ном. ОРС-серверы физических уст­ройств обычно являются только серве­рами данных (Data Access Servers). Сер­веры тревог и исторические чаще всего «паразитируют» на серверах данных. Сервер тревог формирует определен­ные логические переменные, называе­мые состояниями (conditions), имея в качестве исходной информации некую переменную (тег), полученную от сер­вера данных. Состояния изменяют свое значение, если переменная, например, вышла за допустимые границы. Об из­менении состояния сервер тревог опо­вещает клиентов, посылая им событие (тревогу), а клиент возвращает серверу подтверждение, что он тревогу воспри­нял. Впрочем, могут существовать со­стояния, не связанные с каким-либо па­раметром и управляемые сервером тре­вог по собственному усмотрению (на­пример, если сервер тревог напрямую взаимодействует с аппаратурой, он мо­жет устанавливать или снимать состоя­ние неисправности). Серверы истори­ческих данных получают от серверов данных параметры в реальном времени и архивируют их, а затем предоставля­ют эти данные другим приложениям (например, для построения графиков трендов).

Центральное место среди специфи­каций ОРС занимает доступ к данным реального времени (DataAccess). Это са­мая старая и отработанная спецификация, в настоящее время действует ее вторая версия.

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

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

Элементы в группе - это своего рода клиентские ссылки на некие реальные переменные (теги), находящиеся на сервере или в физическом устройстве. Понятие тега спецификацией ОРС не определяется, но подразумевается неяв­но. Элементы в группу клиент добавляет по имени, и эти имена, разумеется, на самом деле являются именами соответ­ствующих тегов. Клиент может либо знать нужные имена заранее (если он такой умный), либо запросить список имен тегов у сервера.

Для запроса имен тегов служит интер­фейс lOPCBrowseServerAddressSpace, с помощью которого сервер описывает клиенту свое «пространство имен», ор­ганизованное в общем случае иерархи­чески. Пример полного имени тега: Устройство_1. Модуль_2. Аналоговый Вход_3 (в качестве разделителя используется точка). При добавлении элемента в группу клиент всегда указывает это пол­ное имя. Заметим, что группы, создавае­мые клиентом на сервере, не обязаны совпадать (и, как правило, не совпада­ют) с подразделами пространства имен сервера, элементы в группу добавляют­ся вразнобой. Единственное, что их объединяет. - это общая частота обнов­ления и синхронность отправки клиен­ту.

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

Схема взаимодействия ОРС-клиентов с ОРС-сервером представлена на рис. 33.

Обмен данными между клиентом и сервером может осуществляться в двух режимах — синхронном и асинхрон­ном. При асинхронном варианте обме­на сервер сам оповещает клиента об из­менившихся значениях данных, на ко­торые подписался клиент (по возмож­ности с частотой, заданной клиентом при создании группы). При синхрон­ном клиент осуществляет инициатив­ное чтение или запись данных. Запись может быть только синхронной.

Рис. 33

Взаимосвязь групп и элементов OPC показана на рис. 34.

Рис. 34. Взаимосвязь групп и элементов OPC

Разработано множество различных ОРС-серверов. Рассмотрим интерфейс пользователя на примере ADAM OPC –сервер.

Поиск по сайту: