AO_424

SETTEMBRE 2020 AUTOMAZIONE OGGI 424 105 Standard proprietari: i protagonisti del passato Analogamente a quello che succede per i di- versi sistemi di bus di campo, le attuali versioni di Industrial Ethernet non danno vita a uno standard uniforme. Al contrario, vi sono nume- rose soluzioni proprietarie incompatibili le une con le altre. Ciò d’altra parte non deve sorpren- dere, perché gli standard relativi a questi bus di campo di seconda generazione sono stati sviluppati dalle stesse aziende e gruppi di inte- resse che avevano redatto le specifiche dei loro predecessori e opportunamente adattati per soddisfare esigenze specifiche. Si tratta di un processo che aveva già portato alla prolifera- zione di un gran numero di standard differenti per i bus di campo della prima generazione. Canopen, ad esempio, è la versione Industrial Ethernet del bus di campo CAN, Profinet è basato su Profibus, Modbus/TCP su Modus e così via. Mentre ciò semplifica la migrazione verso appli- cazioni basate su Industrial Ethernet o una combinazione tra bus di campo e Industrial Ethernet, è utile ricordare che la scelta di uno di questi sistemi Industrial Ethernet proprietari può compor- tare alcuni svantaggi, legati alla necessità di ottenere licenze di utilizzo, oltre a limitazioni nel momento in cui si vuole implemen- tare una connettività senza interruzioni all’interno di una fabbrica perché in molti casi è necessario ricorrere a un controllore Indu- strial Ethernet specifico disponibile sotto forma di una sistema hardware dedicato. Solo il protocollo Ethercat consente una con- nessione in rete in realtime utilizzando un controllore Ethernet standard, fatto questo che lo colloca in una posizione privilegiata tra tutte le versioni Industrial Ethernet al momento disponibili. Il passaggio da Ethernet a Industrial Ethernet In ogni caso è bene ricordare che per sviluppatori dei bus di campo della seconda generazione l’implementazione di comunicazioni realtime, dove i requisiti realtime sono suddivisi in diverse classi in funzione dei tempi di risposta richiesti, rappresenta una sfida abbastanza impegnativa, indipendentemente dalla versione presa in considerazione. Ciò è ascrivibile al fatto che lo standard Ether- net classico, utilizzato nelle classiche applicazioni IT e conforme a Ieee 802.3 non supporta la trasmissione di tipo deterministico, nonostante garantisca velocità di trasmissione relativamente ele- vate. La risoluzione delle problematiche relative alla collisione dei dati è governata da unmeccanismo basato su un principio casuale (random) che può creare ritardi irregolari nel traffico dei dati. Le soluzioni Ethernet in grado di supportare funzionalità realtime sono in grado di impedire il verificarsi di tali collisioni grazie all’in- troduzione dei loro stack di protocollo realtime decisamente più ‘leggeri’. Essi sono identificati specificando la tipologia EtherType nel livello del protocollo Ethernet e ovviamente viene assegnata loro una priorità più alta. La continuità della connettività Ethernet richiesta per le comunicazioni classiche, ovvero quelle che utiliz- zano il protocollo TCP/IP (posta elettronica, web server) è comun- que garantita, poiché i dati meno critici possono essere incanalati in parallelo sfruttando il cosiddetto canale mailbox senza distur- bare il traffico con requisiti realtime. Hard realtime Mentre le applicazioni soft realtime sono abbastanza generose nel tollerare ritardi di propagazione dei segnali (in quanto ovvia- mente non producono effetti catastrofici), quelle hard realtime ri- chiedono tempi di risposta rigidamente deterministici, spesso con ritardi prossimi allo zero e cicli di clock dell’ordine dei μs. La sin- cronizzazione deve sempre essere temporizzata in modo preciso. La comunicazione Ethernet con requisiti hard realtime con latenza garantita richiede una sincronizzazione temporale esatta di tutti i nodi coinvolti nella comunicazione. A questo punto è utile sottoli- neare che il protocollo NTP (Network Time Protocol) utilizzato per impostare data e ora sui computer non è idoneo per questo tipo di sincronizzazione in realtime. Questo è il motivo per cui i moderni sistemi di bus di campo utilizzano il protocollo PTP (Precision Time Protocol) Ieee 1588 in grado di sincronizzare i clock sui differenti nodi (master, slave) con una precisione a livello di ns (a due cifre). Ma per assolvere al suo compito il protocollo PTP deve essere inte- grato nell’hardware delle interfacce di rete coinvolte, altrimenti la sincronizzazione può risultare alterata. Per poter garantire un fun- zionamento in tempo reale di questo tipo per tutti i singoli nodi coinvolti, le differenti versioni di Industrial Ethernet hanno finora fatto ricorso a sistemi hardware di tipo proprietario oppure a speci- fiche estensioni del protocollo. Questo ha ovviamente contribuito alla proliferazione di standard Industrial Ethernet incompatibili tra di loro e acuito la necessità di poter disporre di standard aperti e interoperabili per la comunicazione Ethernet in realtime, special- mente se si considera la tendenza alla realizzazione di fabbriche connesse che adottano i concetti di Industry 4.0 e IIoT (Industrial IoT) che, a loro volta, in un certo senso definiscono un loro nuovo livello nella piramide dell’automazione e pertanto richiedono una standardizzazione per lo scambio dei dati utilizzando protocolli realtime come OPC UA. Senza dimenticare il ruolo sempre più im- portante delle applicazioni di Internet tattile (che permette di tra- sportare tocchi e azionamenti in tempo reale), rese possibili dalla disponibilità delle tecnologie 5G e di reti GBE che supportano ve- locità di trasferimento dati superiore a 10 Gbps nelle fabbriche, nei veicoli autonomi per la logistica e nelle reti di distribuzione dell’e- nergia intelligenti (smart grid). Internet tattile in realtime con TSN L’obiettivo ora è sempre più a portata di mano. Un gruppo tec- nico che si occupa degli standard TSN all’interno del gruppo di Tra le funzioni dello standard TSN (Time-Sensitive Networking) si possono annoverare la sincronizzazione temporale, la schedulazione del traffico e la configurazione a livello di sistema dei dispositivi master e slave