73 / 102
pari a 84 byte (si veda Figura 1), nonostante la quantità di dati utili
scambiata da ciascun dispositivo sia tipicamente inferiore a 8 byte
(nel caso di nodi CAN, per esempio, tra 1 e 8). Un simile scenario
produce un overhead superiore al 90%.
La tipica architettura di un impianto adotta una topologia lineare
per il sistema di comunicazione, dove l’infrastruttura Fast Ethernet
richiede un accoppiamento attivo delle interfacce di comunicazione.
Tale accoppiamento è realizzato mediante la cosiddetta Bridged
LAN, nota anche come ‘Switched Ethernet’, dove gli switch sono
spesso parte integrante dei nodi di rete come dispositivi di I/O o
azionamenti. Dal momento che tutti i dati vengono comunque ritra-
smessi da ogni nodo della rete, è possibile in alternativa raggrup-
pare l’intera informazione utile in un unico frame e, come nel caso di
Ethercat, processarla ‘on-the-fly’. Questa modalità di elaborazione
del protocollo viene designata come soluzione ‘shared-frame’ (si
veda Figura 2). Il risultato è un overhead inferiore al 50%, anche nel
caso di un numero ridotto di dispositivi connessi in rete. Qualora
poi la dimensione complessiva dei dati ciclici scambiati dal sistema
sia superiore a 400 byte, l’overhead nel caso di soluzione ‘shared-
frame’ risulta inferiore al 10%.
Per quanto il mezzo fisico (PHL - Physical Layer) utilizzato da Ether-
net sia robusto, disturbi elettromagnetici particolarmente intensi
possono determinare errori di comunicazione. Se si confrontano gli
effetti di tali disturbi nel caso di un approccio tradizionale, basato
su frame individuali per ogni nodo di rete, con quelli che si hanno
nel caso di soluzione ‘shared frame’, è possibile riconoscere in
quest’ultimo una probabilità di errore all’interno del singolo ciclo di
comunicazione nettamente inferiore.
La maggior parte delle applicazioni di controllo è in grado di tolle-
rare un singolo errore di comunicazione, mentre già nel caso di due
errori consecutivi, viene a determinarsi una situazione critica. Di
conseguenza, esiste una correlazione tra l’insorgere di situazioni
critiche e il numero di errori per ciclo di comunicazione. Riferendosi
allo scenario realistico descritto sopra, questo significa un numero
nettamente superiore di frame corrotti nel caso di una soluzione a
frame individuali in confronto a una soluzione ‘shared frame’, in
quanto in quest’ultimo caso il tempo effettivo di trasmissione dei
dati risulta di circa un sesto, pertanto un disturbo casuale influenza
il frame condiviso solamente in un caso su sei.
Il numero di bit errati non influenza
la qualità dell’elaborazione
Le applicazioni di motion control utilizzano complessi algoritmi per
poter interpolare i valori di posizione comandata e di posizione
attuale nel caso di un singolo errore di comunicazione. L’approc-
cio a frame individuali determina da questo punto di vista risultati
difficilmente prevedibili, soprattutto nel caso di assi accoppiati tra
loro. Dalla percentuale nettamente maggiore di cicli affetti da er-
rori di comunicazione, caratteristica di questo approccio, consegue
una serie di situazioni critiche in cascata. In aggiunta, la minore
efficienza di questo approccio determina un ulteriore incremento di
circa il 10% del numero di cicli affetti da errore e rende un controllo
affidabile dell’applicazione decisamente più difficile.
Allo stesso modo, in termini di movimento è necessario controllare
velocità e posizione. Il controllo della posizione risulta di gran lunga
più critico del controllo della velocità, che subisce solo piccole va-
riazioni incrementali. Una previa pianificazione delle interazioni in
caso di errore può in questo caso essere di aiuto. Anche la massima
del programmatore ‘mantieni i valori, finché non cambia qualcosa’
aiuta a ridurre drasticamente le conseguenze degli errori così come
a evitare errori a pacchetto.
Gli aspetti descritti mostrano come non esista una dipendenza di-
retta tra il numero di errori per singolo ciclo di comunicazione e gli
errori di controllo da essi risultanti. Errori singoli possono rivelarsi
addirittura più critici che non errori a multipli.
L’approccio a frame individuali non può
evitare errori multipli
Un ulteriore problema nel caso di approccio a frame individuali è l’i-
solamento di errori. Con Ethernet la propagazione dei disturbi viene
evitata alla radice dal fatto che ogni sin-
golo segmento della rete è controllato da
una interfaccia hardware dedicata. No-
nostante il mezzo fisico in Ethernet non
sia un vero e proprio bus, bensì una serie
di collegamenti punto-punto, possono
tuttavia verificarsi errori, per esempio a
causa di disturbi sulla tensione di alimen-
tazione, che determinano conseguenze
contemporaneamente su più nodi. Una
simile fonte di errore è rappresentata,
per esempio, da una carente connessione
dello schermo, qualora quest’ultimo
venga collegato a terra in modo diretto.
Ethercat non raccomanda questa modalità di collegamento dello
schermo a terra; tuttavia, essendo invece prescritta da altri stan-
dard bus di campo, essa è necessariamente utilizzata da dispositivi
multi-protocollo che non possono adottare soluzioni hardware dedi-
cate per ogni specifico bus. Dal momento che il collegamento a terra
dei quadri elettrici presenta talvolta un’impedenza non trascurabile
e superiore in ogni caso a quanto atteso, in caso di collegamento
diretto dello schermo a terra all’interno dei dispositivi un disturbo
può affliggere diversi segmenti della rete. La diagnosi di un simile
scenario risulta molto difficile, motivo per cui questo tipo di propa-
gazione dei disturbi dovrebbe essere evitato con opportune misure
ovunque possibile. Qualora, come nel caso di Ethercat, si utilizzino
frame condivisi tra i vari nodi della rete, una propagazione dei di-
sturbi quale quella appena descritta non fa altro che agire più volte
sullo stesso frame.
Nell’approccio a frame individuali, caratterizzati da una modalità di
inoltro dei pacchetti sulla rete di tipo ‘switch’, che tipicamente ri-
sulta almeno dieci volte più lenta della modalità utilizzata da Ether-
cat, vengono contemporaneamente trasmessi più frame a differenti
dispositivi di rete. Ciò comporta una maggiore fluttuazione tempo-
rale della comunicazione, motivo per cui una propagazione del di-
sturbo su più segmenti della rete può coinvolgere frame diversi. In
alcuni casi possono essere coinvolti anche dati appartenenti a cicli
di comunicazione differenti. Per questo motivo, con l’approccio a
MAGGIO 2016
FIELDBUS & NETWORKS
73
Figura 2 - Un errore ripetitivo casuale, nel caso di soluzione ‘shared-frame’, interessa
il telegramma in un caso su sette
Fonte Karl-Martin Skontorp