F&N_109

NOVEMBRE 2021 FIELDBUS & NETWORKS 26 Fieldbus & Networks Per applicazioni critiche nell’ambito dell’automa- zione, per le quali l’hard realtime è essenziale, l’Ethernet originale appare ‘veloce ma inaffidabile’, a motivo della natura stocastica dei tempi di tra- smissione di un messaggio e della relativa variabi- lità (latenza e jitter). Entrambi tali dati sono infatti influenzati, nel protocollo originale, da molteplici fattori: la scelta di percorsi di instradamento mu- tevoli, la scelta di risolvere le collisioni durante la trasmissione mediante eliminazione del pacchetto e ritrasmissione dopo intervalli variabili, e in gene- rale una serie di ulteriori scelte progettuali motivate da obiettivi diversi dal realtime. Per ottenere il realtime risulta quindi necessario estendere il protocollo di comunicazione, e l’esten- sione può essere condotta essenzialmente in tre modi, che qui elenchiamo in ordine di crescente in- vasività, ovvero agendo rispettivamente: al di sopra di Ethernet, al livello TCP/IP; allo stesso livello, spe- cializzando il protocollo standard ma preservando la compatibilità con lo standard; al di sotto, arrivando a introdurre modifiche fin nelle infrastrutture fisiche, per esempio mediante clock e switch progettati ad hoc. In termini di limitazioni, il primo tipo di soluzione sacrifica fortemente le prestazioni in termini di ve- locità ed è quindi indicato per applicazioni che sono sostanzialmente ‘lente’, ossia con tempi di risposta di decine o centinaia di millisecondi, e che si acconten- tano di un realtime soft. All’altro estremo, le soluzioni che richiedono hardware specifico possono ottenere prestazioni estreme sacrificano però la possibilità di usare infrastrutture standard e già esistenti, limi- tando così al contempo l’interoperabilità. Pertanto, tranne che per esigenze molto particolari, il secondo tipo di approccio sembra in generale preferibile, com- binando prestazioni elevate e alta compatibilità con le infrastrutture e i protocolli standard. Due esempi specifici Anche se diverse soluzioni utilizzano differenti meccanismi implementativi, i principi di fondo per ottenere una comunicazione hard realtime sono fondamentalmente gli stessi. In sostanza, se, come si è già ricordato, il non determinismo di Ethernet è fortemente legato a collisioni e percorsi multipli, la soluzione del problema passa per un’organizzazione appropriata della comunicazione. È un po’ come suc- cede in una tavola rotonda ben organizzata, nella quale il moderatore concede la parola a un ospite per volta, a intervalli prefissati e per un tempo limitato, lasciando un tempo per interventi a priorità inferiore (magari la pubblicità, o gli interventi del pubblico...) e un po’ di margine in caso di ospiti indisciplinati che stentano a lasciare la parola. Considerando, per esempio, il caso di Powerlink, ogni ciclo di comunicazione è diviso in quattro fasi (o periodi): iniziale, isocrono (o ciclico o sincrono), asincrono, inattivo. Fra i nodi vi è un master, detto Managing Node (MN), che coordina le comunicazioni con gli slave, detti Controlled Node (CN). All’inizio di ogni ciclo, nel periodo iniziale, il MN sincronizza tutti i CN inviando un frame Ethernet di inizio ciclo o SoC (Start of Cyclic). Inizia quindi la fase isocrona, durante la quale il MN, secondo una sequenza prestabilita, fa un polling sui CN. Il MN manda un frame di ‘Poll Request’ a uno specifico CN e riceve un frame di ‘Poll Response’ dal CN interrogato prima di passare a interrogare il CN successivo. Tutti i frame scambiati nella fase isocrona hanno lunghezza massima prefis- sata, in modo da garantire il rispetto della deadline di trasmissione. Una volta interrogati tutti i nodi, il MN invia un frame di EoC (End of Cyclic) e dà inizio alla fase asincrona. Durante la fase asincrona viene gestito il traffico non realtime, schedulato mediante i consueti algoritmi, con l’accortezza di suddividere i dati da inviare in pacchetti tali da non richiedere un tempo di trasmissione superiore alla durata della fase asincrona. Infine, il periodo inattivo consente un mar- gine di sicurezza che garantisce che operazioni dovute a potenziali conflitti o ritardi associati alle trasmissioni asincrone possano essere terminati senza accaval- larsi all’inizio del successivo ciclo di comunicazione. Come accennato, il ciclo base descritto sopra con- sente di intuire gli aspetti principali, ma può essere raffinato in molti modi. In presenza di nodi che hanno bisogno di trasmettere in hard realtime, ma con frequenze inferiori a quelle dettate dal ciclo di comunicazione, per esempio, è possibile introdurre Fonte Shutterstock La possibilità di mischiare su una stessa infrastruttura di rete comunicazioni in hard realtime e generiche è abilitante nel contesto di Industria 4.0 e IIoT, dove si punta alla convergenza fra IT e OT Esistono aspetti comuni fra i differenti protocolli Industrial Ethernet disponibili, il che suggerisce l’opportunità di avere standard aperti e ben congegnati Fonte Shutterstock