OPC UA: различия между версиями
[непроверенная версия] | [непроверенная версия] |
Softy (обсуждение | вклад) |
F Motik (обсуждение | вклад) →Категории: категоризация |
||
(не показано 50 промежуточных версий 30 участников) | |||
Строка 1: | Строка 1: | ||
'''OPC Unified Architecture''' ({{lang-en|Унифицированная архитектура OPC}}) — [[спецификация]], определяющая передачу данных в промышленных сетях и взаимодействие устройств в них. Разработана промышленным консорциумом [[OPC Foundation]] и значительно отличается от его предшествующих спецификаций. Первая версия Унифицированной архитектуры была выпущена после 3 лет работ над спецификацией и еще 1 года [[прототипирование|прототипирования]]. |
'''OPC Unified Architecture''' ({{lang-en|Унифицированная архитектура [[OPC]]}}) — [[спецификация]], определяющая передачу данных в промышленных сетях и взаимодействие устройств в них. Разработана промышленным консорциумом [[OPC Foundation]] и значительно отличается от его предшествующих спецификаций. Первая версия Унифицированной архитектуры OPC была выпущена после 3 лет работ над спецификацией и еще 1 года [[прототипирование|прототипирования]]. |
||
== Нововведения == |
== Нововведения == |
||
⚫ | Предыдущие спецификации OPC Foundation опирались на механизмы [[Component Object Model|COM]]/[[Distributed Component Object Model|DCOM]], но несмотря на то, что привязка к COM/DCOM помогает OPC хорошо работать в [[распределённая система управления|распределённых системах]], имеются также и отрицательные стороны: |
||
⚫ | |||
* частые проблемы с конфигурированием DCOM |
* частые проблемы с конфигурированием DCOM |
||
* ненастраиваемые тайм-ауты |
|||
* ненастаиваемые таймауты |
|||
* доступность только в операционных системах Microsoft Windows |
* доступность только в операционных системах Microsoft Windows |
||
* |
* неприменимость безопасности |
||
* нет управления поверх DCOM (COM/DCOM |
* нет управления поверх DCOM (COM/DCOM представляется [[чёрный ящик|чёрным ящиком]], разработчики не имеют доступа к [[исходный код|исходному коду]] и поэтому вынуждены жить с ошибками или неполными реализациями) |
||
Эти и другие причины породили решение о разработке нового независимого коммуникационного стека для OPC UA, который заменит COM/DCOM. |
Эти и другие причины породили решение о разработке нового независимого коммуникационного стека для OPC UA, который заменит COM/DCOM. Основные характеристиками этого стека: |
||
* Мультиплатформенная реализация, включающая реализации на [[Портирование ПО|портируемом]] [[ANSI C]], [[Java]] и [[.NET Framework|.NET]]; |
|||
* реализация на портируемом языке программирования ANSI C |
|||
* масштабируемость от встраиваемых систем до |
* [[масштабируемость]] от [[встраиваемые системы|встраиваемых систем]] до [[мейнфрейм]]ов; |
||
* |
* поддержка как многопоточного, так и для однопоточного/однозадачного исполнения, что необходимо для портирования стека на встраиваемые устройства; |
||
* |
* реализация безопасности, основанная на новых стандартах; |
||
* настройка |
* настройка [[Тайм-аут (телекоммуникации)|тайм-аутов]] для каждой службы; |
||
* формирование больших датаграмм. |
* формирование больших [[Датаграмма|датаграмм]]. |
||
Этот коммуникационный стек отражает только начало различных инноваций. Унифицированная архитектура OPC является |
Этот коммуникационный стек отражает только начало различных инноваций. Унифицированная архитектура OPC является [[сервисно-ориентированная архитектура|сервисно-ориентированной архитектурой]] (SOA) и основана на различных логических уровнях. |
||
<!-- В en-wiki здесь был рисунок, но теперь он удалён --> |
<!-- В en-wiki здесь был рисунок, но теперь он удалён --> |
||
Базовые сервисы OPC — это описания абстрактных методов, независящие от протокола и обеспечивающий основу всей функциональности OPC UA. Транспортный уровень помещает эти методы в протокол, что означает что он отвечает за [[сериализация|сериализацию/десериализацию]] данных и передачу их по сети. Для этих целей определены два протокола. Один двоичный TCP протокол, оптимизированный для высокой производительности, и второй на основе [[веб-сервис]]ов. |
|||
Информационная модель OPC больше не основывается только на иерархических папках, элементах и свойствах, вместо этого используется, так называемая, полная ячеистая сеть, основанная на узлах. Кроме того, эти узлы могут передавать всё многообразие метаинформации. В простейшем случае узел можно сравнить с объектом, известным из объектно-ориентированного программирования. Он имеет атрибуты доступные для чтения (DA, HDA), методы, которые могут быть вызваны (Commands), и инициирующие события (triggering events), которые могут быть переданы (AE, DA DataChange). Узлы используются для обработки данных наравне со всеми другими типами [[Метаданные|метаданных]]. Используемое пространство имён OPC теперь также включает модель типов, используемую для описания всех возможных типов данных. Основываясь на вышеизложенном, другие организации, например, EDDL, определяют свой собственный источник информации. Клиентское программное обеспечение может иметь возможность проверки того, какой из так называемых Профилей поддерживает сервер. Дополнительно, может быть получена информация о том, поддерживает ли сервер, например, профиль EDDL и, следовательно, клиент может узнать, что здесь также доступно описание определённого [[EDDL]] устройства. Добавленными новыми и важными возможностями OPC UA являются: |
|||
* Поддержка резервирования. |
* Поддержка резервирования. |
||
* |
* Двустороний «[[Heartbeat-сообщение|heartbeat]]». Это означает, что и сервер, и клиент распознают разъединение. |
||
* Буферизация данных и подтверждения передачи данных. Потеря соединения больше не приводит к потере данных. Потерянные датаграммы доставляются повторно. |
* Буферизация данных и подтверждения передачи данных. Потеря соединения больше не приводит к потере данных. Потерянные датаграммы доставляются повторно. |
||
== Протоколы == |
== Протоколы == |
||
⚫ | |||
⚫ | |||
1. Двоичный протокол |
1. Двоичный протокол |
||
Строка 37: | Строка 37: | ||
* лучшая производительность, минимальные накладные расходы |
* лучшая производительность, минимальные накладные расходы |
||
* потребляет минимум ресурсов (не требуются парсер XML, SOAP и HTTP, что важно для встраиваемых устройств) |
* потребляет минимум ресурсов (не требуются парсер XML, SOAP и HTTP, что важно для встраиваемых устройств) |
||
* наилучшая возможная совместимость (двоичный код определён явно и допускает меньшую степень свободы в процессе исполнения в |
* наилучшая возможная совместимость (двоичный код определён явно и допускает меньшую степень свободы в процессе исполнения в отличие от XML) |
||
* всего один порт TCP (4840) используется для коммуникации и легко может быть туннелирован или пропущен через межсетевой экран. |
* всего один порт TCP (4840) используется для коммуникации и легко может быть туннелирован или пропущен через межсетевой экран. |
||
Строка 45: | Строка 45: | ||
* применимый с межсетевыми экранами. Порт 80 (http) и 443 (https) обычно будут использоваться без дополнительных настроек. |
* применимый с межсетевыми экранами. Порт 80 (http) и 443 (https) обычно будут использоваться без дополнительных настроек. |
||
Так как имеющийся стек ANSI C поддерживает оба протокола, то ожидается, что большинство конечных продуктов смогут обмениваться информацией по более эффективному двоичному протоколу. |
Так как имеющийся стек [[ANSI C]] поддерживает оба протокола, то ожидается, что большинство конечных продуктов смогут обмениваться информацией по более эффективному двоичному протоколу. |
||
== Спецификации == |
== Спецификации == |
||
Спецификация OPC UA является многоэлементной и состоит из следующих частей: |
Спецификация OPC UA является многоэлементной и состоит из следующих частей: |
||
# Основные понятия |
|||
# Концепция |
|||
# Модель безопасности |
# Модель безопасности |
||
# Модель адресного пространства |
# Модель адресного пространства |
||
# Сервисы |
|||
# Службы |
|||
# Информационная модель |
# Информационная модель |
||
# Протоколы |
|||
# Распределение служб |
|||
# Профили |
# Профили |
||
# Доступ к данным |
# Доступ к данным |
||
# Аварийная сигнализация и условия |
# Аварийная сигнализация и условия |
||
# Доступ к программам |
|||
# Программы |
|||
# Доступ к |
# Доступ к архивным данным |
||
<!-- В en-wiki здесь был рисунок, но теперь он недоступен --> |
<!-- В en-wiki здесь был рисунок, но теперь он недоступен --> |
||
В |
В противоположность спецификациям, основывающихся на COM, спецификации Унифицированной архитектуры не являются чисто прикладными. Они описывают существенно внутренние механизмы UA, функционирующие на базе коммуникационного стека, и обычно представляют интерес только для тех, кто портирует 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 и встроенный контроллер основан на [[ОСРВ]] европейских производителей. |
||
⚫ | |||
⚫ | Зелёные части |
||
== Модель безопасности OPC UA == |
== Модель безопасности OPC UA == |
||
Безопасность UA состоит из аутентификации и авторизации, шифрования и обеспечения целостности данных при помощи сигнатур. Для этого OPC Foundation не стала заново изобретать колесо, а ориентировалась на спецификации Web Service Security. Для веб-служб используются WS Secure Conversation и следовательно они совместимы с .NET и другими реализациями SOAP. Для двоичного протокола соблюдаются алгоритмы WS Secure Conversation и также конвертируются в двоичный эквивалент. Это теперь называется UA Secure Conversation. |
Безопасность 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. |
||
⚫ | |||
⚫ | Как видно из рисунка выше, также |
||
== OPC UA API == |
== OPC UA API == |
||
Разработчикам UA предоставлена возможность программировать используя C API, комфортный C++ API или напрямую .NET API. Все программные интерфейсы предоставляют одинаковую функциональность. Коммуникационный стек и API предоставляются OPC Foundation. |
Разработчикам UA предоставлена возможность программировать используя C API, комфортный C++ API или напрямую .NET API. Все программные интерфейсы предоставляют одинаковую функциональность. Коммуникационный стек и API предоставляются OPC Foundation. |
||
== Реализация на .NET == |
== Реализация на .NET == |
||
⚫ | Реализация на .NET использует только низшую часть стека ANSI C и реализует остальную часть стека непосредственно в .NET. Это значит что только обработчики сокетов и формирование сообщений интегрированы из стека ANSI C. [[сериализация|Десериализация]] имеет место непосредственно в .NET и следовательно конвертируется напрямую в структуры и объекты .NET. Это даёт лучшую производительность, чем сперва [[сериализация|десериализация]] в структуру C и потом копирование данных в структуру .NET. |
||
⚫ | Реализация на .NET использует только низшую часть стека ANSI C и реализует остальную часть стека непосредственно в .NET. Это значит что только обработчики сокетов и формирование сообщений интегрированы из стека ANSI C. |
||
== Реализация на Java == |
== Реализация на Java == |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
2. Код основывается напрямую на сетевом уровне (подобно реализации на .NET) и десереализуется в Java. |
2. Код основывается напрямую на сетевом уровне (подобно реализации на .NET) и десереализуется в Java. |
||
⚫ | |||
: − Остается зависимость от стека на C. |
|||
⚫ | |||
3. Реализация полностью на Java |
3. Реализация полностью на Java |
||
: + Наилучшая портируемость. |
|||
⚫ | |||
⚫ | |||
⚫ | |||
* + Наилучшаяпортируемость |
|||
⚫ | |||
== См. также == |
|||
* OLE for process control |
|||
* OPC Foundation |
|||
* OPC Data Access |
|||
== Ссылки == |
== Ссылки == |
||
* [http://www.opcfoundation.org/ OPC Foundation] |
* [http://www.opcfoundation.org/ OPC Foundation] |
||
* [http://www.unified-automation.com/ UA OPC SDK] |
|||
* [http://teslascada.com/ Android OPC UA SCADA] |
|||
* [http://asneg.github.io/projects/opcuastack ASNeG OPC UA Stack] — Открытая реализация на C++ |
|||
{{нет источников|дата=2015-01-25}} |
|||
[[Категория:Автоматизация]] |
[[Категория:Автоматизация]] |
||
[[Категория:Индустрия 4.0]] |
|||
[[en:OPC Unified Architecture]] |
|||
[[de:OPC Unified Architecture]] |
|||
[[pl:OPC Unified Architecture]] |
Текущая версия от 19:30, 8 марта 2022
OPC Unified Architecture (англ. Унифицированная архитектура OPC) — спецификация, определяющая передачу данных в промышленных сетях и взаимодействие устройств в них. Разработана промышленным консорциумом OPC Foundation и значительно отличается от его предшествующих спецификаций. Первая версия Унифицированной архитектуры OPC была выпущена после 3 лет работ над спецификацией и еще 1 года прототипирования.
Нововведения
[править | править код]Предыдущие спецификации OPC Foundation опирались на механизмы COM/DCOM, но несмотря на то, что привязка к COM/DCOM помогает OPC хорошо работать в распределённых системах, имеются также и отрицательные стороны:
- частые проблемы с конфигурированием DCOM
- ненастраиваемые тайм-ауты
- доступность только в операционных системах Microsoft Windows
- неприменимость безопасности
- нет управления поверх DCOM (COM/DCOM представляется чёрным ящиком, разработчики не имеют доступа к исходному коду и поэтому вынуждены жить с ошибками или неполными реализациями)
Эти и другие причины породили решение о разработке нового независимого коммуникационного стека для OPC UA, который заменит COM/DCOM. Основные характеристиками этого стека:
- Мультиплатформенная реализация, включающая реализации на портируемом ANSI C, Java и .NET;
- масштабируемость от встраиваемых систем до мейнфреймов;
- поддержка как многопоточного, так и для однопоточного/однозадачного исполнения, что необходимо для портирования стека на встраиваемые устройства;
- реализация безопасности, основанная на новых стандартах;
- настройка тайм-аутов для каждой службы;
- формирование больших датаграмм.
Этот коммуникационный стек отражает только начало различных инноваций. Унифицированная архитектура OPC является сервисно-ориентированной архитектурой (SOA) и основана на различных логических уровнях.
Базовые сервисы OPC — это описания абстрактных методов, независящие от протокола и обеспечивающий основу всей функциональности OPC UA. Транспортный уровень помещает эти методы в протокол, что означает что он отвечает за сериализацию/десериализацию данных и передачу их по сети. Для этих целей определены два протокола. Один двоичный TCP протокол, оптимизированный для высокой производительности, и второй на основе веб-сервисов.
Информационная модель OPC больше не основывается только на иерархических папках, элементах и свойствах, вместо этого используется, так называемая, полная ячеистая сеть, основанная на узлах. Кроме того, эти узлы могут передавать всё многообразие метаинформации. В простейшем случае узел можно сравнить с объектом, известным из объектно-ориентированного программирования. Он имеет атрибуты доступные для чтения (DA, HDA), методы, которые могут быть вызваны (Commands), и инициирующие события (triggering events), которые могут быть переданы (AE, DA DataChange). Узлы используются для обработки данных наравне со всеми другими типами метаданных. Используемое пространство имён OPC теперь также включает модель типов, используемую для описания всех возможных типов данных. Основываясь на вышеизложенном, другие организации, например, EDDL, определяют свой собственный источник информации. Клиентское программное обеспечение может иметь возможность проверки того, какой из так называемых Профилей поддерживает сервер. Дополнительно, может быть получена информация о том, поддерживает ли сервер, например, профиль EDDL и, следовательно, клиент может узнать, что здесь также доступно описание определённого EDDL устройства. Добавленными новыми и важными возможностями OPC UA являются:
- Поддержка резервирования.
- Двустороний «heartbeat». Это означает, что и сервер, и клиент распознают разъединение.
- Буферизация данных и подтверждения передачи данных. Потеря соединения больше не приводит к потере данных. Потерянные датаграммы доставляются повторно.
Протоколы
[править | править код]Как описано выше есть два протокола. Прикладной программист будет распознавать это только через различие в 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 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 и встроенный контроллер основан на ОСРВ европейских производителей.
Модель безопасности 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.
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.
- + Этот метод использует производительность C при десериализации.
- − Теряется простота портирования Java. Хотя стек может быть портирован на различные операционные системы, необходимо компилировать его под каждую отдельно;
- − Необходимо копировать данные в границы JNI.
2. Код основывается напрямую на сетевом уровне (подобно реализации на .NET) и десереализуется в Java.
- + Одним копированием данных меньше.
- − Остается зависимость от стека на C.
3. Реализация полностью на Java
- + Наилучшая портируемость.
- − Требует значительных инженерных усилий на реализацию.
В качестве альтернативы есть простой вариант, поддерживающий только протокол веб-службы. Для этого необходим инструментарий SOAP, поддерживающий WS Security.
Ссылки
[править | править код]- OPC Foundation
- UA OPC SDK
- Android OPC UA SCADA
- ASNeG OPC UA Stack — Открытая реализация на C++
В статье не хватает ссылок на источники (см. рекомендации по поиску). |