Реферат Орс-технологии

Работа добавлена на сайт bukvasha.net: 2015-10-28

Поможем написать учебную работу

Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.

Предоплата всего

от 25%

Подписываем

договор

Имя

Выберите тип работы:

Принимаю Политику конфиденциальности

Скидка 25% при заказе до 22.11.2024

Гипероглавление:
ОРС-технологии
1.1        Описание предметной области
1.2        Постановка задачи
1.3        Существующие системы
1.4        Возможные решения
1.4.1       Представление информации посредством протокола обмена данными
1.4.2       Организация общей памяти для обмена данными
1.4.3       Предоставление информации посредством встраивания объектов
1.5        Описание и сравнительный анализ выбранной технологии
1.5.1       Технологии построения компонентных приложений
1.5.1.1       COM
1.5.1.2       CORBA
1.5.1.3       Проблемы при разработке.
1.5.1.4       Ранее применяемые подходы.
1.5.1.5       Сравнение технологий COM и CORBA
1.5.1.6       OPC
1.5.2       Пользователи OPC
1.5.2.1       OPC-сервер
1.5.2.2       OPC-клиент
1.5.4. Выводы
1.6        Структура программного обеспечения сервера OPC Modbus
1.7        Средства реализации
1.8        Средства тестирования и верификации
1.9        Выводы из сравнения технологий реализации
2          Разработка программного обеспечения OPC сервера
2.1        Структура программного обеспечения
2.1.1       Блок взаимодействия с сеть Modbus
2.1.1.1       МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ
2.1.1.2       ОСОБЕННОСТИ ПРОТОКОЛА MODBUS/TCP
2.2        Блок взаимодействия с OPC клиентами
2.2.1       Внутрипроцессный сервер (DLL)
2.2.2       Локальный сервер
2.2.3       Удаленные подключения и прозрачность местонахождения
2.2.4       Выбор реализации COM компонента
2.3        Блок синхронизации
4. Технология разработки и тестирования
4.1. Технология построения программы
4.1.1. Программирование на основе интерфейсов
4.2.2. Модель COM
4.1.3. Связь OPC и COM
4.2. Обзор технологии OPC
4.3. Верификация программного обеспечения
4.4.Отладка и тестирование
4.4.1. Подгрузка внутрипроцессного сервера
4.4.2. Запуск локального сервера
4.4.3. Запуск удаленного сервера
4.4.4.Создание элемента данных
4.4.5. Запись данных в источник
4.4.6. Определение устойчивости соединения
6. Примеры реализации ОРС-технологии

ОРС-технологии

1     Введение

1.1   Описание предметной области

1.2   Постановка задачи

1.3   Существующие системы

1.4   Возможные решения

1.4.1      Представление информации посредством протокола обмена данными

1.4.2      Организация общей памяти для обмена данными

1.4.3      Предоставление информации посредством встраивания объектов

1.5   Описание и сравнительный анализ выбранной технологии

1.5.1      Технологии построения компонентных приложений

1.5.1.1 COM

1.5.1.2 CORBA

1.5.1.3 Проблемы при разработке.

1.5.1.4 Ранее применяемые подходы.

1.5.1.5 Общие выводы по сравнению технологий COM и CORBA

1.5.1.6 OPC

1.5.1.7 OPC- спецификации и стандарты

1.5.2      Пользователи OPC

1.5.2.1 OPC-сервер

1.5.2.2 OPC-клиент

1.5.2.3       OPC DATA ACCESS

         1.5.3      Реализация ОРС

1.5.4      Выводы

1.6      Структура программного обеспечения

1.7   Средства реализации

1.8   Средства тестирования и верификации

1.9.      Производительность ОРС-систем (данные 1999 года)

1.10.    SCADA-системы и ОРС

1.11 Выводы из сравнения технологий реализации

2     Разработка программного обеспечения OPC сервера

2.1   Структура программного обеспечения

2.1.1     Блок взаимодействия с сетью Modbus

2.1.1.1 МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ

2.1.1.2 ОСОБЕННОСТИ ПРОТОКОЛА MODBUS/TCP

2.2   Блок взаимодействия с OPC клиентами

2.2.1      Внутрипроцессный сервер (DLL)

2.2.2      Локальный сервер

2.2.3      Удаленные подключения и прозрачность местонахождения

2.2.4      Выбор реализации COM компонента

2.3   Блок синхронизации

3. Программное обеспечение универсального ОРС-сервера

(ОРС UA) для систем НMI/SCADA

     3.1.      Туннелинг ОРС

      3.2.       Группировка, архивация и резервирование данных ОРС

4     Технология разработки и тестирования

4.1   Технология построения программы

4.1.1      Программирование на основе интерфейсов

4.1.2      Модель COM

4.1.3      Связь OPC и COM

4.2   Обзор технологии OPC

4.3   Верификация программного обеспечения

4.4   Отладка и тестирование

4.4.1      Подгрузка внутрипроцессного сервера

4.4.2      Запуск локального сервера

4.4.3      Запуск удаленного сервера

4.4.4      Создание элемента данных

4.4.5      Запись данных в источник

4.4.6      Определение устойчивости соединения

5.       Распределенные системы данных на основе ОРС

6.        Примеры реализации

8     Список использованной литературы

1. Введение

1.1 Описание предметной области

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

Широко для контроллерных сетей используется протокол Modbus и его модификации. Разработанный компанией Modicon, этот протокол стал стандартным для разработчиков контроллерных сетей. В следствии развития контроллеров и средств телекоммуникаций появилась модификация протокола Modbus для сетей TCP/IP – Modbus/TCP. Данная модификация протокола позволяет создавать сети управляющих устройств на базе сети IP.

Рис. 1.1. Схема использования Modbus/TCP.

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

               В помощь оператору создано множество автоматизированных систем управления технологическими процессами. C появлением концепции открытых систем программные средства для операторских станций становятся самостоятельным продуктом, свободно компонуемым с программно-техническими средствами разных производителей. Специализация изготовителей позволяет им сосредоточиться на проблемах создания программного обеспечения для компьютерных станций в АСУТП и, привлекая к разработкам программистов высокой квалификации, создавать высококачественные и эффективные продукты. Появляется функция поддержки сетевых связей. Особой заботой разработчиков стала необходимость обеспечения программных систем средствами связи с контроллерами и устройствами разных производителей; большое количество контроллеров с разными аппаратно-программными платформами и постоянное увеличение их числа заставляет разработчиков включать в состав программной системы большое количество готовых драйверов (до 700 – 800) и инструментарий для разработки новых драйверов.

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

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

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

               На сегодняшний день, офисные компьютеры имеют мощные графические подсистемы и процессоры с высоким быстродействием. Эту развитость аппаратуры офисных компьютеров можно использовать в области управления технологическими процессами, например, при построении систем администрирования и сбора информации, так называемых SCADA [Supervisory Control And Data Acquisition] – диспетчерское управление и сбор данных. SCADA системы – название класса систем для комплексной автоматизации промышленного производства Данные системы используются в области управления технологическими процессами и выполняют следующие функции:

v     Прием информации о контролируемых технологических параметрах от контроллеров нижних уровней и датчиков.

v     Сохранение принятой информации в архивах.

v     Вторичная обработка принятой информации.

v     Графическое представление хода технологического процесса, а также принятой и архивной информации в удобной для восприятия форме.

v     Прием команд оператора и передача их в адрес контроллеров нижних уровней и исполнительных механизмов.

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

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

v     Формирование сводок и других отчетных документов на основе архивной информации.

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

               SCADA-системы ведущих производителей получают расширение в иерархии уровней управления производством «по вертикали» – в сторону непосредственного управления процессом (автоматическое регулирование и программно-логическое управление), и в сторону управления производством. Такие программные системы в совокупности представляют собой мощные программные комплексы, обеспечивающие интегрированные системы управления производством в целом. Использование в системах разных уровней единого стиля оформления, единой терминологии, инструментария, служебных средств и т.д., значительно облегчают системным интеграторам разработку систем, а предприятиям – их освоение и эксплуатацию. Функции непосредственного управления реализуются в пакетах прикладных программ для контроллеров, построенных на основе персональных компьютеров (SoftPLC), и для компьютерной реализации функций непосредственного управления (SoftControl).

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

               Прогресс в области SCADA-систем в последние годы получил значительное ускорение. Привлечение разработчиками новейших информационных технологий, интеграция приложений, встраивание стандартных языковых средств для программирования пользовательских алгоритмов и экранных взаимодействий значительно повысили эффективность SCADA-систем. В распоряжении пользователей разных групп теперь появляется мощный инструментарий. Технологии распределенной межсетевой архитектуры для корпоративных систем DNA (Distributed interNet Architecture) в среде MS Windows, комплексирование продуктов для управления технологией и офисов создают новые возможности в интеграции систем управления и перераспределения функций между ними. Теперь в дежурный список поддерживаемых системами технологий и интерфейсов дополнительно к уже ставшим традиционными DDE, DLL, OLE, ODBC/SQL включаются объектные компонентные модели COM/DCOM с ActiveX,, технологии Java, универсальный интерфейс связи с внешними устройствами OPC, языки стандарта IEC 61131-3, языки описаний на основе Visual Basic for Applications, Internet/Intranet и т.д.

               Конечных пользователей не очень интересует перечень технологических средств, использованных в конкретной SCADA-системе. Для него важны функциональные и коммуникационные возможности и технические характеристики систем, например, такие, как возможность через Internet приобрести нужный фрагмент для разрабатываемой станции и без проблем «вставить» его в проект; руководству фирмы – «заглянуть» на экраны операторских станций дальнего предприятия и убедиться в соблюдении технологии; программисту – по просьбе заказчика проверить работу своей программы в системе управления и после исправлений немедленно переслать новый вариант. И возможность избавиться от «проблемы драйверов» средствами ОРС-интерфейса. В целом новации в SCADA-системах обеспечивают значительное снижение затрат труда на разработку и обслуживание операторских станций, повышение скоростей и дальности обмена данными в системах управления и многие другие, важные для применений, качества. Добавим, что интеграция систем управления на всех уровнях в пределах предприятия, о которой говорили уже несколько десятилетий, теперь обеспечена средствами интегрированных программных систем (наборов) и коммуникаций.

               В целом анализ и исследование потребительских качеств программных средств для автоматизированных систем управления в промышленно развитых странах представляет собой важную сферу деловой активности. Ими занимаются многочисленные ассоциации производителей и потребителей программно-аппаратных средств автоматизации. Уже из краткой характеристики описанных выше работ видно, что проведение этих дорогих мероприятий не под силу отдельным предприятиям, но доступно для ассоциаций, защищающих корпоративные интересы пользователей разных групп. Выполняемая же экспертиза важна и для конкретных пользователей продуктов, и для повышения уровня работ в стране в целом. Отметим, что до отечественного заинтересованного читателя доходит лишь очень небольшая часть сведений о проводимых в ведущих промышленных странах исследованиях, направленных на защиту интересов предприятий-потребителей средств автоматизации. Значительная часть отчетов о работах этого направления, выполняемых на коммерческой основе, распространяется за плату и остается недоступной для наших потребителей.

1.2 Постановка задачи

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

ü      Тип промышленной сети – MODBUS и другие.

ü      Рекомендуемые технологии – CORBA или OPC.

ü      Необходимо обеспечить возможность множественного подключения к данному приложению. Количество подключенных приложений не должно быть ниже 10.

ü      Количество обслуживаемых управляющих устройств – 5.

ü      Количество опрашиваемых переменных для каждого управляющего устройства – 64.

ü      Приложение должно функционировать на IBM PC совместимой аппаратной платформе с процессором 950МГц и объемом оперативной памяти 256Мб.

ü      Приложение должно быть построено с помощью компилятора Visual C++.

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

               На уровне управляющих контроллеров задачи вторичной обработки данных решать нецелесообразно. Данный уровень предназначен для осуществления надежного и своевременного управления процессом производства, обнаружения аварий. Для этого удобно использовать компьютеры офисного, или «бизнес» уровня. Набор программ бизнес уровня для решения подобных задач широк. Для хранения данных существуют СУБД, для визуализации информации существуют графические редакторы, для статистического анализа – электронные таблицы. Возникает вопрос, каким образом предоставить информацию промышленного уровня на уровень офисных приложений. Есть ли стандартный способ сопряжения приложений бизнес-уровня с оборудованием контроллерных сетей. Что необходимо сделать для возможности предоставления информации независимо от вида источника. Как должно быть исполнено приложение, организующее взаимодействие с устройствами промышленного уровня.

               Для решения поставленной задачи необходимо:

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

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

Ø      Рассмотреть способы модернизации реализованного ПО для возможности применения с различным оборудованием.

Ø      Рассмотреть базовые технологии для выбранного способа реализации задания.

Ø      Рассмотреть их перспективы, поддержку со стороны разработчиков этих технологий.

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

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

1.3 Существующие системы

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

Таким образом, можно сказать, что не было стандартного способа доступа к источникам данных, в том числе, производственного уровня.

               На сегодня, множество программ реализовано, как клиенты источников данных производственного уровня. Организация доступа осуществляется их собственными драйверами, разработанными только для данных клиентов. Как следствие, можно привести следующие недостатки:

·        Многократное повторное приложение

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

·        Несовместимость между драйверами различных производителей

Особенности аппаратуры не поддерживаются всеми производителями драйверов.

·        Поддержка изменений специфики аппаратуры

Изменения возможностей аппаратуры могут привести к неработоспособности некоторых драйверов.

·        Конфликты доступа

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

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

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

1.4 Возможные решения

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

·        физический протокол передачи данных – 10BaseT, или 100BaseT;

·        канальный уровень – Ethernet II & IEEE 802.3;

·        сетевой уровень – IP;

·        транспортный уровень – TCP;

·        прикладной протокол управляющей сети – Modbus;

·        аппаратная платформа приложений бизнес-уровня – IBM PC;

·        операционная система – Microsoft Windows 9x/NT (в том числе 2000 и XP);

(операционная система уже поддерживает стек протоколов TCP/IP).
               Исходя из этого возникает ряд возможных реализаций необходимого посредника, принимающего участие в процессе передачи данных. Необходимо помнить набор систем, которые принимают участие в управлении. Так, или иначе, должен существовать сервис, который получает данные из полевой сети. Далее, данные буферизируются и предоставляются потребителям с помощью заранее оговоренного способа. Буферизация необходима для организации вторичной обработки до предоставления и для возможности предоставления данных многим потребителям. Без буферизации каждый из клиентов должен будет получить прямой доступ к устройству через драйвер для получения данных. В большинстве случаев, все потребители будут получать различные данные из-за больших временных затрат на обслуживание организации прямого доступа.

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

               Необходимо помнить, что источниками и потребителями данных являются обе стороны. При сборе информации, например, для архивного хранения, источники находятся на уровне промышленной сети, а потребители на офисном уровне. При передаче управляющей информации для контроллеров, источником является (может являться) SCADA-система, а получатель данных – управляющий контроллер, работающий на уровне управляющей контроллерной сети.

1.4.1 Представление информации посредством протокола обмена данными

Для решения поставленной задачи возможно использовать прикладные протоколы обмена данными, например HTTP, FTP, TELNET. При организации такого подхода, должен быть разработан сервер сбора данных по протоколу полевой шины, в данной задаче – по протоколу Modbus, для получения данных с уровня полевой системы. Сервер организовывает кэширование полученных данных для предоставления из удаленным клиентам. Далее полученные данные становятся доступными для удаленных клиентов по одному из прикладных протоколов. Для организации установления соединений каждый клиент и каждый сервер должны знать друг о друге для возможности организации передачи данных. Возникают трудности для организации множественных подключений многих клиентов ко множеству серверов. При необходимости перехода на другое клиентское приложение есть ограничения на выбор таковых.

Обычно, сервер, например, HTTP поддерживает подключение многих клиентов, но не всякий клиент поддерживает множественное подключение к нескольким серверам, а это иногда бывает необходимо.

Рис. 1.2. Реализация представления данных посредством протокола обмена.

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

1.4.2 Организация общей памяти для обмена данными

Для обмена данными приложения используют общую память. Каждое из взаимодействующих приложений должно иметь средства управления общей памятью. Сравнительно несложно организуются множественные подключения. Все взаимодействующие приложения знают об общей памяти, используемой для обмена, но не знают о других приложениях работающих с данной общей памятью. Количество взаимодействующих приложений не ограничено. Ограничен объем памяти, выделенный для передаваемых данных. Следовательно, ограничено количество данных, передаваемых одновременно.

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

Рис. 1.3. Реализация представления данных посредством общей памяти.

1.4.3 Предоставление информации посредством встраивания объектов

               При данном подходе драйвер контроллерной сети выполняется в виде компонента, который предоставляет в систему интерфейсы (наборы методов) для выполнения запросов и посылок данных, каких-либо иных специальных действий. Для данной реализации приложение офисного уровня должно иметь средства вызовов методов компонентов, присутствующих в системе. При реализации средства («драйвера») представления данных таким образом, его использование принимает следующий вид:

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

               Множественное подключение реализуется за счет возможности многократного использования компонента.

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

Рис. 1.4. Реализация представления данных посредством вызовов методов объектов.

1.5 Описание и сравнительный анализ выбранной технологии

               Прежде всего нужно сделать несколько замечаний по терминологии. Дело в том, что по ходу изложения встречаются (и уже встречались) термины одинаковые по написанию, но имеющие совершенно разный смысл.

Автоматизация. Это – собственно автоматизация (например, производства). Но это также и OLE-автоматизация (даже без приставки OLE). И еще это интерфейс автоматизации.

Интерфейс. Это – интерфейс в общепринятых смыслах. Но это также интерфейсы объектов COM и еще интерфейсы серверов (например, интерфейс автоматизации).

С этого момента употребление слов интерфейс и автоматизация имеют значение применительно к технологии компонентного объектного подхода. При употреблении этих слов в другом смысле будут даны специальные комментарии.

            OLE [Object Link Embedding] – до 1996 года – общее название группы объектно-ориентированных технологий Microsoft на основе COM (OLE 1, OLE 2, OLE automation, OLE Database и др.); с 1996 года после введения термина ActiveX применяется для обозначения технологий на основе COM, используемых для создания составных документов внедрением и связыванием.

               Постепенно COM пронизала все варианты Windows 9.x/ME/NT/CE. Достаточно упомянуть такие ее производные, как ActiveX (OLE-автоматизация) или OLE DB, не говоря уже о самой офисной OLE. Эта технология все больше и больше развивалась Microsoft. И в Windows 2000 к COM добавляются некоторые компоненты (транзакции, безопасность, очереди и др.), она преобразовывается в COM+ и объявляется главной, “склеивающей” технологией программирования в архитектуре DNA (Distributed interNet Application — распределенные приложения Internet), а связанные с этим технологии объединяются под общим названием Component Services (сервисы компонентов).

               На сегодняшний день для компьютеров офисного уровня широко используется операционные системы Microsoft Windows.

               Создав компонент и зарегистрировав его в операционной системе, появляется возможность использовать его методы другими приложениями. В этом состоит преимущество технологий на базе COM. Как дополнение к COM существует DCOM, что раскрывается как Distributed (распределенная) COM. В результате развития операционных систем Windows DCOM стала частью операционной системы в Windows NT, ранее возможности DCOM были доступны только после инсталляции в систему специального дополнения. Использование возможностей операционной системы для решения проблемы предоставления данных удобно. Тем более, что многие приложения, ориентированные на эту операционную систему, уже имеют средства вызовов методов COM объектов, зарегистрированных в системе. При данном подходе задача решается построением приложения, которое имеет средства доступа к контроллерной сети Modbus и предоставляет свои интерфейсы другим приложениям. Для данного решения нет необходимости разрабатывать средства доступа к общей памяти, или трансляторы данных между протоколами Modbus и выбранным протоколом и между выбранным протоколом и приложением.

1.5.1 Технологии построения компонентных приложений

1.5.1.1 COM

               [Component Object Model] - предложенная Microsoft технология построения компонентных объектов. Component Object Model (модель составных объектов) — и ее сетевое расширение DCOM — Distributed COM (распределенная COM) — это технология, введенная первоначально Microsoft для интеграции различных офисных приложений в Windows. Интеграция подразумевала использование объектов одного приложения, например, таблицы Excel, в другом приложении, например, в редакторе Word. Все это известно под аббревиатурой OLE. Начиная с версии OLE 2.0 в ее основу была положена модель COM.

               Технология создавалась фирмой Microsoft как средство взаимодействия приложений (в том числе составных частей операционной системы) Windows, функционирующих на одном компьютере, с последующим развитием для использования в пределах локальной сети.

               COM содержит все необходимое, что нужно для построения распределенной системы: технологию удаленного вызова методов (как статических, так и динамических), базы данных серверных объектов (библиотеки типов), которые могут быть импортированы для анализа структуры серверов COM, универсальный протокол обмена между клиентами и серверами, спецификации так называемых “составных документов” (ActiveDoc), объектный монитор транзакций (MTS), компонентную модель (ActiveX) и др. Все составные части прекрасно соответствуют друг другу в рамках модели COM. Уникальной возможностью COM является универсальная технология доступа к базам данных – OLE DB/ADO.

               Потенциально COM могут поддерживать самые различные языки программирования. Добавление некоторых расширений или экспертов (wizard) в систему разработки позволит использовать для работы с COM любой язык программирования. В настоящий момент наиболее широко используются Visual Basic, C++ и Delphi.

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

               Передача данных между клиентом и сервером основана на наборе типов, которые называются OLE Automation types. В принципе, схема маршалинга (в том числе типы передаваемых данных) определяется парой стандартных интерфейсов COM. Реализовав по-своему некоторые из методов этих интерфейсов, можно определить свою схему маршалинга. Впрочем, это нетривиальная задача, и обычно разработчики используют уже готовую стандартную реализацию. Упаковка данных и их передача могут быть реализованы поверх различных сетевых протоколов.

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

1.5.1.2 CORBA

               [Common Object Request Broker Architecture] - модель общих, запрашиваемых у посредника, объектов, предложенная фирмой IBM.

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

               В настоящий момент CORBA не имеет своей собственной компонентной модели; работа над ней началась в 1998 г. и еще не завершена. Это главный серьезный недостаток. Пусть это не имеет практического значения для Java-программистов, но в общем случае эта та область, где OMG (и фирмам-производителям программного обеспечения) еще предстоит серьезно поработать.

1.5.1.3 Проблемы при разработке.

При разработке OPC-сервера программисту достаточно выполнять требования, применяемые для проектирования COM-объектов. Выполняя эти требования, откомпилированное приложение будет автоматически наполнено компилятором набором функций, необходимых для установления соединений с клиентами. С одной стороны это является достоинством, так как облегчает разработку. С другой стороны, это является недостатком, так как не дает программисту возможности дополнительной оптимизации исходного кода и скрывает реализацию клиент-серверного взаимодействия. Программист в данной ситуации полностью лишен возможности управления данным процессом. Ответственность за передачу данных полностью лежит на операционной системе.

При построении приложений в виде COM-объектов, вызовы их методов и передача данных лежат на операционной системе. Однако управление полученными данными, разделение данных между подключенными клиентами, управление данными, полученными от нескольких клиентов одновременно, данный процесс назван маршалингом, лежит на программисте. Таким образом, необходимо различать по времени прибытия данные, буферизировать их, передавать в управляющую систему в нужном порядке. Только правильно спроектированная процессная модель позволит предоставлять данные множественным клиентам и одновременно обслуживать подключенные управляющие устройства.

1.5.1.4 Ранее применяемые подходы.

До предложения технологии OPC разработчики контроллерных систем должны были представлять покупателю широкий набор драйверов своих устройств. При этом, для каждого устройства, имеющего свои особенности, необходимо было разрабатывать свои драйверы. В свою очередь, для обеспечения покупателю набора необходимых функций, было необходимо проектировать заказные приложения, либо искать не очень удобные пути сопряжения. Если рассматривать SCADA, то они разрабатывались для конкретного устройства, либо типа устройств. При использовании OPC возможно создание универсальных SCADA. Для этого необходимо наделить эти системы возможностью вызывать COM-объекты.

1.5.1.5 Сравнение технологий COM и CORBA

               Альтернативным OPC подходом является технология CORBA. Но альтернатива здесь в том, что вместо используемой OPC технологией DCOM, становится CORBA – Common Object Request Broker Architecture – технология построения распределенных объектных приложений. Данная технология аналогична по сути DCOM, но более развита в межмашинном взаимодействии. Например, для получения указателя на интерфейс и вызова метода удаленного компонента в DCOM необходимо явно указывать имя компьютера, на котором располагается компонент. Технология CORBA позволяет не указывать точное расположение компонента. Система берет на себя задачу поиска указанного компонента в сети. В отличии от DCOM, CORBA не поддерживается Microsoft. Из-за широкого использования Windows более актуальной является технология DCOM, так как ее поддержка встроена в ядро операционной системы.

               CORBA, в отличие от COM’а, является концепцией, а не ее реализацией. Когда мы говорим “COM”, то понимаем под этим скорее набор конкретных средств – элементов операционной системы, библиотек, утилит и т.п., являющихся составной частью того, что называется Microsoft Windows. Под термином “CORBA” понимается именно сложная и развитая концепция, сформулированная на уровне специального языка описаний – IDL. Реализации же этой концепции могут сильно отличаться друг от друга по различным критериям, наиболее важным в том или другом случае. Inprise/Corel VisiBroker и Application Server, BEA WebLogic, Iona Orbix, Oracle Application Server и “картриджи” Oracle, IBM BOSS – все эти продукты используют те или иные возможности CORBA. Технология Sun Enterpise JavaBeans создана поверх CORBA и использует такие ее возможности, как удаленный вызов объектов, службу имен, управление транзакциями. Реализация EJB фирмы Inprise связано с CORBA еще более тесным образом. Мы будем сравнивать COM и CORBA именно как концепции создания распределенных систем, а не как ту или иную их реализацию.

               При работе с реальным проектом необходимо учитывать область применения той или иной технологии. COM (как цельное и комплексное решение) способен функционировать только под Windows NT/Windows2000. Рассуждения о переносе COM на другие операционные системы в настоящий момент носят скорее рекламный характер. Ни компонентная модель COM (т.е. ActiveX), ни монитор транзакций (Microsoft Transaction Server, MTS) не способны работать нигде, кроме Windows, и сама Microsoft не проявляет никакой активности в этом напрвлении (вопросами переноса тех или иных элементов COM на другие платформы занимается консорциум Open Group).

               CORBA является многоплатформенным решением просто по определению.

               Помимо чисто технологических аспектов, при принятии решения необходимо оценить затраты на закупку необходимого программного обеспечения, его сопровождения и обучение персонала. COM (в отличие от CORBA) официально является бесплатной технологией. Вы получаете все необходимое, просто приобретя, например, Windows NT Server. (Кстати, сам факт конкуренции дорогостоящей технологии с “аналогичной”, но бесплатной, многое говорит об их технических возможностях).

               Наличие готовых серверов приложений, пригодных для решения вашей задачи. Если Вы можете решить свои проблемы, используя функциональность Microsoft Office, то ничего лучше COM вы, естественно, не найдете.

               Несмотря на внешнюю похожесть, что вызвано общностью решаемых задач, между COM и CORBA, пожалуй, больше различий, чем сходства. В большинстве случаев либо нецелесообразно использовать CORBA (для небольших и простых проектов под Windows просто по причине относительно высоких затрат на приобретение программного обеспечения, лицензий и пр.), либо практически невозможно использовать COM (для сложных, масштабируемых, высоконадежных проектов или просто при работе в гетерогенных средах, а не только в Windows). Windows-приложения, ориентированные на взаимодействие с Microsoft Office, всегда будут использовать COM; проекты с использованием Java и любых Java-технологий (кроме Microsoft J++), как говорится, “сам бог велел” строить на основе CORBA. Во многих случаях выбор технологии диктует выбор той или иной части проекта: если вы планируете работать, например, с ORACLE 8i, то, безусловно, гораздо лучше ориентироваться на CORBA.

               Обе технологии не испытывают особых проблем с точки зрения взаимодействия с языками программирования. Некоторые преимущества имеет CORBA – за счет более строгой стандартизации и более богатого выбора доступных средств разработки. В настоящий момент COM более законченная система, но на более низком уровне и при существенно большем количестве ограничений, определяемых самой концепцией системы. Помимо чисто технологических аспектов, при принятии решения необходимо оценить затраты на закупку необходимого программного обеспечения, его сопровождения и обучение персонала. Технология COM (в отличие от CORBA) официально является бесплатной. Вы получаете все необходимое, просто приобретя, например, Windows NT Server.

               На базе технологии построения компонентных объектов существует технология использования компонентов для предоставления данных между офисным (бизнес) уровнем и уровнем промышленных котроллеров. Данная технология названа OPC.

1.5.1.6 OPC

Какова экономическая целесообразность применения ОРС, т.е. соотношения затрат на построение единой информационной системы с возможным экономическим эффектом от интеграции? Промышленно развитые страны столкнулись с этими вопросами значительно раньше, что и спровоцировало появление первого единого стандарта для организации сбора и передачи данных в системах промышленной автоматизации – ОРС, позволяющего полностью решить проблему несовместимости интерфейсов и протоколов обмена данными при объединении разнородных АСУ ТП.

В 1994 г., под эгидой Microsoft была создана организация OPC Foundation (http://www.opcfoundation.org). Как определяет сама OPC Foundation, ее цель —разработка и поддержка открытых промышленных стандартов, регламентирующих методы обмена данными в режиме реального времени между клиентами на базе ПК и ОС Microsoft.

OPC (OLE for Process Control) – промышленный коммуникационный стандарт, созданный консорциумом производителей оборудования и программного обеспечения при участии Microsoft. Этот стандарт описывает интерфейс обмена данными между устройствами управления технологическими процессами. Главной целью было предоставить разработчикам систем автоматизации некоторую независимость от конкретного типа контроллеров. OPC основывается на технологии распределенных компонентных объектов OLE/COM/DCOM компании Microsoft, Inc. , устанавливает требования к классам объектов доступа к данным и их специализированным (custom) интерфейсам для использования разработчиками клиентских и серверных приложений. Для обмена данными с приложениями-клиентами, разработка которых ведется на языках типа MS Visual Basic, а также с популярными приложениями типа Excel, спецификация OPC содержит дополнительные, но необязательные для реализации требования к интерфейсу OLE-автоматизации (OLE-Automation).

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

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

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

OPC (OLE for Process Control) – это также стандарт взаимодействия между программными компонентами системы сбора данных и управления (SCADA). Через интерфейсы OPC одни приложения могут читать или записывать данные в другие приложения, обмениваться событиями, оповещать друг друга о нештатных ситуациях (тревогах), осуществлять доступ к данным, зарегистрированным в архивах (так называемые «исторические» данные). Эти приложения могут располагаться как на одном компьютере, так и быть распределенными по сети, при этом независимо от фирмы поставщика стандарт OLE for Process Control, признанный и поддерживаемый всеми ведущими фирмами производителями SCADA систем и оборудования, обеспечит их совместное функционирование.
Еще раз отметим основные причины создания OPC.

Довольно много программ-клиентов может получать данные из различных источников и делать их доступными для драйверов независимых разработчиков. Но при этом возникают следующие проблемы:

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

Широкое распространение технологии OPC в промышленности имеет следующие преимущества:

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

Рисунок 1.5a: Пример схемы работы «множества различных драйверов» …

... and its OPC solution

Рисунок 1.5.b: … и решения на базе OPC

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

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

Технология OPC позволяет различным программным модулям, разработанным самостоятельно или другими компаниями, взаимодействовать друг с другом через унифицированный интерфейс. Стандарт OPC описывает два типа интерфейсов для приложений. Первый тип интерфейса предназначен для обмена большими объёмами информации при высокой пропускной способности. Это специализированный интерфейс OLE custom interface. Второй тип интерфейса – OLE Automation interface – позволяет получать доступ к данным более простым способом. Он предназначен для использования в программах, написанных на языках Visual Basic (VB) и Visual Basic для приложений (VBA).

               Проектирование OPC серверов может осуществляться на базе технологии CORBA, хотя эта технология используется реже, COM/DCOM.

            OPC в основном используется там, где установлен Microsoft СОМ/DCOM:

большинство Unix-подобных ОС, включая Linux; поддерживается фирмой GE Software;
все Windows, начиная с Windows 95. Это обеспечивается самой компанией Microsoft;
ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver; имеется поддержка OPC, встроенная в систему разработки Tornado.

               Если COM/DCOM не поддерживается операционной системой контроллера (а большинство операционных систем реального времени не поддерживают), то OPC-сервер должен работать не на контроллере, а на другом компьютере. В этом случае он обменивается с контроллером по своему внутреннему протоколу, становясь, по сути дела, промежуточным программным обеспечением (middleware), единственное назначение которого – организация обмена данными между OPC-клиентами и программами контроллера. По такому принципу организовано большинство OPC-серверов.
            В то же время контроль за «устареванием» данных имеется: каждое передаваемое значение (тег) сопровождается меткой времени происхождения (timestamp). Несмотря на то, что требования жесткого реального времени, строго говоря, не выполняются, реальная частота передачи данных порядка 50 миллисекунд достигается без каких либо специальных мер. Не следует думать, что любое устройство можно просто так «через OPC» подключить к любой SCADA системе, – для этого надо иметь OPC сервер.



Особый класс OPC приложений представляют собой OPC серверы конкретных аппаратных устройств – они поставляются многими производителями аппаратуры. OPC сервер создает своего рода абстракцию аппаратуры, позволяя любому OPC клиенту записывать и считывать данные с устройства. Устройство, для которого есть OPC сервер, может использоваться вместе с любой современной SCADA системой. Теперь у пользователя – системного интегратора или разработчика АСУ ТП—появилась возможность выбирать оптимальные для своей системы компоненты, а не ориентироваться, как раньше, целиком на «монолитные» решения, предлагаемые тем или иным поставщиком (рис.1.7.)
1.5.1.7. ОРС – спецификации и стандарты

            Стандарт OPC разрабатывает OPC Foundation – добровольная международная организация, расположенная в Boca Raton, (Флорида, США), насчитывающая более 500 членов, среди которых Siemens, FisherRosemount, Honeywell, Rockwell, Iconics, Wonderware, Intellution и др., то есть практически все известные компании производители SCADA-систем и оборудования для систем промышленной автоматизации. Microsoft, Inc. Также является членом OPC Foundation, принимая участие в разработке новых спецификаций. Техническая деятельность OPC Foundation осуществляется в рабочих группах по направлениям. Среди этих направлений:

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

Ø      обработка тревог и событий (OPCAlarms and Events Working Group);

Ø      защита данных (OPC Security WorkingGroup);

Ø      подтверждение соответствия стандартам OPC (OPC Compliance WorkingGroup);

Ø      доступ к историческим (архивным) данным (OPC Historical Working Group);

Ø      выбор и поддержка среди них языка общения Windows CE (OPC Windows CE Working Group);



OPC Foundation определяет направления, по которым ведутся разработки, и создаёт по этим направлениям комитеты. Комитеты делают следующее:

·   разрабатывают спецификации COM-интерфейсов и COM-объектов;

·   присваивают им GUID;

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

·   генерируют или создают вспомогательные файлы: idl-, h- и c-файлы для Custom-интерфейса; библиотеки типов для интерфейса автоматизации; заместители (proxy) и заглушки (stub) для поддержки межпроцессорного взаимодействия;

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

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

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

·                     Спецификация OPC Data Access 1.0 и 2.0 – доступ к данным реального времени;

·                     Спецификация ОРС Alarms and Events – обработка тревог и событий;

·                     Спецификация ОРС Historical Data Access – доступ к историческим данным;

§                     Спецификация ОРС Batch – отправляет рецепты дозирования в технологический процесс и отслеживает их выполнение.

            Сейчас в разработке находятся еще две спецификации:

§                     OPC Data Access 3.0

§                     OPC XML

OPC серверов тоже может быть, сколько спецификаций, хотя не возбраняется совмещать все эти функции в одном OPC

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

OPC Common Definitions and Interfaces — общие для всех OPC-спецификаций интерфейсы.

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

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

OPC
Batch
Custom
Interface
Specification — спецификация COM-интерфейсов конфигурирования оборудования, программирование на C++.

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

OPC
Alarms
and
Events
Custom
Interface
Specification — спецификация COM-интерфейсов для обслуживания событий (event) и нештатных ситуаций (alarm), программирование на C++.

OPC
Alarm
and
Events
Automation
Interface
Specification – спецификация COM-интерфейсов для обслуживания событий и нештатных ситуаций, программирование на языках типа Visual Basic.

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

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

OPC
Security
Custom
Interface — спецификация COM-интерфейсов для обработки прав доступа к данным, программирование на C++.

1.5.2 Пользователи OPC

Рис.1.7.

1.5.2.1 OPC-сервер

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

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

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

Перечень необходимых действий для обеспечения продукта стандартным интерфейсом:

Получить нужную спецификацию и прилагаемые программные компоненты.

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

Найти опытного программиста на Visual Studio, который с помощью ATL-библиотеки (библиотеки активных шаблонов) реализует требуемые интерфейсы, а значит, и OPC-сервер.

Можно приобрести один из комплектов инструментальных средств (Toolkit).

1.5.2.2 OPC-клиент

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

Что же требуется от производителя ПО офисного уровня, если он задумал обеспечить свой продукт стандартным интерфейсом?

Ø                  Получить нужную спецификацию и прилагаемые программные компоненты.

Ø                  Изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-клиента.

Ø                  Нанять опытного программиста на Visual Studio, чтобы тот с помощью ATL-библиотеки реализовал требуемые интерфейсы (OPC-клиент для Custom-интерфейса).

Ø                  Можно использовать Visual Basic или, скажем, Delphi, и тогда будет создан OPC-клиент для интерфейса автоматизации (если она предусмотрена для данной спецификации). Сэкономить на квалификации программиста помогает Toolkit.

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

Установление соединения между клиентом и сервером на одном компьютере

Установочная программа автоматически производит регистрацию сервера (запись соответствующей информации в системные реестр). Программы-клиенты, как правило, имеют соответсвующий пользовательский интерфейс, позволяющий выбрать из списка зарегестрированных серверов нужный (при этом, если сервер не активен, он автоматически запустится), пролистать его адресное пространство и подписаться на необходимые тэги. Таким образом, для обеспечения соединения на одной машине каких-либо специальных настроек (кроме установки сервера и клиентского программного обеспечения, например SCADA-системы) производить не нужно.

Установление соединения между клиентом и удаленным сервером

Для работы в сети (клиент и сервер на разных компьютерах) необходимо присутствие в сети хотя бы одной станции с установленной Windows NT (Server или Workstation). Станция с Windows NT используется в качестве сервера авторизации и аутентификации, при этом сам OPC-сервер может располагаться как на ней, так и на другой сетевой станции. Перед установлением соединения между приложением-клиентом и удаленным сервером следует произвести настройку системных компонентов DCOM

1.5.2.3. ОРС Data Access.

               Чтобы лучше почувствовать, что такое OPC, необходимо рассмотреть подробнее главный, по большому счету, стандарт Data Access (DA), предназначенный для поставки оперативных данных от оборудования и/или к оборудованию (термин “OPC” часто используют как синоним OPC DA). Для DA реализованы спецификации как пользовательского интерфейса, так интерфейса автоматизации. Как функциональный интерфейс, последний ничем не отличается от пользовательского, за исключением того, что не позволяет одновременно работать с несколькими OPC-серверами и к нему добавлен упомянутый выше COM-интерфейс IDispatch, обязательный в OLE Automation. Это позволило OPC Foundation издать "обертку" (wrapper) в виде dll, преобразующую один интерфейс в другой. Таким образом, разработчик OPC-сервера заботится только о Custom-интерфейсе, а если клиент предпочитает автоматный интерфейс, он использует эту библиотеку в качестве переводчика.

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

            Спецификации OPC Data Access 1.0 и 2.0 являются основными и наиболее популярными спецификациями среди используемых в OPC-серверах и клиентах. Они применяются для получения следующих типов данных:

§               Данные, полученные от датчиков в реальном времени (температура, давление, проток и т.п.);

§               Управляющие воздействия (открыть, закрыть, старт, стоп и т.п.);

§               Информация о текущем состоянии оборудования и исполнительных программ систем и подсистем.

OPC-сервер Data Access объединяет следующие типы объектов (Рисунок 1.8 ): OPC-сервер, OPC-группа, и OPC-ячейка. OPC-сервер обеспечивает информацией реальный сервер и является хранилищем всех данных. ОРС-группа обеспечивает информацией участников группы и предоставляет механизм обновления и логической организации ОРС-ячеек. ОРС-ячейки обеспечивают связь источника данных с сервером. Это означает, что ОРС-ячейка не представляет реальный источник данных, но содержит соответствующий адрес в конфигурации сервера (ItemID).

Object model for the OPC Data Access Server

Рис. 1.8. Объектная модель OPC-сервера Data Access.
Для каждого OPC-клиента, OPC-сервер формирует объект типа OPC-сервер и создает специальный (безраздельный) коммуникационный канал (thread). Это защищает обмен данными от влияния других OPC-клиентов и повышает производительность OPC-сервера.

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

OPC-группы создаются динамически, согласно требованиям текущего приложения (Клиента) по списку тэгов и их свойств. В зависимости от этих требований может варьироваться как содержание группы, так и число включенных в нее OPC-ячеек по ходу связи. Однако это не влияет на систему управления (PLC).

В отличии от OPC-группы и OPC-сервера, OPC-ячейка не поддерживает OPC-интерфейс и не является, таким образом, COM-объектом (Component Object Model). Это внутренний объект OPC-сервера, который содержит важную информацию о запросах OPC-клиента (например, тип данных, использующихся для загрузки значений, или состояние (активное или пассивное) запрашиваемых значений и т.п.).

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

ItemID – уникальный идентификатор тэга и используется OPC-клиентом для связи с OPC-сервером. ItemID представляет собой последовательность имен всех уровней конфигурации. Например, в трехуровневой конфигурации OPC-сервер, разработанный для электрической подстанции ItemID будет выглядеть так: имя_станции.имя_буфера.имя_ячейки. Если OPC-клиент использует интерфейс IOPCBrowseServerAddressSpace, для него не составляет труда получить правильные ItemID и использовать их в своей конфигурации.

На рисунке 1.9. показаны стандартные компоненты OPC-сервера, определенные спецификацией OPC Data Access. На нижнем уровне находится I/O driver, который передает данные от подключенных физических устройств (например, ПЛК). Другая часть OPC-сервера -это оптимизированная система блочного сбора данных, которая поддерживает максимальную производительность канала обмена данными с контроллером. При помощи соответствующего интерфейса спецификации OPC Data Access, полученные данные передаются OPC-клиенту.

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

Components of a typical OPC Data Access Server

Рис. 1.9. Компоненты типового OPC-сервера Data Access.



Повторим основные моменты стандарта OPC-DA.
            ОРС Data Access. Стандарт DA предназначен для поставки оперативных данных от оборудования и/или к оборудованию. Для стандарта DA реализованы спецификации как Custom-интерфейса, так интерфейса Автоматизации. С точки зрения функциональных интерфейсов, последний ничем не отличается от Custom, кроме того, что не позволяет одновременно работать с несколькими OPC- серверами и добавлен COM-интерфейс IDispatch, обязательный в OLE Automation. Это позволило OPC Foundation издать обёртку (wrapper) в виде dll, преобразующую один интерфейс в другой. Стандарт DA имеет две версии интерфейсов: 1.0 и 2.0. Как мы уже знаем, с точки зрения COM, это самостоятельные спецификации. OPC-клиент предварительно запрашивает, может ли он работать с нужным ему COM-интерфейсом в используемом OPC-сервере. С точки зрения функциональности, в версии 2.0 механизм уведомления клиента приведён к стандартному механизму COM/DCOM, что упрощает программирование.

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

            Свойства. Каждая переменная обладает свойствами. Различаются обязательные свойства, рекомендуемые и пользовательские. Обязательными свойствами, понятно, обязана обладать каждая переменная. Это, во-первых, текущее значение переменной, тип переменной и права доступа (чтение и/или запись). Во-вторых, очень важные свойства - качество переменной и метка времени. Технология OPC ориентирована на работу с оборудованием, а оборудование может давать сбои, так что корректное значение переменной не всегда известно OPC-серверу, о чём и уведомляется клиент через качество. Качество—это код, содержащий в себе грубую оценку достоверности параметра—UNCERTAIN, GOOD и BAD (не определено, хорошее и плохое), а на случай плохой оценки — еще и расшифровку, например, QUAL_SENSOR_FAILURE – неисправность датчика. Метка времени (timestamp) сообщает о том, когда переменная получила данное значение и/или качество. Время предоставляется со 100-наносекундной точностью (на самом деле это FILETIME Win32 API). Реальная точность измерения времени обычно бывает хуже и , в общем случае, зависит от реализации сервера и аппаратуры.

            Ещё одним обязательным свойством является частота опроса переменной OPC-сервером. Все данные в группе сервер старается обновлять и передавать клиенту с заданной частотой. Не совсем понятно, почему это свойство объявлено обязательным, так как не все OPC-серверы работают в режиме опроса оборудования. Поэтому существуют серверы, не реализующие это свойство.

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

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

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

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

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

            Получение данных.Существует три основных способа получения OPC-клиентом данных от OPC-сервера: синхронное чтение, асинхронное чтение и подписка. При синхронном чтении клиент посылает серверу запрос со списком интересующих его переменных и ждёт, когда сервер его выполнит. При асинхронном чтении клиент посылает серверу запрос, а сам продолжает работать. Когда сервер выполнил запрос, клиент получает уведомление (через

интерфейс соответствующего COM-объекта, реализованного в клиенте!). И, наконец, в случае подписки клиент передаёт серверу список интересующих его переменных, а сервер затем регулярно присылает клиенту информацию об изменившихся переменных из этого списка (опять же, через интерфейс соответствующего COM-объекта клиента!). Эти списки в терминологии OPC называются группами. Каждый клиент может поддерживать много групп с разной скоростью обновления.

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

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

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

Проблемы.     Есть очень много сложных вопросов, которые придётся решить при программировании OPC-интерфейсов. Во-первых, само программирование COM не такое уж незатейливое, даже с применением ATL. Во-вторых, сами OPC-объекты и их OPC-интерфейсы достаточно сложны и громоздки. Есть где потрудиться. И, в-третьих, есть вопросы системного уровня, которыми нужно владеть. Очень схематично: фабрики класса (новый COM-термин!), заглушки и заместители, апартаменты (новый COM-термин!), асинхронный обмен, многозадачность, синхронизация, память. Кстати, последний вопрос весьма актуальный, так как в COM допускается (и сплошь и рядом в OPC используется) выделение памяти в сервере, а удаление её возлагается на клиента. Малейшая неточность, и пойдут трудно устранимые утечки памяти. А, учитывая, что OPC-сервер обычно должен работать стационарно, рано или поздно крах системы неизбежен.

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

нижний уровень полевые шины (fieldbus) и отдельные контроллеры;
средний уровень цеховые сети;
уровень АСУ ТП уровень работы систем типа SCADA;
уровень АСУ П уровень приложений управления ресурсами предприятия.

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

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

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

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

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

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

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

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

Производители оборудования
     В настоящее время широкое распространение получили стандарты OPC DA(стандарт передачи данных в реальном времени), OPC HDA(стандарт по работе с историческими значениями), OPC A&E(стандарт на тревоги и события) . Можно сказать, что сейчас почти все производители снабжают свои продукты OPC-серверам
Список потенциальных изготовителей OPC-серверов неограничен. OPC-сервером можно снабдить контроллер, плату ввода/вывода, адаптер полевой шины, программу пересчета, генератор случайных чисел, что угодно, лишь бы это устройство поставляло или принимало данные. Но все-таки здесь речь идет в первую очередь о программном обеспечении для более низкого уровня в системах автоматизации.

Что необходимо сделать производителю, если он решил обеспечить свой продукт стандартным интерфейсом?

Сначала он должен получить нужную спецификацию и прилагаемые программные компоненты, затем изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-сервера, и, наконец, посадить самого опытного программиста за Visual Studio, который с помощью ATL-библиотеки реализует требуемые интерфейсы, а значит, и OPC-сервер. Это все. Можно только добавить, что если он не хочет использовать самого опытного программиста, ему придется купить какой-нибудь комплект инструментальных средств (Toolkit).

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

Что же требуется от производителя “верхнего” ПО, если он задумал обеспечить свой продукт стандартным интерфейсом? Как и в предыдущем случае, ему надо получить нужную спецификацию и прилагаемые программные компоненты. Затем он должен изучить COM-интерфейсы тех COM-объектов этой спецификации, которые относятся в ней к модели OPC-клиента, и только после этого посадить достаточно опытного программиста за Visual Studio, чтобы тот с помощью ATL-библиотеки реализовал требуемые интерфейсы, а значит, и OPC-клиент для Custom- интерфейса. Можно использовать Visual Basic или, скажем, Delphi, и тогда будет создан OPC-клиент для интерфейса автоматизации (если она предусмотрена для данной спецификации). По-прежнему, сэкономить на квалификации программиста помогает Toolkit.
Структура взаимодействия между приложениями-клиентами и серверами OPC различных производителей показана на рис. 1.12 а, б.

А)

Б)

Рис. 1.12. Взаимодействия между приложениями-клиентами и OPC-серверами.
Опираясь на объектную технологию COM/DCOM, стандарт OPC фиксирует определенную модель взаимодействия между клиентом и сервером.

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

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

Элементы в группе, таким образом, - это своего рода клиентские ссылки на некие реальные переменные (тэги), находящиеся на сервере или в физическом устройстве. Понятие тэга спецификацией OPC не определяется, но подразумевается неявно. Элементы в группу клиент добавляет по имени, и эти имена являются именами соответствующих тэгов. Клиент может либо знать нужные имена заранее, либо запросить список имен тэгов у сервера. Для запроса имен тэгов служит интерфейс IOPCBrowseServerAddressSpace, с помощью которого сервер описывает клиенту свое "пространство имен", организованное в общем случае иерархически. Пример полного имени тэга: Устройство1.Модуль5.АналоговыйВход3. При добавлении элемента в группу клиент всегда указывает это полное имя. Заметим, что группы, создаваемые клиентом, не обязаны совпадать (и, как правило, не совпадают) с подразделами пространства имен сервера, элементы в группу добавляются в "разнобой". Единственное, что их объединяет - это общая частота обновления и синхронность отправки клиенту.

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

            Реализация OPC основана на объектной модели COM/DCOM фирмы Microsoft. COM — это Component ObjectModel – модель много компонентных объектов, позволяющая приложению манипулировать удаленными программными объектами, точнее, вызывать те или иные функции (методы) этих объектов так, как будто объекты находятся «рядом». Объект может находиться и в самом деле рядом (в адресном пространстве приложения) – тогда это просто COM. Если же объект находится в другой программе на том же компьютере или на другом узле сети, то это DCOM –Distributed (распределенная) COM. ее сетевое расширение DCOM

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

            OPC взаимодействие основано на клиент серверной схеме. OPC клиент (например, SCADA), вызывая определенные функции объекта OPC сервера, подписывается на получение определенных данных с определенной частотой. В свою очередь, OPC сервер, опросив физическое устройство, вызывает известные функции клиента, уведомляя его о получении данных и вручая сами данные. Таким образом, при OPC взаимодействии используются как прямые COM вызовы (от клиента к серверу), таки обратные (callback, от сервера к клиенту). Это надо учитывать при настройках безопасности DCOM в Windows NT: если клиент «видит» данные, но не получает их, значит, скорее всего, система безопасности NT блокировала обратные вызовы. Стандарт OPC, в отличие, например, от устаревшего DDE (Dynamic Data Exchange), хотя и основан на универсальном фундаменте – COM/DCOM, разрабатывался специально для использования в промышленной автоматизации, поэтому он имеет вполне содержательную концептуальную сторону, то есть, на самом деле, свою проблемно ориентированную модель взаимодействия, которая и реализована через совокупность COM интерфейсов. Эта концептуальная сторона в известной степени независима и представляет самый большой интерес, особенно для пользователя не программиста, для которого тонкости реализации СОМ интерфейсов не столь важны. В принципе, основные идеи OPC могли бы быть реализованы и с помощью других объектных технологий (получилось бы что нибудь вроде CORBA for Process Control, например), однако распространенность Windows платформ предопределила выбор в пользу стандартов Microsoft.

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

               Технология OPC регламентирует только интерфейс между OPC-клиентами и OPC-серверами (как и положено в технологии клиент-сервер, допускаются множественные подсоединения). И она абсолютно не регламентирует способ получения этих данных от оборудования! Разработчик сам определяет, где и как их брать. Но, тем не менее, есть некоторые разумные, с точки зрения разработчиков OPC, модели взаимодействия с оборудованием. Для их рационального обслуживания предлагаются соответствующие механизмы. Например, можно попросить OPC-сервер получать данные не напрямую, а извлекать их из своего внутреннего буфера (кэша). Разумеется, если сервер не делает кэширования, он вправе эту просьбу "игнорировать".

               Переменные в OPC-сервере могут быть представлены либо в виде простого списка, либо в виде дерева, напоминающего дерево файлов на диске (только вместо термина “папка” в OPC говорят “ветвь”). И есть соответствующие интерфейсы для навигации по этому дереву, позволяющие, в частности, в любой момент запросить дерево переменных, поддерживаемых OPC-сервером. Если оборудование допускает, дерево может изменяться динамически. Впрочем, если быть до конца точными, интерфейс для просмотра дерева объявлен в OPC-спецификации как необязательный. Тем не менее, он настолько удобен, что практически все OPC-серверы его реализуют.

               Кроме того, есть механизм оповещения о завершении работы OPC-сервера, запроса информации о самом сервере и списка зарегистрированных групп. В общем, разработчики OPC-спецификаций предусмотрели многое для облегчения организации взаимодействия поставщика данных (OPC-сервера) и потребителя данных (OPC-клиента). Однако цель этого раздела — описание не DA-интерфейсов, а того, как OPC ориентируется именно на работу с оборудованием, в частности на обмен данными.

               Коммуникационный стандарт OPC позволяет использовать его для обмена данными в индустриальных информационных системах (Рис.1.13). В нижней части рисунка (Field
Management), показаны три компьютера с установленными OPC
-серверами, которые поддерживают различные спецификации OPC (см. далее). Каждый компьютер может иметь OPC-сервера с различными спецификациями. Существуют сервера, которые обмениваются данными с АСУ, построенной на ПЛК. Они разработаны на базе коммуникационного протокола (например, AS511, RK512, S-bus, Modbus, DF1 и т.д.), и "распознаются" подключенным оборудованием (например, ПЛК). Доступ к протоколам, хранящимся в базе данных, обеспечивается OPC-серверами, соответствующими спецификациям OPC Historical Data Access.

Рис.1.13: Архитектура OPC-клиент/ OPC-сервер в промышленной информационной системе.
            В центральной части иллюстрации (Process
Management) показаны еще три компьютера. На этих компьютерах установлен OPC-клиент – программа диспетчеризации – SCADA HMI (Supervisory
Control
And
Data
Acquisition
Human
Machine
Interface). Соединение с OPC-серверами происходит через локальную сеть (LAN), что расширяет возможности в построении топологии сбора данных при помощи OPC-серверов.

            OPC-серверы опираются на коммуникационный протокол представленного оборудования (например, ПЛК). Не смотря на попытки увеличить в коммуникациях долю стандартных протоколов (Profibus, Interbus, CANBus и т.д.), сейчас трудно сказать, на основании чего лучше строить системы обмена данными: на базе специфических протоколов производителей оборудования или более стандартных протоколов полевых шин. По этой причине номенклатура OPC-серверов практически копирует номенклатуру наиболее популярных систем автоматического управления.

            В дальнейшем данные могут подыматься выше уровня Process
Management для использования в системах управления и планирования производством, например ERP
(Enterprise
Resource
Planning
) или MES
(Manufacturing
Execution
Systems
) на уровне Business
Management. Это позволяет использовать реальные данные всеми подразделениями предприятия, которые в них нуждаются.

            Рис. 1.13 демонстрирует пример связи OPC-сервера и OPC-клиента при использовании одной OPC спецификации. Однако в спецификации OPC Data Access необходимо следить за использованием версии данной спецификации: сервер OPC Data Access 1.0 может общаться только с клиентом OPC Data Access 1.0 client. Поэтому удобней, если OPC-сервер поддерживает несколько версий OPC-спецификации.

            Программирование. Существует несколько языков программирования для написания клиентской программы: C/C++, Visual Basic, Delphi и т.д.. Чтобы соответствовать современным требованиям к средам разработки, спецификации OPC содержат 2 различных подхода к написанию OPC-клиента. Для внедрения его в программу, написанную на C/C++, используется Custom
interface, а для программ на Visual Basic, используется Automation
interface. В основном, OPC-сервера пишутся на C/C++. Для установки надежного соединения между OPC-сервером и OPC-клиентом, написанными на разных языках, используется OPC
Automation
Wrapper. Он организует взаимосвязь между OPC-сервером, написанным на C/C++ и приложением на Visual Basic (рис. 1.14).

Рис. 1.14: Схема использования OPC Automation Interface Wrapper
    OPC и Internet. В настоящее время, OPC Foundation разрабатывает новую спецификацию – OPC XML. Ее цель – разработать гибкий и удобный интерфейс для обмена данными через OPC, используя XML (Extensible Markup Language) в приложениях Internet/Intranet. Функции XML позволяют очень легко записывать любые структуры данных и, в то же время, передавать данные в виде XML-файлов, удобных для пересылки через Internet.

OPC
и управление дозированием. OPC
Batch – другая спецификация OPC, которая уже широко применяется в автоматике. Ее используют для посылки пропорций дозирования в технологические процессы и отслеживания выполнения этих пропорций (лабораторные системы, дозаторы, весовые системы и т.п.). Очень важный факт состоит в том, что каждый OPC Batch сервер (клиент) одновременно является OPC Data Access 2.0 сервером (клиентом). Другими словами, OPC Batch сервер (клиент) включает в себя, кроме спецификации OPC Batch, также и спецификацию OPC Data Access 2.0, включая некоторые дополнительные интерфейсы (например, загрузка переменных).

Операционные системы. Один из необходимых компонентов для работы OPC-коммуникаций – COM и его сетевая версия DCOM. DCOM – стандартный компонент для операционных систем Windows NT 4.0, Windows 2000 и Windows 98. Для работы в Windows 95 DCOM нужно установить. Все эти операционные системы позволяют передавать данные в рамках одного компьютера или через локальную сеть. В Windows CE сетевые возможности появились в версии 3.0. Сейчас стандарт OPC был разработан и для операционной системы Linux.
Связь OPC
-сервера с процессом. Первый шаг в конфигурации OPC-клиента – установить на компьютер OPC-сервер (локальный или сетевой). При установлении связи OPC-сервера к OPC-клиенту, технология COM предоставляет механизм сканирования доступных OPC-серверов на указанном компьютере. Это позволяет быстро установить соединение с OPC-сервером. Это сканирование называется OPC
server
browsing.

            Второй шаг – это связать данные из конфигурации OPC-сервера с конфигурацией OPC-клиента. Обеспечивается это с помощью загрузки данных, которая поддерживается и OPC-сервером и OPC-клиентом. После этого необходимо связать данные из OPC-клиента с данными из OPC-сервера по адресному пространству. Если OPC-сервер или OPC-клиент не поддерживают загрузку данных/item
browsing, конфигурирование OPC-клиента превращается в довольно длительную работу.

Динамическое добавление данных/Dynamic
adding
of
items предоставляет еще более удобную методику конфигурирования OPC-клиента. С ее помощью можно создавать (или удалять) и сразу же устанавливать связь с новыми источниками данных в OPC-сервере, не останавливая ни сервер, ни клиент. В настоящее время, эта функция реализована всего в нескольких OPC серверах (клиентах), но удобство, которая она предоставляет при конфигурировании OPC-клиента, должно привести

1.5.4. Выводы

          Какое же будущее у технологии OPC? OPC-сервера включаются в оборудование все большего числа производителей. В то же время, увеличивается число разработчиков систем автоматизации, которые поддерживают сбор данных через OPC-сервер с помощью собственных OPC-клиентов. И если так пойдет и дальше, то технология OPC постепенно станет всемирным стандартом для обмена данными в промышленных информационных системах.
            Технология OPC предлагает стандарты для обмена технологическими данными, в которые заложены самые широкие возможности. Учитывая большой авторитет вовлечённых в эту деятельность фирм, включая саму Microsoft, можно ожидать, что технология OPC будет набирать силу. И это перспективная технология для использования её в интеграции разнородных систем. Хотя процесс становления ещё далеко не завершён и есть много проблем, которые предстоит решить.

               Оптимальным решением данной задачи является создание OPC-сервера на базе технологии COM. Данные технологии открыты и документированы. Нет необходимости для приобретения дорогостоящих реализаций, например, CORBA для Microsoft Windows, что значительно снижает стоимость разработки программного обеспечения. Из-за широкого использования возможностей операционной системы значительно облегчается разработка данного программного продукта. При создании исходных кодов существует возможность широко использовать возможности среды Visual C++ для автоматической генерации классов и интерфейсов, что сокращает сроки разработки.

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

1.6 Структура программного обеспечения сервера OPC Modbus

               В программное обеспечение сервера OPC Modbus входят:

Ø      Модуль поддержки Modbus/TCP

Ø      Модуль поддержки TCP/IP

Ø      Функции управления потоками данных от устройств

Ø      Функции поддержки обслуживания запросов от многих клиентов

Ø      Организация поддержки удаленных подключений

Ø      Организация интерфейса пользователя для администрирования сервера
               Модуль поддержки TCP/IP предназначен для организации поддержки протокола TCP/IP, на базе которого функционирует Modbus/TCP. Создание и распаковка IP пакетов, управление IP адресацией. Обработка ошибок передачи лежит на операционной системе. В функции модуля Modbus входит организация обмена данными с устройствами Modbus: создание и распаковка пакетов Modbus, организация обработки ошибок устройств, управление адресацией Modbus.

               Под удаленными подключениями подразумевается обслуживание OPC клиентов, работающих не в рамках компьютера, содержащего OPC сервер. Данная возможность обусловлена использованием технологии DCOM при построении OPC сервера.

1.7 Средства реализации

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

Программирование COM нетривиальный труд, даже с применением ATL. OPC-объекты и их OPC-интерфейсы достаточно сложны и громоздки.

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

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

               Типичный инструментарий представляет собой библиотеку, состоящую из OPC-объектов выбранной спецификации. Разработчику же, например, OPC-сервера, предлагается некий набор вызовов, достаточно простых (read, write), которые необходимо подключить к своему оборудованию для доступа к его данным. Эти функции могут быть реализованы как виртуальные функции некоторого класса, их нужно перегрузить в своем приложении. Так устроен, например, инструментарий фирмы Factory Soft (http://www.factorysoft.com/).

1.8 Средства тестирования и верификации

               Тестирование и верификация включают в себя определение протокольной истинности для модуля Modbus. Для этого используются устройства Modbus/TCP. Разработка одного из устройств, работающего в сети Modbus ведется в раках дипломного проекта студентом этого потока. Для установления корректности работы OPC сервера можно использовать готовые OPC клиенты, примеры которых свободно распространяются через сеть Internet производителями OPC серверов. Примерами таких программ являются Automated Solution Inc OPC client, Microsoft Excel OPC client, Visual Basic client и др.

               Определение производительности сервера заключается в исследовании на практике, какое количество устройств может обслуживать сервер, при отсутствии коллизий и определение реального количества клиентов, которое может быть подключено к серверу и нормально обслуживаться. Также необходимо определить, как влияет количество подключенных устройств и количество подключенных клиентов на загрузку сервером оперативной памяти и центрального процессора. Для этих целей можно использовать стандартные для операционных систем Windows NT, 2000 средства: диспетчер задач, монитор производительности.
1.9. Производительность ОРС-систем(данные 1999 года).

            Затраты ресурсов компьютера на поддержку OPC взаимодействия и предельно достижимая интенсивность обмена между клиентом и сервером зависят от ряда факторов, но прежде всего –от того, находится ли сервер непосредственно в адресном пространстве клиента (так называемый внутри задачный— InProcess Server) или он является самостоятельным приложением. В последнем случае важно, расположен сервер на том же компьютере, что и клиент, или на другой станции локальной сети. Третий по важности фактор – это возможность группировки данных для отправки клиентам. Так, передача раз в секунду 100 тегов займет значительно меньше ресурсов, чем одного тега через каждые 10 миллисекунд. Предельная пропускная способность внутри задачного сервера может достигать (здесь и далее – на компьютере с процессором Pentium233) 1 млн. элементов OPC в секунду(данные на 1999 г.) что значительно превышает все мыслимые реальные потребности.

            Однако не все OPC серверы имеют внутри задачный (InProcess) вариант – для этого они должны оформляться как динамические библиотеки (DLL), а не как самостоятельные программы. В случае локального сервера (отдельная программа, но на том же компьютере) пропускная способность колеблется примерно от 3 до 60тысяч элементов в секунду. Наихудший вариант соответствует передаче единственного элемента с максимальной частотой, наилучший – передаче одновременно 100 или более элементов с соответственно меньшей частотой. Наконец, для удаленного сервера (в сети Ethernet 10Base–T) пропускная способность оказалась заключена в пределах 330 – 7000 элементов в секунду (наилучший и наихудший варианты соответствуют тем же самым крайним случаям).

            Не следует придавать приведенным цифрам абсолютное значение – они могут варьироваться в зависимости от системной конфигурации, а также особенностей реализации сервера и клиента. Так, по данным RockwellAutomation, OPC сервер (отдельное приложение, не внутризадачный) может обеспечить обмен с сетевыми клиентами до 200000 элементов в секунду. С другой стороны, столь оптимистические оценки могут быть резко снижены за счет ресурсоемкости обмена с реальной аппаратурой – коммуникационными портами, интерфейсными модулями и т.п., что, конечно, не учитывалось в тестовых экспериментах, поскольку не имеет прямого отношения к OPC. С точки зрения программной реализации, важно, насколько сервер использует многопоточность (multithreading), в частности, для обслуживания различных групп, а также производится ли кэширование значений тегов с целью минимизации количества запросов к аппаратуре
1.10. SCADA системы и OPC

               Как уже говорилось, практически все производители SCADA систем поддерживают OLE for ProcessControl, среди них –F i x D y n a m i c s (Intellution), FactorySuite 2000 (Wonderware), Genesis32 (Iconics), FactoryLink(US Data), Lookout (NationalInstruments) и т.д. Однако для большинства из них OPC —только один из поддерживаемых интерфейсов взаимодействия, их внутренняя идеология построения напрямую не связана с этим стандартом и часто унаследована от предыдущих 16- разрядных версий. Пока только Genesis32 изначально спроектирована на основе OPC (OPC to the Core). Все компоненты Genesis32 взаимодействуют между собой через OPC, являясь, в зависимости от ситуации, либо серверами, либо клиентами, либо и теми и другими одновременно. Это придало системе во многом единый стиль, стройность архитектуры и предопределило ее компонентный характер: унификация интерфейсов взаимодействия дала возможность легко выбирать совокупность компонентов, действительно необходимых пользователю (и не переплачивать за ненужные). Конечно, у других SCADA систем есть, безусловно, свои сильные стороны, однако Genesis32 в наибольшей степени дает своим пользователям почувствовать свободу выбора, которую обеспечивает OLE for Process Control.

1.9 Выводы из сравнения технологий реализации

               Идеальной должна быть следующая картина. Все производители в мире признают OPC своим стандартом. При этом поставщики оборудования, в том числе полевых шин, снабжают выпускаемые продукты OPC-серверами, а поставщики программ для систем управления делают собственные продукты OPC-клиентами и во многих случаях еще и OPC-серверами. При этом и те, и другие реализуют все спецификации и поддерживают все интерфейсы OPC. А все производители операционных систем встраивают в свои операционные системы технологии COM/DCOM, а также предоставляют сервисный инструментарий как для него, так и для OPC. И при этом все должно делаться на высоком профессиональном уровне и очень грамотно быть рассказано сборщикам систем, как это все монтировать и конфигурировать. Вот тогда вопрос обмена данными в системах автоматизации можно было бы считать закрытым.

               В настоящее время общепризнанным стандартом является только OPC Data Access , а остальные спецификации только начинают завоёвывать себе место под Солнцем. Не все спецификации завершены, по крайней мере, с точки зрения интерфейса автоматизации (например, для OPC Batch существует версия 2.0 custom-интерфейса, а интерфейс автоматизации – только версии 1.0, для некоторых других спецификаций тоже существует отставание интерфейсов автоматизации от custom-интерфейсов; для OPC Security спецификации на интерфейс автоматизации вообще не существует).

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

               Среди программ высокого уровня аналогичная картина. Спросом пользуется лишь OPC DA. Все известные SCADA-продукты являются OPC-клиентами, например Wonderware InTouch, CiTect (Ci Technologies), а многие из них и OPC-серверами (тот же, CiTect). Другое программное обеспечение подвержено влиянию OPC в гораздо меньшей степени.

               Из операционных систем технологию COM/DCOM поддерживают следующие:

все Windows, начиная с Windows 95. Это обеспечивается самой компанией Microsoft;

большинство Unix-подобных ОС, включая Linux; поддерживается фирмой GE Software;

ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver; имеется поддержка OPC, встроенная в систему разработки Tornado.

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

               В настоящее время картина далеко не идеальна. Еще довольно много оборудования и программного обеспечения не охвачено OPC-технологиями. Представляется, что сейчас в мире налицо некий бум OPC, по крайней мере, в отношении Data Access методов OPC для доступа к данным. Думается также, что Microsoft рано или поздно доведет все до желаемого уровня по всем направлениям. Тем более что альтернативных вариантов пока нет. Не имеется в виду COM/DCOM, а именно спецификации на обмен технологическими данными. Поскольку для COM/DCOM замена как раз имеется — CORBA. Это действительно изначально платформенно-независимая технология взаимодействия приложений. Но это не обмен технологическими данными, реализующий более высокий уровень абстракции. Кстати, заметим, что на рынке имеются OPC-шлюзы к CORBA (это возможно, как и к любому другому протоколу).

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

2 Разработка программного обеспечения OPC сервера

2.1 Структура программного обеспечения

               Логически программное обеспечение OPC сервера можно логически разделить на четыре больших функциональных блока. Каждый блок выполняет определенный набор функций в определенной области. Перечислим выделенные функциональные блоки:

Ø      Блок взаимодействия с сетью Modbus;

Ø      Блок взаимодействия с OPC клиентами;

Ø      Блок приведения данных из формата сети Modbus;

Ø      Блок синхронизации.

2.1.1 Блок взаимодействия с сеть Modbus

               Протокол MODBUS – прикладной протокол передачи сообщений, соответствующий седьмому уровню OSI модели, который обеспечивает связь клиент-сервер между устройствами, связанными различными типами шин и сетей.

            В настоящее время используются следующие типы сетей и шин:

Ø      TCP/IP поверх Ethernet (MODBUS/TCP).

Ø      Асинхронная последовательная передача по различным шинам ( EIA/TIA-232-E, EIA-422, EIA/TIA-485-A,и т.д.)

Ø      маркерные сети (MODBUS PLUS).

Рис. 2.1 Иерархическая коммуникационная модель MODBUS.

               Протокол MODBUS позволяет обеспечивать взаимодействие в режиме реального времени:

Ø      между программными приложениями

Ø      между устройствами

Ø      между SCADA системами и устройствами

Ø      между персональным компьютером и устройством

               В данной системе блок взаимодействия организован в отдельном потоке. В его функции входит опрос указанных клиентами устройств для получения значений переменных. Данный блок, так же, преобразует (пакует) Modbus запрос в IP пакет. Через сокет производится посылка IP пакета по заранее указанному IP адресу. После получения подтверждения, данные передаются для обработки в блок преобразования данных для передачи на клиента.

2.1.1.1 МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ

Модель взаимодействия в рамках протокола MODBUS построена по принципу клиент-сервер. В рамках протокола MODBUS предусмотрено одно ведущее устройство и до 247 ведомых. Запросы может инициализировать только ведущее устройство (клиент).

Рис. 2.2 Модель взаимодействия в сети MODBUS.

В соответствии с типом запроса, ведомое устройство (сервер) может выдавать два вида ответов: подтверждение и исключение.

Рис. 2.3 Транзакция протокола MODBUS.

2.1.1.2 ОСОБЕННОСТИ ПРОТОКОЛА MODBUS/TCP

               Так как протокол MODBUS/TCP является разновидностью протокола MODBUS на основе Ethernet и стеке протоколов TCP/IP, то он имеет ряд особенностей:

Ø      MODBUS/TCP является протоколом с установлением логического соединения;

Ø      Контроль за целостность информации возлагается на нижележащие протоколы;

Ø      Двухуровневая адресация: IP (4 байта) + идентификатор устройства (1…255);

Ø      Имеет место ряд ограничений на максимально допустимое время установки логического соединения;

Ø      В сети Internet за протоколом MODBUS/TCP зарезервирован порт 502. В следствии этого, каждое IP устройство может иметь только один MODBUS сервер. Клиент для установки соединения может использовать порт, значение которого больше1024 (см. рисунок 2.4.).

Рис. 2.4 Модель взаимодействия в сетях MODBUS/TCP.

Сети MODBUS на базе Ethernet TCP/IP могут иметь различную архитектуру. При этом, узлы MODBUS, выполненные на других полевых шинах, могут объединяться в единую сеть MODBUS на Ethernet TCP/IP, используя мосты и шлюзы.

Рис. 2.5 Типовая архитектура сети MODBUS/TCP.

2.2 Блок взаимодействия с OPC клиентами

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

               Механизм взаимодействия сервера и клиента построен на возможности удаленного вызова процедур COM компонента, коим является OPC-сервер. Данный механизм полностью обслуживается и поддерживается операционной системой. Разработчик должен, в соответствии со спецификацией, описать интерфейсы (наборы предоставляемых методов) и создать специальный файл, в котором данные описания будут храниться.

               Интерфейсы (наборы методов) данного блока доступны подключаемым клиентам посредством стандартного внутрисистемного протокола RPC (Remote Procedure Call). Данный протокол позволяет приложениям вызывать методы COM компонентов, зарегистрированных в системе. Механизм удаленного вызова реализуется через реестр операционной системы. Компонент регистрирует себя в системе, делая доступной информацию о своем нахождении. Клиент создает экземпляр COM компонента, вызывая его по имени. Операционная система находит в реестре информацию об описании компонента с данным именем и создает его экземпляр. Далее клиенту передается указатель на стандартный интерфейс, через который становится возможным получение указателей на другие интерфейсы, предоставляемые данным COM компонентом.

               При получении указателей на интерфейсы, клиенту становятся доступны функции, реализуемые данными интерфейсами.

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

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

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

2.2.1 Внутрипроцессный сервер (DLL)

               Для реализации COM компонента возможны два подхода. Первый способ реализации – внутрипроцессный сервер. Данная реализация подразумевает компиляцию в динамически загружаемую библиотеку (DLL). Таким образом, при попытке создания экземпляра COM компонента, баблиотека загружается в адресное пространство вызывающего процесса и работает в самом вызвавшем процессе.

               Достоинство такого способа заключается в скорости доступа к методам объекта. Разница между локальным и внутрипроцессным сервером – примерно два порядка (сто раз). Операционная система не тратит время на трансляцию адресов из одного адресного пространства вызывающего процесса в другое адресное пространство процесса компонента.

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

2.2.2 Локальный сервер

               Первый – выполнение в виде локального сервера (EXE – файла). Второй подход обеспечивает функционирование экземпляров в собственном адресном пространстве. То есть, при попытке создания объекта, порождается отдельный процесс, к которому производятся обращения за предоставляемыми методами.

               Основное достоинство построения локального сервера – при возникновении ошибки в компоненте, разрушается процесс, в котором компонент функционировал. При возникновении подобных ситуаций, операционная система обычно аварийно завершает процесс, в котором возникла ошибка. Таким образом, процесс, который использовал компонент, остается в работоспособном состоянии.

               Недостаток исполнения библиотеки COM компонента в виде локального сервера заключается в низкой производительности. Операционной системе приходится тратить время для преобразования адресов (для передачи данных из одного адресного пространства в другое).

               Специфика локального сервера заключается в том, что для взаимодействия с клиентом необходимы специальные объекты прокси и заглушка (см. Удаленный вызов). При отсутствии пользовательского объекта-заглушки/прокси, операционная система сама предоставляет стандартные средства для пакетирования запросов от клиента к серверу. Это средство – стандартный системный COM объект прокси/заглушка oleout32.dll.

               Локальный сервер может быть выполнен в виде динамически загружаемой библиотеки (dll). Но для этого необходимо специально указывать, что данная библиотека должна быть загружена в отдельном процессе. Данный процесс называется суррогатным. Преимущества данного подхода такие же, как и при выполнении exe файла. Недостатки те же. Существенные различия по сути отсутствуют, однако, такой подход – единственный способ загрузить динамически загружаемую библиотеку на удаленной машине.

2.2.3 Удаленные подключения и прозрачность местонахождения

               Понятие прозрачности местонахождения позволяет COM клиенту получать доступ к объектам таким образом, что существующий код не требует изменений в зависимости от физического расположения COM сервера (внутри процесса, локального, или удаленного). До появления модели COM разработчики приложений были вынуждены создавать отдельные блоки кода для доступа к разным файлам. В модели COM единый блок кода используется для доступа с объекту вне зависимости от его положения.

               Удаленные подключения организуются через специальный протокол удаленного вызова процедур RPC (Remote Procedure Call). Данный протокол позволяет сделать прозрачными для процесса вызовы методов COM компонентов, физически располагающихся на удаленных компьютерах.

               Для реализации удаленных вызовов используются специальные COM объекты, названные Proxy и Stub (прокси и заглушка). Каждый из них загружается в адресное пространство клиента и сервера соответственно.

               Прокси-объект – COM объект, загруженный в процесс клиента, который пакетирует запросы клиента, касающиеся вызова любых внепроцессных методов.

               Заглушка – COM объект, загруженный в процесс сервера, которые получает запросы клиента, распаковывает их и передает «реальному» COM объекту.

Рис. 2.6 Создание экземпляра класса.
               Комментарии к схеме:

·        При запросе клиента на создание объекта (экземпляра компонента), операционная система обрабатывает данное обращение и осуществляет поиск уникального идентификатора (CLSID) компонента в реестре. По найденному идентификатору осуществляется поиск файла, в котором находится исполняемый код методов компонента.

·        Далее система загружает файл компонента и вызывает метод создания фабрики классов компонента для возвращения клиенту указателя на фабрику классов клиенту через операционную систему.

·        После получения указателя на фабрику классов клиент вызывает ее метод по создания экземпляра компонента. После создания экземпляра фабрику классов можно освободить (если она не нужна).

·        При вызове метода фабрики классов для создания экземпляра компонента клиенту возвращается указатель на стандартный интерфейс IUnknown.

·        Через указатель на интерфейс IUnknown можно получить указатели на другие интерфейсы, используя стандартную (обязательную) функцию QueryInterface.

               Таким образом, при правильной конфигурации системы, как со стороны OPC сервера, так и со стороны клиента, становится прозрачным местонахождение самого серверного программного обеспечения. Главное условие – присутствие прокси/заглушки на обоих компьютерах и правильное конфигурирование прав доступа к COM компоненту для организации удаленных вызовов (с удаленных компьютеров). Таким же образом реализуется соединение с локальным сервером (работающем в отдельном процессе). Только для взаимодействия операционная система использует протокол LRPC (Lightweight Remote Procedure Call).

2.2.4 Выбор реализации COM компонента

               Для определения способа реализации и способа регистрации COM компонента OPC сервера в операционной системе необходимо определить рамки использования данного сервера. Возможные подходы:

Ø      Реализация в виде DLL. Загрузка в клиентский процесс.

Данная реализация характерна самым высоким быстродействием. Функции компонента импортируются в процесс клиента. Без дополнительных средств отсутствует возможность удаленного доступа.

Ø      Реализация в виде EXE. Возможна загрузка только в локальный процесс (локальный сервер). Возможен удаленный доступ.

Данная реализация характерна гарантированной устойчивостью клиентского процесса в случае возникновения ошибок в компоненте. Для преобразования данных используется специальный COM объект прокси/заглушка. При отсутствии пользовательского (специально разработанного) объекта проки/заглушки, операционная система попытается загрузить в адресные пространства клиента и сервера объект системный прокси/заглушку. Но для нормальной работы такой системы необходимым требованием является поддержка со стороны объекта-сервера стандартных типов данных и стандартных интерфейсов (oleautomation).

Ø      Реализация в виде DLL. Загрузка в суррогатный процесс. Возможен удаленный доступ.

Характеристики реализации те же, что и при EXE файле. Отличие в том, что файл является динамической библиотекой. Достоинство заключено в том, что при необходимости можно быстро преобразовать данный локальный сервер в внутрипроцессный. Еще одно достоинство заключено в том, что компонент, выполненный, как динамическая библиотека, может быть преобразован в COM+ компонент.

               В случае реализации удаленных подключений необходимо организовать локальный сервер и разработать пользовательский (собственный) объект прокси/заглушку. Для облегчения дальнейшей модификации и перехода на более новые технологии проще реализация в виде динамической библиотеки.

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

2.3 Блок синхронизации

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

               Синхронизация осуществляется путем выставления в очередь запросов (сообщений) от различных подсистем. Далее, из очереди выбирается одно и обрабатывается. Данный механизм препятствует возникновению в системе нескольких событий одновременно.

               При самостоятельной реализации управления синхронизацией необходимо оборачивать обработку потокоопасных данных в критические секции.
3. Программное обеспечение универсального ОРС-сервера (OPC UA) для систем HMI/SCADA

При передаче данных на большие расстояния, что, безусловно, необходимо для АСУ ТП, DCOM имеет серьёзные недостатки. Один из главных недостатков — неприспособленность для работы в глобальной сети Интернет. Основная причина — это применение межсетевых экранов, или брандмауэров, которые защищают компьютер от несанкционированного доступа из вне. Защита организована таким образом, что весь обмен по сети проходит через брандмауэр. Сетевой экран анализирует передаваемые пакеты, и если информация не соответствует настройкам системы безопасности, их прохождение блокируется. Технология DCOM может использовать различные транспортные протоколы для передачи данных, но преимущественно применяется TCP/IP.

Обычно брандмауэры настраивают таким образом, чтобы максимально ограничить количество портов для выхода в глобальную сеть. Порты, используемые DCOM, чаще всего не являются разрешёнными для обмена данными, и открытие их существенно ослабляет защищённость от несанкционированного доступа.

Для решения этой проблемы можно использовать технологию туннелинга (tunneling) TCP, с помощью которой осуществляется передача данных через стандартный 80-й порт брандмауэра.

Этот порт обычно используется для передачи данных по http-протоколу (протокол передачи гипертекста), и поэтому он, как правило, открыт. Но для осуществления туннелинга и передачи данных требуется установка специального программного обеспечения, входящего в Windows, COM Internet Services и IIS web_сервер (Internet Information Server).

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

3.1. Туннелинг ОРС.

Учитывая данные сложности, ОРС сообщество за последние 5 лет разработало универсальный ОРС-сервер (OPC UA) для систем HMI/SCADA.

Технология OPC UA позволяет обеспечить надёжную связь клиентов, доступ к серверам данных через локальные вычислительные сети и Интернет, защищённое использование web служб (http://www.opcfoundation.org).

Фирма Iconics входит в число основателей ОРС_сообщества, давно и успешно работает в области создания приложений, базирующихся на ОРС-

технологии. В новой версии SCADA_системы GENESIS32 V9 Iconics используется встроенная поддержка технологии OPC UA и туннелинг OPC (компонент DataWorX32).

Новая технология туннелинга OPC включена во все модификации DataWorX32 V9 и позволяет связывать удалённый OPC_сервер с локальными клиентами устойчивым и безопасным способом. Туннелинг OPC основан на мощной коммуникационной платформе GenBroker™, которая обеспечивает высокоэффективную и устойчивую связь, заменяя протокол DCOM Microsoft. Функциональная схема туннелинга OPC представлена на рис. 3.1.

Рис. 3.1. DataWorX32: OPC-архитектура туннелинга.

Все OPC совместимые приложении клиенты могут обмениваться данными с локальными устройствами или по сети. Кроме того, обмен может осуществляться более чем с одним сервером OPC одновременно.

Любое приложение-клиент OPC может обмениваться данными с любым OPC-сервером данных (OPC DA), OPC_сервером тревог и событий (OPC A&E) и OPC_сервером исторических данных (HDA).

Приложение DataWorX32, входящее в пакет GENESIS32 V9, представлено в трёх модификациях: профессиональной, стандартной и облегчённой.

DataWorX32 содержит большое количество принципиально новых возможностей:

● полное резервирование данных OPC, OPC тревог и событий и OPC исторических данных;

● туннелинг для любых сторонних OPC-серверов и OPC-клиентов;

● новую утилиту MonitorWorX, обеспечивающую централизованную диагностику системы и отображающую её производительность;

● интеграцию туннелинга в универсальном навигаторе данных;

● группировку OPC-тегов и построение мостов данных.

Туннелинг OPC в DataWorX32 V9 полностью совместим с OPC-стандартом, не нарушает систему сетевой защиты IT, поддерживает связь по LAN, WAN и Интернет со всеми атрибутами встроенной безопасности и полностью поддерживает открытые стандарты промышленности и протоколы, такие как:

● OPC доступа к данным (DA 3.0);

● OPC тревог и событий;

● OPC доступа к историческим данным;

● OPC единой архитектуры (UA);

● протоколы связи TCP/IP и XML.
3.2. Группировка, архивация и резервирование данных ОРС.

Одной из важных характеристик пакета DataWorX32 является инструмент группировки OPC-тегов и построения мостов данных. Допустим, нам необходимо использовать данные ОРС-серверов с двумя различными протоколами. Для этого в конфигураторе DataWorX32 указываем в каталоге Bridging навигатора источники данных ОРС-серверов, настраиваем тип регистра и свойства данных. Затем запускаем на исполнение, и ОРС-теги различных протоколов становятся сгруппированными и доступными для приложений, являющихся ОРС-клиентами.

Другой важной характеристикой DataWorX32 является возможность

группировки ОРС-данных различных ОРС-серверов. Схема механизма группировки показана на рис. 3.2.

Рис. 3.2. Реализация функции группировки в ОРС DataWorX.

Часто в очень больших проектах различные приложения-клиенты OPC обращаются к одним и тем же OPC-серверам.

Например, в экранной форме GraphWorX32 необходимо отображать уровень жидкости в резервуаре, в AlarmWorX32 нужно контролировать и сигнализировать о состоянии того же самого значения уровня жидкости, в TrendWorX32 давать его графическое представление и т.п. Это приводит к увеличению загрузки OPC-сервера, поскольку одни и те же данные будут запрашиваться неоднократно.

Таким образом, когда многие клиенты запрашивают данные от сервера OPC, DataWorX32 проводит мониторинг OPC-серверов и группирует данные по запросам клиентов. Часто требуется оптимизировать работу, выполняемую серверами ввода/вывода на низком уровне (например, для увеличения скорости архивации). DataWorX32 может выступать «посредником» между клиентами и серверами и позволяет оптимизировать этот процесс. Это наиболее выгодно, когда приходится взаимодействовать с удалёнными серверами по сети.

Новый DataWorX32 — единственный продукт, который поддерживает три самых важных OPC-стандарта (DA, A&E, HDA), обеспечивает полнофункциональное резервирование данных, наиболее востребованное в больших распределённых системах управления.

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

Эта технология может применяться к существующим OPC-серверам и клиентам, не требует реконфигурации приложений, остановки процессов и

не приводит к искажению и потере данных (рис. 3.3.).

Рис.3.3. Структурная схема реализации ОРС – сервером тревог, событий и исторических данных.

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

Тревоги автоматически квитируются, синхронизируются, гарантированно регистрируются все действия оператора в системном журнале с тем, чтобы при переключении с основного сервера

тревог на резервный и наоборот сохранялись все регистрируемые параметры процессов (рис. 3.4.).

Рис. 3.4. Структурная схема передачи и резервирование ОРС-серверов данных.

В дополнение ко всему DataWorX32 поддерживает резервирование OPC-серверов исторических данных (OPC HDA), согласованных по времени. Это достигается за счёт того, что приложение создаёт несколько конфигураций для гарантированного обеспечения синхронизации времени выводимых исторических данных. Встроенная технология хранения и восстановления данных обеспечивает синхронизацию исторических данных между основными и резервными узлами с помощью файлов системного журнала. DataWorX32 поддерживает наиболее эффективные базы данных Microsoft SQL 2000 и SQL 2005 для резервирования (рис. 3.5.).

Рис. 3.5. Функциональная схема резервирования ОРС-серверов данных.

Использование технологии OPC позволяет разработчику SCADA_системы свободно выбирать оборудование независимо от того, кто его производит. В прошлом разработчик был вынужден пользоваться только тем оборудованием, которое поддерживали те или иные программные модули и приложения.

Использование же технологии OPC позволяет любому OPC совместимому клиентскому приложению получать доступ к любому устройству управления, у которого есть OPC совместимый сервер. Другое неоценимое преимущество технологии ОРС состоит в том, что при её использовании снижаются риски и стоимость реализации проектов АСУ ТП. Это обусловлено тем, что применяемые OPC совместимые компоненты, производимые целым рядом компаний, работают на единой технологической основе.
Опишем подробнее “места работы” OPC-сервера. Если имеется оборудование, например, плата АЦП, управляемая через драйвер на компьютере с Windows или другой ОС, поддерживающей COM/DCOM, то это самый главный кандидат на то, чтобы непосредственно поверх драйвера реализовать OPC-сервер. Замена устройства не потребует изменения остальных приложений: драйвер изменяется, но OPC-интерфейс поверх него остается прежним.

При наличии устройства, управляемого через какой-нибудь сетевой протокол, вполне возможна реализация OPC-сервера, получающего данные по этому протоколу. Единственная особенность — следует предусмотреть механизмы восстановления связи в случае сбоев.[3]

Несколько более сложной будет схема при работе управляющих приложений на компьютере, не поддерживающем COM/DCOM. В этом случае применим двухкомпонентный OPC-сервер. На стороне ОС, не поддерживающей COM, устанавливается сетевой модуль, который, с одной стороны, связан с приложениями, а с другой — через сеть с OPC-сервером. Заметим, что сетевой модуль может быть стандартным (как, например, ISaNet в системе ISaGRAF). В этом случае необходимо разработать только OPC-сервер. По такому принципу функционирует OPC-сервер ISaGRAF фирмы “РТСофт” (www.rtsoft.ru). Иногда сетевой модуль создается специально для OPC- сервера. Возможна даже реализация, при которой этот модуль не ориентирован на конкретное приложение, а предоставляет некоторый API-интерфейс для любых приложений, желающих обслуживаться с помощью OPC. Так действует OPC-сервер для операционной системы OS-9, также разработанный в “РТСофт”.

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

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

Полезность применения OPC с точки зрения интеграции достаточно прозрачна и вытекает из самой сути OPC.

Это стандарт на интерфейс обмена данными с оборудованием. Первое преимущество — если вы заменяете какой-нибудь компонент, то нет нужды корректировать другое ПО, так как даже при замене драйвера поверх него работает OPC. Второе — если вы хотите добавить в систему новые программы, нет необходимости предусматривать в них драйверы устройств, кроме OPC-клиента, разумеется. Ну и так далее.

В настоящее время общепризнанным стандартом является только OPC DA, а остальные спецификации только начинают завоёвывать себе место под Солнцем. Не все спецификации завершены, по крайней мере, с точки зрения интерфейса автоматизации (например, для OPC Batch уже существует версия 2.0 custom-интерфейса, а интерфейса автоматизации – только версия 1.0, для некоторых других спецификаций тоже существует отставание интерфейсов автоматизации от custom-интерфейсов; для OPC Security спецификации на интерфейс автоматизации вообще не существует).

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

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

Из операционных систем технологию COM/DCOM поддерживают следующие:

– все Windows, начиная с Windows 95. Это обеспечивается самой компанией Microsoft;

– большинство Unix-подобных ОС, включая Linux; поддерживается фирмой GE Software;

– ОС реального времени VxWorks; обеспечивается фирмой-разработчиком WindRiver; имеется поддержка OPC, встроенная в систему разработки Tornado.

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

4. Технология разработки и тестирования

4.1. Технология построения программы

4.1.1. Программирование на основе интерфейсов

               Основой модели COM является концепция интерфейсов. Без них нет возможности создать ни одного приложения COM. Часто переход от традиционного ООП к программированию на основе интерфейсов оказывается несколько напряженным (так же, как и переход от структурного программирования в ООП). Хотя COM немыслима без интерфейсов, сами интерфейсы могут существовать и без COM. Чтобы облегчить переход на интерфейсное программирование, необходимо рассмотреть их с точки зрения C++, а не модели COM.

               Каждый класс в C++ определяет открытый сектор (называемый, так же, открытым интерфейсом).

               Дадим понятие слову интерфейс: интерфейс – набор методов, выделенный в логически (и программно) выделенный блок. Определение, которое дает Трельсен: интерфейс – набор семантически связанных функций, описывающих операции, которые могут поддерживаться классом.

               В самом простом случае, открытый сектор представляет собой набор методов класса, которые доступны из самого экземпляра класса. Например, класс CСlass, показанный на рисунке ниже, содержит открытый интерфейс, состоящий из трех методов.

Рис. 4.1 Класс с одиночным открытым интерфейсом

Данный класс обладает весьма скромным открытым интерфейсом, предоставляющим только три метода. Часто классы C++, особенно те, что входят в коммерческие библиотеки классов, определяют гигантское количество методов в своих открытых интерфейсах. С практической токи зрения обширный открытый интерфейс может не очень устраивать пользователя объекта, поскольку огромная область покрывается всего одним классом. С точки зрения проектирования одиночный интерфейс может быть разбит на несколько интерфейсов, обеспечивающих более управляемую и масштабируемую архитектуру объектов приложения.

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

4.2.2. Модель COM

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

Рис. 4.2 Механизмы доступа к различным ресурсам в отсутствие COM.

Приложения, скомпонованные с библиотекой, могут пользоваться ее сервисами, вызывая функции их этой библиотеки. Приложение также может использовать сервисы другого – являющегося совершенно отдельным процессам. В этом случае два таких локальных процесса взаимодействуют посредствам некоего механизма связи, который обычно требует определения протокола между этими приложениями (набор сообщений, позволяющий одному приложению выдавать запросы, а другому соответствующим образом отвечать на них). Еще пример – приложение, использующее сервисы операционной системы. Здесь приложение обычно выполняет системные вызовы, обрабатываемые операционной системой. Наконец, приложению могут понадобиться сервисы, предоставляемые программным обеспечением, выполняемым на другой машине, доступ к которой осуществляется по сети. Получить доступ к таким сервисам можно множеством способов, таких как обмен сообщениями с удаленным приложением или вызовы удаленных процедур.

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

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

В COM любая часть программного обеспечения реализует свои сервисы как один или несколько объектов COM. Каждый такой объект поддерживает один или несколько интерфейсов, состоящих, как было сказано выше, из методов. Метод – это процедура или функция, которая выполняет некоторое действие и может быть вызвана программой, использующей данный объект (клиентом объекта). Методы, составляющие каждый интерфейс, обычно определенным образом взаимосвязаны. Клиенты могут получить доступ к сервисам объекта COM только через вызовы методов интерфейсов объекта – у них нет непосредственного доступа к данным объекта.

4.1.3. Связь OPC и COM

Технология OPC, как уже говорилось, средство предоставления данных между различными уровнями управляющей системы. Базовой технологией для нее является технология встраивания и связи объектов (OLE), в свою очередь, в основе которой лежит технология COM и ее расширение для сети DCOM.

Построение программного обеспечения с использованием данных технологий обуславливает те возможности, которыми обладает данное программное обеспечение. Встраивание в вычислительный процесс динамических библиотек (внутрипроцессных серверов), запуски локальных и удаленных серверов – все это набор стандартных возможностей технологии COM.

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

Для установки соединения клиента и сервера, клиент должен заранее знать или получить в качестве настроечной информации «имя» того OPC сервера, с которым необходимо связаться и сетевое имя машины, на которой находится сервер (в случае попытки установления удаленного соединения). Обслуживание данного процесса производится операционной системой и оно скрыто от самого клиента. Иными словами, нет разницы, где находится программное обеспечение. Операционная система осуществляет поиск исполняемых файлов сервера для их загрузки. Для того, чтобы у операционной системы была возможность осуществления данного поиска, сервер должен быть зарегистрирован в системном реестре того компьютера, в рамках которого он будет исполняться.

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

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

4.2. Обзор технологии OPC

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

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

Приведем пример. Для хранения архивных данных необходима реализация базы данных. Но есть возможность использования уже реализованной системы управления базами данных, например, Microsoft SQL server. Для сопряжения его с управляющей системой достаточно, в рамках программного обеспечения к самому SQL серверу, на его языке написать клиента. Таким образом лишив себя трудностей, возникающих обычно при написании программ сопряжения разноуровневого программного обеспечения. При этом, созданный программный элемент становится переносимым компонентом, который возможно использовать для любого SQL сервера и для любого OPC сервера.

Таким же примером может являться приложение на VBA для приложений пакета Microsoft Office. Для многих из них уже существуют программы, являющиеся клиентами.

Кроме возможностей использования существующего ПО можно создавать свои программы, поддерживающие интерфейсы OPC. Для этого применяют среду программирования MS Visual C++.

4.3. Верификация программного обеспечения

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

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

Удалось найти в свободном распространении OPC клиенты, реализованные для Microsoft Excel, C++ клиенты, созданные для взаимодействия с серверами, не использующие интерфейсы автоматизации.

4.4.Отладка и тестирование

Разработка программы производилась на языке C++ на базе операционной системы MS Windows 2000. Для компиляции исходных текстов использовался компилятор MS C++. Для выполнения отладки исходных текстов был использован встроенный отладчик MS Visual Studio C++. Данный отладчик позволяет по шагам исполнять программу, создавать точки останова, отслеживать значения переменных простых и составных типов.

Для установления протокольной истинности были использованы созданные сертифицированные OPC клиенты фирмы Automation Solution Inc. Данное программное обеспечение распространяется свободно для демонстрационных целей.

Первым шагом является корректная компиляция программного модуля. Для этого необходимо наличие всех модулей исходного кода (заголовочные файлы, файлы реализаций методов классов, файлы описания интерфейсов для создания файлов заголовков, ресурсы). При корректной компиляции генерируется программный модуль в виде динамической библиотеки. Создание библиотеки позволяет иметь дополнительные возможности использования программного обеспечения в рамках локальной машины.

Второй шаг – корректная регистрация библиотеки в системе. На данном шаге необходимо удостовериться, что существуют все необходимые записи в системном реестре. Для этого используется программа regedit операционной системы. Регистрация осуществляется на основе специального текстового файла, который интерпретируется операционной системой, как набор ключей, переменных и их значений для внесения в реестр.
Тестирование программного обеспечения есть достаточно сложная и комплексная задача. Для ее решения существуют различные подходы и различные наборы методов, руководствуясь которыми можно разрабатывать и выпускать качественное программное обеспечение, содержащее минимальное число ошибок.

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

Вторым основным аспектом тестирования является сама разработка кода. То есть, создание собственно того, что потом будет тестироваться. Один из способов исправления ошибок – их предотвращение. Разработчик должен организовывать свой процесс так, чтобы как можно больше застраховаться от внесения логических ошибок.

Самодокументирование и комментирование исходного кода позволит исправлять ошибки и модернизировать, то есть поддерживать код, вне зависимости от его давности и авторства.

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

Один из подходов к тестированию назван «тестирование черного ящика». Данный подход заключается в том, что предлагаемый для тестирования продукт рассматривается, как черный ящик у которого есть средства для ввода информации и средства для вывода полученных результатов. При тестировании с абстрагированием от внутренней организации можно с достаточной вероятностью утвердить, что данное программное обеспечение функционирует корректно. То есть, на заданные входные воздействия были получены результаты, совпадающие с эталонными (ожидаемыми). Для тестирования без обращения внимания на реализацию возможно использование автоматизированных средств тестирования. Таковыми являются Rational Rose, Visual Test, Test Complete, QA Partner, Silk. Например, Rational Rose является не одним продуктом, а программным комплексом, охватывающим все аспекты разработки программного обеспечения (разработка, документирование, тестирование, сопровождение кода, система контроля дефектов). В частности, Rational Rose содержит как инструментарий для функционального тестирования (RR Robot), Visual Test, так и средства для разработчиков, которые позволяют своевременно отлавливать такие ошибки, как утечки памяти и так далее.

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

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

4.4.1. Подгрузка внутрипроцессного сервера

Первым тестом был выяснен факт установления соединения клиента и сервера. Для этого использовались следующие средства: C++ OPC клиент, Excel OPC клиент, Automation Solutions Inc C++ клиент, MS Visual Studio C++ Debugger.

Для выяснения установления соединения с внутрипроцессным сервером были выполнены следующие действия:

·        загружен клиент;

·        вызвана функция установления соединения;

·        подключен отладчик к процессу клиента;

·        в случае C++ клиента, к клиентскому процессу;

·        в случае Excel клиента, к Excel;

·        установлена точка останова в отладчике на вызове метода создания экземпляра объекта.

Результатом теста является установление факта корректной загрузки сервера (создание экземпляра объекта), наличия соединения с внутрипроцессным сервером. Данный факт подтверждается остановкой на точке, указанной в отладчике. Указанная точка останова находится в коде сервера.

4.4.2. Запуск локального сервера

Для этого использовались следующие средства: Automation Solutions Inc C++ клиент, MS Visual Studio C++ Debugger. При попытке использования Excel клиента мы получим результат предыдущего теста (загрузку внутрипроцессного сервера). Для запуска локального сервера в рамках одного компьютера необходим клиент, который умеет запрашивать на запуск локальный сервер.

Данный тест должен проиллюстрировать факт загрузки динамической библиотеки в суррогатный процесс DLLHOST.EXE.

Тест включает в себя следующие шаги:

·        загрузка клиента;

·        вызвана функция установления соединения с локальным сервером;

·        с помощью диспетчера задач установлен факт запуска процесса DLLHOST.EXE;

·        подключен отладчик к процессу DLLHOST.EXE;

·        установлена точка останова в отладчике на вызове метода создания экземпляра объекта.

Результатом теста является установление факта корректного запуска сервера (создание экземпляра объекта), наличия соединения с локальным сервером. Данный факт подтверждается остановкой на точке, указанной в отладчике. Указанная точка останова находится в коде сервера.

4.4.3. Запуск удаленного сервера

Для этого использовались следующие средства: Automation Solutions Inc C++ клиент, MS Visual Studio C++ Debugger, VMWare эмулятор удаленного компьютера. Для запуска удаленного сервера необходим клиент, который умеет запрашивать на запуск удаленный сервер. Для этого клиент должен обладать функциональностью опроса указанного компьютера на наличие программного обеспечение OPC сервера. Дополнительным необходимым средством, необходимым для организации удаленного соединения являются специализированные COM объекты, называемые заглушкой и прокси. Данные объекты должны быть зарегистрированы в операционных системах сервера и клиента соответственно.

Ожидаемым результатом является запуск системного суррогатного процесса DLLHOST.EXE, в который затем подгружается библиотека программного обеспечения OPC сервера. При загрузке отладчика и установлении точки останова на вызове метода создания экземпляра объекта должна произойти остановка выполнения программы.

Данный тест должен проиллюстрировать факт загрузки динамической библиотеки в суррогатный процесс DLLHOST.EXE на эмулируемом удаленном компьютере.

Тест включает в себя следующие шаги:

·        регистрация прокси-объекта на клиентской машине;

·        загрузка клиента;

·        регистрация объекта-заглушки на серверной машине;

·        вызов функции установления соединения с удаленным сервером;

·        с помощью диспетчера задач установлен факт запуска процесса DLLHOST.EXE на серверной машине;

·        подключен отладчик к процессу DLLHOST.EXE;

·        установлена точка останова в отладчике на вызове метода создания экземпляра объекта.

Результатом теста является установление факта корректного запуска удаленного сервера (создание экземпляра объекта), наличия соединения с удаленным сервером. Данный факт подтверждается остановкой на точке, указанной в отладчике. Указанная точка останова находится в коде сервера.

Рис. 4.3 Блок-схема алгоритма тестирования установления соединения.

4.4.4.Создание элемента данных

Данный тест необходим для установления факта создания элемента «источника» данных, которые будут предоставлены клиенту по запросу или по «подписке». Для осуществления теста используется следующий инструментарий: C++ OPC клиент, Excel OPC клиент. Исходными данными для проведения данного теста является установленный факт организации соединения между клиентом и сервером в трех режимах (внутрипроцессный, локальный и удаленный).

Тест включает в себя следующие шаги:

·        загрузка клиента;

·        вызов функции установления соединения с сервером;

·        вызов функции создания элемента данных;

·        для Excel клиента по запросу;

·        для C++ клиента по подписке;

·        вызов функции чтения данных с сервера;

·        для Excel клиента по запросу;

·        для C++ клиента автоматически по подписке.

В результате теста была установлена корректность выполнения функции создания элемента данных на сервере. При выполнении теста была протестирована функция чтения данных сервера в двух случаях (по запросу и по подписке).

Данный тест был выполнен в трех режимах – внутри процессном, локальном и удаленном. Во всех случаях были получены одинаковые (удовлетворяющие требованиям) результаты.

4.4.5. Запись данных в источник

Данный тест необходим для установления факта корректной записи данных в источник, полученных от клиента. Для выполнения теста используются следующие средства: C++ OPC клиент, Excel OPC клиент.

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

Тест включает в себя следующие шаги:

·        загрузка клиента;

·        вызов функции установления соединения с сервером;

·        вызов функции создания элемента данных;

·        для Excel клиента по запросу;

·        для C++ клиента по подписке;

·        вызов функции записи корректных данных на сервера;

·        вызов функции чтения данных с сервера;

·        сравнение записанных и прочитанных данных;

·        запись на сервер некорректных данных.

Рис. 4.4 Блок-схема алгоритма тестирования записи данных в источник.

При записи некорректных данных было получено сообщение об ошибке, сгенерированное программой. Данное сообщение предупреждает о попытке записи некорректных данных на сервер.

Данный тест был выполнен в трех режимах – внутрипроцессном, локальном и удаленном. Во всех случаях были получены одинаковые (удовлетворяющие требованиям) результаты.

4.4.6. Определение устойчивости соединения

Тест не устойчивость соединения необходим для опытного определения времени устойчивого соединения, для выявления причин разрыва соединения без запроса со стороны сервера или клиента и для выявления возможных утечек ресурсов при долгосрочной работе программного обеспечения. Причиной необходимости данного теста является область применения данного программного обеспечения. В системах УТП не допускается использование оборудования и программного обеспечения, неспособного обеспечить безотказную работу в течении длительного времени, и неспособного заявить о возникших неполадках в системе (в случае, если эти неполадки не могут быть устранены работающей аппаратурой или ПО).

Для проведения данного теста использовались следующие средства: C++ OPC клиент и VMWare эмулятор виртуального удаленного компьютера.

Тест включает в себя следующие шаги:

·        загрузка клиента;

·        вызов функции установления соединения с сервером;

·        вызов функции создания элемента данных;

·        вызов функции чтения данных с сервера по подписке;

Данный тест был проведен в течении 72 часов. При этом не было выявлено сбоев при попытке чтения данных с сервера.

Данный тест был выполнен в трех режимах – внутри процессном, локальном и удаленном. Во всех случаях были получены одинаковые, удовлетворяющие требованиям результаты.

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

Рис. 5.5 Тест на устойчивость соединения.
5. Распределенная система сбора данных на основе OPC
На российском рынке систем автоматизации технологических процессов с некоторой задержкой относительно общих тенденций развития информационных систем начинает формироваться совершенно новый класс задач – интеграционные, связанные с объединением потоков информации от разнородных локальных систем сбора данных и управления технологическими объектами. Решению подобных задач препятствуют многочисленные трудности, во-первых, связанные с несовместимостью локальных систем (по форматам данных, по поддерживаемым интерфейсам и протоколам обмена), во-вторых, в большинстве случаев речь идет об объединении территориально распределенных систем, и здесь на первый план выходят вопросы организации передачи данных, редко встречающиеся при внедрении локальных АСУ ТП. В такой ситуации решение, “лежащее на поверхности”, – построение специализированной масштабной системы с полной или частичной заменой существующих АСУ ТП и решением коммуникационных задач – зачастую возможно лишь при неограниченном бюджете проекта, что безусловно является исключением. Те же вопросы, связанные с организацией передачи данных, возникают и при необходимости проектирования любой территориально (географически) распределенной АСУ ТП. Кроме того, при построении масштабных систем сбора данных и управления достаточно часто встречаются задачи, для которых не находится оптимального решения в рамках предлагаемых одним поставщиком программно-аппаратных средств, и вновь возникают проблемы совместимости разнородного оборудования и ПО. Перед каждой компанией, подошедшей к необходимости решения подобных задач, возникает вопрос экономической целесообразности, т.е. соотношения затрат на построение единой информационной системы с возможным экономическим эффектом от интеграции. Промышленно развитые страны столкнулись с этими вопросами значительно раньше, что и спровоцировало появление первого единого стандарта для организации сбора и передачи данных в системах промышленной автоматизации – ОРС.

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

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

Сложности, появляющиеся при создании территориально (географически) распределенных проектов, существенно отличаются от задач, решаемых в ходе создания как локальных систем “нижнего” уровня – АСУ ТП, так и систем уровня управления предприятием (ERP). Прежде всего возникают вопросы, связанные с организацией каналов передачи данных как от поставщиков данных (контроллеров, УСПД, УСО), так и между иерархическими уровнями системы, зачастую разделенными сотнями километров. В большинстве случаев существующие каналы связи не отличаются качеством и надежностью, а построение специализированных линий передачи данных невозможно по экономическим причинам.

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

Следующий вопрос возникает при выборе стандарта передачи данных. Стандарт для передачи данных желательно иметь открытый, широко распространенный, поддерживаемый большинством независимых разработчиков и оборудования, и ПО (в частности, SCADA-систем). И если по транспортному уровню на эту роль оптимально подходит протокол TCP/IP, то с протоколом верхнего уровня ситуация остается неясной. Идеальным ответом было бы использование одного и того же протокола на всех уровнях создаваемой системы. Стандарт ОРС как раз годится на роль универсального, но при условии решения проблем, связанных с функционированием COM/DCOM.

Решение появилось вместе с новым классом программных продуктов, названных коммуникационными OPC-серверами. Их основная задача – качественная передача данных. В табл. 5.1 представлены некоторые из них.

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

Одним из основных отличительных достоинств SplitOPC (на которые он изначально и был ориентирован) являются высокая производительность и устойчивость в условиях работы с большими объемами данных по каналам связи низкого качества. SplitOPC обладает рядом уникальных возможностей, позволяющим на его основе строить географически, иерархически и административно распределенные системы сбора данных и управления в реальном масштабе времени (рис.5.1).

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


            1. “Сквозная” передача данных, независимо от нахождения узлов в различных сегментах локальной/глобальной сети, учитывая установленные брандмауэры (firewall).

            2. Определение и создание нового маршрута доступа к данным в случае разрыва старого (динамическая перемаршрутизация). Автоматически находится новый (резервный) путь передачи данных в случае потери связи по работающему маршруту. При восстановлении более короткой цепочки передачи информации маршрут вновь автоматически перестраивается с целью уменьшения накладных расходов.

            3. “Горячее” резервирование с автоматическим “подхватом” роли в случае выхода из строя основного сервера (требуется дублирование серверов).

            4. Поддержка криптозащиты любых сегментов межсетевого трафика с произвольной длиной ключа. На рис. 5.1 приведен пример построения распределенной системы передачи данных с использованием перечисленных возможностей.

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

            Например, на рис. 5.2 показано, как с помощью таблиц глобальных псевдонимов и системы именования сигналов возможно “упорядочивание” структуры имен сигналов и автоматическое построение иерархической системы, в которой пользователь, находящийся, к примеру, в Казани, по имени тега MSK.TUM.NBR.NAD.Pout получает доступ к значению сигнала с именем 142_Pвых, сформированному контроллером в ранее установленной АСУ ТП в районе Надыма.

            7. Высокая скорость передачи большого количества тегов (до 200 000) в режиме реального времени, использование уникальных алгоритмов сжатия, позволяющих передавать требуемые объемы данных по низкоскоростным каналам связи (табл. 5.2).

Рис. 5.2. Пример построения иерархической структуры имен сигналов

При оценке пропускной способности коммутируемого соединения использовались модемы 3COM, Zyxel и GSM Siemens TC35i. В последнем столбце приведены значения, рассчитанные исходя из процентного соотношения часто/редко меняющихся сигналов, встречающегося в реальных условиях на объектах промышленной автоматизации.

8. Гарантированное время для прохождения команд телемеханики достигается работой встроенной системы приоритетов, при этом команды управления имеют наивысший приоритет.

9. Указание прав доступа (чтение, запись) к определенным группам сигналов предотвращает возможность несанкционированной отдачи команды или изменения значений. Указанное на рис. 5.3 время задержки в 100 мс учитывает задержку передачи команды непосредственно на промежуточном узле, т.е. время обработки команды и перехода IP→OPC→IP.

Рис.5.3. Задержки при передаче команд телемеханики
В случае достаточной пропускной способности канала, например, в локальной сети, и гарантированно малого времени прохождения пакета по канальной/сетевой инфраструктуре это значение может использоваться в качестве коэффициента для предварительного расчета времени прохождения команды телемеханики. При выполнении этого условия в реальных проектах для расчета задержки данный коэффициент (100 мс) требуется умножить на количество промежуточных узлов. Если же время прохождения пакета не гарантированно, как в случае передачи через Интернет по имеющимся каналам связи, требуется учитывать потери времени на передачу пакета и возможные задержки в коммуникационном оборудовании и производить расчет поправки для каждого конкретного случая. На рис. 5.3 показан канал Москва-Тюмень (2 Мбит/с), для которого величина поправки составляет ~800 мс, что в результате дает примерно секундную задержку при прохождении команды телемеханики. Столь богатая функциональность и высокая надежность работы SplitOPC обусловили широкую распространенность продукта – в частности, на начало2005 г. в России и в сопредельных государствах на базе SplitOPC реализованы десятки распределенных систем сбора данных и управления (телемеханика, системы диспетчерского контроля и управления –СДКУ, узлы учета нефти, АСУ ТП распределенных объектов и др.), в которых установлено более 300 копий продукта.

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

6. Примеры реализации ОРС-технологии

На приведенной ниже структурной схеме показано использование программы «OPC-Процессор» в объединенной диспетчерской службе Оршанских Электрических Сетей.

OPC-Процессор собирает данные с двух OPC-серверов — Симпс-OPC и ТК-РЭС OPC, для которых он является клиентом. Обработанные данные OPC-Процессор передает для отображения двум OPC-клиентам ТМ2000, один из которых подключен локально, а другой получает данные через ЛВС. Для этих клиентов OPC-Процессор является сервером. Кроме этого, собранные данные передают серверу щита АРКМЕД-OPC по клиентскому интерфейсу. Все программы, работающие в данном комплексе, отечественной разработки.
Структура взаимодействия OPC-компонентов в Оршанских ЭС

            7. Список использованной литературы

1.      Дэвид Чеппел. ActiveX и OLE. – Microsoft Press 1997.

2.      Адам Деннинг. ActiveX для Windows 95, Windows NT.

3.      Э. Трельсен. Модель COM и применение ATL 3.0. «BHV –Санкт-Петербург», 2000.

4.      Спецификация на разработку OPC серверов и клиентов.

5.      Спецификация на протокол обмена данными MODBUS.

6.      Описание стандарта OPC Data Access 1.0.

http://www.opcfoundation.org
http://www.asutp.ru/go/?id=600094&url=www.rtsoft.ru
http://www.rtsoft.ru/products/OPC

Bukvasha