OPC UA arhitektūra: informācijas modelis, drošība, sesijas un transports

IEC 62541 standarta struktūra

IEC 62541 sastāv no 13 numurētām daļām. 1.–7. daļa nosaka pamata arhitektūru; 8.–14. daļa aptver kartējumus, drošību un profilus. Ēku automatizācijas integratoriem būtiskākās ir 1. daļa (Koncepti), 3. daļa (Adrešu telpas modelis), 4. daļa (Pakalpojumi), 6. daļa (Kartējumi — kodēšana un transports), 7. daļa (Profili) un pavadošā specifikācija IEC 62541-100 (OPC UA ēkām).

Informācijas modelis: NodeClass tipi un atsauces

Katrs datu elements OPC UA serverī tiek attēlots kā Mezgls adrešu telpā. Mezgliem ir NodeClass atribūts, kas nosaka to lomu. Mezgli ir savienoti viens ar otru ar tipizētām Atsaucēm — piemēram, HasComponent, HasProperty, Organizes, HasSubtype. Tas veido virzītu grafu, kuru klienti var pārlūkot, lai atklātu servera saturu bez iepriekšējām zināšanām par datu struktūru.

Adrešu telpa: vārdu telpas un pārlūkojams koks

Adrešu telpa ir strukturēta kā pārlūkojams koks. Katrs mezgls tiek identificēts ar NodeId, kas sastāv no vārdu telpas indeksa un identifikatora (ciparu, virknes vai GUID). Vārdu telpa 0 (ns=0) vienmēr ir OPC UA standarta vārdu telpa, kas satur iebūvētos tipus un standarta mezglus. Vārdu telpas 1+ tiek piešķirtas serverim pārdevēja vai lietojumprogrammas specifiskam saturam. Klienti atklāj vārdu telpu tabulu, izmantojot GetNamespaceArray pakalpojuma izsaukumu.

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]

Klienti pārvietojas no Objects saknes, izmantojot Browse pakalpojumu, sekojot HierarchicalReferences (HasComponent, Organizes, HasProperty), lai atklātu mezglus. TranslateBrowsePathsToNodeIds pakalpojums ļauj klientiem pāriet tieši uz zināmo ceļu, nešķērsojot visu koku — noderīgi veiktspējas jutīgai zināmo mainīgo aptaujāšanai.

Transporta iespējas

OPC UA definē trīs transporta saistījumus. Izvēle ietekmē latentumu, ugunsmūra šķērsošanu un protokola papildu slodzi. OPC UA Binary pa TCP ir noklusējums rūpnīcas stāva BMS integrācijai; HTTPS un WebSockets tiek izmantoti mākoņa vai pārlūkprogrammas saskarnēm.

Drošības režīmi un drošības politikas

OPC UA drošība tiek saskaņota Secure Channel līmenī pirms jebkādu lietojumprogrammu ziņojumu apmaiņas. Serveris publicē savus atbalstītos EndpointDescription (MessageSecurityMode un SecurityPolicyUri kombinācijas). Klients izvēlas vienu, atverot savienojumu. Nekad neizmantojiet None ražošanas vidē — visi dati tiek pārraidīti vienkāršā tekstā bez integritātes aizsardzības.

SecurityPolicyUri izvēlas kriptogrāfiskos algoritmus. Pašreizējās ieteicamās politikas (saskaņā ar IEC 62541-7:2022) ir:

Autentifikācijas metodes

Autentifikācija tiek veikta sesijas slānī (virs drošā kanāla). OPC UA definē trīs ActivateSession identitātes marķieru tipus. Sertifikātu autentifikācija ir visdrošākā un ir nepieciešama rūpnieciskās drošības standartiem, piemēram, IEC 62443-3-3 Drošības līmenis 2.

Sesijas un abonementi

Sesija tiek izveidota virs droša kanāla pēc autentifikācijas. Sesijai ir RequestedSessionTimeout (parasti 60–3600 sekundes); ja klients nenosūta keep-alive pirms taimauta, serveris dzēš sesiju un visus tās abonementus. Klientiem jāapstrādā atkārtota savienošana ar sesijas atjaunošanu vai pārnešanu.

Abonementi ir primārais mehānisms efektīvai datu uzraudzībai. Tā vietā, lai atkārtoti aptaujātu mainīgos (kas rada lieku trafiku), klienti izveido abonementu ar PublishingInterval un pievieno tam MonitoredItems. Serveris paraugā katru MonitoredItem ar SamplingInterval un rindā ievieto izmaiņas; kad iestājas PublishingInterval, visi uzkrātie paziņojumi tiek nosūtīti vienā PublishResponse ziņojumā.

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 pavadošās specifikācijas

Pavadošās specifikācijas paplašina OPC UA pamatstandartu ar nozarei specifiskiem informācijas modeļiem. Tās definē standarta ObjectTypes, VariableTypes un vārdu telpas URI, lai dažādu ražotāju ierīces atklātu datus vienotā, savietojamā struktūrā. Ēku automatizācijas inženieriem būtu jāzina šādas pavadošās specifikācijas: