FN_115

Fieldbus & Networks MAGGIO 2023 FIELDBUS & NETWORKS 13 Un esempio applicativo Vediamo qui di seguito un esempio che illustra l’applicazione di Uafx. Poniamo che un operatore di macchina acquisti 2macchine utensili identiche dal produttore X e 2 robot identici dal produttore Y, per automatizzare le operazioni di carico e scarico dalle macchine utensili. Per controllare e sincronizzare i pro- cessi tra la macchina utensile e il robot, i rispettivi controllori devono scambiarsi dati di processo definiti. Né la macchina utensile, né il robot cambiano funzio- nalità oppure operatività dopo l’installazione, ma non vi è alcuna pianificazione preliminare di quale macchina sarà collegata a quale robot, e possibilmente l’i- dentità di rete dei diversi controller non è definita in anticipo. Al momento della messa in servizio, a ogni macchina e robot (o, più precisamente, al controllore di ogni macchina o robot) devono essere assegnate un’identità di rete propria e l’identità di rete del rispettivo partner di comunicazione. Non dovrebbe essere necessaria nessun’altra configurazione da parte dell’utente, per abilitare opera- zioni plug&produce con uno scambio di dati realtime e di sicurezza. L’approccio risolutivo di OPC UA Field eXchange Per implementare il concetto plug&produce sopra descritto, il framework OPC UA è stato ampliato con funzionalità corrispondenti. I controller Uafx devono esporre le informazioni selezionate tramite un modello informativo OPC UA prestabilito, il cosiddetto Automation Component (AC - Componente di Automazione), che contiene sia il functional model (modello funzionale), sia l’asset model (modello risorse). La scala di un AC dipende dal venditore: potrebbe essere piccolo, come un singolo controller stand-alone con 8 I/O, oppure grande come una macchina complessa delle dimensioni di una stanza. L’asset model descrive aspetti fisici, ma può includere anche elementi non fisici, come firmware o licenze. Il function model descrive una funzione lo- gica. È costituito da una o più Functional Entity (FE - Entità Funzionali), ciascuna delle quali incapsula variabili di ingresso/uscita, parametri di comunicazione e del dispositivo, nonché le connessioni a livello di comunicazione. Un’entità funzionale è astratta rispetto all’hardware, il che consente il porting delle ap- plicazioni su un nuovo hardware. Il Connection Manager (CM - Responsabile della Connessione) è un servizio che di solito si trova in uno dei controller ed è responsabile di stabilire o gestire le connessioni tra le FE dei diversi controller. Prima, viene stabilita una connessione Uafx tramite meccanismi client/server, dove si scambiano informazioni per effettuare una connessione PubSub bidi- rezionale (inclusi controlli di compatibilità e parametrizzazione); quindi, viene preparata e messa in funzione la connessione PubSub. 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 di questo approccio è che l’iter di valutazione e test da parte di un organismo notificato (per esem- pio TÜV) viene limitato al protocollo di trasmissione sicuro, mentre le connessioni Uafx sottostanti non richiedono alcuna valutazione né test aggiuntivi. Ogni connessione Uafx può essere autenticata e, facoltativamente, critto- grafata impiegando i meccanismi di sicurezza dello standard OPC UA spe- cifici per la comunicazione client/server e PubSub. La connessione viene stabilita solo dopo il completamento di una sessione OPC UA protetta, uti- lizzando la crittografia asimmetrica con certificati e chiavi private. Prima versione delle specifiche Uafx La prima versione delle specifiche Uafx è composta da 4 parti specifiche: − Parte 80 (OPC 10000-80): fornisce una panoramica e introduce i concetti di base dell’utilizzo di OPC UA per le comunicazioni a livello di campo; − Parte 81 (OPC 10000-81): specifica il modello informativo di base e i concetti di comunicazione necessari per soddisfare i vari casi applicativi, nonché i requisiti per l’automazione di fabbrica e di processo; − Parte 82 (OPC 10000-82): descrive i servizi di rete, come il rilevamento della topologia e la sincronizzazione temporale; − Parte 84 (OPC 10000-84): descrive i profili Uafx utilizzati per separare le funzio- nalità Uafx in relazione al test dei prodotti OPC UA che implementano la funzio- nalità Uafx. Prima demo multi-vendor di Uafx È stata realizzata una demo relativa all’interoperabilità multi-vendor, in cui sono stati combinati insieme componenti di automazione e di rete di un totale di oltre 20 produttori, per illustrare lo scambio dati tra fornitori differenti tramite OPC UA e le estensioni Uafx. A tale scopo, 16 controllori (tra cui PLC, controllori di movimento e di robot, nonché DCS) di produttori diversi, inclusi i più noti al mondo nel campo dell’automazione, sono stati interconnessi tramite un’infrastruttura di rete comune. L’infrastruttura in questione comprende switch Ethernet convenzionali, switch Ethernet TSN (Time-Sensitive Networking) e un banco di prova 5G, che utilizza la gamma di frequenza delle onde millimetriche. La demo multi-vendor Uafx mostra l’interazione fra controller e componenti dell’infrastruttura di rete forniti da diversi produttori, per lo scambio dei dati di processo a livello di campo Architettura del sistema OPC UA e Uafx