Число установленных единиц оборудования

Некоторые протоколы в настоящее время насчитывают большее число пользователей, чем FOUNDATION fieldbus, особенно если при подсчете числа единиц установленного оборудования учитываются различные версии одного протокола. Однако, невозможно отрицать тот факт, что FOUNDATION fieldbus активно привлекает все большее число пользователей и получает все более широкое распространение среди производителей аппаратно-программных средств для управления промышленными процессами, предъявляющих повышенные требования к отказоустойчивости и надежности работы систем. За последние несколько месяцев системы, использующие технологию и спецификации Fieldbus Foundation, были установлены такими крупными клиентами, как Dow Chemical, Syncrude Canada, Ltd. и Daishowa Paper. Среди других крупных клиентов можно назвать следующие компании: ARCO-Alaska, Sunoco (Канада), Kaneka (Малазия), Seattle Steam, CFE (Мексика), Binzhou Chemical (Китай) и PCVSA (Венесуэлла).

Хотя многие архитектуры полевых шин могут использоваться в качестве цифровых аналогов схемы с аналоговым управлением, использующей сигналы с амплитудой 4-20 мА, архитектура FOUNDATION fieldbus, несомненно, обладает рядом преимуществ перед всеми остальными. Кроме значительно более высокого уровня комплексируемости системы, реализуемого FOUNDATION fieldbus, использование сложных компонентов пользовательского уровня позволяет перенести часть распределенного управления на уровень полевых устройств.

Вне всякого сомнения, FOUNDATION fieldbus - более открытый протокол; он разработан и используется организацией, в состав которой входят крупнейшие поставщики контрольно-измерительной аппаратуры и оборудования для автоматизированных систем. Этот протокол основан на разработках международной комисси по стандартизации. Между тем, большинство других промышленных стандартов в области полевых шин разрабатываются и жестко контролируются единственной компанией-производителем.

Хотя технология PROFIBUS-PA, вероятно, сможет полностью удовлетворить все потребности клиентов в настоящем и ближайшем будущем, эта технология, несомненно, является устаревшей по сравнению с открытой, постоянно совершенствующейся технологией FOUNDATION fieldbus, разработанной на основе международных стандартов и обладающей рядом уникальных возможностей.

Благодаря надичию средств управления аппаратурой, FOUNDATION fieldbus значительно увеличивает производительность установки, и является уникальной технологией, не имеющей аналогов в настоящее время, при помощи которой можно достичь результатов, не обеспечиваемых ни одной другой существующей промышленной технологией.

FOUNDATION fieldbus является промышленной сетевой технологией, позволяющей снизить затраты на приобретение и эксплуатацию оборудования, предназначенной для промышленных предприятий, для которых является необходимостью снизить эксплуатационные расходы при поддержке множества различных продуктов.

 

 

7. ОРС-сервер [54]

 

ОРС – это аббревиатура от OLE for Process Control, или OLE для Управления Процессами. Ключевыми словами для понимания технологии ОРС являются технология Microsoft OLE (Object Linking and Embedding – связывание и встраивание объектов) и интеграция.

Историческая справка Сравнительно недавно, в 1994 г., под эгидой Microsoft, была создана организация ОРС Foundation.

Её целью является разработка и поддержка открытых промышленных стандартов, регламентирующих методы обмена данными в реальном времени между клиентами на базе персональных компьютеров и ОС Microsoft. Сейчас эта организация насчитывает более 220 членов, включая почти всех ведущих поставщиков контрольно-измерительного и управляющего оборудования для АСУ ТП, таких фирм, как Siemens, Schneider Automation, Rockwell Software, Iconics, Wonderware, Intellution, Ci Technologies, Microsoft.

 

Список распространенных OPC-серверов:

 

– OPC-сервер Modbus RTU

– OPC-сервер Modbus TCP

– OPC-сервер контроллеров Master110, 210

– OPC-сервер УВП-280 (DA и HDA)

– OPC-сервер Гиперфлоу 3пм (DA и HDA)

– OPC-сервер DPL

– OPC-сервер EK260 (DA)

– OPC-сервер EK88 (DA и HDA)

– OPC-сервер Ломиконта

– OPC-сервер Ремиконта-130

– OPC-сервер Ш711

– OPC-сервер для связи с SoftLogic MicPlus PLC

– OPC-сервер для связи с SCADA-пакетом VNS

– OPC-сервер для связи с SCADA-пакетом MasterSCADA

– Многие другие OPC-серверы в стандарте OPC DA и OPC HDA

 

Технология

Технология ОРС реализована и продолжает реализовываться по схеме разработка стандартов. ОРС Foundation определяет направления, по которым ведутся разработки, и создаёт по этим направлениям комитеты. Комитеты делают следующее:

– разрабатывают спецификации СОМ-интерфейсов и СОМ-объектов;

– присваивают им уникальные идентификаторы GUID;

– оформляют всё в виде стандартов и опубликовывают;

– генерируют или создают вспомогательные файлы: idl-, h- и с-файлы для пользовательского интерфейса; библио­теки типов для интерфейса автоматизации;

– разрабатывают вспомогательные компоненты, например, утилиту opcenum, позволяющую ОРС-клиенту "увидеть" список всех ОРС-серверов локальной сети;

– развивают деятельность по рекламе и популяризации, включая демонстрационные программы и оценку производительности.

 

Спецификации

В настоящее время имеются следующие ОРС-стандарты.

– ОРС Common Definitions and Interfaces – общие для всех ОРС-спецификаций интерфейсы

– Data Access Custom Interface Standard - спецификация СОМ-интерфейсов для обмена оперативными данными, программирование на C++.

– Data Access Automation Interface Standard – спецификация СОМ-интерфейсов для обмена оперативными данными, программирование на языках типа Visual Basic.

– ОРС Batch Custom Interface Specification – спецификация СОМ-интерфейсов конфигурирования оборудования, программирование на C++.

– ОРС Batch Automation Interface Specification – спецификация СОМ-интерфейсов для конфигурирования оборудования, программирование на языках типа Visual Basic.

– ОРС Alar ms and Events Interface Specif ication – спецификация СОМ-интерфейсов для обслуживания событий (event) и нештатных ситуаций (alarm), программирование на C++.

– Historical Data Access Custom Interface Standard – спецификация СОМ-интерфейсов для работы с хранилищами данными, программирование на C++.

– ОРС Security Custom Interface – спецификация СОМ-интерфейсов для обработки прав доступа к данным, програм­мирование на C++.

Консорциум ОРС Foundation пытается охватить все аспекты, связанные с взаимодействием с технологическим оборудованием. В разработке самих спецификаций принимают участие ведущие производители оборудования и систем автоматизации, которые стараются максимально учесть свой опыт и предоставить абсолютно "всё необходимое" тому, кто будет использовать.

 

ОРС-сервер (потребители "снизу")

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

Список возможных изготовителей ОРС-серверов неограничен. ОРС-сервером можно снабдить контроллер, плату ввода/вывода, адаптер полевой шины, программу пересчёта, генератор случайных чисел, что угодно, лишь бы это могло поставлять или принимать данные. Но всё-таки здесь речь идёт, в первую очередь, о программном обеспечении для более низкого уровня в системах автоматизации.

 

ОРС-клиент (потребители "сверху")

Относятся в первую очередь те, кто реализует программное обеспечение более высокого уровня. Например, поставщик SCADA-пакета.

 

Остальные потребители

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

 

OPC и интеграция [55]

Теперь настало время взглянуть на OPC с точки зрения главной темы статьи. На рисунке 7.1 представлена схема, иллюстрирующая возможные области применения OPC-серверов в АСУ предприятия. Мы различаем несколько уровней управления:

– нижний уровень — полевые шины (fieldbus) и отдельные контроллеры;

– средний уровень — цеховые сети;

– уровень АСУТП — уровень работы систем типа SCADA;

– уровень АСУП — уровень приложений управления ресурсами предприятия.

Каждый из этих уровней может обслуживаться OPC-сервером, поставляя данные OPC-клиенту на более высоком уровне или даже "соседу".

 

Рис. 7.1 Возможные области применения OPC-серверов в АСУ предприятия

 

 

ОРС Data Access (DA)

Стандарт DA предназначен для поставки оперативных данных от оборудования и/или к оборудованию.

Стандарт DA имеет две версии интерфейсов: 1.0 и 2.0. Как мы уже знаем, с точки зрения СОМ, это самостоятельные спецификации. ОРС-клиент предварительно запрашивает, может ли он работать с нужным ему СОМ-интерфейсом в используемом ОРС-сервере. Более современным является стандарт 2.0. С точки зрения функциональности, в версии 2.0 механизм уведомления клиента приведён к стандартному механизму COM/DCOM, что упрощает программирование.

 

Данные

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

 

Свойства

Каждая переменная обладает свойствами. Различаются обязательные свойства, рекомендуемые и пользовательские.

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

 

Получение данных

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

 

Запись данных

Ничем не отличается от чтения, за исключением того, что нет записи по подписке.

 

Источники данных

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

 

Организация данных

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

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

Инструментарий

Как уже было сказано, чтобы написать ОРС-сервер или ОРС-клиент, нужно только взаимодействие с ОРС Foundation (ОРС-спецификации) и Microsoft (Visual C++ и пр.). Но...

 

Toolkit

Всего этого избежать можно, если воспользоваться так называемыми Toolkit'aMH. Есть

достаточно много фирм, которые реализацию ОРС-спецификаций избрало своим бизнесом. Они в той или иной степени уже "наступили на все грабли" и предлагают средства, позволяющие более-менее безопасно и легко создавать ОРС -продукцию.

Типичный Toolkit представляет собой библиотеку, реализующую ОРС-объекты выбранной спецификации, что реализует все прихоти со стороны ОРС. Разработчику же, например, ОРС- сервера предлагается некий набор вызовов, достаточно простых (read, write,...), которые необходимо "подцепить" к своему оборудованию для доступа к его данным. Для знающих объектное программирование заметим, что эти функции могут быть реализованы как виртуальные функции некоторого класса, которые нужно перегрузить в своём приложении. Так сделаны, например, Toolkit'bi фирмы FactorySoft (http://www.factoryfoft.com).

 

Примеры применения ОРС-сервера:

1. ОРС поверх драйвера

Если имеется оборудование, например плата АЦП, управляемая через драйвер на компьютере с Windows или другой ОС, поддерживающей COM/DCOM, то это самый главный кандидат на то, чтобы непосредственно поверх драйвера был реализован ОРС-сервер.

Замена устройства не потребует изменения остальных приложений: драйвер изменился, но ОРС-интерфейс поверх него остался прежний.

2. ОРС через сеть

Имеется устройство, управляемое через какой-нибудь сетевой протокол. В этом случае вполне типична реализация ОРС-сервера, получающего данные по этому протоколу. Единственная особен­ность в этом случае - предусмотреть механизмы восстановления связи в случае сбоев.

3. ОРС для ОС

Несколько более сложная схема, когда некоторые управляющие приложения работают на компьютере, где не поддерживается COM/DC0M. В этом случае возможна реализация двухкомпонентного ОРС-сервера. На стороне ОС, не поддерживающей СОМ, устанавливается сетевой модуль, который с одной стороны связан с приложением(ями), а с другой стороны связан через сеть с ОРС-сервером. Заметим, что сетевой модуль мо­жет быть стандартным, как, например, ISaNet в системе ISaGRAF. Тогда необходимо разрабатывать только ОРС-сервер. По такому принципу создан, например, ОРС-сервер ISaGRAF от фирмы "РТСофт" (www.rtsoft.ru). Другая разновидность - сетевой модуль создаётся специально для ОРС-сервера. Возможна даже реализация, когда этот модуль не ориентирован на конкретное приложение, а предоставляет некоторый API-интерфейс для любых приложений, желающих обслуживаться с помощью ОРС. Пример такого решения - ОРС-сервер для операционной системы 0S-9, разработанный в компании "РТСофт" (www.rtsoft.ru).

4. ОРС для fieldbus

Ещё одна разновидность ОРС-сервера - шлюз к сети полевой шины, такой как Profibus или Lonworks. С точки зрения реализации это очень похоже на предыдущие случаи. Скорее всего, на компьютере с ОС Windows будет установлен адаптер fieldbus-сети, а ОРС-сервер будет работать с этой сетью через драйвер адаптера. В Internet можно найти немало таких примеров.

Идея такой схемы достаточно очевидна. Сеть полевой шины работает в жёстком реальном времени, а ОРС предоставляет менее требовательный шлюз к этой сети из приложений более высокого уровня.

И другие применения ОРС

Можно придумать много других применений ОРС. Например, ОРС для работы с базами данных, вспомогательные ОРС-серверы, промежуточные и т.д. Возможности для фантазии неограниченны. Одну такую фантазию хотелось бы привести.

Технология DCOM, как уже говорилось, не работает в глобальных сетях. Поэтому для привлечения к ОРС-технологии Internet-технологий можно набросать такой путь. Расширение web-сервера является ОРС-клиентом, собирающим данные от ОРС-серверов. А на стороне клиентов запускается динамическая html- или xml-страница, полу­чающая данные от этого web- сервера. Её можно сделать даже ОРС-сервером для других приложений.

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

 

В настоящее время по настоящему широкое распространение получил только стандарт DA ОРС. Можно сказать, что сейчас действительно очень многие производители снабжают свои продукты DA ОРС-серверами.

 

Программы высокого уровня

Спросом пользуется лишь DA ОРС. Все известные нам SCADA-продукты являются ОРС-клиентами. Например, Wonderware InTouch, CiTect (Ci Technologies). Многие SCADA-продукты являются также ОРС-серверами. Например, Citect. Другое ПО подвержено влиянию ОРС в гораздо меньшей степени.

 

Операционные системы

В настоящее время технологию COM/DCOM поддерживает следующие операционные системы: все Windows, начиная с Windows 95. Это обеспечивается самой компанией Microsoft; большинство Unix-подобных ОС, включая Linux; поддерживается фирмой GE Software;

ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver;

имеется поддержка ОРС, встроенная в систему разработки Tornado.

В других операционных системах, насколько нам известно, поддержки COM/DCOM нет. Это не очень отрадный факт, поскольку разработчиков систем автоматизации в первую очередь интересуют ОС реального времени.

 

Технология ОРС предлагает стандарты для обмена технологическими данными, в которые заложены самые широкие возможности. Учитывая большой авторитет вовлечённых в эту деятельность фирм, включая саму Microsoft, можно ожидать, что технология ОРС будет набирать силу. И это перспективная технология для использования её в интеграции разнородных систем.

 

В качестве примера применения рассмотрим описание OPC-сервера AgavaOPC [56] для системы диспетчеризации котельных

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

На даный момент AgavaOPC поддерживает контроллеры АГАВА 6432, а так же контроллеры сторонних производителей, работающие по протоколу Modbus-RTU

ОРС-сервер AgavaOPC реализует следующие функции:

– сбор и выдача данных о состоянии контроллеров;

– сбор и выдача технологических параметров котлоагрегатов, информации об авариях;

– управление работой котлоагрегатов;

– пересчет значений, полученных с контроллеров из физических значений в инженерные;

– логическая обработка технологических сигналов и их свойств;

– предоставление доступа ОРС-клиентам ко всей оперативной информации по интерфейсу ОРС DA версии 2.0;