MAGGIO 2017
FIELDBUS & NETWORKS
19
processamento a livello software, firmware e hardware, per la presenza
stessa di alcuni dispositivi infrastrutturali di rete necessari per instradare
la comunicazione Ethernet. Si tenga conto che la dimensione di un frame
Ethernet va da 1,5 kb a 80-84 kB, mentre lo scambio dati a livello di dispo-
sitivi di campo è solitamente dell’ordine di pochi byte: con 32 I/O potrei
avere appena 4 byte di dati da trasmettere. Questo implica un utilizzo
della banda inefficiente: sarebbe come utilizzare un ‘TIR’ per trasportare
una singola lettera. La gestione dello stack software del protocollo Ether-
net richiede quindi l’impiego di processori con una certa potenza di calcolo
e tempi di elaborazione di decine di ms, il che limita notevolmente i tempi
della comunicazione. Inoltre, non è possibile stabilire a priori il tempo di
invio/ricezione dei dati, in quanto il protocollo non è deterministico. Infatti,
a meno di non utilizzare alcune tipologie di switch
piuttosto costose, gli switch standard per Ethernet
hanno solitamente unamodalità di funzionamento
‘store&forward’ ed eseguono l’instradamento nel
firmware, dove i tempi di elaborazione non si
possono conoscere a priori. Infine la topologia,
tipicamente lineare, della rete pone altri limiti alla
velocità di trasmissione in base al numero dei di-
spositivi collegati.
I protocolli Industrial Ethernet sono nati per su-
perare questi limiti. Ethercat in particolare offre
elevate prestazioni, elevata velocità di refresh e
tempi ciclo molto spinti, che arrivano ai 30 micro-
secondi di aggiornamento per 1.000 dispositivi e
100 microsecondi per 100 servo-assi. Consente inoltre di evitare l’imple-
mentazione di sotto-reti bus locali, in quanto il bus principale Ethercat è
in grado di raggiungere lui stesso tutti i dispositivi I/O in rete con tutti i
vantaggi che ciò comporta.
F&N:
Come si può integrare Ethercat in una rete Ethernet standard?
Figini:
Oggi le tecnologie IP sono sempre più importanti in quanto legate
al concetto di Industry 4.0: Ethercat può integrare qualsiasi tecnologia
grazie alla soluzione ‘Ethernet over Ethercat’, che permette di trasferire
su Ethercat i frame Ethernet standard inmodo trasparente per i dispositivi
end-to-end, tramite tunnelling. I pacchetti TCP/IP (o anche UDP/IP) ven-
gono trasmessi sull’infrastruttura Ethercat come payload del frame Ether-
cat aciclico. In tal modo, è possibile collegare per esempio delle stampanti
per etichette, oppure impiegare un web server per la visualizzazione dei
dati di diagnostica, ovvero utilizzare i dispositivi che adottano Ethernet
standard, servendosi della rete Ethercat quale dorsale. Il master Ethercat
si comporta come uno switch software e il protocollo provvede anche alla
frammentazione dei frame Ethernet, che sono tipicamente più lunghi dei
frame Ethercat.
F&N:
Cosa si intende per ‘Ethernet on the fly’?
Figini:
Il funzionamento di Ethercat è definito ‘Ethernet on the fly’, ossia
‘al volo’, in quanto tutti i frame inviati dal master percorrono la rete rag-
giungendo tutti gli I/O: i singoli dispositivi inseriscono i propri dati di out-
put e ricevono gli input ‘al volo’ e al termine del loop, quando il frame
torna al master, quest’ultimo già è in possesso di tutte le variazioni e
dei nuovi valori. È come se dei passeggeri salissero e scendessero da
un treno in corsa senza bisogno di fermate. In questo modo, con un solo
frame o un numero di frame basso, il master è in grado di inviare i dati di
output potenzialmente a tutti gli slave della rete che supportino dati ciclici
in uscita e di raccogliere i dati di input da tutti gli ingressi. Ogni Ethercat
slave controller ha inoltre un supporto hardware dedicato per la sincroniz-
zazione dei clock. La comunicazione aciclica, impiegata per esempio per
l’invio di dati di diagnostica, viene supportata in parallelo, senza influire
sulle prestazioni realtime della rete.
F&N:
Si parla molto di diagnostica predittiva. Cosa prevede Ethercat
in tal senso?
Figini:
La diagnostica di rete ha sempre rappresentato per Ethercat un
punto centrale. Lo prova per esempio il fatto che lo standard Ethercat
impone per qualsiasi dispositivo conforme la presenza di un LED che
indichi all’utente a prima vista lo stato del collegamento di ogni porta
I/O Ethercat. Le informazioni diagnostiche sono trasmesse in modalità
aciclica, vi sono però anche informazioni cicliche di diagnostica recepite
dal master tramite un contatore (‘watching counter’), di cui ogni slave
controller Ethercat è dotato, che si incrementa ogniqualvolta viene perso
il link fisico della comunicazione, per esempio in caso di interruzione fisica
della rete, disturbi EMC, errori legati alla topologia. Un counter segnala
anche il caso in cui il frame sia corrotto o i dati non siano consistenti. Il
master, non appena riceve i dati dagli slave, in base allo stato del counter
può capire se si è verificato un evento negativo, di perdita della comunica-
zione o di errore, e reagire di conseguenza interrogando direttamente gli
slave che hanno avuto problemi, per capire quale device è coinvolto, quale
problema si è verificato e quando, oppure può inviaremessaggi di allarme.
È anche possibile raffinare l’impiego dei counter creando dei gruppi di
dispositivi in rete, per cui il counter ricevuto dal master sarà relativo non a
tutti i dispositivi della rete, ma solo a un certo gruppo, delimitando l’area
interessata dall’errore.
F&N:
Come viene affrontato il tema della sicurezza?
Figini:
La sicurezza rappresenta un altro punto saliente, essenziale anche
per ottenere la conformità alle normative vigenti. Nel tempo siamo pas-
sati da soluzioni di sicurezza ‘ad hoc’, che imponevano l’esistenza di una
rete di sicurezza separata a se stante, con i propri dispositivi ‘sicuri’, per
arrivare a soluzioni integrate. Oggi si impiegano per lo più bus ‘ibridi’,
con una logica di sicurezza integrata in controllori standard o remotata
sul bus, con convergenza di funzionalità standard e di sicurezza veicolate
sullo stesso mezzo fisico. In tal modo, vengono integrati sulla stessa rete
e sullo stesso ‘cavo’ dispositivi standard e di sicurezza, senza bisogno di
installare una nuova rete. I protocolli bus standard si sono perciò dotati di
un apposito layer di sicurezza aggiuntivo, il ‘safety protocol layer’. Ethercat
adotta un approccio black channel: ciò che serve per garantire il livello di
sicurezza voluto, che può arrivare a SIL3 secondo IEC61784-3, è contenuto
nel layer di sicurezza, ovvero nel Functional Safety on Ethercat (FSoE),
tecnologia certificata da TÜV e supportata da ETG. I frame di sicurezza
vengono trasmessi insieme a quelli standard, ma sono particolarmente
verificati e controllati in modo da garantire che vengano recepiti corretta-
mente dai dispositivi di sicurezza.
ETG-Ethercat Technology Group -
www.ethercat.orgNell’area espositiva i partecipanti hanno potuto toccare con mano alcune soluzioni
proposte dai membri di ETG
Video disponibile al link
http://automazione-plus.it/ether-cat-i-punti-chiave-della-rete-in-unintervista-ad-alessandro-fig-
ini-di-etg_91002/