OPC DA e OPC UA: differenze e migrazione

Un sito che sostituisce uno storico o un'interfaccia HMI OPC DA con una soluzione OPC UA scopre che il nuovo client non può accedere direttamente al vecchio server. Serve un componente di traduzione; la sua scelta determina se, dopo la migrazione, un host Windows e un server COM dovranno restare in servizio nel sito.

OPC DA (Data Access) usa Microsoft COM sullo stesso computer e DCOM fra computer. La connessione si apre sulla porta TCP 135, il mapper degli endpoint RPC, e passa poi a una porta assegnata dinamicamente. Da Windows Vista e Windows Server 2008, l'intervallo predefinito è 49152–65535. Un abbonamento DA invia anche dati dal server al client, quindi il firewall deve consentire DCOM in entrambe le direzioni.

L'irrobustimento DCOM di Microsoft per CVE-2021-26414 (KB5004442) richiede ora il livello di autenticazione con integrità dei pacchetti (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) per l'attivazione DCOM. Era attivo per impostazione predefinita dal 14 giugno 2022 e non può più essere disattivato dal 14 marzo 2023. Un client Windows aggiornato innalza automaticamente il proprio livello. Un client su host non aggiornato, o con uno stack DCOM non Windows, non riesce ad attivare il server. Il server registra l'evento 10036 e il client 10037 o 10038. I collegamenti DA remoti non preparati per questo livello hanno smesso di funzionare: è una ragione frequente per avviare la migrazione.

OPC UA usa un protocollo binario su un'unica porta TCP, di norma 4840, con certificati applicativi X.509. Funziona su qualsiasi sistema operativo.

Che cosa comprende OPC Classic

Ogni specifica Classic ha un proprio spazio degli indirizzi e propri servizi. OPC UA riunisce le tre in un solo spazio degli indirizzi con un unico insieme di servizi (OPC 10000-1, clausola 4.3).

Elenca quali delle tre usa il sistema esistente. Un wrapper DA trasferisce solo i valori correnti; non trasferisce conferme degli allarmi né interrogazioni storiche.

A&E richiede particolare attenzione. L'allegato D della parte 9 mappa le categorie di eventi A&E in tipi di eventi UA quando il wrapper ne conosce il significato. Per esempio, una condizione Level denominata HI HI può diventare un NonExclusiveLevelAlarmType. L'allegato non definisce una mappatura generica delle sottocondizioni A&E: configura il wrapper per ogni categoria di allarmi usata dagli operatori e verifica il risultato.

Tre percorsi di migrazione

OPC Foundation pubblica un COM UA Wrapper e un COM UA Proxy come componenti di esempio (parte 8, A.1). I prodotti commerciali usano talvolta questi termini in modo impreciso. Un «tunnel OPC», per esempio, di solito trasporta DA fra due computer senza DCOM ma espone DA a entrambi gli estremi: elimina il problema DCOM senza fornire un server UA. Documenta i ruoli client e server su ciascun lato di ogni prodotto.

Un wrapper conserva le vecchie dipendenze: host Windows, server DA e relativa licenza, account di servizio e ordine di avvio. Installa il wrapper sullo stesso host del server DA. COM resta così locale e il traffico DCOM non attraversa la rete. Assegna un responsabile dell'host e un piano di aggiornamento.

Prova l'ordine di avvio. Dopo il riavvio di Windows, il servizio wrapper può partire prima che il server DA sia pronto. Alcuni wrapper non ritentano e i punti restano Bad finché qualcuno non riavvia il wrapper.

La versione DA del vecchio server determina le capacità del wrapper (parte 8, A.3.3 e A.3.4). Con DA 2.05a, ogni UA Read accede al dispositivo e il wrapper ignora maxAge. Una scrittura UA che include un codice di stato o un timestamp fallisce con Bad_WriteNotSupported. Con DA 3.0, Read può leggere dal dispositivo o dalla cache del server; maxAge sceglie la sorgente. Una scrittura può portare insieme valore, qualità e timestamp.

Mappare gli item nei nodi

Costruisci la mappa punto per punto:

La parte 8, A.3.1.5 descrive tre modi di costruire un NodeId. Un wrapper che esplora l'intero spazio DA e ne conserva una copia offline può usare l'ItemID come identificatore. Un wrapper che divide ogni ItemID in corrispondenza di un separatore configurato può fare lo stesso, ma solo se gli ItemID del server sono percorsi. Un terzo tipo codifica insieme ItemID e nome dell'item nel NodeId. In quel caso NodeId e ItemID non coincidono più e abbinarli manualmente diventa difficile.

Per esempio, l'item DA BoilerA.Flow può diventare ns=2;s=BoilerA.Flow. Il 2 è la posizione nel NamespaceArray del server, non un nome fisso. L'indice può cambiare con la configurazione del wrapper, mentre l'URI dello spazio dei nomi resta uguale. Conserva URI e identificatore per ogni punto e risolvi l'indice a ogni connessione del client. La guida all'identità dei nodi approfondisce il tema. Conserva la configurazione del wrapper nel pacchetto di ripristino: ricostruirlo assegnando nuovi identificatori rompe tutti i consumer.

Controlla i tipi nella tabella A.2 della parte 8. Molti corrispondono direttamente, per esempio VT_R4 a Float e VT_I4 a Int32. VT_DATE diventa Double, non DateTime. Un item DA che contiene una data arriva quindi come numero di giorni dal 30 dicembre 1899; un consumer che si aspetta un timestamp mostra un numero come 46289.5.

Un item con proprietà High EU e Low EU diventa AnalogItemType con EURange ed EngineeringUnits. Controlla la scala da un capo all'altro: una portata di 21,7 m³/h non deve diventare 2,17 perché il nuovo collettore ripete una conversione già eseguita dal server DA.

Qualità e tempo

Un valore DA ha una qualità a 16 bit. Il byte basso ha la forma QQSSSSLL: due bit di qualità principale, quattro di sottostato e due bit di limite. Il byte alto è specifico del fornitore. Valori comuni del byte basso sono 0xC0 (Good), 0x40 (Uncertain) e 0x00 (Bad).

Un valore UA ha uno StatusCode a 32 bit. I due bit più alti determinano la gravità: 0x00000000 è Good, 0x40000000 Uncertain e 0x80000000 Bad. La parte 8, A.3.2.3 mappa la qualità principale DA nella gravità, il sottostato nel sottocodice e i bit di limite nei bit corrispondenti. Il byte del fornitore viene scartato.

Due righe richiedono attenzione. Primo: il byte del fornitore si perde. Se un server DA segnala un valore inserito manualmente con un bit nel byte alto, per esempio qualità 0x80C0, il valore passato dal wrapper arriva come semplice Good. Secondo: la tabella A.3 mappa lo stato DA «ultimo valore noto» in Bad_OutOfService. Un consumer che interpreta OutOfService come «fermato intenzionalmente» segnala allora un guasto di comunicazione come fermata pianificata. La parte 8, A.1 ammette mappature specifiche del fornitore: leggi anche la documentazione del wrapper. Se un'applicazione usa il byte del fornitore, concorda un altro modo per conservarlo oppure accettane per iscritto la perdita.

Per il tempo, il wrapper imposta il timestamp DA come SourceTimestamp UA e il ServerTimestamp all'inizio dell'operazione Read (parte 8, A.3.2.4). Il timestamp DA indica di norma quando il server DA ha ricevuto l'ultimo valore dal dispositivo. Non è l'ora di campionamento del sensore, salvo che il sistema sorgente lo definisca così.

Un wrapper può fornire uno stato UA dettagliato che il collettore successivo scarta. Controlla quindi il record nello storico o nel sistema di analisi, non solo nel wrapper. Decidi prima della migrazione come i valori obsoleti, mancanti e non validi influenzano grafici, totali e allarmi.

Frequenze di aggiornamento e bande morte

Un client DA imposta per ciascun gruppo una frequenza di aggiornamento e una banda morta percentuale; il server richiama il client quando un valore cambia. Nel wrapper della Foundation, un UA MonitoredItem crea l'abbonamento DA. UA SamplingInterval e banda morta impostano la callback DA (parte 8, A.3.5).

Il wrapper supporta soltanto il filtro PercentDeadband. La banda morta percentuale è una percentuale di EURange, quindi richiede un item con High EU e Low EU nel server DA. Senza queste proprietà manca EURange e il filtro non si applica.

Un client che interroga con il servizio UA Read non usa queste regole. Riceve un valore per punto a ogni interrogazione. Con un server DA 2.05a dietro il wrapper, ogni interrogazione legge anche il dispositivo: dimensiona l'intervallo considerando il carico sul server DA e sulla rete di campo.

Sicurezza su entrambi i lati

Sul lato UA imposta l'endpoint su SignAndEncrypt con una politica attuale, per esempio Basic256Sha256, Aes128_Sha256_RsaOaep o Aes256_Sha256_RsaPss. Non accettare la modalità None, anche se il wrapper la offre. Configura la fiducia reciproca fra certificati applicativi e concedi all'utente client soltanto le operazioni necessarie. La parte 2 della specifica descrive questo modello.

I certificati hanno una validità limitata, quindi gli orologi contano. Un certificato scaduto, o non ancora valido per via di un orologio errato, causa Bad_CertificateTimeInvalid. Il client smette di leggere finché qualcuno non rinnova il certificato o corregge l'orologio. Inserisci la scadenza di ogni certificato applicativo nel piano di manutenzione.

Sul lato DA, COM DA non ha una propria identità utente (parte 8, A.2). Un wrapper può accettare nome utente e password UA e impersonare l'utente Windows prima di collegarsi al server DA. Molti wrapper si collegano invece con il proprio account di servizio. Registra quale account Windows vede il server DA e che cosa può scrivere. Se un collegamento DA rimane remoto, deve rispettare la regola sull'integrità dei pacchetti DCOM descritta sopra.

Non risolvere un problema di messa in servizio disattivando la sicurezza o trasformando un account di sola lettura in uno con permesso di scrittura.

Provare la migrazione

Verifica un punto per ogni tipo di dato prima di migrare gli altri. Includi un valore analogico scalato, un Booleano, una stringa e, se presenti nel progetto, un array e una data. Per ciascun punto di prova:

1. Registra l'URI dello spazio dei nomi e il NodeId creato dal wrapper.
2. Leggi il valore tramite DA e UA entro un periodo di scansione DA e confrontali. Cerca una doppia applicazione della scala.
3. Con approvazione, ferma il dispositivo o il suo driver. Registra la qualità DA, lo StatusCode UA e ciò che mostra il consumer finale. L'ultimo valore non deve apparire come un nuovo campione Good.
4. Riavvia l'host del wrapper. Verifica che i punti tornino Good senza cambiamenti all'elenco e registra il tempo necessario.
5. Leggi un ItemID inesistente e prova a scrivere in un punto senza accesso in scrittura. Attendi Bad_NodeIdUnknown e Bad_NotWritable.

Esegui poi entrambi i percorsi in parallelo per almeno un ciclo operativo completo, per esempio un turno, un lotto o una settimana. Includi un riavvio programmato della sorgente. Il percorso DA invia su cambiamento con una banda morta, mentre un client UA può interrogare periodicamente: i numeri di messaggi saranno diversi. Confronta valori ed età dell'ultimo dato in ogni istante. Concorda differenza ammessa e tempo di ripristino prima della prova.

Mantieni separato il controllo. Non lasciare che vecchio e nuovo percorso comandino contemporaneamente la stessa apparecchiatura e verifica il risultato fisico di ogni scrittura. La guida all'array di priorità BACnet mostra come un comando condiviso possa persistere dopo chi lo ha inviato.

OPC UA con Edge

Edge sul Gateway ZGW-20 è un client OPC UA. Si collega fino a cinque endpoint opc.tcp, nativi o tramite wrapper, e non si collega a OPC DA. Un sistema soltanto DA richiede prima un wrapper.

Edge legge ogni punto con il servizio Read secondo un programma, da una volta al secondo a una volta al giorno. Non crea abbonamenti, quindi le regole sulla banda morta sopra non si applicano. Assegna a ogni valore l'ora della lettura programmata dal Gateway, non SourceTimestamp. Inoltre applica a ogni punto il proprio moltiplicatore e offset: impostali rispettivamente a 1 e 0 se il server DA ha già scalato il valore.

Edge accetta None, Sign e SignAndEncrypt, e un nuovo slot di endpoint parte da None. Imposta tu SignAndEncrypt con Basic256Sha256 o una politica Aes e mantieni corretto l'orologio del Gateway per le verifiche dei certificati.