77 / 84
MAGGIO 2015
FIELDBUS & NETWORKS
77
zionamento tanto efficiente quanto unico nel suo genere: il processa-
mento dei telegrammi ‘on the fly’. Compiti quali la configurazione, la
diagnosi e la manutenzione risultano con Ethercat molto semplificati,
in quanto Ethercat assegna automaticamente gli indirizzi ai nodi, quindi
un’impostazione manuale di questi ultimi non è più necessaria. Nella
maggior parte delle applicazioni, per indirizzare tutti i dispositivi della
rete è sufficiente inviare un singolo telegramma Ethercat per ogni ciclo
di comunicazione. Grazie a questa elevata efficienza di trasmissione
dei dati, insieme all’approccio ‘peer-to-peer’, anche l’immunità ai di-
sturbi elettromagnetici risulta massimizzata. Qualora nonostante tutto
si verifichino dei disturbi, questi ultimi vengono non solo riconosciuti in
modo affidabile, ma anche localizzati in modo preciso, fatto che riduce
notevolmente i tempi di ricerca guasti.
Ethercat non richiede né switch, né hub per la realizzazione dell’infra-
struttura fisica di rete, cosicché le collisioni vengono prevenute alla ra-
dice anche in caso di applicazioni caratterizzate da specifiche temporali
particolarmente stringenti. In aggiunta, per ogni porta di un dispositivo
Ethercat sono disponibili dei contatori di errore, che rendono possibile
una precisa diagnostica di rete.
In termini di interoperabilità Ethercat segna una notevole differenza
rispetto a tecnologie analoghe proprio per la modalità con cui il proto-
collo viene processato. Tale processamento avviene in un componente
di comunicazione Ethercat dedicato, che garantisce sempre l’elabora-
zione dei telegrammi con una velocità elevata e costante. Quanto Ether-
cat sia performante come tecnologia bus di campo è testimoniato, non
da ultimo, dalla molteplicità di dispositivi slave e master, così come di
tool di configurazione, disponibili sul mercato mondiale.
Comportamento uniforme a tutti i livelli
dello stack
Ethercat viene descritto, come normalmente avviene nell’ambito della
comunicazione, sulla base del modello a livelli ISO/OSI. Considerando
questa struttura è possibile spiegare bene l’uniforme comportamento
dei dispositivi Ethercat.
Il ‘Physical Layer’ (PhL) descrive le condizioni per l’invio e la ricezione sul
cavo Ethernet di ‘0’ e ‘1’ intesi come segnali elettrici. In pratica, esso è
rappresentato dai componenti (PHY) che a entrambi gli estremi del cavo
convertono i segnali elettrici analogici in segnali digitali e viceversa. Il
PhL definisce la velocità così come le caratteristiche di trasmissione, nel
caso di Ethercat 100Mbps full-duplex. Il ‘Data Link Layer’ (DLL) descrive
la struttura dei telegrammi, l’indirizzamento dei singoli dispositivi così
come pure l’ordine di processamento, che in Ethercat segue un sem-
plice principio.
Il percorso dei telegrammi è fisso e noto a priori e non sussiste possibi-
lità di collisioni. Inoltre, con questo approccio il tempo di propagazione
è deterministico in qualunque condizione.
Sia il PhL che il DLL sono in Ethercat completamente conformi allo stan-
dard Ieee 802.3 così come utilizzato, per esempio, da router, switch o PC
(si veda figura 1). I problemi di interoperabilità a livello fisico, così come
Data Link sono quasi completamente esclusi, in quanto il fornitore del
dispositivo non è chiamato a implementare alcuna funzionalità a questi
livelli e il processamento affidabile del protocollo DLL è assicurato au-
tomaticamente dall’impiego di un chip hardware dedicato.
L’‘Application Layer’ (AL) si divide in due parti: lo stack di comunicazione
e lo stack applicativo (si veda figura 2). Il primo implementa tutte le
funzioni rilevanti dal punto di vista Ethercat, come lo scambio dei dati
di processo ciclici o dei parametri aciclici.
A questo livello, un ruolo importante rivestono la sincronizzazione e la
gestione degli errori, definita dalla Ethercat State Machine. Lo stack
applicativo implementa invece le funzionalità specifiche del dispositivo,
per esempio l’acquisizione della misura di un sensore o gli algoritmi
di controllo di un azionamento. I servizi e le strutture dati di questo
secondo livello sono definite in modo fisso, mentre il contenuto varia a
seconda della funzione del singolo dispositivo e viene implementato nel
software dal fornitore del dispositivo stesso.
Riassumendo, si può affermare che i livelli inferiori (PhL e DLL) negli
dispositivi Ethercat sono interoperabili grazie alla struttura e all’impiego
descritti e questo costituisce la migliore premessa per un approccio
plug&play.
Gli aspetti critici, ai quali è necessario porre specifica attenzione in ter-
mini di interoperabilità, sono nel caso di Ethercat molto limitati. Essi si
riducono a quelle funzionalità implementate nel AL e, in particolare,
nello stack applicativo, così come nel master Ethercat e nel tool di
configurazione di quest’ultimo. Elemento di semplificazione è a questo
riguardo il fatto che, anche nel AL, è necessario considerare sempre e
solo una relazione uno-a-uno tra lo slave Ethercat e il master o il tool
di configurazione.
Figura 3 - Ordine di processamento dei telegrammi nella rete
Figura 1 - Il protocollo Ethercat utilizza frame Ieee 802.3 standard
Figura 2 - Ethercat viene descritto con il modello a livelli ISO/OSI