EtherCAT – il Fieldbus Ethernet

Questa sezione fornisce un'introduzione dettagliata ad EtherCAT (Ethernet for Control Automation Technology). Le seguenti informazioni sono reperibili anche nella brochure EtherCAT, disponibile in varie lingue.

EtherCAT è una tecnologia Ethernet industriale deterministica sviluppata originariamente da Beckhoff Automation. Il protocollo EtherCAT, pubblicato nello standard IEC61158, soddisfa requisiti hard e soft real-time nell'automazione, in sistemi di test e di misura e in molte altre applicazioni.

L'attenzione principale durante lo sviluppo di EtherCAT è stata dedicata a tempi ciclo veloci (≤ 100 µs), jitter contenuto per un'accurata sincronizzazione (≤ 1 µs) e bassi costi dell'hardware.

EtherCAT è stato introdotto nell'Aprile 2003, ed EtherCAT Technology Group è stato fondato nel Novembre 2003 - ad oggi ETG è diventata la più vasta organizzazione Ethernet industriale e bus di campo al mondo. ETG riunisce costruttori e utilizzatori, che contribuiscono all'interno dei Technical Working Group allo sviluppo della tecnologia EtherCAT.

1. Proprietà di EtherCAT

1.1 Principio di Funzionamento
1.2 Il Protocollo EtherCAT
1.3 Topologia Flessibile
1.4 EtherCAT P
1.5 Precisa Sincronizzazione
1.6 Diagnostica e Localizzazione Errori
1.7 Requisiti di Alta Disponibilità
1.8 Safety over EtherCAT
1.9 Profili di Comunicazione
1.9.1 CAN Application Protocol over EtherCAT (CoE)
1.9.2 Servo drive profile basato su IEC 61800 7 204 (SoE)
1.9.3 Ethernet over EtherCAT (EoE)
1.9.4 File Access over EtherCAT (FoE)
1.9.5 ADS over EtherCAT (AoE)
1.10 EtherCAT Automation Protocol (EAP)
1.11 Integrazione di Altri Bus di Campo
1.12 EtherCAT, TSN, Industrie 4.0 e IoT

2. Implementare Interfacce EtherCAT

2.1 Master
2.2 Slave

3. Conformità e Certificazione

3.1 Plug Fest
3.2 Conformance Test Tool
3.3 Technical Working Group Conformance
3.4 EtherCAT Test Center

4. Standardizzazione internazionale

 

 

 

1.1 Principio di Funzionamento 

Il master EtherCAT invia un telegramma che attraversa tutti i nodi. Ogni slave EtherCAT legge i dati di uscita ad esso destinati e scrive quelli da esso prodotti nel frame “al volo” (“on-the-fly”), mentre quest’ultimo si propaga verso i nodi successivi. Il ritardo subito dal frame è pari al solo tempo di attraversamento fisico dello slave. L’ultimo nodo in un segmento o linea di caduta reinvia il messaggio al master avvalendosi della comunicazione full-duplex di Ethernet.

La percentuale di utilizzo effettivo dei telegrammi sale a oltre il 90%, e grazie alla comunicazione full-duplex il flusso di dati teorico è addirittura superiore a 100 Mbit/s.

Il master EtherCAT è l’unico nodo della rete in grado di inviare attivamente un frame EtherCAT; tutti gli altri nodi non fanno altro che inoltrare tali frame a valle. Questo principio previene ritardi di durata variabile e garantisce prestazioni deterministiche.

Il master utilizza un Media Access Controller (MAC) standard, senza alcun processore dedicato alla comunicazione. Questo consente di implementare un dispositivo master su qualunque piattaforma hardware dotata di una porta di rete, indipendentemente dal Sistema Operativo o software applicativo utilizzato. I dispositivi EtherCAT slave integrano un cosiddetto EtherCAT Slave Controller (ESC) in grado di processare i frame on-the-fly e in modo puramente hardware, il che rende le prestazioni della rete predicibili e indipendenti dalla particolare implementazione dei dispositivi slave.

1.2 Il Protocollo EtherCAT 

EtherCAT utilizza frame Ethernet standard. I frame EtherCAT sono identificati da EtherType 0x88A4. Essendo EtherCAT ottimizzato per pochi dati di processo ciclici, è possibile evitare l’utilizzo di ingombranti stack software come TCP/IP o UDP/IP.

EtherCAT in un frame Ethernet standard (in base alla specifica IEEE 802.3)

Per consentire una comunicazione Ethernet classica tra i nodi, è possibile trasferire i telegrammi TCP/IP tramite tunneling attraverso un canale aciclico senza impattare sullo scambio di dati deterministico.

Durante la fase di avvio, il master configura e mappa i dati ciclici di processo negli slave. Ogni slave può scambiare quantità di dati variabili, da un bit ad alcuni byte, o perfino kilobyte di dati.

Ogni frame EtherCAT contiene uno o più Datagram. Il Datagram header indica quale tipo di accesso il dispositivo master richiede:

• Lettura, scrittura o lettura+scrittura
• Accesso ad uno secifico slave tramite indirizzamento diretto, o accesso a più slave attraverso indirizzamento logico (indirizzamento implicito).

L’indirizzamento logico è utilizzato per lo scambio dei dati di processo ciclici. Ciascun Datagram indirizza uno specific sottinsieme dell’immagine di processo della rete, la cui dimensione massima complessiva può raggiungere i 4 GByte. Durante la configurazione iniziale, ad ogni slave viene assegnata una locazione specifica in tale spazio di indirizzamento globale. Slave allocati nello stesso intervallo possono essere indirizzati dallo stesso Datagram. Dato che i Datagram contengono tutta l’informazione relativa all’accesso dati, il master può decidere quando e a quali dati accedere. Per esempio, il master può utilizzare tempi ciclo veloci per accedere ai dati dei servoazionamenti, e tempi ciclo più lenti per campionare gli I/O. Questo semplifica il funzionamento del master rispetto ad altri bus di campo, nei quali i dati di ogni nodo devono essere letti individualmente, ordinati da un processore, e copiati in memoria.

In EtherCAT, il master deve solo riempire un singolo frame EtherCAT con nuovi dati di uscita, e inviare il frame al controllore MAC tramite Direct Memory Access (DMA). Quando un frame con nuovi dati di ingresso è ricevuto dal MAC, il master può trasferire il frame sempre via DMA nella memoria del controllore – il tutto senza che la CPU debba attivamente effettuare alcuna operazione di copiatura. Accanto ai dati ciclici, ulteriori Datagram possono essere utilizzati per la comunicazione asincrona o basata su evento .

Aggiungere dati di processo on-the-fly

Oltre che tramite indirizzamento logico, il master può accedere a uno slave in base alla posizione di quest’ultimo nella rete. Questo metodo è utilizzato in fase di configurazione iniziale per determinare la topologia della rete e confrontarla con quella attesa.

Dopo aver verificato la configurazione della rete, il master può assegnare ad ogni nodo un indirizzo preconfigurato e comunicare con il nodo stesso attraverso tale indirizzo fisso. Questo consente di accedere ai singoli dispositivi anche qualora la topologia della rete venga modificata, come in applicazioni Hot Connect. Esistono due soluzioni per la comunicazione slave to slave. Uno slave può inviare dati direttamente ad un altro nodo collocato a valle nella rete. Dato che i telegrammi EtherCAT vengono processati solamente nel percorso di andata, questo tipo di comunicazione diretta dipende dalla topologia della rete ed è adatta in modo particolare ad architetture di macchina fisse (es. macchine per stampa o confezionamento). Al contrario, una comunicazione slave to slave completamente flessibile passa attraverso il master e richiede due cicli di comunicazione (non necessariamente due cicli del controllore). Grazie alle eccellenti prestazioni di EtherCAT, questo tipo di comunicazione slave to slave è comunque più veloce di quella realizzabile con altre tecnologie bus di campo.

1.3 Topologia Flessibile 

Linea, albero, stella, o cascata: EtherCAT supporta praticamente tutte le topologie. EtherCAT consente di implementare una topologia a daisy chain o a linea pura con centinaia di nodi senza le limitazioni che normalmente nascono quando switch o hub vengono posti in cascata.

In fase di cablaggio, la combinazione di linee con diramazioni o segmenti in cascata è particolarmente vantaggiosa: le porte necessarie per creare le diramazioni sono direttamente integrate in molti moduli di I/O, per cui non sono richiesti switch addizionali o altri componenti infrastrutturali attivi. La classica topologia a stella di Ethernet può essere ovviamente utilizzata anch’essa.

Macchine modulari o che prevedano cambi di utensile richiedono che segmenti di rete o singoli nodi vengano connessi e disconnessi durante il funzionamento. Gli EtherCAT Slave Controller integrano già il presupposto per la funzionalità di Hot Connect. Se un nodo adiacente viene disconnesso, la porta si chiude automaticamente cosicché il resto della rete può continuare a funzionare senza interruzioni. Rapidi tempi di reazione <15µs garantiscono un passaggio regolare.

EtherCAT offre una grande flessibilità quanto alla tipologia di cavi, e ogni segmento può utilizzare il mezzo fisico più adatto alla situazione. Cavi Ethernet industriale economici posso essere utilizzati per la connessione tra nodi distanti fino a 100m utilizzando lo standard 100BASE-TX. La tecnologia EtherCAT P consente inoltre la trasmissione di dati e alimentazione sullo stesso cavo: questa opzione consente la connessione di dispositivi quali sensori con una singola linea. Possono essere utilizzate anche fibre ottiche (di tipo 100BASE-FX), ad esempio per coprire distanze di collegamento superiori a 100m.

Topologia flessibile – liea, albero o stella

Una rete EtherCAT può includere fino a 65,535 dispositivi, dunque l’espandibilità della rete è praticamente infinita. Dato il numero praticamente illimitato di nodi, dispositivi modulari come sistemi di I/O possono essere realizzati in modo tale che ogni modulo sia uno slave EtherCAT indipendente e autonomo. Pertanto, è possibile eliminare il bus di estensione locale; le elevate prestazioni di EtherCAT raggiungono ogni modulo direttamente e senza ritardi, in quanto l’accoppiatore non deve effettuare nessuna conversione di protocollo.

1.4 EtherCAT P: segnale e alimentazione in un solo cavo 

EtherCAT P (P = power) è un’estensione del protocollo EtherCAT finora descritto. Essa consente di trasmettere non solo i dati, ma anche la tensione di alimentazione attraverso un singolo cavo Ethernet standard a quattro fili.

Dal punto di vista del protocollo EtherCAT e EtherCAT P sono identici, in quanto l’estensione riguarda solamente il livello fisico. Per implementare EtherCAT P non sono necessari EtherCAT Slave Controller specifici. Si potrebbe dire che EtherCAT P ha gli stessi vantaggi di EtherCAT dal punto di vista della comunicazione ma fornisce in più l’alimentazione attraverso il cavo di comunicazione, il che determina benefici e vantaggi per numerose applicazioni.

EtherCAT P: dati e alimentazione su un cavo

Le due tensioni 24V indipendenti ed elettricamente isolate alimentano i dispositivi EtherCAT P, dotati di US dedicata all’elettronica e ai sensori e UP destinata alla periferia e agli attuatori. Entrambe le tensioni US e UP sono trasmesse direttamente sulla linea di comunicazione EtherCAT a 100Mbit/s. Grazie a ciò, gli utilizzatori possono connettere in cascata diversi dispositivi EtherCAT P con un unico cavo. Ciò consente una semplificazione del cablaggio, un contenimento dei costi e una riduzione delle dimensione di dispositivi, apparati e macchine.

EtherCAT P è particolarmente vantaggioso per quelle parti di macchina indipendenti e spesso isolate, potendo ora queste essere raggiunte con dati e alimentazione attraverso un singolo cavo. Sensori di ogni tipo si prestano perfettamente a EtherCAT P: un singolo connettore M8 consente un’efficiente integrazione di questi dispositivi nella rete ad alta velocità e li connette all’alimentazione. Possibili errori nella connessione dei dispositivi vengono evitati grazie alla codifica meccanica dei connettori.

EtherCAT P può essere utilizzato insieme a EtherCAT tradizionale nella stessa rete. Componenti dedicati trasformano il livello fisico di EtherCAT tradizionale in EtherCAT P mantenendo la codifica dei dati. Allo stesso modo, un dispositivo può essere alimentato con EtherCAT P ma trasmettere EtherCAT standard in uscita.
continua a leggere...

1.5 Distributed Clock per una Precisa Sincronizzazione 

In applicazioni caratterizzate da processi distribuiti nello spazio e che richiedano azioni simultanee, un’esatta sincronizzazione è particolarmente importante. È il caso, ad esempio, di più azionamenti che eseguano movimenti coordinati.

A differenza di una comunicazione completamente sincrona, la cui qualità soffre immediatamente di errori di comunicazione, i clock distribuiti sincronizzati hanno un alto grado di tolleranza nei confronti del jitter di comunicazione. Per questo, la soluzione EtherCAT per la sincronizzazione dei nodi è basata sull’approccio dei distributed clock (DC).

Sincronizzazione completamente hardware con compensazione dei ritardi di propagazione

La calibrazione dei clock nei singoli nodi avviene a livello completamente hardware. Il riferimento temporale del primo slave DC è distribuita ciclicamente a tutti gli altri dispositivi del sistema. Con questo meccanismo, i clock degli slave possono essere sincronizzati precisamente a quello del clock di riferimento. Il jitter di sincronizzazione risultante è di molto inferiore a 1µs.

Poiché il riferimento temporale inviato dal reference clock giunge agli altri slave con un certo ritardo di propagazione, quest’ultimo deve essere misurato e compensato per ogni slave in modo da garantire sincronismo e simultaneità. Il ritardo è misurato durante la fase di avvio della rete e, se necessario, anche a regime, il che garantisce una massima deviazione tra i clock di molto inferiore a 1µs.

Sincronismo e simultaneità – traccia di due dispositivi di uscita digitale separati da 300 nodi e 120 m di cavo.

Se tutti i nodi condividono lo stesso riferimento temporale, essi possono attivare le proprie uscite simultaneamente o acquisire i propri ingressi con un timestamp ad elevata precisione. In applicazioni di controllo assi, la stabilità del tempo ciclo è tanto importante quanto il sincronismo e la simultaneità. In tali applicazioni, la velocità è normalmente derivata dalla posizione misurata, per cui è fondamentale che le misure di posizione siano temporalmente equidistanti: fluttuazioni anche minime nell’istante di misura della posizione possono tradursi in un errore maggiore nella velocità calcolata, specialmente in caso di tempi ciclo rapidi. Con EtherCAT, le misure di posizione sono innescate dal preciso clock locale e non dal bus, il che garantisce un’accuratezza molto maggiore.

Inoltre, l’utilizzo dei distributed clock ammorbidisce anche le specifiche sul dispositivo master; dato che azioni come la misura della posizione vengono innescate dal clock locale invece che dalla ricezione del frame, il master non è soggetto a requisiti particolari relativamente all’invio dei frame. Questo consente di implementare il master a livello completamente software su di un hardware Ethernet standard. Anche un jitter dell’ordine di grandezza dei microsecondi non diminuisce l’accuratezza dei distributed clock! Dato che tale accuratezza non dipende da quando avviene la regolazione del clock, l’istante esatto di trasmissione del frame diventa irrilevante. Il master EtherCAT deve solamente garantire che il telegramma EtherCAT venga inviato sufficientemente in anticipo rispetto all’istante in cui il segnale DC all’interno dei dispositivi slave inneschi l’attuazione delle uscite.

1.6 Diagnostica e Localizzazione Errori 

L’esperienza con i fieldbus convenzionali ha mostrato come le proprietà di diagnostica giochino un ruolo fondamentale nel determinare la disponibilità della macchina e i tempi di messa in servizio. Accanto all’individuazione degli errori, è importante anche la loro localizzazione in fase di ricerca guasti. EtherCAT consente di scansionare e confrontare la topologia reale della rete con quella configurata durante la fase di avvio. EtherCAT supporta in modo intrinseco anche molte altre funtionalità di diagnostica.

L’EtherCAT Slave Controller in ogni nodo effettua un controllo di ridondanza ciclico su ogni frame. I dati in esso contenuti sono inoltrati all’applicazione dello slave solo se il frame ricevuto è valido. Se viene individuato un errore, viene incrementato un corrispondente contatore e i nodi successivi vengono informati che il frame è corrotto. Anche il dispositivo master individuerà che il frame è stato danneggiato e scarterà i dati. Il master può localizzare dove il frame è stato originariamente corrotto analizzando i singoli contatori di errore degli slave. Ciò rappresenta un vantaggio enorme in confronto ai fieldbus convenzionali, nei quali gli errori si propagano sull’intero mezzo fisico rendendo impossibile localizzarne la sorgente. EtherCAT consente di individuare e localizzare disturbi occasionali prima che il problema impatti sul funzionamento della macchina.

Grazie all’efficiente utilizzazione della banda di EtherCAT, che è ordini di grandezza migliore rispetto alle tecnologie Ethernet industriale basate su frame individuali, la probabilità di errori causati da disturbi è molto inferiore a parità di tempo ciclo. E, nel caso di tempi ciclo molto rapidi – scenario tipico per EtherCAT – il tempo richiesto per il riavvio della rete a seguito di un errore è molto inferiore.

All’interno dei frame, il Working Counter consente di monitorare la consistenza dei dati in ogni Datagram. Ogni nodo indirizzato da un Datagram e la cui memoria sia accessibile incrementa automaticamente il corrispondente Working Counter. Il master è quindi in grado di verificare ciclicamente se tutti i nodi stanno lavorando con dati consistenti. Se il Working Counter ha un valore diverso da quello atteso, il master non inoltra i dati del Datagram all’applicazione di controllo. Il master può poi determinare la causa del comportamento inatteso con l’aiuto delle informazioni di stato e di errore provenienti dai nodi, così come dello stato del link fisico.

Dato che EtherCAT utilizza frame Ethernet standard, il traffico di rete può essere registrato tramite software gratuiti come Wireshark, che viene fornito con un interprete di protocollo specifico per EtherCAT.
Diagnostica EtherCAT per Utilizzatori
Diagnostica EtherCAT per Sviluppatori

1.7 Requisiti di Alta Disponibilità 

Per macchine e dispositivi aventi esigenze di alta disponibilità, un’interruzione di un cavo o il malfunzionamento di un nodo non devono determinare in alcun modo l’irraggiungibilità di un segmento della rete o l’arresto della rete stessa.

EtherCAT permette la ridondanza di cavo con semplici accorgimenti. Connettendo un cavo dall’ultimo nodo ad una porta di rete addizionale nel master, una topologia a linea viene estesa in una topologia ad anello. Un evento di ridondanza, come l’interruzione di un cavo o il malfunzionamento di un nodo, è individuato da un supplemento software nel dispositivo master. Questo è tutto!

Gli slave non richiedono di essere modificati, e non sono neppure a conoscenza del fatto che stiano lavorando in condizioni di rete ridondata.

Ridondanza di cavo con dispositivi EtherCAT slave standard

Il monitoraggio del link fisico negli slave individua e risolve automaticamente i casi di ridondanza con tempi di reazione inferiori a 15 µs, cosicché al massimo un frame ciclico viene perso. Questo significa che perfino applicazioni di controllo assi con tempi ciclo molto brevi possono continuare a funzionare quando un cavo viene interrotto.

In EtherCAT è possibile realizzare anche una ridondanza di master con funzionalità di Hot Standby. Componenti di rete vulnerabili, come quelli connessi tramite una catena portacavi, possono essere collegati come diramazione della rete, in modo che anche a fronte dell’interruzione del cavo il resto della macchina continui a funzionare.

1.8 Safety over EtherCAT 

I moderni sistemi di comunicazione non implementano soltano lo scambio deterministico dei dati di controllo, ma consentono anche il trasferimento di informazioni di sicurezza sullo stesso mezzo fisico. EtherCAT utilizza a questo scopo il protocollo Safety over EtherCAT (FSoE = Fail Safe over EtherCAT) e rende quindi possibile:

• Un solo sistema di comunicazione per i dati di controllo e per quelli di sicurezza
• La possibilità di modificare ed espandere l’architettura del sistema di sicurezza
• Soluzioni pre certificate per semplificare le applicazioni di sicurezza
• Ampie informazioni di diagnostica per le funzioni di sicurezza
• Semplice integrazione del progetto di sicurezza nel progetto della macchina
• Stesso ambiente di sviluppo per le applicazioni standard e di sicurezza

Safety over EtherCAT consente architetture di sicurezza più semplici e flessibili rispetto ad una logica a relè.

La tecnologia di sicurezza EtherCAT è stata sviluppata in accordo alla normativa IEC 61508, è approvata dal TÜV SÜD Rail, ed è standardizzata nella specifica IEC 61784-3. Il protocollo è idoneo ad applicazioni di sicurezza con Safety Integrity Level fino a SIL 3.

Con Safety over EtherCAT, il sistema di comunicazione è parte del cosiddetto “black channel”, considerato non rilevante ai fini della sicurezza. Il sistema di comunicazione fa uso di un singolo canale per trasferire sia i dati standard che quelli di sicurezza. I frame di sicurezza, denominati Safety Container, contengono i dati di processo critici insieme all’informazione necessaria per garantirne l’integrità. I Safety Container sono scambiati come parte dei dati di processo. Il fatto che il trasferimento dei dati sia sicuro non dipende dalla tecnologia di comunicazione, e non è quindi limitato ad EtherCAT; i Safety Container possono viaggiare attraverso fieldbus, Ethernet o tecnologie analoghe, e possono utilizzare cavi di rame, fibre ottiche o perfino connessioni wireless.

Il Safety Container è mappato all´interno dei dati di processo ciclici di comunicazione.

Grazie a questa flessibilità, connettere in modo sicuro diverse parti della macchina è più semplice. Il Safety Container è instradato attraverso i vari controllori e processato nelle diverse parti dell’impianto. Questo consente di implementare funzioni di arresto di emergenza per l’intera macchina o fermarne una parte in modo semplice, anche se tali parti sono connesse con altre tecnologie (es. Ethernet).

Implementare il protocollo FSoE in un dispositivo richiede risorse limitate garantendo elevate prestazioni e rapidi tempi di risposta. Nell’industria robotica, esistono applicazioni che utilizzano FSoE per applicazioni di controllo assi di sicurezza con un anello di controllo a 8 kHz.

Principio “black channel”: è possibile utilizzare l´interfaccia di comunicazione standard.

Ulteriori informazioni relative a Safety over EtherCAT sono disponibili qui:
www.ethercat.org/safety

1.9 Profili di Comunicazione 

Allo scopo di configurare i dispositivi slave ed estrarne informazioni di diagnostica, è possibile accedere alle variabili mediante comunicazione aciclica. Quest’ultima è basata su un protocollo mailbox affidabile con funzionalità di auto-recover in caso di perdita o danneggiamento dei messaggi.

Per supportare un’ampia varietà di dispositivi e applicazioni, sono stati definiti i seguenti profili di comunicazione EtherCAT:

• CAN application protocol over EtherCAT (CoE)
• Servo drive profile, secondo specifica IEC 61800-7-204 (SoE)
• Ethernet over EtherCAT (EoE)
• File access over EtherCAT (FoE)
• Automation Device Protocol over EtherCAT (ADS over EtherCAT, AoE)

Differenti profili di comunicazione possono coesistere nello stesso dispositivo.

Uno slave non supporta necessariamente tutti i profile di comunicazione; al contrario, è possibile decidere quale profilo è più adatto alle specifiche necessità. Il dispositivo master è informato su quali profili di comunicazione sono stati implementati nello slave attraverso il file descrittivo di quest’ultimo.

1.9.1 CAN application protocol over EtherCAT (CoE) 

Tramite il protocollo CoE, EtherCAT fornisce gli stessi meccanismi di comunicazione di CANopen®-Standard EN 50325-4: Object Dictionary, mappatura dei PDO (Process Data Objects) e SDO (Service Data Objects) – anche la gestione della rete è simile. Ciò permette di implementare EtherCAT con uno sforzo minimo in dispositivi precedentemente dotati di interfaccia CANopen, e persino di riutilizzarne gran parte del firmware. Opzionalmente è possibile superare la limitazione di 8 byte di lunghezza per i PDO, così come sfruttare l’ampia banda di EtherCAT per supportare l’upload dell’intero Object Dictionary. Anche i profili di dispositivo, come quello per azionamenti CiA 402, possono essere riutilizzati in EtherCAT.

1.9.2 Servo drive profile basato su IEC 61800 7 204 (SoE) 

SERCOS™ è noto come interfaccia di comunicazione deterministica, specialmente per applicazioni di controllo assi. Il profilo SERCOS™ per azionamenti è definito nello standard internazionale IEC 61800-7. Tale standard contiene anche la mappatura di questo profilo su EtherCAT. Il canale di servizio, comprensivo di accesso ai parametri e alle funzioni interne dell’azionamento, è mappato nella Mailbox di EtherCAT.

1.9.3 Ethernet over EtherCAT (EoE) 

EtherCAT utilizza il layer fisico e frame Ethernet. Il termine Ethernet è anche associato comunemente al trasferimento di dati in applicazioni IT, basate su connessioni TCP/IP.

Trasmissione trasparente di protocolli IT standard

Utilizzando il protocollo Ethernet over EtherCAT (EoE) qualunque traffico dati Ethernet può essere trasportato all’interno di datagrammi EtherCAT. I dispositivi Ethernet sono connessi alla rete EtherCAT attraverso i cosiddetti Switchport. I frame Ethernet, così come i protocolli internet (e.g. TCP/IP, VPN, PPPoE (DSL), etc.) sono veicolati su EtherCAT in modo trasparente tramite tunneling. Il dispositivo dotato di funzionalità Switchport si occupa di inserire i frammenti TCP/IP nel traffico EtherCAT ed impedisce pertanto che venga compromesso il determinismo della comunicazione.

In aggiunta, dispositivi EtherCAT possono supportare protocolli Ethernet (come HTTP) localmente, e comportarsi quindi come nodi Ethernet tradizionali esterni ad una rete EtherCAT. Il master si comporta come uno switch di livello 2, capace di inviare i frame ai nodi destinatari tramite EoE in base ai loro indirizzi MAC. In questo modo, è possibile supportare tutte le tecnologie internet quali web server, e-mail, trasferimento FTP in un contesto EtherCAT.

1.9.4 File access over EtherCAT (FoE) 

Questo semplice protocollo, simile a TFTP (Trivial File Transfer Protocol) consente l’accesso a file all’interno di un dispositivo e l’aggiornamento del firmware attraverso la rete. Il protocollo è stato volutamente definito in modo essenziale, così da poter essere supportato da applicazioni di boot loader senza necessità di stack TCP/IP.

1.9.5 ADS over EtherCAT (AoE) 

Protocollo client-server basato su Mailbox, ADS over EtherCAT (AoE) è definito dalla specifica EtherCAT. Mentre protocolli come CAN application protocol over EtherCAT (CoE) forniscono una dettagliata semantica dei dati, AoE li integra perfettamente tramite servizi paralleli e instradabili ogniqualvolta l'applicazione lo richieda. Per esempio, ciò potrebbe includere l'accesso attraverso EtherCAT a sotto-reti come CANopen®, IO-Link™ e altre mediante dispositivi gateway.

AoE possiede un overhead molto inferiore rispetto a servizi analoghi forniti dal protocollo IP. I parametri di indirizzamento della sorgente e del destinatario sono sempre contenuti nel telegramma AoE - di conseguenza, è possibile un'implementazione molto semplice sia lato client che lato server. AoE è anche il protocollo prescelto per la comunicazione aciclica mediante EtherCAT Automation Protocol (EAP), e consente pertanto una comunicazione diretta tra sistemi MES, master EtherCAT e dispositivi bus di campo subordinati connessi attraverso gateway. AoE rappresenta anche un protocollo standard per acquisire informazioni di diagnostica da una rete EtherCAT da parte di software di diagnostica remoti.

1.10 Comunicazione di Impianto EtherCAT Automation Protocol (EAP) 

Il livello di controllo di processo presenta requisiti di comunicazione che differiscono in parte da quelli a cui si rivolge l’EtherCAT Device Protocol descritto nei precedenti paragrafi. Macchine o sezioni di impianto richiedono spesso di scambiare informazioni sul proprio stato o sul successivi step di produzione. Inoltre, è presente di norma un controllore centrale che supervisiona l’intero processo produttivo, fornisce agli utilizzatori informazioni di stato relativamente alla produttività, e impartisce ordini alle varie stazioni della macchina. EtherCAT Automation Protocol (EAP) soddisfa tutti questi requisiti.

Comunicazione di impianto con EtherCAT

Il protocollo definisce interfacce e servizi per:

• Scambio dati tra dispositivi EtherCAT Master (comunicazione master-master),
• Comunicazione verso interfacce uomo-macchina (HMI),
• Un controllore di supervisione per accedere a dispositivi appartenenti ai segmenti EtherCAT sottostanti (Routing),
• Integrazione di tool per la configurazione dell’impianto, così come per quella dei dispositivi.

Architettura di comunicazione di un impianto con EtherCAT Automation Protocol e Safety over EtherCAT

I protocolli di comunicazione utilizzati da EAP sono parte dello standard internazionale IEC 61158. EAP può essere trasmesso su qualunque connessione Ethernet, inclusi collegamenti wireless, consentendo ad esempio di gestire veicoli a guida automatica (AGV) comuni nelle industrie dei semiconduttori e automotive.

Lo scambio di dati ciclico segue in EAP la logica „Push“ o quella „Poll“. In modalità “Push”, ogni nodo invia i propri dati con il proprio tempo ciclo o un multiplo di esso. Ogni ricevitore può essere configurato per intercettare i dati di specifiche sorgenti. La configurazione dei dati trasmessi e ricevuti avviene tramite l’Object Dictionary. In modalità “Poll”, un nodo (spesso il controllore centrale) invia un telegramma a tutti gli altri nodi, e ognuno di questi risponde con il proprio telegramma.

La comunicazione EAP ciclica può essere inserita direttamente all’interno del frame Ethernet, senza ulteriori protocolli di trasporto o di instradamento. L’EtherType 0x88A4 indica ancora che il frame è utilizzato da EtherCAT. Ciò consente di scambiare dati tramite EAP con tempi ciclo dell’ordine dei millisecondi. Qualora sia necessario l’instradamento dei dati tra macchine remote, i dati di processo possono essere trasmessi anche via UDP/IP o TCP/IP.

Inoltre, grazie al protocollo Safety over EtherCAT, è possibile trasmettere su EAP anche dati di sicurezza. In questo modo parti di una macchina possono realizzare una funzione di arresto di emergenza globale, o informare i moduli adiacenti in merito all’intervento di una funzione di sicurezza locale.

1.11 Integrazione di Altri Bus di Campo 

L’ampia banda di comunicazione di EtherCAT consente di integrare reti bus di campo convenzionali come sistemi subordinati attraverso un gateway EtherCAT, il che è particolarmente utile in caso di migrazione da un bus di campo convenzionali a EtherCAT. Il passaggio a EtherCAT può così essere graduale, e consente di continuare a utilizzare componenti che non supportano ancora un’interfaccia EtherCAT.

Interfacce bus di campo decentralizzate

La capacità di integrare gateway decentralizzati riduce inoltre la dimensione fisica del PC industriale, e in alcuni casi di poter addirittura utilizzare PC embedded, in quanto non sono più richieste schede di espansione. In passato, tali schede erano necessarie anche per connettere dispositivi complessi, come gateway bus di campo master e slave, interfacce seriali veloci, e altri sottosistemi di comunicazione. Con EtherCAT, tutto quello che è richiesto per collegare questi dispositivi è una singola porta di rete. I dati di processo del sottosistema subordinato sono resi direttamente disponibili nell’immagine di processo di EtherCAT.

1.12 Attuare la Trasformazione Digitale con EtherCAT, Industrie 4.0 e IoT 

Ottimizzazione di processo, manutenzione predittiva, produzione come servizio, sistemi adattativi, risparmio di risorse, fabbriche intelligenti, riduzione dei costi – esistono innumerevoli buone ragioni per utilizzare i dati delle reti di controllo in sistemi di livello superiore. Internet of Things (IoT), Industrie 4.0, Made in China 2025, Industrial Value Chain Initiative: esiste un’esigenza diffusa per una comunicazione diretta e standardizzata attraverso tutti i livelli. Dati di sensori caricati nel cloud insieme a ricette, o parametri scaricati da sistemi ERP in dispositivi distribuiti; si pensi ad esempio ad un sistema di alimentazione condiviso da due macchine: esistono requisiti sul flusso dei dati in direzione sia verticale sia orizzontale. EtherCAT soddisfa intrinsecamente i requisiti della trasformazione digitale grazie alle sue elevate prestazioni, alla flessibilità e all’apertura delle interfacce. Le prestazioni superiori del sistema sono il prerequisito per includere la gestione di Big Data nelle reti di controllo.

EtherCAT fornisce la flessibilità per integrare la connettività al cloud a sistemi esistenti senza dover modificare minimamente il controllore o aggiornare gli slave: un Edge Gateway può accedere ai dati locali di qualunque slave EtherCAT attraverso la funzionalità di Mailbox Gateway del master EtherCAT. L’Edge Gateway può essere sia un dispositivo remoto, connesso al master via TCP o UDP/IP, sia un modulo software collocato direttamente nello stesso hardware del master EtherCAT.

Inoltre, le interfacce aperte consentono di integrare qualsiasi protocollo IT - inclusi OPC UA, MQTT, AMQP e altri – o all’interno del master o direttamente nei dispositivi slave, fornendo quindi un collegamento diretto per IoT dal sensore al cloud senza discontinuità di protocollo.

Tutte queste proprietà fanno parte da sempre del protocollo EtherCAT, il che mostra quanto lungimirante sia la sua architettura. Ciononostante, opzioni di connettività addizionali vengono introdotte quando queste si sviluppano e diventano rilevanti. Ovviamante è importante considerare anche il passato quando si guarda al futuro: l’introduzione di nuove funzionalità è gestita in totale continuità, e il protocollo EtherCAT in sé è stabile alla sua “Versione 1” sin dalla sua introduzione nel 2003.

Ulteriori nuovi sviluppi nell’ambito del Time Sensitive Networking (TSN) migliorano ulteriormente le proprietà di determinismo della comunicazione tra controllori. Grazie a TSN, i controllori – inclusi quelli basati sul cloud – possono accedere ad una rete di slave EtherCAT anche attraverso le reti dell’impianto. Dato che EtherCAT tipicamente necessita di un singolo frame ciclico per tutta la rete, questo accesso è molto più semplice e più veloce che con qualunque altra tecnologia bus di campo o Ethernet industriale. Gli esperti di EtherCAT Technology Group contribuiscono al gruppo di lavoro TSN all’interno dello standard IEEE 802.1 fin dagli esordi – in un tempo in cui TSN era ancora noto come AVB (Audio Video Bridging).

EtherCAT Technology Group (ETG) è stata anche tra le prime organizzazioni bus di campo a stabilire una collaborazione con OPC Foundation. Il protocollo OPC UA complementa EtherCAT, essendo una tecnologia di comunicazione client/server basata su TCP/IP con sicurezza intrgrata che consente di trasferire dati in forma criptata ai sistemi MES/ERP. Con OPC UA Pub/Sub, l’utilizzabilità di OPC UA è stata ottimizzata in applicazioni maccina-macchina (M2M) e per la comunicazione verticale verso servizi basati sul cloud. ETG contribuisce attivamente a tutti questi sviluppi per garantire che essi siano interamente compatibili con EtherCAT.

EtherCAT non è quindi solo pronto per IoT, EtherCAT è già IoT!

Per saperne di più su EtherCAT & TSN...

 

 

La tecnologia EtherCAT è stata ottimizzata per consentire un’implementazione con costi contenuti, pertanto aggiungere un’interfaccia EtherCAT ad un sensore, a un dispositivo di I/O o ad un controllore embedded non incrementa significativamente i costi complessivi. Inoltre, l’interfaccia EtherCAT non richiede una CPU di elevate prestazioni – i requisiti sulla CPU dipendono unicamente dall’applicazione finale.

Oltre ai requisiti hardware e software, in fase sviluppo di un’interfaccia sono importanti il supporto all’implementazione e la disponibilità di stack di comunicazione. EtherCAT Technology Group offre supporto allo sviluppo in tutto il mondo. Infine, sono disponibili kit di valutazione di diversi fornitori, seminari per sviluppatori ed codici di esempio gratuiti che permettono di intraprendere lo sviluppo più semplicemente.

Per l’utilizzatore finale, il fattore più importante è l’interoperabilità tra dispositivi di vari fornitori. Per assicurare tale interoperabilità, i fornitori di dispositivi sono chiamati ad eseguire un test di conformità prima di poter introdurre il loro dispositivi sul mercato. Tale test verifica che l’implementazione rispetti la specifica EtherCAT, e può essere eseguito tramite il Conformance Test Tool. Questo software può essere utilizzato anche durante la fase di sviluppo del dispositivo in modo da individuare e correggere tempestivamente errori di implementazione.

2.1 Master 

L’interfaccia per un dispositivo EtherCAT master ha un unico, semplicissimo requisito: una porta Ethernet. L’implementazione utilizza o l’Ethernet controller integrato, o una scheda di rete standard di costi contenuti, per cui non è richiesta alcuna costosa scheda di interfaccia dedicata. Questo significa che con una sola porta Ethernet standard è possibile implementare una soluzione di rete hard real-time.

Nella maggior parte dei casi l’Ethernet controller è integrato attraverso Direct Memory Access (DMA), per cui non vengono consumate risorse della CPU per il trasferimento dei dati tra il dispositivo master e la rete. In una rete EtherCAT, la mappatura avviene nei dispositivi slave. Ogni slave scrive i dati da lui prodotti e legge i dati a lui indirizzati nel punto corretto dell’immagine di processo, il tutto mentre il telegramma lo sta attraversando. Perciò, l’immagine di processo che arriva al master è già ordinata nel modo corretto.

Dato che la CPU del dispositivo master non è più responsabile dell’ordinamento, i requisiti sulle sue prestazioni dipendono esclusivamente dall’applicazione di controllo e non dall’interfaccia EtherCAT. Specialmente per applicazioni medio-piccole, realizzare un master EtherCAT è semplicissimo. Dispositivi EtherCAT master sono stati implementati per una vasta gamma di sistemi operativi: Windows e Linux, QNX, RTX, VxWorks, Intime, eCos sono solo alcuni esempi.

Tipica architettura di un EtherCAT Master

I membri ETG offrono una varietà di opzioni per agevolare l’implementazione di un dispositivo master, da librerie gratuite scaricabili dalla rete, a codici sorgente di esempio, fino a pacchetti completi (inclusivi di servizi) per diversi sistemi operativi e CPU.

Per poter gestire la rete, il master EtherCAT deve conoscere la struttura dei dati ciclici così come i comandi di inizializzazione per ogni dispositivo slave. Questi comandi possono essere esportati in un file denominato EtherCAT Network Information (ENI) con l’aiuto di un software di configurazione della rete, che utilizza i file EtherCAT Slave Information (ESI) dei singoli slave connessi alla rete stessa.

Lo spettro delle implementazioni master disponibili e delle loro funzionalità varia. A seconda dell’applicazione finale, funzionalità opzionali sono supportate o volutamente omesse per ottimizzare l’utilizzazione delle risorse hardware e software. Per questa ragione, i dispositivi EtherCAT master vengono raggruppati in due classi: i master di classe A rappresentano dispositivi EtherCAT master standard, mentre i master di classe B supportano un numero di funzionalità più limitato. Tutte le implementazioni master dovrebbero in linea di principio aspirare ad essere di classe A: la classe B è raccomandata solamente per quei casi in cui le risorse disponibili non siano sufficienti per supportare tutte le funzionalità, come in sistemi embedded.

2.2 Slave 

I dispositivi EtherCAT slave utilizzano EtherCAT Slave Controller (ESC) di costo contenuto sotto forma di ASIC, FPGA, o integrati in un microcontrollore standard. Slave semplici non richiedono neppure alcun microcontrollore, in quanto ingressi e uscite digitali possono essere connessi direttamente all’ESC. Per dispositivi slave più complessi, le prestazioni della comunicazione dipendono solo mimimamente dalle prestazioni del microcontrollore, e nella maggior parte dei casi un controllore a è sufficiente 8-bit.

EtherCAT Slave Controller sono disponibili da numerosi fornitori: la dimensione della DPRAM interna o il numero di Fieldbus Memory Management Units (FMMU) dipendono dalla particolare variante. Sono disponibili inoltre diverse Process Data Interface (PDI) per l’accesso alla DPRAM da parte del microcontrollore:

• Interfaccia Digital I/O, adatta per connettere fino a 32 ingressi e uscite digitali, ma anche per semplici sensori o attuatori per i quali 32 bit di dati sono sufficienti e non è necessario un controllore per l’applicazione.
• Interfaccia seriale (SPI), adatta per applicazioni con piccole quantità di dati di processo come dispositivi di I/O analogici, encoder, o semplici azionamenti.
• Interfaccia parallela 8/16-bit, corrisponde a interfacce comuni per controllori di bus di campo con DPRAM integrata. È particolarmente adatta per nodi complessi che richiedano di scambiare quantità di dati più elevate.
• Interfacce sincrone per vari microcontrollori sono state implementate per le varianti FPGA e on chip.

Slave Hardware: EtherCAT Slave Controller con I/O diretti

La configurazione hardware è salvata in una memoria non volatile (es. una EEPROM), la Slave Information Interface (SII), la quale contiene informazioni relative alle funzionalità elementari del dispositivo che il master può leggere durante la fase di avvio per poter gestire lo slave anche in assenza del file descrittivo del dispositivo. Il file EtherCAT Slave Information (ESI) fornito insieme allo slave è basato su formato XML è contiene la descrizione completa delle proprietà dello slave, come i dati ciclici di processo e le loro opzioni di mappatura, o le modalità di sincronizzazione supportate. Il software di configurazione della rete utilizza queste informazioni per la definizione della struttura della rete stessa.

Slave Hardware: EtherCAT Slave Controller con CPU

Vari fornitori offrono kit di valutazione per implementare dispositivi EtherCAT slave. Questi kit includono codice applicativo sorgente, e in alcuni casi anche un master di test. Utilizzando un kit di valutazione, è possibile realizzare una rete master-slave EtherCAT perfettamente finzionante in pochi semplici passi. Il sito web di ETG contiene una Slave Implementation Guide contenente utili consigli e riferimenti ad ulteriori documenti per l’implementazione di dispositivi slave:
ETG.2200 EtherCAT and EtherCAT P Slave Implementation Guide

 

Conformità e interoperabilità sono due dei fattori più importanti per uno standard di comunicazione di successo. Questo è il motivo per cui EtherCAT Technology Group tiene entrambi questi fattori in grande rilievo. Oltre a richiedere un test di conformità per ogni dispositivo slave implementato (eseguibile grazie al software automatizzato EtherCAT Conformance Test Tool), ETG offre un’ampia gamma di servizi per assicurare l’interoperabilità tra dispositivi master, slave e software di configurazione.
continua a leggere...

3.1 Plug Fest 

Per verificare l’interoperabilità tra dispositivi, uno dei test più pratici è provare a collegare i dispositivi tra loro. In base a questo principio, ETG organizza ogni anno numerosi Plug Fest, ciascuno della durata di due giorni. Durante i Plug Fest, i fornitori di master e slave si incontrano per verificare come i loro dispositivi operano insieme, il che migliora l’utilizzabilità dei dispositivi sul campo. I partecipanti possono scambiarsi suggerimenti o ricevere risposta alle proprie domande da parte degli esperti di EtherCAT. Plug Fest si tengono in Europa, Nord America e Asia.
continua a leggere...

3.2 Conformance Test Tool (CTT) 

L’EtherCAT Conformance Test Tool (CTT) consente di testare automaticamente il funzionamento di uno slave EtherCAT. Si tratta di un applicativo Windows che presuppone solo la disponibilità di una porta di rete Ethernet standard. Il software invia frame EtherCAT al Device under Test (DuT) e riceve le risposte da quest’ultimo. Uno specifico test è superato se la risposta ricevuta dal DuT corrisponde a quella attesa. I test sono definiti sotto forma di file XML. Questo rende possibile modificare o estendere i test senza dover modificare il tool. Il TWG Conformance (si veda oltre) ha la responsabilità di specificare e rilasciare la versione più aggiornata dei test. In aggiunta ai test relative al protocollo, il CTT verifica anche la validità del EtherCAT Slave Information (ESI). Infine, il CTT esegue test specifici per un dispositivo, come ad esempio per il profilo CiA 402. Tutti i passaggi e i risultati dei test sono salvati in un file di log, e possono essere analizzati o archiviati come documentazione in vista del rilascio del dispositivo.
continua a leggere...

3.3 Technical Working Group Conformance 

L’EtherCAT Conformance Test Policy richiede che i costruttori di dispositivi verifichino ogni implementazione tramite una versione valida dell’EtherCAT Conformance Test Tool prima che il prodotto venga immesso sul mercato. Il costruttore può eseguire il test presso la propria sede. Il Technical Committee (TC) di ETG ha creato un Technical Working Group (TWG) Conformance, che determina le procedure di test, il contenuto dei test, e l’implementazione del Conformance Test Tool. Il TWG Conformance espande continuamente i test e il loro livello di profondità. Il TWG Conformance ha stabilito inoltre una procedura per un test di interoperabilità, tramite la quale i dispositivi possono essere testati all’interno di una rete completa.
continua a leggere...

3.4 EtherCAT Test Center 

Gli EtherCAT Test Center (ETC) ufficiali in Europa, Asia and Nord America sono accreditati da ETG ed consentono di eseguire l’EtherCAT Conformance Test ufficiale. L’EtherCAT Conformance Test include i test automatizzati effettuati con il CTT, test di interoperabilità all’interno di una rete, insieme ad un esame degli identificatori del dispositivo, etichette, e test delle interfacce EtherCAT hardware.

I costruttori di dispositivi slave sono incoraggiati, sebbene non obbligati a far testare i propri dispositivi presso un ETC. A seguito del superamento dell’EtherCAT Conformance Test, il costruttore riceve un certificato EtherCAT Conformance Tested per il dispositivo. Questo certificato è rilasciato solamente per dispositivi che abbiano superato il Conformance Test presso un ETC accreditato - non per quelli che sono stati testati nella propria sede.

Il test addizionale presso un EtherCAT Test Center incrementa ulteriormente la compatibilità, così come l’uniformità del funzionamento e delle funzionalità di diagnostica delle diverse implementazioni EtherCAT. Gli utilizzatori finali dovrebbero richiedere preferenzialmente il certificato EtherCAT Conformance Tested nella fase di selezione dei dispositivi da utilizzare per la propria applicazione.
continua a leggere...

 

EtherCAT Technology Group è un partner ufficiale di IEC. EtherCAT e Safety over EtherCAT sono standard IEC (IEC61158 e IEC61784). Questi standard includono non solo gli strati inferiori del protocollo, ma anche il livello applicativo e i profili dispositivo, ad esempio per azionamenti. SEMI™ (Semiconductor Equipment and Materials International) ha accettato EtherCAT come standard di comunicazione (E54.20) per l'industria dei semiconduttori. I diversi Task Group all'interno del Semiconductor Technical Working Group (TWG) hanno definito profili dispositivo specifici per il settore e guide implementative. La specifica EtherCAT è disponibile in Inglese, Giapponese, Coreano e Cinese.