Архитектура OPC UA: информационная модель, безопасность, сеансы и транспорт

Структура стандарта IEC 62541

IEC 62541 состоит из 13 пронумерованных частей. Части 1–7 определяют базовую архитектуру; части 8–14 охватывают отображения, безопасность и профили. Для интеграторов систем автоматизации зданий наиболее важны части 1 (Концепции), 3 (Модель адресного пространства), 4 (Сервисы), 6 (Отображения — кодирование и транспорт), 7 (Профили) и дополнительная спецификация IEC 62541-100 (OPC UA для зданий).

Информационная модель: типы NodeClass и ссылки

Каждый элемент данных в сервере OPC UA представлен как Узел в адресном пространстве. Узлы имеют атрибут NodeClass, определяющий их роль. Узлы связаны между собой типизированными Ссылками — например, HasComponent, HasProperty, Organizes, HasSubtype. Это создает ориентированный граф, который клиенты могут просматривать для обнаружения содержимого сервера без предварительного знания структуры данных.

Адресное пространство: пространства имён и обозримое дерево

Адресное пространство структурировано как обозримое дерево. Каждый узел идентифицируется NodeId, состоящим из индекса пространства имён и идентификатора (числового, строкового или GUID). Пространство имён 0 (ns=0) — это всегда стандартное пространство имён OPC UA, содержащее встроенные типы и стандартные узлы. Пространства имён 1+ назначаются сервером для специфического содержимого вендора или приложения. Клиенты узнают таблицу пространств имён через вызов сервиса GetNamespaceArray.

Objects (ns=0;i=85)  ← OPC UA standard root
├── Server (ns=0;i=2253)  ← always present, server diagnostics
└── Building_01 (ns=1;s=Building_01)  ← application namespace
    ├── Floor_02 (ns=1;s=Building_01/Floor_02)
    │   ├── AHU_01 (ns=1;s=AHU_01)  [Object]
    │   │   ├── SupplyAirTemperature (ns=1;s=AHU_01.SAT)  [Variable, Float]
    │   │   │   ├── EngineeringUnits  [Property: "°C"]
    │   │   │   ├── EURange  [Property: Low=0, High=60]
    │   │   │   └── StatusCode  [Property: Good/Bad/Uncertain]
    │   │   ├── FanSpeed (ns=1;s=AHU_01.FanRPM)  [Variable, UInt16]
    │   │   ├── DamperPosition (ns=1;s=AHU_01.Damper)  [Variable, Byte, 0–100%]
    │   │   └── ResetAlarm (ns=1;s=AHU_01.ResetAlarm)  [Method]
    │   └── VAV_Zone_2A (ns=1;s=VAV_2A)  [Object]
    │       ├── RoomTemperature (ns=1;s=VAV_2A.RoomTemp)  [Variable, Float]
    │       └── Setpoint (ns=1;s=VAV_2A.SP)  [Variable, Float, writable]
    └── Meters (ns=1;s=Meters)
        └── Main_kWh (ns=1;s=Meter.kWh)  [Variable, Double]

Клиенты перемещаются от корня Objects с помощью сервиса Browse, следуя по иерархическим ссылкам (HasComponent, Organizes, HasProperty), чтобы обнаружить узлы. Сервис TranslateBrowsePathsToNodeIds позволяет клиентам перейти напрямую к известному пути, не обходя всё дерево — полезно для производительного опроса известных переменных.

Варианты транспорта

OPC UA определяет три транспортные привязки. Выбор влияет на задержку, прохождение через брандмауэр и накладные расходы протокола. OPC UA Binary по TCP — стандарт для интеграции BMS на уровне завода; HTTPS и WebSockets используются для облачных или браузерных интерфейсов.

Режимы безопасности и политики безопасности

Безопасность OPC UA согласовывается на уровне Secure Channel до обмена любыми прикладными сообщениями. Сервер публикует поддерживаемые EndpointDescription (комбинации MessageSecurityMode и SecurityPolicyUri). Клиент выбирает один из них при открытии соединения. Никогда не используйте None в рабочей среде — все данные передаются открытым текстом без защиты целостности.

SecurityPolicyUri выбирает криптографические алгоритмы. Текущие рекомендуемые политики (по состоянию на IEC 62541-7:2022):

Методы аутентификации

Аутентификация выполняется на уровне сеанса (выше защищённого канала). OPC UA определяет три типа токенов ActivateSession. Аутентификация на основе сертификатов является наиболее безопасной и требуется для промышленных стандартов безопасности, таких как IEC 62443-3-3 Уровень безопасности 2.

Сессии и подписки

Сессия создаётся поверх защищённого канала после аутентификации. У сессии есть RequestedSessionTimeout (обычно 60–3600 секунд); если клиент не отправляет keep-alive до истечения таймаута, сервер удаляет сессию и все её подписки. Клиентам следует обрабатывать переподключение с восстановлением сессии или переносом.

Подписки — основной механизм эффективного мониторинга данных. Вместо многократного опроса переменных (что создаёт лишний трафик) клиенты создают подписку с PublishingInterval и добавляют в неё MonitoredItems. Сервер опрашивает каждый MonitoredItem с интервалом SamplingInterval и помещает изменения в очередь; когда срабатывает PublishingInterval, все накопленные уведомления отправляются в одном сообщении PublishResponse.

CreateSubscription request:
  RequestedPublishingInterval: 1000  // ms — how often server sends Publish
  RequestedMaxKeepAliveCount: 10     // Publish cycles before keep-alive sent
  RequestedLifetimeCount: 30         // LifetimeCount × PublishingInterval = session timeout
  MaxNotificationsPerPublish: 1000   // cap notifications per PublishResponse
  PublishingEnabled: true

MonitoredItem parameters:
  SamplingInterval: 500              // ms — server samples item at this rate
                                     // must be ≥ server MinSupportedSampleRate
  QueueSize: 10                      // buffer for overrun; 1 = last value only
  DiscardOldest: true                // discard oldest on queue overflow
  DeadbandType: None / Absolute / Percent
  DeadbandValue: 0.5                 // Absolute: only report if change > 0.5 units
                                     // Percent: only report if change > 0.5% of EURange

Спецификации-компаньоны OPC UA

Спецификации-компаньоны расширяют базовый стандарт OPC UA отраслевыми информационными моделями. Они определяют стандартные типы объектов, типы переменных и URI пространств имён, чтобы устройства разных производителей представляли данные в единой совместимой структуре. Инженерам по автоматизации зданий стоит знать следующие спецификации-компаньоны: