Технология Active X основана на использовании компонентной структуры приложений и DCOM. Приложение, к которому подключается Active X компонент, называется КОНТЕЙНЕРОМ для данного компонента. Компонент может передавать контейнеру данные, методы и события. Существует два основных способа выполнения Active X компонентов:
встроенный в процесс (единое пространство памяти позволяет увеличить быстродействие)
выполняемая в отдельном процессе (возможна организация распределенной архитектуры)
Особенности Active X
2. возможность независимой разработки частей распределенного приложения
3. стандартность (обеспечена использованием DCOM)
4. открытость и переносимость. В настоящее время ведется разработка Active X для UNIX платформы.
5. существует большое количество готовых Active X компонентов, которые могут быть использованы.
Механизм OLE for Process Control(OPC).
OPC — это стандарт взаимодействия между программными компонентами системы сбора данных и управления (SCADA), основанный на объектной модели COMYDCOM фирмы Microsoft.
На базе механизма OLE был разработан новый стандарт обмена, ориентированный на задачи промышленной автоматизации - OPC(OLE for Process Control). Стандарт OPC обладает следующими преимуществами:
позволяет объединить на уровне объектов различные системы управления и контроля, функционирующие в распределенной гетерогенной среде;
устраняет необходимость использования нестандартных протоколов обмена данными между устройством и SCADA-системой.
Концепция стандарта ОРС
Стандарт состоит из трех основных спецификаций:
доступ к данным РВ (Data Access).
обработка тревог и событий (Alarm & Events).
доступ к историческим данным (Historical Data Access).
OPC — серверов соответственно тоже может быть три вида, хотя не возбраняется совмещать все эти функции в одном. ОРС - серверы физических устройств обычно являются только серверами данных. Серверы тревог и исторических данных чаще всего паразитируют на серверах данных. Сервер тревог формирует определенные логические переменные, называемые состояниями, имея в качестве исходной информации некую переменную (тег), полученную от сервера данных. Состояния изменяют свое значение, если например, переменная вышла за допустимые границы. Об изменении состояния сервер тревог оповещает клиентов, посылая им событие (тревогу), а клиент возвращает серверу подтверждение, что он тревогу принял. Серверы исторических данных получают от серверов данных параметры в РВ и архивируют их, а затем представляют эти данные другим приложениям, (например для построения графиков и трендов)
Основная цель стандарта ОРС заключается в создании универсального механизма доступа к любому аппаратному устройству из прикладной программы. ОРС позволяет производителям оборудования поставлять программные компоненты, которые стандартным способом обеспечат связь ПО с технологическим контроллером.
Таким образом, с точки зрения SCADA-систем, появление ОРС-серверов означает разработку программных стандартов обмена с технологическими устройствами. ОРС -интерфейс допускает различные варианты обмена:
• получение данных с физических устройств;
обмен между частями распределенного приложения;
обмен между различными приложениями.
В первую очередь в качестве серверов ОРС выступают драйверы, написанные в соответствии со стандартом ОРС и осуществляющие обмен данными с компонентами систем автоматизированного управления через соответствующее коммуникационное оборудование. Кроме того, любая программа, снабженная стандартным ОРС-ннтерфейсом, может выступать в качестве ОРС-сервера.
Применительно к SCADA-системам ОРС-серверы, расположенные на всех компьютерах системы управления, стандартным образом могут поставлять данные в программу визуализации, базу данных и т.д.
При обмене данными с ОРС - сервером возможно два режима:
Периодический режим, когда с заданной частотой данные запрашиваются ОРС -клиентом.
Режим обмена по изменению значения, когда обмен происходит при изменении значения переменной на заранее заданную величину.
Предпочтительным является второй тип обмена. При обмене через ОРС-интерфейс данные передаются пакетами данных, содержащие следующие поля:
Value (значение).
Quality (качество).
Timestamp (отметка времени).
Такой пакет в терминологии ОРС называется «элемент данных». Поле Quality позволяет определить, не произошла ли ошибка в момент измерения величины или во время передачи. Во всех современных SСADА-системах при обмене данными осуществляется проверка поля Quality. Причем в различных системах реакция на «неудовлетворительное» значение качества получаемых данных может быть реализована по-разному. Обрабатывать поле Quality может либо приложение пользователя, либо сама SCADA-система. Поле Quality может принимать различные значения: - UNCERTAIN (не определено), GOOD (удовлетворительно), BAD (неудовлетворительно). В случае если поле Quality принимает значение BAD, в этом поле содержится дополнительный признак, позволяющий уточнить причину неполадки.
В ОРС все элементы данных объединяются в группы. Каждый элемент данных и группа имеют свое уникальное имя, и могут быть организованы в иерархическую структуру. Все элементы в каждой группе обновляются периодически, через равные промежутки времени, причем обновление элементов происходит синхронно.
Элементы данных часто называют тегами (TAG). Именно эти тэги и являются технологическими переменными в SCADA-системе. ОРС-сервер должен осуществлять буферизацию данных, запрашиваемых различными клиентскими приложениями, и оптимизировать их передачу так, чтобы коммуникация с физическими устройствами была наиболее эффективной. Буферизация данных необходима для того, чтобы исключить их потерю, и чтобы была возможность их многократного считывания. Важным преимуществом ОРС является возможность превращения системы управления в своего рода «конструктор», разнотипные элементы которого могут быть подключены к системе стандартным образом - через ОРС-интерфейс. Использование технологии ОРС в качестве процедуры обеспечения целостного доступа к производственным данным дает следующие преимущества:
производители устройств имеют возможность создания универсальных «переходников» от своего устройства к стандартизованному интерфейсу;
производители программного обеспечения SCADA могут ориентировать свои программные продукты на работу со стандартным интерфейсом, не зависящим от типа устройства;
потребители (заказчики) комплектуют свои системы такими устройствами и программным обеспечением, которое наиболее подходит для решения поставленных задач.
Технологические устройства представляются управляющему ПО в виде серверов ОРС и в общем случае являются "черными ящиками". Конечно не бывает средства, решающего все проблемы. ОРС может использоваться только на тех операционных системах, где поддерживается механизм Microsoft DCOM. В настоящее время к таким ОС относятся Windows NT/95/98? а также некоторые системы семейства UNIX.
Группа создается ОРС - сервером по требованию клиента, который затем может добавить в группу элементы. Для группы клиентом задается частота обновления данных, и сервер старается обновлять и передавать клиенту все данные в группе с заданной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся требуемой частотой обновления. Группа всегда создается для каждого клиента своя, даже если состав элементов и частоты обновления совпадают. Отсоединение клиента приводит к уничтожению созданных для него групп.
Элементы в группе — это своего рода клиентские ссылки на некие реальные переменные (теги), находящиеся на сервере или в физическом устройстве. Элементы в группу клиент добавляет по имени, которые являются именами тегов. Клиент может запросить список имен тегов у сервера.
Для запроса имен тегов служит специальный интерфейс, с помощью которого сервер описывает клиенту свое «пространство имен», организованное иерархически. При добавлении элемента в группу клиент всегда указывает его полное имя - например Устройство 1. Модуль 2. Аналоговый вход_3.
На верхней ступени иерархии понятий находится сам ОРС - сервер. Из всех перечисленных (ОРС-группа, ОРС-элемент) он единственный является СОМ — объектом. Все остальные объекты доступны через его интерфейсы, которые он представляет клиенту.
Схема взаимодействия ОРС — клиентов с ОРС — сервером представлена на рис.
9.6.
Обмен данными между клиентом и сервером может осуществляться в двух режимах: синхронном и асинхронном. При асинхронном варианте обмена сервер сам оповещает клиента об изменившихся значениях данных, на которые подписался клиент. При синхронной передаче клиент осуществляет инициативное чтение или запись данных.
Производительность
Затраты ресурсов компьютера на поддержку ОРС-взаимодействия и предельно достижимая интенсивность обмена между клиентом и сервером зависят от ряда факторов, но прежде всего - от того, находится ли сервер непосредственно в адресном пространстве клиента (так называемый внутризадачный - InProcess Server) или он является самостоятельным приложением. В последнем случае важно, расположен сервер на том же компьютере, что и клиент, или на другой станции локальной сети. Третий по важности фактор — это возможность группировки данных для отправки клиентам. Так, передача в 1 секунду 100 тегов займет значительно меньше ресурсов, чем одного тега через каждые 10 мс.
Ориентировочные экспериментальные данные о пропускной способности интерфейсов ОРС опубликованы на Web-узле ОРС Foundation (там же можно получить более подробное описание условий проведения эксперимента).
Предельная пропускная способность внутризадачного сервера может достигать (здесь и далее - на компьютере с процессором Pentium-233) 1 млн. элементов ОРС в секунду, что значительно превышает все мыслимые реальные потребности. Однако не все ОРС-серверы имеют внутризадачный (InProcess") вариант - для этого они должны оформляться как динамические библиотеки (DLL), а не как самостоятельные программы.
В случае локального сервера (отдельная программа, но на том же компьютере) пропускная способность колеблется примерно от 3 до 60 тысяч элементов в секунду. Наихудший вариант соответствует передаче единственного элемента с максимальной частотой, наилучший - передаче одновременно 100 или более элементов с соответственно меньшей частотой.
Наконец, для удаленного сервера (в сети Ethernet 10Base-T) пропускная способность оказалась заключена в пределах 330...7000 элементов в секунду (наилучший и наихудший варианты соответствуют тем же самым крайним случаям).
Не следует придавать приведенным цифрам абсолютное значение - они могут варьироваться в зависимости от системной конфигурации, а также особенностей реализации сервера и клиента. Так, по данным Rockwell Automation, ОРС-сервер (отдельное приложение, не внутризадачный) может обеспечить обмен с сетевыми клиентами до 200000 элементов в секунду. С другой стороны, столь оптимистические оценки могут быть резко снижены за счет ресурсоемкости обмена с реальной аппаратурой - коммуникационными портами, интерфейсными модулями и т.п., что, конечно, не учитывалось в тестовых экспериментах, поскольку не имеет прямого отношения к ОРС. С точки зрения программной реализации, важно, насколько сервер использует многопоточность (multithreading), в частности, для обслуживания различных групп, а также производится ли кэширование значений тегов с целью минимизации количества запросов к аппаратуре.
Процесс стандартизации
Стандарт ОРС разрабатывает независимая организация ОРС Foundation, насчитывающая более 170 членов, среди которых Siemens, Fisher-Rosemount, Honeywell, Rockwell, Iconics и др., т. е. практически все известные (и не очень известные) компании-производители SCADA-систем и оборудования для систем промышленной автоматизации. Техническая деятельность ОРС Foundation осуществляется в рабочих группах по направлениям. Среди этих направлений:
доступ к данным РВ (ОРС Data Access Working Group);
обработка тревог и событий (ОРС Alarms and Events Working Group);
защита данных (ОРС Security Working Group);
подтверждение соответствия стандартам ОРС (ОРС Compliance Working Group);
доступ к историческим (архивным) данным (ОРС Historical Working Group);
Windows СЕ (ОРС Windows СЕ Working Group).
Выпущена вторая версия спецификации (версия 2.0), определяющая интерфейс доступа к данным РВ (октябрь 1998 г.). До этого действовала спецификация 1а, которая продолжает поддерживаться ОРС-клиентами (т. е. серверы, разработанные в соответствии со старой спецификацией, можно продолжать использовать без каких-либо доработок). Версия 2.0 отличается несколько измененным интерфейсом, используемым при соединении с клиентом (IConnectionPoint), улучшенной поддержкой национальных языков (теперь клиент может запросить сервер, какие языки он поддерживает, и выбрать среди них язык общения) и некоторыми другими модификациями. Однако концептуальная сторона, описанная ранее, осталась прежней.
Относительно недавно появилась первая спецификация, касающаяся обработки тревог и событий (Alarms & Events), она также доступна с Web-узла ОРС Foundation.
Как разработать свой ОРС-сервер
Утвержденные спецификации ОРС, а также proxy/stub DLL, соответствующая интерфейсам ОРС, свободно доступны с Web-узла ОРС Foundation. Строго говоря, этого достаточно для разработки своего ОРС-сервера. Однако разработка сервера "с нуля" -довольно сложный процесс, а аккуратная реализация интерфейсов ОРС в многопоточной (multithread) среде изобилует различными "подводными камнями". Это представляет известную опасность, так как ОРС-сервер обязан быть достаточно надежной программой.
Проще всего разработать сервер, используя специально созданные для этого средства. Так, фирма Iconics, известная своей SCADA-системой Genesis, предлагает ОРС ToolWorX, который оформлен в виде дополнительного мастера (Wizard), встраиваемого в среду разработки Visual С++. Мастер генерирует некий "образцовый" проект, в котором требуется только модификация фрагментов кода, связанных со спецификой обслуживаемого устройства или протокола. Поддержка ОРС-взаимодействия обеспечивается специальными классами объектов, не требующими каких-либо исправлений, поэтому программист может сосредоточиться на функциональности своего устройства, не заботясь о реализации собственно ОРС-интерфейсов. Все компоненты ОРС ToolWorx поставляются в исходном коде. Для квалифицированного программиста срок разработки несложного ОРС-сервера с помощью Iconics ОРС ToolWorX - 3...4 недели.
В случае, если к серверу не предъявляются особо жесткие требования к синхронности обновления данных и не требуется динамическая реструктуризация пространства имен во время его работы, можно применить самое простое и недорогое решение - универсальный ОРС - сервер фирмы Fastwel. Он создан на базе Iconics ToolWorX и предусматривает подключение динамической библиотеки (DLL), написанной пользователем, в которой сосредоточен весь код, специфичный для обслуживаемого устройства. Интерфейс этой DLL с сервером очень прост, и разработка ее для простых устройств (или когда уже есть соответствующий программный задел в виде ранее написанных драйверов и т.п.) занимает у квалифицированного программиста всего 1...3 дня. Вместе с универсальным ОРС - сервером (в виде исполняемого модуля) поставляется исходный текст "образцовой" DLL, который можно использовать как пример реализации.
Достаточно широко известен также пакет для разработки ОРС-приложений фирмы Intellution. Для разработчиков АСУТП, использующих SCADA-систему FiX Dynamics, это, безусловно, наилучший выбор.
Однако для написания "просто ОРС - сервера" пакет от Intellution чрезмерно перегружен "фирменными" чертами: по существу, разрабатывается не сервер как таковой, а FiX-драйвер, открытый остальному миру через ОРС - интерфейсы. Впрочем, выбор инструментальных средств разработки - во многом вопрос вкуса и привычки.
SCADA-системы и ОРС
Как уже говорилось, практически все производители SCADA-систем поддерживают OLE for Process Control, среди них - FixDynamics (Intellution), FactorySuite 2000 (Wonderware), Genesis32 (Iconics), FactoryLink(US Data), Lookout (National Instruments) и т.д. Однако для большинства из них ОРС - только один из поддерживаемых интерфейсов взаимодействия, их внутренняя идеология построения напрямую не связана с этим стандартом и часто унаследована от предыдущих 16-разрядных версий. По-видимому, пока только Genesis32 изначально спроектирован на основе ОРС (ОРС to the Core). Все компоненты Genesis32 взаимодействуют между собой через ОРС, являясь, в зависимости от ситуации, либо серверами, либо клиентами, либо и теми и другими одновременно. Это придало системе во многом единый стиль, стройность архитектуры и предопределило ее компонентный характер: унификация интерфейсов взаимодействия дала возможность легко выбирать совокупность компонентов, действительно необходимых пользователю (и не переплачивать за ненужные). Конечно, у других SCADA-систем есть, безусловно, свои сильные стороны, однако Genesis32 в наибольшей степени дает своим пользователям почувствовать свободу выбора, которую обеспечивает OLE for Process Control.
При внедрении ОРС имеют место следующие преимущества:
1.ОРС позволяют определять на уровне объектов различные системы управления и контроля, работающие в распределенной гетерогенной среде;
ОРС устраняет необходимость использования различного нестандартного оборудования и соответствующих коммуникационных драйверов;
У потребителя появляется больший выбор при разработке приложений.
С ОРС решениями интеграция в гетерогенные (неоднородные) системы становится достаточно простой. Применительно к SCADA - системам ОРС - серверы, расположенные на всех компьютерах системы управления производственным предприятием, стандартным способом могут поставлять данные со скоростью 10...20 тыс. переменных/сек в программу визуализации, базы данных и т.п. Клиент-серверная архитектура системы ОРС представлена на рис. 9.7.
ODBC - интерфейс
Аббревиатура ODBC является сокращением для Open Data Base Connectivity, что можно перевести как „открытый интерфейс доступа к базам данных". Этот интерфейс представляет собой набор функций, которые можно использовать для доступа к любой реляционной СУБД, поддерживающей SQL. На уровне операционной системы ODBC реализуется в виде группы DLL-библиотек, состоящей из драйверов отдельных баз данных (ODBC-драйверов) и так называемого менеджера драйверов, выполняющего роль прослойки между приложением-клиентом и ODBC-драйвером; именно наличие такой прослойки и обеспечивает независимость приложения от конкретного сервера БД.
Последняя версия ODBC, выпущенная в 1997 году, имеет номер 3.51; как показывает практика, для решения большинства типичных задач бывает достаточно версий 2.x, выходивших в период с 1993 по 1995 год. Заметим, что Microsoft официально прекратила развитие ODBC, предлагая в качестве замены технологию ADO (Active Data Objects), которая представляет собой ни что иное, как построенную на базе СОМ оболочку ядра ODBC (см. рис. 9.8).
Технологические устройства представляются управляющему ПО в виде серверов ОРС и в общем случае являются "черными ящиками". Конечно не бывает средства, решающего все проблемы. ОРС может использоваться только на тех операционных системах, где поддерживается механизм Microsoft DCOM. В настоящее время к таким ОС относятся Windows NT/95/98? а также некоторые системы семейства UNIX.
