Технология OPС Unified Architecture

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Министерство образования и науки РФ

ФГ БОУ ВПО

«УРАЛЬСКИЙ ГОСУДАРСТВЕННЫЙ ГОРНЫЙ УНИВЕРСИТЕТ»

Кафедра автоматики и компьютерных технологий

РЕФЕРАТ

по дисциплине «ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В СИСТЕМАХ АВТОМАТИЗАЦИИ»

Тема: Технология OPС Unified Architecture

Студент Муратова О.Р.

Екатеринбург, 2016

Содержание

• Введение
• 1. OPC UNIFIED ARCHITECTURE
• 2. Нововведения
• 3. Структура программного обеспечения
• 4. Спецификации
• 5. Сосуществование разных поколений
• 6. Унифицированная архитектура повышает влиятельность технологии OPC
• 7. Быстрое реагирование на сбои и резервирование передачи данных
• 8. Использование OPC UA в работе
• 9. Коммуникационный стек OPC UA
• 10. Модель безопасности OPC UA
• 11. Обновление данных в результате опроса или события
• 12. Реализация потенциала OPC UA
• 13. Тунеллинг OPC UA
• 14. Что позволяет "OPC Data Center"
• 15. OPS UA - на пути к промышленной информационной революции
• Литература

Введение

Для упрощения и удешевления реализации информационных обменов в системах промышленной автоматизации в 1996 году была предложена технология OPС (OLE for Process Control), в которой единообразие в настройках стыков SCADA-системы с «внешним миром» достигается за счет использования определенного шлюза, унифицирующего интерфейс взаимодействия с клиентом и скрывающего частный протокол отдельных средств автоматизации. Использование «классической» OPС ограничено платформой Windows, так как это не протокол передачи данных, а именно программная технология, основанная на механизме удаленного вызова процедур с использованием стека DCOM. Это накладывает свой негативный отпечаток на такие параметры процесса взаимодействия по OPС, как безопасность, надежность и резервирование. Проанализировав недочеты текущих спецификаций, ассоциация OPC Faundation разработала оригинальную унифицированную технологию, которая добавляет новые возможности, призванные помочь пользователям построить усовершенствованные решения для систем автоматизации.

Какие изменения в типах передачи данных, архитектуре доступа к различным категориям данных и в структуре программного обеспечения несет в себе новое поколение OPC? Какие преимущества дает эта технология? На эти вопросы будут ответы ниже, используя разработки одного из первых и наиболее последовательных участников OPC Foundation - компании ICONICS, которая в этом году добавила поддержку OPC Unified Architecture (OPC UA) в свои ключевые продукты.

Технология OPC.

Сравнительно давно в АСУ ТП обмен данными между программами и устройствами осуществляется с использованием стандарта OPC. Стандарт разработан ассоциацией OPC Foundation. По сути стандарт является аналогом технологии Plug n Play для программного обеспечения в сфере промышленной автоматизации. В настоящее время в ассоциации более 500 членов, и поддержка стандарта осуществляется всеми крупными производителями аппаратных и программных средств АСУ ТП и промышленными ассоциациями.

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

Первый тип интерфейса предназначен для обмена большими объёмами информации при высокой пропускной способности. Это специализированный интерфейс OLE custom interface.

Второй тип интерфейса - OLE Automation interface - позволяет получать доступ к данным более простым способом. Он предназначен для использования в программах, написанных на языках Visual Basic (VB) и Visual Basic для приложений (VBA).

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

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

Группы на сервере могут быть доступны нескольким клиентам одновременно или только одному клиенту. OPC группа содержит набор OPC элементов, в которых хранятся данные, поступившие от соответствующего устройства управления процессами. Клиент может произвольно объединять элементы в группы. В основе стандарта ОРС лежит технология DCOM (Distributed Component Object Model). Эта технология, встроенная в Windows, предназначена для организации взаимодействия между различными приложениями, в том числе и между приложениями, работающими на разных компьютерах. В настоящее время DCOM является основным средством взаимодействия программ в системе. Благодаря этой технологии между программами происходит двусторонний обмен, который позволяет не только клиенту вызывать функции сервера, но и серверу вызывать функции клиента. Но при передаче данных на большие расстояния, что безусловно необходимо для АСУ ТП, DCOM имеет серьёзные недостатки. Один из главных недостатков -- неприспособленность для работы в глобальной сети Интернет.

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

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

Для решения этой проблемы можно использовать технологию туннелинга (tunneling) TCP, с помощью которой осуществляется передача данных через стандартный 80 й порт брандмауэра. Этот порт обычно используется для передачи данных по HTTP протоколу (протокол передачи гипертекста), и поэтому он, как правило, открыт. Но для осуществления туннелинга и передачи данных требуется установка специального программного обеспечения, входящего в Windows, COM Internet Services и IIS web сервер (Internet Information Server). Успешный доступ через DCOM происходит в том случае, когда компьютеры находятся в одном домене или в одной рабочей группе, что указывает на возможность использования тунелинга TCP соответствующим образом настроенными брандмауэрами в пределах одного домена. Кроме проблем, связанных с передачей данных, существуют проблемы с аутентификацией клиента.

логический контроллер программный безопасность

1. OPC UNIFIED ARCHITECTURE

Типовая схема использования OPC для доступа к данным ПЛК и SCADA-систем показана на рис.1.

Рисунок 1

Говоря о «классической» OPC, мы в первую очередь имеем в виду передачу данных согласно спецификациям OPC DA ( Data Access - масштабе реального времени), OPC HAD (Historical Data Access - архивов изменений параметров) и OPC A&E (Alarm and Events -тревог и событий). Популярность последних двух спецификаций существенно меньше, чем у OPC DA, не в последнюю очередь потому, что передача данных архивов и аварийных событий требовала от производителя оборудования разработки еще двух отдельных программ, а от разработчика системы диспетчеризации - настройки еще одного или двух дополнительных информационных стыков с серверами OPC HAD и OPC A&E, имеющим независимые и не связанные с OPC DA адресные пространства. В OPC UA предусматривается объединение механизмов адресации и доступа к разным категориям данных.

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

Вторая особенность OPC UA - полностью переработанный механизм взаимодействия OPC - клиента и OPC - сервера. Произошел отказ от DCOM в пользу обмена бинарными или XML - сообщениями (то есть OPC UA - это именно протокол передачи данных; к такому механизму намного «дружественнее» относятся межсетевые экраны - firewall - и прочие средства информационной безопасности; с другой стороны, отказ от DCOM вызван и ростом популярности решений под Linux в 2000-х гг.). Также стандарт определяет гибкий механизм управления сетевыми и логическими соединениями OPC - серверов и OPC - клиентов для поддержки резервированных конфигураций и т.п. Более того, интерфейс OPC - сервера рассматривается как набор сервисов, а значит, данные систем автоматизации могут стать доступными другим приложениям в единой сервисной шине предприятия (ESB), построенной по технологии SOA.

Третья особенность OPS UA - отказ от использования механизмов контроля прав доступа Windows (основанных на проверке имени/пароля пользователя, от имени которого запускается OPC - клиент), разработчики OPC UA предложили более современный способ контроля с использованием сертификатов. Также предусмотрена возможность шифрования передаваемых данных.

Естественно, удалено внимание и вопрос сохранения уже сделанных предприятиями инвестиций. Использование «классической» OPC возможно и в OPC UA - среде: специальная оболочка (wrapper) обеспечивает доступ к обычному OPC DA - серверу, а proxy - модуль позволяет OPC DA - клиенту взаимодействовать с новыми OPC UA - серверами.

Рассмотрим подробнее технические особенности OPC Unified Architecture и возможность их использования для изменения существующего порядка разработки систем диспетчерского управления.

2. Нововведения

Предыдущие спецификации OPC Foundation опирались на механизмы COM/DCOM, но несмотря на то, что привязка к COM/DCOM помогает OPC хорошо работать в распределённых системах, имеются также и отрицательные стороны:

· частые проблемы с конфигурированием DCOM

· ненастраиваемые тайм-ауты

· доступность только в операционных системах Microsoft Windows

· неприменимость безопасности

· нет управления поверх DCOM (COM/DCOM представляется чёрным ящиком, разработчики не имеют доступа к исходному коду и поэтому вынуждены жить с багами или неполными реализациями)

Эти и другие причины породили решение о разработке нового независимого коммуникационного стека для OPC UA, который заменит COM/DCOM. Ожидаемыми характеристиками этого стека будут:

· реализация на портируемом языке программирования ANSI C

· масштабируемость от встраиваемых систем домейн фреймов

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

· собственная реализация безопасности, основанная на новых стандартах, реализующих «настоящую» безопасность

· настройка тайм-аутов для каждой службы

· формирование больших дата грамм.

Этот коммуникационный стек отражает только начало различных инноваций. Унифицированная архитектура OPC является сервисно-ориентированной архитектурой(SOA) и основана на различных логических уровнях.

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

Он имеет атрибуты доступные для чтения (DA, HDA), методы, которые могут быть вызваны (Commands), и инициирующие события (triggering events), которые могут быть переданы (AE, DA DataChange). Узлы используются для обработки данных наравне со всеми другими типамиметаданных. Используемое пространство имён OPC теперь также включает модель типов, используемую для описания всех возможных типов данных. Основываясь на вышеизложенном, другие организации, например, EDDL, определяют свой собственный источник информации. Клиентское программное обеспечение может иметь возможность проверки того, какой из так называемых Профилей поддерживает сервер. Дополнительно, может быть получена информация о том, поддерживает ли сервер, например, профиль EDDL и, следовательно, клиент может узнать, что здесь также доступно описание определённого EDDL устройства. Добавленными новыми и важными возможностями OPC UA являются:

· Поддержка резервирования.

· Пульс соединения в обоих направлениях. Это означает, что и сервер, и клиент распознают разъединение.

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

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

Переход от межпрограммного взаимодействия поверх DCOM к передаче пакетов позволяет исполнять OPC - серверы и OPC - клиенты не только на компьютерах под управлением отличных от Windows операционных систем, но и в самих контроллерах (рис. 2а).

Рисунок 2

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

При любом варианте отказ от использования проприетарного протокола в пользу OPC UA для взаимодействия с ПЛК - это сокращение разнотипности средств, используемых при построении системы автоматизации, приводящее не только к снижению трудозатрат при пусконаладочных работах, но и облегчающее модернизацию отдельных компонентов системы в будущем. Также при реализации сценария удаленного взаимодействия OPC - клиента и OPC - сервера ( не через ЛВС, а через региональную сеть передачи данных в масштабе региона - WAN), когда трафик TCP/IP проходит через маршрутизаторы и межсетевые экраны ( см. взаимодействие центрального офиса и филиала на рис.1), «классическая» OPC требует использования программного обеспечения промежуточного слоя, например, ICONICS GenBroker или ICON - ICS DataWorX OPC Tunnelling. OPC UA не использует такой прослойки, ей безразлично, установлены ли клиент и сервер на компьютерах, находящихся в соседних комнатах или в разных городах.

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

Спецификация OPC UA является многоэлементной и состоит из следующих частей:

1. Основные понятия

2. Модель безопасности

3. Модель адресного пространства

4. Сервисы

5. Информационная модель

6. Протоколы

7. Профили

8. Доступ к данным

9. Аварийная сигнализация и условия

10. Доступ к программам

11. Доступ к архивным данным

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

Прикладные программисты пишут код на OPC UA API и поэтому, в основном, пользуются документацией по API. Тем не менее, части 3, 4 и 5 спецификаций могут быть интересны и для прикладных программистов.

5. Сосуществование разных поколений

«Классические» продукты ОРС, основанные на DCOM, и продукты OPC UA будут сосуществовать в течение многих лет, а может, и десятилетий. Однако тенденция в пользу OPC UA, особенно на рынке встроенных решений, MES и ERP - очевидна. OPC Foundation и производители OPC продуктов делают многое, чтобы облегчить переход с классических решений OPC на OPC UA. Тулкиты, такие как OPC UA C++ и/или OPC UA .NET от Softing, облегчают процесс адаптации технологии OPC UA и ускоряют вывод на рынок серверов и клиентов OPC UA.

Доступ к настройке

При инсталляции Сервера на платформе Windows, он является Службой Windows и по умолчанию всегда запущен. У него имеется интерфейс - окно настроек. После инсталляции Сервера, чтобы открыть окно настроек, выберите Пуск -Программы - Kontar - Kontar2OPC - Kontar2OPC - Настройка.

Откройте в окне настроек вкладку Сервер OPC UA. Эта вкладка предназначена для настройки обмена данными между OPC UA Сервером и OPC UA клиентами:

Рисунок 3 Настройка подключения к серверу

Таблица 1

Таблица 2

6. Унифицированная архитектура повышает влиятельность технологии OPC

Технология OPC «хорошо себя чувствует» на рынке, не в последнюю очередь благодаря сотрудничеству OPC Foundation с другими консорциумами (например: PLCopen, MES Dachverband, ODVA, MIMOSA, FDI, ADI). Это было бы неслыханным еще 10 лет назад, а теперь стало нормой - организации стремятся распространять свои спецификации и технологии всеми эффективными путями.

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

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

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

Соединение легкости в использовании и максимальной совместимости - что уже долгое время является стандартом в области потребительской электроники - должно стать целью и для производителей продуктов промышленной автоматизации. OPC Foundation будет всячески способствовать этому. Ее основной целью на ближайшие несколько лет станет максимально возможное облегчение процесса принятия этого стандарта производителями. А конечные пользователи систем промышленной автоматизации получат возможность использовать продукцию высочайшего качества, обладающую функциональностью plug-and-play.

7. Быстрое реагирование на сбои и резервирование передачи данных

OPC UA разделяет несколько уровней взаимодействия OPC - клиентов и OPC - серверов. Во-первых, каждый из клиентов устанавливают с сервером свое защищенное сетевое соединение. При этом если в «классической» OPC право доступа клиента к серверу определялось, исходя из прав пользователей Windows, от чьего имени они запускались на соответствующих компьютерах, то в OPC UA клиент и сервер идентифицируют себя цифровыми сертификатами. Во-вторых, в рамках соединения создается сессия - логическое соединение клиента и сервера. Параметром сессии являются уже права отдельного пользователя, использующего OPC - клиент, так как OPC - сервер может вводить ограничения на операции чтения/записи отдельных элементов для разных пользователей. Уже в рамках сессии производится собственно передача данных (выполнение запросов на чтение/запись), а также производится инициализация списка элементов, об изменениях значений которых сервер направляет клиенту уведомление (рис.4 - между соединением, сессией, пропиской, элементом отношения «один ко многим»).

Рисунок 4

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

Отдельно отметим изменения в концепции отправки OPC - сервером уведомлений об изменениях значений отдельных параметров клиентам (механизмы так называемого спонтанного уведомления об изменениях SRBX - spontaneous report by exception). В OPC DA этот механизм был реализован через обратный вызов методов клиента, в OPC UA межпрограммное взаимодействие не используется, а отправляются сообщения. Важной особенностью их отправки является то, что сервер сам определяет момент отправки (по факту изменения значений отдельных параметров), но не создает новых сообщений, а выбирает их из очереди ранее полученных «заготовок» от данного клиента. То есть сначала клиент направляет серверу массив запросов об изменениях (с уникальными ID), сервер их кэширует и по мере появления изменений (или при прохождении заданного периода времени без изменений) отправляет клиенту; далее клиент подтверждает факт получения сообщения. Периодически клиент пополняет очередь на сервере сообщениями с новыми ID. Таким образом исключается возможность неконтролируемого роста числа отправляемых сервером сообщений об изменениях.

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

Транзакционная передача данных

Как уже отмечалось, OPC UA реализует важные изменения и в части организации данных сервера, то есть адресного пространства. Напомним, что в OPC DA теги были сгруппированы иерархически с помощью папок. У каждого тега были обязательные свойства: значение (скалярное или векторное, одного из предопределённых простых типов данных - Int16, Float, String ит.п.); признак достоверности (quality); метка времени. Разработчик OPC сервера мог определять дополнительные свойства для тегов, такие как описание единиц измерения и т.п.; было желательным, чтобы OPC клиент мог считывать значения этих дополнительных свойств наряду с обязательными свойствами. В OPC UA адресное пространство организовано иерархически за счёт введения объектов (в терминах объектно ориентированного программмирования), то есть экземпляров классов.

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

Адаптивность задачи информационного стыка с OPC сервером

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

Рисунок 5

На рис. 5 показан пример: в адресном пространстве OPC UA сервера может быть задано определение класса со списком параметров, поступающих от систем автоматизации и характеризующих режим работы скважины на подземном хранилище или месторождении газа, нефти. OPC клиент, формирующий отчёт по добыче за предыдущий час, может получить список обратных ссылок типа HasTypeDefinition, указывающих от объектов на их класс, то есть получить массив имен объектов и составить запрос на чтение значений переменных QLH из каждого объекта.

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

8. Использование OPC UA в работе

Спецификация OPC UA, разработанная OPC Foundation, состоит на текущий момент из 13 частей и формальным образом описывает различные аспекты логики работы и взаимодействия OPC UA серверов и клиентов. Текст спецификации распространяется только среди организаций членов OPC Foundation, поэтому всем заинтересованным в более детальном изучении особенностей этого нового протокола мы рекомендуем первую из появившихся книг [1].

Однако, в 2010 году, поддержка OPC UA уже реализована в большом количестве коммерческих и бесплатных приложений. Продемонстрируем, как это работает, с использованием 64 битового пакета ICONICS GENESIS64 версии 10, демонстрационных UA сервера и клиента разработки Unified Automation GmbH.

Запустим GraphWorX64. Создаём динамический элемент Process Point, выбираем источник данных - появляется окно Data Browser. Вводим непривычный адрес opc.tcp://192.168.2.143:4841 и подключаемся к демо OPC UA серверу. Обратите внимание: мы указали тип протокола, IP адрес (можно было указать имя хоста), на котором запущен сервер, и номер порта. После подключения для просмотра доступно адресное пространство сервера, но традиционная древовидная структура неинформативна - используя табличное (Grid) или сетевое (Mesh) представления, можно увидеть, что элементы адресного пространства связаны ссылками различных типов. В частности, объект MyDemoObject (рис. 6) группирует (ссылка типа HasComponent) переменные Temperature, Counter, Test1, Test2 и метод SetAllValues. К объектам экземплярам классов тревог ведут также ссылки типа HasCondition и т.д.

Рисунок 6

Выберем переменную Temperature как источник данных для одного элемента Process Point и её свойство Enginee ringUnits - для второго. Переведя Graph WorX64 в режим Runtime, увидим отображаемые значения (рис. 7; снимок экрана также содержит всплывающий при наведении мыши на второй из элементов Process Point поясняющий текст). Данный пример, помимо очевидного подтверждения «это работает», демонстрирует упоминавшуюся ранее возможность представления в OPC UA сервере и передаче клиенту не отдельных значений, а структур данных. В данном случае свойство EngineeringUnits содержит значение (Value), объединяющее элементы UnitID, DisplayName, Description (и еще, если быть точным, пустой NameSpaceIndex). Для адресации к конкретному элементу его имя нужно добавить к адресу (обратите внимание на разделитель «::»), например, чтобы отобразить только «°C», необходимо указать: opc.tcp://192.168.2.143:4841 \\MyDemoObject.Temperature.Engineering Units::DisplayName.

Рисунок 7

Возможности OPC UA оболочек, то есть программного обеспечения доступа к «классическим» OPC серверам с использованием OPC UA клиентов, можно дополнительно испытать, загрузив, например, UA Wrapper компании Unified Automation. Если ранее подключение удалённого OPC сервера требовало использования программного обеспечения туннелирования со стороны и клиента, и сервера (например, GenBroker из состава SCADA пакета ICONICS GENESIS 32), то при применении современных SCADA систем, имеющих OPC UA клиента, можно ограничиться установкой дополнения в виде OPC UA оболочки на стороне сервера. Эти продукты не имеют собственного графического интерфейса и служат только преобразователями протокола; при этом одновременно с их использованием сохраняется возможность и традиционного подключения к OPC серверу.

С другой стороны, отказаться от отдельных традиционных OPC DA серверов позволяет ICONICS OPC UA Server, разработанный ICONICS в партнерстве с фирмой Kepware. Этот продукт при зван создать единую точку доступа к полевым устройствам автоматизации, так как он включает в себя драйверы для связи по более чем 100 протоколам (Allen Bradley DH+, Omron FINS, Siemens S7 MPI, Triconex Ethernet, BACnet, DNP и многие другие). ICONICS OPC UA Server можно протестировать как отдельное приложение (в версиях Standard и Premium), а также в составе пакета GENESIS64 V10. На рис. 8 показана схема применения этого OPC UA сервера. Для каждого протокола, используемого на предприятии, вводится свой «канал», определяющий базовые характеристики стыка, затем для каждого отдельного устройства настраивается перечень сигналов. Эти перечни могут быть выгружены в CSV файл, отредактированы в Excel и загружены обратно, что минимизирует трудозатраты инженера.

Рисунок 8

9. Коммуникационный стек OPC UA

В архитектуре приложения OPC UA, независимо от того, клиентская это часть или серверная, можно выделить следующие уровни. Зелёные части соответствуют COM прокси/заглушкам и предоставляются OPC Foundation. Новым является уровень портирования, который позволяет легко переносить стек UA ANSI C на другие платформы. Портированная версия для Windows и Linux также предоставляется OPC Foundation. Как описывалось ранее, могут быть разработаны приложения основанные наAPI, подобно тому как они программировались в прошлом для COM.

На конференции OPC UA DevCon в октябре 2006 в Мюнхене в живую были представлены первые прототипы. Компания ascolab GmbH, которая также разработала стек ANSI C для OPC Foundation, представила разнообразные прототипы и продемонстрировала впечатляющее взаимодействие UA клиента под Windows/.NET и UA сервера подLinux. К тому же различные UA серверы были показаны наBeckhoffPLCи встраиваемых тестовых платах европейских производителей. Из-за того, что Beckhoff PLC основаны на Windows XP Embedded и встроенный контроллер основан наОСРВевропейских производителей.

10. Модель безопасности OPC UA

Безопасность UA состоит из аутентификации и авторизации, шифрования и обеспечения целостности данных при помощи сигнатур. Для этого OPC Foundation не стала заново изобретать колесо, а ориентировалась на спецификации Web Service Security. Для веб-служб используются WS Secure Conversation и следовательно они совместимы с .NET и другими реализациями SOAP. Для двоичного протокола соблюдаются алгоритмы WS Secure Conversation и также конвертируются в двоичный эквивалент. Это теперь называется UA Secure Conversation. Как видно из рисунка выше, также присутствует смешанная версия, где код двоичен, но транспортным уровнем является SOAP. Это компрометирует эффективность двоичного кодирования и удобной для межсетевых экранов передачи. Двоичное кодирование всегда требует UA Secure Conversation. При аутентификации используются исключительно сертификаты x509. Выбор схемы сертификации, используемой приложением, возлагается на разработчиков приложений. Например, можно использовать Public Key Infrastructure (PKI) из Active Directory.

11. Обновление данных в результате опроса или события

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

Для управления передачей данных между OPC-сервером и SCADA-клиентами в технологии OPC UA используется функция «подписки и мониторинга элемента». С помощью нее SCADA-клиенты могут присоединяться к набору наблюдаемых элементов, после чего сервер «публикует» показания, получаемые с предварительно настроенной частотой (Рис.9). В данном случае «публикует» означает, что сервер отправляет полученные показания клиенту.

Для того чтобы данная функция работала на устройствах ввода/вывода должны быть настроены два режима: интервал выборки и интервал публикации (Рис.10).

Рисунок 9

Рисунок 10

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

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

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

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

Для того чтобы получать данные с подключенных устройств большинство серверов OPC UA используют протоколы опросного типа, например, Modbus. Но опрос, производимый по сотням или даже тысячам тегов, не будет эффективным. Если оборудование поддерживает передачу данных как в результате опроса, так и события, то у Вас появляется возможность выбрать наиболее подходящий способ чтения данных по классификатору (Рис.11), тем самым увеличивая эффективность работы.

Рисунок 11

12. Реализация потенциала OPC UA

Выпуском спецификации OPC UA, организация OPC Foundation представила совершенно новое поколение OPC, которое открывает возможность платформенно-независимых внедрений, а также развивает промышленный стандарт OPC новыми важными свойствами, такими как масштабируемость, безопасность, надежность, соединение с Интернет, высокоскоростные коммуникации. В первую очередь, такие качества, как платформенная независимость и масштабируемость открывают множество возможностей для совершенно новых и экономичных концепций автоматизации. Самые разнообразные встраиваемые устройства, такие как контроллеры, интеллектуальные полевые устройства или приводы, могут использовать экономичные продукты OPC UA, с портами к используемым операционным системам. Это устраняет необходимость в использовании отдельного сервера Windows PC или OPC. Вертикальная интеграция осуществляется с помощью встроенных серверов OPC UA на процессном уровне, серверов OPC UA на уровне систем автоматизации и вплоть до клиентов OPC UA на уровне ERP-систем.

Первыми последователями UA были члены OPC Foundation, сегодня же множество производителей продуктов и решений для автоматизации уже выпустили или в скором времени выпустят продукты с поддержкой OPC UA. Среди них не только признанные разработчики АСУ ТП, ПЛК, ЧМИ/SCADA, но также и разработчики систем ERP или MES. Особый интерес вызывают устройства со встроенными OPC UA серверами, такие как системы управления электродвигателями Siemens Simocode.

Реализация на .NET

Реализация на .NET использует только низшую часть стека ANSI C и реализует остальную часть стека непосредственно в .NET. Это значит что только обработчики сокетов и формирование сообщений интегрированы из стека ANSI C. Десереализация имеет место непосредственно в .NET и следовательно конвертируется напрямую в структуры и объекты .NET. Это даёт лучшую производительность, чем сперва десереализация в структуру C и потом копирование данных в структуру .NET.

Реализация на JAVA

Различные стеки для Java уже разрабатываются. Но приблизились к .NET в основном 3 варианта. На сегодняшний день трудно определить какой является быстрейшим.

1. Наиболее вероятно, что быстрейшим вариантом (в терминах времени разработки) на данный момент является использование полного стека ANSI C и его инкапсуляция посредством JNI.

+ Этот метод использует производительность C придесериализации.

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

? Необходимо копировать данные в границы JNI.

2. Код основывается напрямую на сетевом уровне (подобно реализации на .NET) и десереализуется в Java.

+ Одним копированием данных меньше.

? Остается зависимость от стека на C.

3. Реализация полностью на Java

+ Наилучшая портируемость.

? Требует значительных инженерных усилий на реализацию.

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

13. Тунеллинг OPC UA

Учитывая данные сложности, ОРС сообщество за последние 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 представлена на рис. 12. Все OPC совместимые приложения клиенты могут обмениваться данными с локальными устройствами или по сети.

Рисунок 12

Кроме того, обмен может осуществляться более чем с одним сервером 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.

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

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

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

Рисунок 13

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

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

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

Рисунок 14

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

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

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

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



Рисунок 15

Рисунок 16

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

Использование технологии OPC в 1С

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

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

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

Продукт "OPC Data Center", который является конфигурацией, разработанной на платформе 1С предприятие - имеет собственный сервер сбора данных и полностью снимает с оператора необходимость отслеживать этот процесс.

"OPC Data Center"реализует следующую схему подключения (Рис.17). Сама система содержит много разных вариантов расчета потребления ресурсов, рассмотрим наиболее востребованные из них.

14. Что позволяет "OPC Data Center"

В первую очередь система "OPC Data Center" является автоматизированной системой по учету и контролю за расходованием ресурсов.



Рисунок 17

Издержки, на которые она может влиять в первую очередь:

· соблюдение производственного графика потребления

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

· полностью автоматизированный контроль - экономия трудовых ресурсов

· Рассчитывать КПД на единицу выпущенного продукта.

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

15. OPS UA - на пути к промышленной информационной революции

OPC UA обеспечивает эффективную и безопасную коммуникационную инфраструктуру и имеет потенциал стать стандартным выбором для реализации технологии «Интернет вещей». Спецификация OPC UA задействует принятые международные вычислительные стандарты, что выводит системы автоматизации на один уровень с общей компьютерной индустрией. OPC UA использует стандартные веб-службы, которые являются предпочтительным методом для систем связи и взаимодействия всех сетевых устройств. World Wide Web Consortium (W3C) определяет веб-службы, как «системное программное обеспечение, предназначенное для поддержки взаимодействия типа «устройство-устройство» в сети».

Главная идея состоит в том, что объекты OPC UA, использующие Internet Protocol (IP), обеспечивают прозрачный механизм с открытой архитектурой, целью которого является объединение информации всех систем автоматизации, а также, корпоративных IТ на предприятии. Осуществление связи датчиков, а также контроллеров, между собой играет важную роль для увеличения производства и повышения оперативности производственных процессов.

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

...