OPC UA
OPC Unified Architecture (англ. Унифицированная архитектура OPC) — спецификация, определяющая передачу данных в промышленных сетях и взаимодействие устройств в них. Разработана промышленным консорциумом OPC Foundation и значительно отличается от его предшествующих спецификаций. Первая версия Унифицированной архитектуры была выпущена после 3 лет работ над спецификацией и еще 1 года прототипирования.
Нововведения
Предыдущие спецификации 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, HAD), методы, которые могут быть вызваны (Commands), и инициирующие события (triggering events), которые могут быть переданы (AE, DA DataChange). Узлы используются для обработки данных наравне со всеми другими типами метаданных. Используемое пространство имён OPC теперь также включает модель типов, используемую для описания всех возможных типов данных. Основываясь на вышеизложенном, другие организации, например, EDDL, определяют их собственный источник информации. Клиентское программное обеспечение может имеет возможность проверки того, какой из так называемых Профилей поддерживает сервер. Это необходимо для получения информации, поддерживает серверо функциональности только DA или кроме того поддерживает функции AE, HAD и т. д. Дополнительно, может быть получена информация поддерживает ли сервер, например, профиль EDDL и, следовательно, клиент знает, что здесь также доступно описание определённого EDDL устройства. Добавленными новыми и важными возможностями OPC UA являются:
- Поддержка резервирования.
- Пульс соединения в обоих направлениях. Это означает, что и сервер, и клиент распознают разъединение.
- Буферизация данных и подтверждения передачи данных. Потеря соединения больше не приводит к потере данных. Потерянные датаграммы доставляются повторно.
Протоколы
Как описано выше есть два протокола. Прикладной программист будет распознавать это только через различие в URL передаваемые им для двоичного протокола opc.tcp://Server и http://Server для веб-служб. Иначе говоря, OPC UA работает полность прозранчо для API.
1. Двоичный протокол
- лучшая производительность, минимальные накладные расходы
- потребляет минимум ресурсов (не требуются парсер XML, SOAP и HTTP, что важно для встраиваемых устройств)
- наилучшая возможная совместимость (двоичный код определён явно и допускает меньшую степень свободы в процессе исполнения в отличии от XML)
- всего один порт TCP (4840) используется для коммуникации и легко может быть туннелирован или пропущен через межсетевой экран.
2. Веб-службы (SOAP)
- лучшая поддержка из доступных инструментов. Легко может быть использован, например, из окружения Java или .Net.
- применимый с межсетевыми экранами. Порт 80 (http) и 443 (https) обычно будут использоваться без дополнительных настроек.
Так как имеющийся стек ANSI C поддерживает оба протокола, то ожидается, что большинство конечных продуктов смогут обмениваться информацией по более эффективному двоичному протоколу.
Спецификации
Спецификация OPC UA является многоэлементной и состоит из следующих частей:
- Концепция
- Модель безопасности
- Модель адресного пространства
- Службы
- Информационная модель
- Распределение служб
- Профили
- Доступ к данным
- Аварийная сигнализация и условия
- Программы
- Доступ к историческим данным
(картинка)
В отличие от спецификаций основывающихся на COM, спецификации UA не являются чистыми определениями приложения. (не определяют реализацию?). Обычно они описывают внутренние механизмы Унифицированной архитектуры, обрабатываемые коммуникационным стеком и нормально лежащие вне пределов интереса тех, кто портирует стек на специфическое устройство, или тех, кто хочет реализовать свой собственный стек UA. Разработчик приложений OPC UA разрабатывает код против OPC UA API и, следовательно, взамен будет в основном использовать документацию API. Несмотря на это, части 3, 4 и 5 также могут быть неинтересны разработчикам приложений.
Коммуникационный стек 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 серверы были показаны на Beckhoff PLC и встраиваемых тестовых платах европейских производителей. Из-за того, что Beckhoff PLC основаны на Windows XP Embedded и встроенный контроллер основан на ОСРВ Euros. (????)
Модель безопасности OPC UA
Безопасность UA состоит из аутентификации и авторизации, шифрования и обеспечения целостности данных при помощи сигнатур. Для этого OPC Foundation не стала заново изобретать колесо, а ориентировалась на спецификации Web Service Security. Для веб-служб используются WS Secure Conversation и следовательно они совместимы с .NET и другими реализациями SOAP. Для двоичного протокола соблюдаются алгоритмы WS Secure Conversation и также конвертируются в двоичный эквивалент. Это теперь называется UA Secure Conversation.
(картинка)
Как видно из рисунка выше, также присутсвует смешаная версия где код двоичен, но транспортным уровнем является SOAP. Это компроментирует эффективность двоичного кодирования и удобной для межсетевых экранов передачи. Двоичное кодирование всегда требует UA Secure Conversation. При аутентификации используются исключительно сертификаты x509. На разработчиков приложений возлагается, чтобы сертификаты ограничивали приложение UA. Например, можно использовать Public Key Infrastructure (PKI) из Active Directory.
OPC UA API
Разработчикам UA предоставлена возможность программировать используя C API, комфортный C++ API или напрямую .NET API. Все программные интерфейсы предоставляют одинаковую функциональность. Коммуникационный стек и API предоставляются OPC Foundation.
Реализация на .NET
Реализация на .NET использует только низшую часть стека ANSI C и реализует остальную часть стека непосредственно в .NET. Это значит что только обработчики сокетов и формирование сообщений интегрированы из стека ANSI C. Десереализация имеет место непосредственно в .NET и следовательно конвертируется напрямую в структуры и объекты .NET. Это даёт лучшую производительность, чем сперва десереализация в структуру C и потом копирование данных в структуру .NET.
Реализация на Java
Различные стеки для Java уже разрабатываются. Но приблизились к .NET в основном 3 варианта. На сегодняшний день трудно определить какой является быстрейшим.
1. Ниболее вероятно, быстрейшим вариантом (в терминах времени разработки) на данный момент является использование полного стека ANSI C и ео инкапсуляция посредством JNI.
- — Недостатком является то, что вы теряете простоту портирования Java. Хотя стек может быть портирован на различные операционные системы, необходимо компилировать его под каждую отдельно.
- — Необходимо копировать данные в границы JNI.
- + Этот метод использует производительность C при десереализации.
2. Код основывается напрямую на сетевом уровне (подобно реализации на .NET) и десереализуется в Java.
- — Остаётся зависимость от стека на C.
- + Одним копированием данных меньше.
3. Реализация полностью на Java
- — Требует значительных инженерных усилий на реализацию
- + Наилучшаяпортируемость
В качестве альтернативы есть простой вариант поддерживающий только протокол веб-службы. Для этого необходим инструментарий SOAP, поддерживающий WS Security.
См. также
- OLE for process control
- OPC Foundation
- OPC Data Access