Казаринов Л.С., Попова О.В., Барбасова Т.А. Автоматизированные информационно-управляющие системы (часть 2)
Подождите немного. Документ загружается.
Предназначен для решения задач в реальном времени, где более важным является продол-
жительность цикла шины. Дает увеличение производительности шины так, что для передачи 512
бит данных, распределенных по 32 станциям, требуется всего 6 мс. DP-протокол представляет
функциональное подмножество 2-го уровня протокола PROFIBUS-FMS. Уровень 7 в DP не опи-
сан.
PROFIBUS-PA
Этот протокол используется в устройствах, работающих в опасных производствах. В основе
протокола PA (Process Automation) лежит протокол ISP (Interoperable Systems Project). Физический
уровень (уровень 1 OSI-модели) реализует стандарт ШС1158-2 (с внутренней защитой данных).
Уровень 2 - это функциональное подмножество стандарта DIN 19245.
Распределенная система может состоять из устройств, реализующих все три типа стандарта,
только РА-устройства необходимо подключать через специальные повторители.
Известно свыше 500 PROFIBUS-изделий (как аппаратных, так и программных). Число
установленных узлов превышает 350 тысяч.
7. Протокол передачи данных FOUNDATION FIELDBUS или PROFIBUS_PA
Протокол FOUNDATION™ Fieldbus был разработан «с нуля» для удовлетворения
требованиям, предъявляемым к современным системам промышленной автоматизации.
Интенсивные совместные усилия многих производителей средств промышленной автоматизации
по разработке нового протокола, включая обширную программу объектовых испытаний,
закончились в 1996 г. выпуском спецификаций на низкоскоростную (31,25 кбод) версию
FOUNDATION™ Fieldbus (Н1). В этой версии полностью определены способы создания
управляющих программ на базе функциональных блоков, а ее коммуникационные возможности
нижнего уровня обеспечивают поддержку управления непосредственно по шине.
Недавно завершена работа над высокоскоростной реализацией протокола
FOUNDATION™ Fieldbus (H2). Протоколы H1 и H2 идентичны, что позволяет, используя простые
«мосты», создавать многоуровневые масштабируемые сети.
Протокол, используемый в FOUNDATION™ Fieldbus, является подмножеством стандартов
IEC_61158 часть 2 и TS_61158 части 3 и 4.
Консорциум Fieldbus Foundation является некоммерческой организацией, которая была
образована в результате слияния двух других консорциумов, продвигавших протоколы полевых
шин, — WorldFIP (North America) и InterOperable Systems Project. В работе Fieldbus Foundation,
штаб квартира которой расположена в городе Остин (штат Техас), участвуют практически все
основные мировые поставщики аппаратно программных средств АСУ ТП.
Общие черты и отличительные особенности PROFIBUS_PA и FOUNDATION™ Fieldbus
имеют ряд общих характеристик (табл. 7.1, табл. 7.2):
• обе системы удовлетворяют требованиям спецификаций физического
уровня H1 IEC/ISA, которые определяют среду передачи данных;
• обе системы искробезопасны и способны по одним и тем же проводам передавать как
данные, так и электропитание для подключенных к сети устройств, что позволяет использовать их
во взрывоопасных зонах;
• обе системы поддерживаются международными организациями, объединяющими как
конечных пользователей, так и поставщиков;
• обе системы могут быть развернуты в качестве цифровой замены аналоговых каналов
4_20 мА с использованием тех же самых, уже существующих линий связи;
• обе системы поддерживают работу в многоточечном режиме, благодаря чему снижаются
затраты на монтаж и обслуживание кабельного хозяйства.
Однако между сетевыми системами имеются и существенные различия (табл. 1, табл. 2).
131
Таблица 7.1
Сравнение коммуникационных протоколов
Таблица 7.2
Сравнение достоинств
Хотя обе системы способны управлять событиями в самой сети, применяемая в
PROFIBUS_PA коммуникационная модель «главный подчиненный», а также отсутствие
протокола системного администрирования делают PROFIBUS_PA неудовлетворительным
решением для управления распределенными процессами.
FOUNDATION™ Fieldbus, напротив, создавалась не только для организации обмена
цифровой информацией между управляющим устройством сети и устройствами нижнего уровня
132
(полевого оборудования), но и для распределенного управления, включая поддержку
функции автоматического конфигурирования (plug_and_play), что существенно расширяет
границы совместимости оборудования.
FOUNDATION™ Fieldbus при передаче данных одновременно поддерживает маркерный
доступ и обмен по расписанию. Таким образом, данные, передаваемые между функциональными
блоками прикладной программы, исполняющейся на разных узлах сети, могут быть точно
синхронизированы по времени. Исполнение функционального блока координируется с
передачами по шине, так как каждое устройство содержит синхронизируемый таймер. Таким
образом, контур управления, распределенный между несколькими устройствами, может завершить
операцию в наикратчайшее время. Это, в свою очередь, приводит к уменьшению времени
запаздывания и увеличению быстродействия контура.
Прикладной уровень в FOUNDATION™ Fieldbus обеспечивает поддержку квитированного
взаимодействия между клиентом и сервером, что может использоваться для изменения
оператором значений уставок, удаленной загрузки и настройки параметров конфигурации. Кроме
того, поддерживается рассылка оповещений об аварийных событиях и их подтверждений. Это
основано на том же прикладном уровне, который используется в PROFIBUS_FMS.
В PROFIBUS_PA один ведущий узел использует протокол DP для опроса подчиненных
узлов, содержащих функциональные блоки ввода/вывода. Время опроса всех узлов сети зависит от
количества узлов и ряда других факторов, поэтому детерминированным может быть только время
начала опроса.
На прикладном уровне PROFIBUS_PA вместо FMS использует расширения DP, что
приводит к ограничению возможностей по удаленному конфигурированию, а также по чтению и
записи.
Одним из ожидаемых достоинств полевой шины является возможность распределения
функций управления процессом среди устройств нижнего уровня (уровня полевых устройств)
АСУ ТП. Архитектура FOUNDATION™ Fieldbus, основанная на модели публикации данных
одними сетевыми узлами и подписки на эти данные других сетевых узлов, позволяет
организовывать тесное взаимодействие между устройствами различных производителей,
объединенными в одну сеть. Таким образом, логика алгоритма управления может быть перенесена
на нижний уровень системы управления (т.е. УСО, датчики и исполнительные механизмы).
Архитектура «ведущий-подчиненный», используемая в PROFIBU`S, означает, что весь обмен
происходит по инициативе ведущего устройства. В результате из-за непредсказуемых задержек
невозможно обеспечить функционирование распределенных по устройствам нижнего уровня
контуров управления с обратной связью.
Функции системного администрирования в FOUNDATION™ Fieldbus обеспечивают
исполнение функциональных блоков на разных узлах сети в точно заданной последовательности в
течение детерминированных интервалов времени, что необходимо при реализации контуров
регулирования на нижнем уровне системы.
Подсистема администрирования и канальный уровень FOUNDATION™ Fieldbus способны
также выполнять следующие важные функции:
• автоматическое присвоение сетевого адреса при добавлении нового устройства, что
обеспечивает функциональность plug and play;
• предотвращение дублирования сетевых адресов, каждому устройству назначается один
уникальный адрес;
• синхронизация времени в прикладных программах, когда по сети рассылаются
широковещательные пакеты, синхронизирующие время во всех узлах сети; это необходимо для
правильного функционирования контуров управления или, например, для простановки метки
времени в аварийных сообщениях для их дальнейшего корректного хронологического анализа;
• поиск тегов; это устраняет необходимость в репликации системной базы данных,
содержащей информацию об устройствах.
PROFIBUS не имеет средств системного администрирования, а значит, не способен
обеспечить выполнение описанных ранее функций.
Функциональная совместимость устройств – это возможность замены устройства полевой
шины одного изготовителя на устройство другого изготовителя без потери функциональности или
133
степени интеграции с системой управления или хост-контроллером. Функциональная
совместимость устройств позволяет пользователю для своего проекта выбрать наиболее
подходящую аппаратуру, независимо от того, кто является производителем конкретного
контроллера, датчика, исполнительного механизма или иного полевого оборудования.
В то время как семиуровневая модель OSI является общепринятой в области сетевых
коммуникаций, FOUNDATION™ Fieldbus вводит еще один, восьмой уровень, называемый
пользовательским (User Level). В этом, в частности, состоит ее отличие от PROFIBUS_PA.
Элементами пользовательского уровня в архитектуре, используемой FOUNDATION™ Fieldbus,
являются функциональные блоки, которые представляют собой стандартизированные объекты
управления, такие, например, как аналоговый вход, аналоговый выход и ПИД-регулятор (рисунок
1). Существуют также дополнительные стандартные функциональные блоки, такие как
дискретный вход, дискретный выход, селектор сигналов, операторский ввод, блок
отношение/смещение и блок отношение. Функциональные блоки встроены в датчики и
исполнительные устройства, за счет чего обеспечивается высокий уровень их функциональных
возможностей.
PROFIBUS не имеет полностью определенных стандартных функциональных блоков.
Вместо этого используются так называемые «профили» для определения функций, главным
образом таких простых, как ввод и вывод. При этом собственно управление осуществляется
специальным хост-контроллером.
В пользовательский уровень (User Layer) FOUNDATION™ Fieldbus включена возможность
описания устройств на языке описания устройств (Device Description Language, DDL). Описания
устройств можно рассматривать как своеобразные драйверы устройств.
Рис. 7.3. ПИД-регулирование FOUNDATION fieldbus
Поставщики оборудования предоставляют описания своих устройств пользователям.
После считывания описания устройств хост-системой система, как и все подключенные к ней
устройства, способна поддерживать весь спектр функциональных возможностей устройства.
PROFIBUS не имеет средств, аналогичных описанию устройства. Совместимое с
PROFIBUS оборудование должно соответствовать профилям устройств, допустимый набор
которых определяется ассоциацией PNO.
134
Профили, содержащие базовый набор параметров устройства, жестко заданы и не
расширяемы. Это означает, что PROFIBUS распознает только базовый набор параметров,
являющихся общими для всех устройств определенного типа. Чтобы получить возможность
доступа к дополнительным или расширенным параметрам или возможностям конкретного
устройства, необходимо написать специальную программу.
Более того, спецификации PROFIBUS не содержат никаких возможностей для обеспечения
выполнения стандартных приложений во всех PROFIBUS совместимых устройствах.
В то время как организации, поддерживающие PROFIBUS, ссылаются на строгое
соблюдение профилей как на доказательство совместимости, на самом деле это относится скорее к
вопросам сетевой совместимости и совсем недостаточно для настоящей совместимости уровня
plug_and_play.
Например, для совместимого с PROFIBUS датчика температуры гарантируется
возможность обмена данными через сеть PROFIBUS. Пользователь будет в состоянии выполнять
базовые функции, такие как установка пределов измерения, считывание температуры и т.д.,
однако без специального программирования он не сможет выполнить специфические для
конкретного датчика операции, такие, например, как калибровка. Это объясняется отсутствием в
PROFIBUS возможностей описания устройств.
Используя FOUNDATION™ Fieldbus, пользователь может легко подключить устройство к
сети и после загрузки описания устройства взаимодействовать с ним без каких-либо ограничений.
Технология FOUNDATION™ Fieldbus обеспечивает полный доступ ко всем данным, в том числе к
параметрам, специфичным для данного устройства.
Несмотря на многочисленные уверения в обратном, лишь некоторые версии PROFIBUS
являются открытыми. Фактически компания Siemens все свои сети на базе RS_485 называет
PROFIBUS, несмотря на то, что некоторые из них являются частнофирменным решением Siemens.
С другой стороны, FOUNDATION Fieldbus разработана в полностью открытой и нейтральной по
отношению к различным производителям среде. Спецификации FOUNDATION Fieldbus
опубликованы и доступны всем желающим. Кроме того, в ассоциации Fieldbus Foundation
установлены такие правила, что любая часть сетевой технологии, будь то микросхемы или
реализации протоколов, принимаются, только если для них существует несколько поставщиков.
Различия между ассоциациями PNO и Fieldbus Foundation со всей очевидностью
проявляются в структуре их руководящих органов.
Совет директоров Fieldbus Foundation состоит из 11 членов, представляющих 11 различных
компаний, в то время как совет директоров PNO состоит только из четырех членов, двое из
которых являются сотрудниками компании Siemens. В версиях PROFIBUS, разработанных для
высокоскоростного управления дискретными процессами, Siemens является единственным
поставщиком необходимых высокопроизводительных микросхем.
Технология PROFIBUS, разработанная компанией Siemens в 1989 г., в настоящее время
применяется большим числом пользователей, чем FOUNDATION™ Fieldbus. Однако следует
заметить, что протокол, используемый PROFIBUS, был разработан значительно раньше, чем
протокол Fieldbus Foundation, и основан на менее современной технологии.
Число инсталляций PROFIBUS, объявленное ассоциацией PNO, отчасти вводит в
заблуждение, так как существует множество версий PROFIBUS, ряд из которых не совместим друг
с другом. Кроме того, компания Siemens разработала ряд протоколов, которые она называет
PROFIBUS, несмотря на то, что эти протоколы не приняты органами стандартизации
Германии или организацией PROFIBUS Users Group. Невозможно отрицать тот факт, что
FOUNDATION™ Fieldbus активно привлекает все большее число пользователей и получает все
более широкое распространение среди производителей аппаратно-программных средств для
систем промышленной автоматизации, предъявляющих повышенные требования к
отказоустойчивости и надежности работы систем. За последние несколько месяцев системы,
использующие технологию Fieldbus Foundation, были установлены такими крупными компаниями,
как Dow Chemical, Syncrude Canada, Ltd. и Daishowa Paper. Подробное изучение состава членов
ассоциации Fieldbus Foundation в сравнении с PNO также показывает, что наибольшие вложения в
разработку новых изделий будут приходиться на FOUNDATION™ Fieldbus. Для большинства
конечных пользователей все перечисленные ограничения делают PROFIBUS_PA скорее
135
временной заменой системы «4...20 мА», чем законченной сетевой архитектурой, с которой имеет
смысл связывать свое будущее.
Хотя обе полевые шины, FOUNDATION и PROFIBUS_PA, могут использоваться в
качестве замены аналогового стандарта 4…20 мА, архитектура FOUNDATION™ Fieldbus,
несомненно, обладает рядом преимуществ перед PROFIBUS_PA. Помимо значительно более
высокого уровня совместимости, FOUNDATION™ Fieldbus с помощью улучшенных средств
пользовательского уровня позволяет перенести часть функций распределенного управления на
уровень датчиков и исполнительных механизмов (полевого оборудования).
Вне всякого сомнения, FOUNDATION™ Fieldbus — более открытый протокол,
разработанный и поддерживаемый организацией, в состав которой входит большинство
крупнейших производителей аппаратно-программных средств для промышленной автоматизации.
И, напротив, контроль над PROFIBUS_PA осуществляется одной компанией.
Хотя технология PROFIBUS_PA, вероятно, сможет удовлетворить потребности большого
числа пользователей в ближайшем будущем, эта технология, несомненно, является устаревшей по
сравнению с открытой, постоянно совершенствующейся технологией FOUNDATION™ Fieldbus.
8. ОРС-сервер
ОРС - это аббревиатура от OLE for Process Control, или OLE для Управления Процессами.
Ключевыми словами для понимания технологии ОРС являются технология Microsoft OLE (Object
Linking and Embedding - связывание и встраивание объектов) и интеграция.
Но, прежде всего, нужно сделать несколько замечаний по терминологии. Дело в том, что
по ходу изложения материала встречаются термины, близкие или даже одинаковые по написанию,
но имеющие совершенно разный смысл.
Интеграция
Во-первых, что понимается под термином интеграция.
Предположим, что в результате огромных усилий программистов создана сложная
комплексная система, охватывающая автоматизацию на всех уровнях предприятия, начиная от
самого нижнего - управления датчиками и исполнительными механизмами - и заканчивая уровнем
управления предприятием, вплоть до обобщённой картинки завода у директора предприятия.
Реализована ли в данном случае концепция интеграции? В общем случае нет. Интеграция
подразумевает не единую глобальную систему как таковую, а, прежде всего, взаимодействие
различных уровней программного обеспечения между собой. Фактически, речь идёт о том, что
различные программные системы, созданные с помощью различных средств, установленных на
различных платформах, работающих на разных компьютерах, умеют взаимодействовать между
собой. То есть, они знают, как запросить друг у друга и как послать друг другу данные.
Для того чтобы договориться, необходимо установить общий язык. И этот язык должны
принимать все программные участники интеграции.
Можно привести множество примеров на эту тему всего того, что употребляется с
ключевыми словами интерфейс, протокол, API, язык и пр.
Теперь для дальнейшего понимания требуется немного остановится не технологии СОМ.
COM/DCOM
Итак, СОМ - Component Object Model, или Модель Составных Объектов - и её сетевое
расширение DCOM -Distributed COM, или Распределённая СОМ - это технология, введённая
первоначально Microsoft для интеграции между различными офисными приложениями в Windows.
Интеграция подразумевала использование объектов одного приложения, например, таблицы Excel,
в другом приложении, например, в редакторе Word.
Всё это известно под аббревиатурой OLE (Object Linking and Embedding - Связывание и
Встраивание Объектов). Начиная с версии OLE 2.0, в её основу была положена модель СОМ.
Первоначально само название СОМ было так сказать, скрыто от "широких масс". Хотя
постепенно СОМ пронизала все варианты Windows 9.x/NT/CE. Достаточно упомянуть такие её
"производные", как ActiveX (OLE-Автоматизация) или OLE DB (OLE for Data Base - OLE для Баз
Данных), не говоря уже о самой "офисной" OLE.
В Windows2000 к СОМ добавляются некоторые компоненты (транзакции, безопасность,
очереди и др.), она преобразовывается в СОМ+ и объявляется основной базовой технологией
программирования в архитектуре DNA (Distributed interNet Application - распределённые
приложения Internet).
136
Основные понятия, связанные с нынешним состоянием технологии СОМ: Объекты СОМ
Модель СОМ оперирует объектами, очень похожими на объекты в объектно-
ориентированных языках программирования типа C++. Но сама технология СОМ не является
языком программирования. Она только регламентирует поведение своих объектов. Нам нужно
знать, что объект может быть создан, после чего он предоставляет свою функциональность
вызвавшему процессу, а после использования - уничтожен.
Интерфейсы объектов
Объекты СОМ предоставляют свою функциональность через интерфейсы (Interface).
Интерфейс в СОМ объединяет группу взаимосвязанных функций, предоставляемых
объектом. Главная особенность интерфейсов СОМ заключается в их "публичности". Интерфейсы
используются после того, как они "опубликованы", и после этого их нельзя изменять никогда.
Если необходима новая версия интерфейса, издаётся новый интерфейс при сохранении старого.
Этим обеспечивается совместимость при обновлении и модернизации объектов. И это первый шаг
на пути к интеграции.
Доступ к объектам
Именно интерфейс, вернее указатель на него, является тем, с чем работает вызывающий
процесс (читай программист). Объект может предоставлять несколько интерфейсов. Указатель на
этот интерфейс передаётся инициирующему процессу при создании объекта.
Обмен в СОМ
Объект СОМ является пассивной стороной. Он лишь предоставляет через интерфейсы свои
функции. В этом смысле употребляется термин СОМ-сервер. Запрашивающая программа,
соответственно, называется СОМ-клиент.
Регистрация
Чтобы создать объект, нужно знать, где он находится. В Windows для этого используется
регистрация объектов в системном реестре. В реестре регистрируются также интерфейсы.
При этом каждый объект регистрации имеет уникальный в полном смысле этого слова
идентификатор, называемый GUID (Globally Unique Identifier - глобально уникальный
идентификатор). Присваивает идентификаторы своим "СОМ-детищам" их создатель, используя
специальную программу. Заметим также, что многие СОМ-объекты могут (a ActiveX просто
обязаны) регистрироваться в системе.
Регистрация делает доступной информацию о расположении объектов всем приложениям.
И это второй шаг на пути к интеграции.
Обслуживание объектов
Вопросы, затрагиваемые здесь, очень важны для понимания всего излагаемого. Объекты
СОМ должны быть достаточно независимыми. Они зачастую, если не сказать в большинстве
случаев, находятся вне программы СОМ-клиента, а могут быть запущены даже на другом
компьютере. Это имеет принципиальные последствия.
Даже на одном компьютере разные приложения Windows функционируют в своих
собственных адресных пространствах. Это означает, что требуется кто-то, кто будет передавать
вызовы из одного процесса в другой. Даже простое создание или уничтожение объекта в другом
адресном пространстве вовсе не тривиальное дело.
В СОМ эти и другие проблема решается с помощью специальных библиотек.
Для нас во всём этом важно то, что эти библиотеки автоматизируют работу с СОМ-
объектами и делают её прозрачной для СОМ-клиента (с его точки зрения объект "находится" в его
собственном адресном пространстве). И это третий шаг на пути к интеграции.
Удалённые объекты
В СОМ по этому поводу существует DCOM - расширение СОМ, позволяющее получить
доступ до объектов на других компьютерах. Существенно то, что с точки зрения
программирования, ничего не меняется: DCOM - это системный сервис, делающий СОМ
прозрачным в локальных сетях. И это четвёртый шаг к интеграции.
Ещё одно существенное замечание. Сервис DCOM базируется на RPC (Remote Procedure
Call - удалённый вызов функций). А это не позволяет использовать его в глобальных сетях
(Internet).
Предоставление объектов (кто их реализует)
Чтобы использовать объект, необходимо знать, как он устроен, вернее, как устроены его
интерфейсы. Для этого они должны быть опубликованы. Например, в виде официальной
документации. Или в виде стандарта. Таким образом, вырисовывается две возможности. Либо вы
137
разрабатываете некий СОМ-объект, дополняете его интерфейсами, снабжаете документацией и
распространяете в виде бинарного кода.
Либо вы намечаете какую-либо проблему, изучаете её, возможно, даже собираете некую
"тусовку", называемую Foundation или Committee, и издаёте стандарт, подробно описывающий
объекты, призванные решать данную проблему. Реализацию вы оставляете другим. Если дело
стоящее, желающие найдутся. Именно это можно сказать об ОРС!
Использование объектов
Использовать СОМ-объекты должны СОМ-клиенты. Но они могут быть разными, если мы
говорим об интеграции. И могут использовать разные языки программирования, не исключая
скриптовых типа Visual Basic.
Технология СОМ здесь предусматривает две возможности. Либо вы программируете на C+
+ и тогда для описания интерфейсов используете в проекте предоставляемые с документацией h- и
с-файлы. В этом случае говорят об пользовательском интерфейсе.
Либо вы используете для скриптовых запросов так называемую автоматизацию (OLE
Automation). В этом случае для доступа к функциям объекта используется специальный СОМ-
интерфейс IDispatch, который СОМ-объект в этом случае обязан поддерживать, предоставляя
интерфейс Автоматизации. Не вдаваясь в подробности, скажем, что при этом никакие
компилируемые файлы не нужны. Но нужна так называемая библиотека типов. Об этом ниже.
Реализация объектов
Программирование СОМ, то есть реализация объектов - занятие не из лёгких. Было бы,
если бы не предоставляемые средства. Очень упрощенно это выглядит так. С помощью С-
подобного языка MIDL (Microsoft Interface Definition Language - язык определения интерфейсов)
описываются интерфейсы. С помощью специального компилятора MIDL.EXE они
преобразовываются в описанные выше файлы, в том числе и в библиотеку типов. А далее
используется библиотека ATL (Active Template Library - библиотека активных шаблонов),
"умеющая" интерпретировать эти файлы и многое другое, связанное с СОМ и ActiveX.
ОРС в свете СОМ
Всё, что было изложено выше, преследовало единственную цель - подвести понятийную
базу под то, что будет рассказано далее.
Историческая справка Сравнительно недавно, в 1994 г., под эгидой Microsoft, была создана
организация ОРС Foundation.
Её целью является разработка и поддержка открытых промышленных стандартов,
регламентирующих методы обмена данными в реальном времени между клиентами на базе
персональных компьютеров и ОС Microsoft. Сейчас эта организация насчитывает более 220
членов, включая почти всех ведущих поставщиков контрольно-измерительного и управляющего
оборудования для АСУ ТП. Достаточно назвать такие фирмы, как Siemens, Schneider Automation,
Rockwell Software, Wonderware, Intellution, Ci Technologies, не говоря уже о самой Microsoft.
Технология
Как уже отмечалось выше, технология ОРС реализована и продолжает реализовываться по
схеме разработка стандартов. ОРС Foundation определяет направления, по которым ведутся
разработки, и создаёт по этим направлениям комитеты. Комитеты делают следующее:
– разрабатывают спецификации СОМ-интерфейсов и СОМ-объектов;
– присваивают им уникальные идентификаторы GUID;
– оформляют всё в виде стандартов и опубликовывают;
– генерируют или создают вспомогательные файлы: idl-, h- и с-файлы для
пользовательского интерфейса; библиотеки типов для интерфейса автоматизации;
– разрабатывают вспомогательные компоненты, например, утилиту opcenum,
позволяющую ОРС-клиенту "увидеть" список всех ОРС-серверов локальной сети;
– развивают деятельность по рекламе и популяризации, включая демонстрационные
программы и оценку производительности.
Практически всё является общедоступным: зайдя на сайт, вы можете либо "скачать" то, что
вас интересует, или заполнить небольшую анкету, и вам вышлют бесплатно компакт-диск со
всеми имеющимися материалами. Но кое-что, например, демо-программы, всё-таки
предоставляется только членам организации. Кстати, стоимость членства зависит от вашего
бизнеса и колеблется от 100 долларов в год для университетов и непрофильных организаций до 10
000 долларов в год для крупных фирм с оборотом более 100 миллионов долларов.
Спецификации
138
В настоящее время имеются следующие ОРС-стандарты.
– ОРС 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 пытается охватить
все аспекты, связанные с взаимодействием с технологическим оборудованием. В разработке самих
спецификаций принимают участие ведущие производители оборудования и систем автоматизации,
которые стараются максимально учесть свой опыт и предоставить абсолютно "всё необходимое"
тому, кто будет использовать ОРС. Далее мы проиллюстрируем это на примере спецификации
Data Access (DA).
ОРС-сервер (потребители "снизу")
Кто же использует ОРС?
Первая категория - производители оборудования автоматизации, или поставщики
комплексного оборудования (OEM). Предполагается, что тот, кто создаёт, например, плату сбора
данных, снабжает её не только драйвером, но и реализует ОРС-сервер, работающий с этой с
платой через драйвер или даже напрямую. Тем самым ОЕМ-производитель предоставляет
стандартный доступ к своей плате.
Список возможных изготовителей ОРС-серверов неограничен. ОРС-сервером можно
снабдить контроллер, плату ввода/вывода, адаптер полевой шины, программу пересчёта,
генератор случайных чисел, что угодно, лишь бы это могло поставлять или принимать данные. Но
всё-таки здесь речь идёт, в первую очередь, о программном обеспечении для более низкого уровня
в системах автоматизации.
Что должен сделать производитель, если он задался целью обеспечить свой продукт
стандартным интерфейсом? Он должен получить нужную спецификацию и прилагаемые
программные компоненты. Затем он должен изучить СОМ-интерфейсы тех СОМ-объектов этой
спецификации, которые относятся в ней к модели ОРС-сервера. И, наконец, он должен посадить
самого опытного программиста за кодирование, и тот с помощью ATL-библиотеки реализует
требуемые интерфейсы, а значит и ОРС-сервер. Это всё. Можно только добавить, что если вы не
хотите использовать самого опытного программиста, придётся купить какой-нибудь готовый
пакет, или Toolkit (комплект инструментальных средств).
ОРС-клиент (потребители "сверху")
Правила игры заданы - ОРС-сервер поставляет данные, ОРС-клиент потребляет.
Этим задаётся вторая категория пользователей спецификаций ОРС. И к ней относятся в
первую очередь те, кто реализует программное обеспечение более высокого уровня. Например,
поставщик SCADA-пакета.
Что же должен сделать производитель "верхнего" ПО, если он задался целью обеспечить
свой продукт стандартным интерфейсом? Он должен получить нужную спецификацию и
прилагаемые программные компоненты. Затем он должен изучить СОМ-интерфейсы тех СОМ-
объектов этой спецификации, которые относятся в ней к модели ОРС-клиента. И, наконец, он
должен посадить достаточно опытного программиста за C++, и тот с помощью ATL-библиотеки
реализует требуемые интерфейсы, а значит и ОРС-клиент для пользовательского интерфейса.
Можно использовать Visual Basic или, скажем, Delphi. По-прежнему, сэкономить на квалификации
программиста можно, используя Toolkit.
Остальные потребители
139
Это те, кто собирают системы из "ОРС-серверного" оборудования, и соединяют его с
"ОРС-клиентным" ПО. Главный задача здесь - каждому ОРС-серверу "найти" ОРС-клиента и
наоборот. Очень часто кого-то из них не хватает, и тогда не исключена вероятность перехода в
категорию изготовителей, но чаще заказчиков, ОРС-продукции.
ОРС Data Access
Чтобы лучше почувствовать, что такое ОРС, рассмотрим подробнее главный, по большому
счёту, стандарт. Будем называть его сокращённо DA.
Стандарт DA предназначен для поставки оперативных данных от оборудования и/или к
оборудованию.
Стандарт DA имеет две версии интерфейсов: 1.0 и 2.0. Как мы уже знаем, с точки зрения
СОМ, это самостоятельные спецификации. ОРС-клиент предварительно запрашивает, может ли он
работать с нужным ему СОМ-интерфейсом в используемом ОРС-сервере. Более современным
является стандарт 2.0. С точки зрения функциональности, в версии 2.0 механизм уведомления
клиента приведён к стандартному механизму COM/DCOM, что упрощает программирование.
Более интересно рассмотреть, с чем работает DA.
Данные
Основной единицей данных в ОРС является переменная (Item). Переменная может быть
любого типа, допустимого в технологии OLE: различные целые и вещественные типы, логический
тип, строковый, дата, валюта, переменный тип и так далее. Кроме того, переменная может быть
массивом.
Свойства
Каждая переменная обладает свойствами. Различаются обязательные свойства,
рекомендуемые и пользовательские.
Обязательными свойствами, понятно, обязана обладать каждая переменная. Это, во-
первых, текущее значение переменной, тип переменной и права доступа (чтение и/или запись). Во-
вторых, очень важные свойства - качество переменной и метка времени. Технология ОРС
ориентирована на работу с оборудованием, а оборудование может давать сбои, так что корректное
значение переменной не всегда известно ОРС- серверу, о чём и уведомляется клиент через
качество (хорошее/плохое/неопределённое и дополнительная информация). Метка времени
сообщает о том, когда переменная получила данное значение. Еще одним обязательным свойством
является частота опроса переменной ОРС-сервером. Последним из обязательных свойств является
описание переменной. Это строковое значение, содержащее информацию для пользователя о том,
зачем нужна эта переменная.
Дополнительные свойства являются необязательными для реализации в ОРС-сервере. Это,
например, диапазон изменения (выход за границы диапазона должен специальным образом
обрабатываться клиентом) и единица измерения. Есть перечень рекомендуемых свойств, но можно
добавить и свои собственные.
Получение данных
Существует три основных способа получения ОРС-клиентом данных от ОРС-сервера:
синхронное чтение, асинхронное чтение и подписка. При синхронном чтении клиент посылает
серверу запрос со списком интересующих его переменных и ждёт, когда сервер его выполнит. При
асинхронном чтении клиент посылает серверу запрос, а сам продолжает работать. Когда сервер
выполнил запрос, клиент получает уведомление. И, наконец, в случае подписки клиент передаёт
серверу список интересующих его переменных, а сервер затем регулярно присылает клиенту
информацию об изменившихся переменных из этого списка. Эти списки в терминологии ОРС
называются группами. Каждый клиент может поддерживать одновременно много групп с разной
скоростью обновления.
Запись данных
Ничем не отличается от чтения, за исключением того, что нет записи по подписке.
Источники данных
Технология ОРС регламентирует только интерфейс между ОРС-клиентами и ОРС-
серверами (как и положено в технологии клиент-сервер, допускается множественные
подсоединения). И она абсолютно не регламентирует способ получения этих данных от
оборудования. Разработчик сам определяет, где и как их брать.
Но, тем не менее, есть некоторые модели взаимодействия с оборудованием,
предполагаемые разумными с точки зрения разработчиков ОРС. И для их рационального
обслуживания предлагаются соответствующие механизмы. Например, можно "попросить" ОРС-
140