OPC Foundation è all’opera per consentire a OPC UA for Field Level Communications di includere il TSN-Time-Sensitive Networking
La Field Level Communications (FLC) Initiative di OPC Foundation è stata lanciata nel novembre 2018 per consentire l’estensione di OPC UA fino a livello di campo, al fine di supportare i diversi casi d’uso e le aree applicative della produzione discreta e dell’industria di processo (si veda figura 1). Nella prima fase dell’iniziativa FLC l’attenzione è stata posta sulle comunicazioni da controller a controller (controller-to-controller) tra diversi fornitori, che supportano attività di processo e produzione flessibili e riconfigurabili, compreso lo scambio di dati critici per la sicurezza e trasmissioni in tempo reale. Nella seconda fase dell’iniziativa i concetti verranno estesi in modo da supportare le comunicazioni da controller a dispositivo (controller-to-device) e da dispositivo a dispositivo (device-to-device). Le specifiche per le estensioni del framework OPC UA che sono state elaborate, sono già state pubblicate e si trovano sotto il nome di OPC UA FX (Field eXchange).
Architettura di sistema di OPC UA FX
La soluzione relativa a OPC UA FX si basa sul framework di OPC UA con le sue funzioni di modellazione delle informazioni, la sicurezza integrata e i servizi di comunicazione client/server e PubSub (si veda figura 2). I controller e i dispositivi di campo Uafx devono esporre le informazioni selezionate tramite il modello informativo prescritto di OPC UA, il cosiddetto AC-Automation Component, che contiene sia il modello funzionale, sia il modello degli asset. La dimensione di un AC dipende dal venditore: può essere sia piccolo come un singolo controller stand-alone con 8 I/O, o grande quanto una macchina complessa, delle dimensioni di una stanza. Il modello degli asset descrive degli elementi fisici, ma può includere anche elementi non fisici, come il firmware o le licenze. Il modello funzionale descrive la logica delle funzioni; è costituito da una o più entità funzionali (FE-Functional Entity), ciascuna delle quali incapsula le variabili di ingresso/uscita, i parametri di comunicazione e del dispositivo, nonché le connessioni della comunicazione. Un’entità funzionale è astratta rispetto all’hardware, il che consente il trasferimento delle applicazioni su hardware nuovo. Il CM-Connection Manager è un servizio che solitamente si trova in uno dei controller ed è responsabile di stabilire o gestire le connessioni tra gli FE di diversi controller. Una connessione Uafx viene innanzitutto stabilita tramite i meccanismi client/server, dove vengono scambiate le informazioni necessarie per stabilire una connessione PubSub bidirezionale (inclusi i controlli di compatibilità e la parametrizzazione); successivamente si prepara il collegamento PubSub, che viene quindi attivato. I dati di sicurezza possono anche essere scambiati tra controllori. A tale scopo viene utilizzato OPC UA Safety, un protocollo di sicurezza che viene trasmesso tramite connessioni Uafx standard e che è indipendente dai protocolli di trasporto sottostanti. Il vantaggio offerto da questo approccio consiste nel fatto che lo sforzo di valutazione e test da parte di un organismo notificato (per esempio TÜV) viene limitato al protocollo di trasmissione sicuro, mentre le connessioni Uafx sottostanti non richiedono alcuna valutazione e test ulteriori. Ogni connessione Uafx può essere autenticata e opzionalmente crittografata mediante meccanismi di sicurezza OPC UA standard specifici per le comunicazioni client/server e PubSub. La creazione della connessione viene effettuata dopo che è stata completata la creazione di una sessione OPC UA protetta (OPC UA Secure Session), che utilizzi la crittografia asimmetrica con certificati e chiavi private.
Architettura di trasporto
Un elemento chiave dell’approccio della soluzione OPC UA FX è l’architettura di trasporto flessibile, che consente l’interoperabilità tra i componenti di automazione utilizzando comunicazioni periodiche, comprese mappature specifiche in base ai casi d’uso per i protocolli di comunicazione sottostanti (come UDP/IP o Raw Ethernet) e livelli fisici (come SPE-Single-Pair Ethernet o Ethernet-APL). La comunicazione PubSub è richiesta in tutti i dispositivi, che condividono un insieme comune di funzionalità di base per questa comunicazione periodica. Funzionalità e capacità aggiuntive vengono costruite l’una sull’altra con sottoinsiemi di funzionalità compatibili, per supportare progressivamente funzionalità più avanzate, inclusa la funzionalità Time-Sensitive Networking (TSN). Tutti i controller e i dispositivi sono interoperabili attraverso il livello 3 delle reti (IP di rete), generalmente distribuite lungo un intero impianto composto da molte macchine, skid e celle. Tutti i controller e i dispositivi supportano OPC UA PubSub utilizzando UDP Uadp: si consiglia di implementare funzionalità di gestione remota, se è stato integrato un bridge embedded. I bridge gestiti integrano le Virtual Local Area Network (Vlan) e la Quality of Service (QoS); offrono inoltre supporto per servizi di rilevamento della topologia e implementano protocolli IT standard di gestione. L’implementazione delle funzioni di gestione è obbligatoria nei bridge (si veda tabella 1). Ciò facilita lo sviluppo di strumenti di monitoraggio e gestione della rete in grado di supportare la maggior parte dei controller e dei dispositivi Uafx all’interno di un’unica visualizzazione del sistema, indipendentemente dal fatto che abbiano o meno implementate le funzionalità TSN. Tuttavia, OPC UA FX può essere distribuito anche su dispositivi con integrati bridge non gestiti (vale a dire che non sono conformi a nessuno dei Uafx Bridge Component Facet).
Ethernet Time-Sensitive Networking (TSN)
TSN fornisce meccanismi per realizzare reti con una perdita di pacchetti per congestione pari a zero e la latenza di rete limitata richiesta da certe applicazioni di automazione. È progettato per il livello 2 della rete tipicamente presenti all’interno di un singolo skid, cella o macchina. Le connessioni che utilizzano TSN offrono il massimo determinismo nelle applicazioni, ma il funzionamento tramite uno switch o un router di livello 3 richiede miglioramenti, come l’uso di Detnet che è in fase di sviluppo da parte di Ietf. Le funzionalità opzionali per i bridge emebdded compatibili con TSN sono definite nelle Uafx Advanced & Full Bridge Component Facet (si veda tabella 1). La Field Level Communications Initiative si impegna a supportare il profilo TSN IEC/Ieee60802 per l’automazione industriale, una volta pubblicato. Si prevede che tutte le varianti Industrial Ethernet e i dispositivi IT che operano in una rete industriale che utilizza TSN si allineeranno a questa specifica, con lo strumento di gestione della rete che allocherà le risorse di rete necessarie a ciascuna applicazione. I ‘Domini di configurazione IEC/Ieee60802’ richiedono che tutti i bridge (integrati in un controller, in un dispositivo o in uno switch dell’infrastruttura) siano conformi a IEC/Ieee60802. Se un controller o un dispositivo implementa la funzionalità TSN e implementa anche un bridge embedded, allora deve implementare una Uafx Advanced Bridge Component Facet o una Uafx Full Bridge Component Facet (secondo la tabella 1) e quel bridge deve essere conforme a IEC/Ieee60802. I meccanismi per connettere più ‘domini di configurazione IEC/Ieee60802’ in un’unica rete e per estenderli tramite router di rete devono ancora essere standardizzati. Una volta che una rete è stata configurata correttamente, con risorse sufficienti allocate, TSN garantisce sia una perdita di pacchetti pari a zero, dovuta alla congestione della rete, sia una latenza limitata della consegna al destinatario.
Tiriamo le somme…
La prima versione delle specifiche Uafx definisce delle estensioni del framework OPC UA che consentono la comunicazione controller-to-controller tramite un’infrastruttura di rete comune per lo scambio periodico di dati di processo sulla base di un’interfaccia indipendente dal produttore. OPC UA si sta di per sé affermando come standard per l’interoperabilità a livello industriale non solo per l’integrazione verticale, dal livello di controllo all’edge o fino al cloud, ma anche come interfaccia per lo scambio di dati di processo tra controllori, indipendentemente dal protocollo utilizzato da questi controllori per comunicare con i dispositivi di campo di livello inferiore, come per esempio servoazionamenti, I/O distribuiti, sensori. Nella Fase 2 della Field Level Communications Initiative, lanciata a gennaio 2024 e pianificata per avere una durata di 4 anni, i concetti sviluppati per i casi d’uso della comunicazione controller-to-controller (C2C) saranno estesi ai casi di comunicazione controller-to-device (C2D) e dispositivo-dispositivo (D2D). Ciò include modelli specifici per i dispositivi, per esempio per il controllo del movimento, la strumentazione e gli I/O distribuiti. OPC UA fornirà quindi uno standard di comunicazione uniforme, adatto a tutti i livelli, dal campo al cloud, sia verticalmente che orizzontalmente. Aspetto decisivo per il successo di OPC UA è il fatto che sia supportato da tutti i principali fornitori di automazione al mondo, in modo che in futuro gli utenti saranno liberi di decidere quali sistemi e componenti utilizzare nei loro impianti di produzione e nelle loro fabbriche.
OPC Foundation – https://opcfoundation.org