Servizi comuni per bus di comunicazione

• 
• Tweet
• Pin It
• Condividi per email

L’automazione industriale ha visto nell’ultimo decennio una forte evoluzione verso il controllo di periferia distribuito per mezzo di differenti tipologie di Fieldbus. La sfida attuale cresce in questa direzione e consiste nella possibilità di distribuire il controllo a livello di dispositivo, dopo aver distribuito la periferia di ingressi e uscite.
Nello stimolo verso la distribuzione di campo sono proliferate numerose reti di comunicazione e anche gli standard che le descrivono. Recentemente la normativa Iec 61158 ha cercato di raggrupparli e sono ben otto i differenti standard contemplati. Oltre a queste esistono altre reti comunque descritte da standard internazionali.
Non è quindi aggiungendo una nuova rete che si pone ordine a ciò ma cercando di offrire servizi siano comuni a differenti reti di comunicazione, siano esse fieldbus seriali che bus paralleli. La comunanza di servizi permette un univoco approccio verso le comunicazioni, anche se queste sono diverse fra loro per mezzo fisico o metodo d’accesso al bus. In particolare:
– i servizi di controllo comuni consentono di avere un insieme di servizi standard tra differenti reti di comunicazione;
– i servizi di comunicazione comuni permettono di connettersi a ciascuna rete, configurare e collezionare dati da una rete differente;
– la capacità di routing comuni fa sì che nessuna routing table o logica di controllo addizionale sia richiesta per movimentare dati tra differenti reti e inoltre consente una integrazione verticale senza cuciture dal campo a Internet;
– la base di conoscenza comune riduce la necessità di formazione nel passare da una rete a un’altra.

Il Control and Information Protocol

Il Control and Information Protocol (Cip) è un layer comune sia a reti aperte quali DeviceNet, ControlNet e Ethernet/Ip che al bus proprietario ControlBus di Allen-Bradley. Tale layer permette sia la schedulazione di I/O che il messaging fra processori quindi permette sia il controllo di device di campo che la configurazione di dispositivi e la raccolta di dati.
La parte di Controllo del protocollo è per la gestione real time di I/O: è chimamata anche Implicit Messaging e consente lo scambio dati di I/O tra dispositivi utilizzando risorse connesse (riservate). La parte di Informazione del protocollo è per lo scambio dati Explicit Message, utilizzato per:
– accessi temporanei (disconnesso) e garantiti (connesso) a tutti i dispositivi;
– upload e download di configurazione da/per tutti I dispositivi;
– llettura/scrittura di singoli parametri in un dispositivo;
– raccolta dati da dispositivi di campo;- routing tra altre network Cip-based.
Per mezzo del layer comune Cip è possibile sia configuarare dispositivi che raccogliere dati, inviare comandi e fare routing/bridging nello stesso modo a prescindere dalla rete che si utilizza.
Eppure i fieldbus in questione EtherNet, ControlNet e DeviceNet sono molto diversi fra loro, sia per mezzo fisico (rispettivamente doppino twistato, cavo coassiale e cavo a cinque fili) che per metodo di accesso (rispettivamente Csma/Cd, Crdma, Csma/Nba) mentre hanno in comune il paradigma di comunicazione producer/consumer.
Il Cip si inserisce a livello 4, 5 e 6 (Session, Presentation e Application) dei livelli Iso/Osi di un network e quindi è facilmente applicabile a nuovi possibili networks. Inserendosi inoltre a livello Application permette un identico approccio utente anche se le reti sono poi sostanzialmente differenti fra loro.

Il controllore ControlLogix

Oltre che sulle reti aperte sopra menzionate e gestite dai consorzi aperti Odva e ControlNet International, tale livello di servizi è stato introdotto da Allen-Bradley nel bus ControlBus del proprio controllore ControlLogix. Quest’ultima è una piattaforma di controllo multiprocessore e multitasking di ultima generazione.
Il metodo di comunicazione su ControlBus è producer/consumer così come avviene per ControlNet e per DeviceNet. I moduli di ingresso generano i dati sul backplane, i processori acquisicono i nuovi dati e generano comandi verso i moduli di uscita.
Ciò è reso possibile dal fatto che ciascun modulo ControlLogix monta uno specifico Asic ControlBus che permette di gestire le comunicazioni producer/consumer verso ControlBus sia che si tratti di Processore, di modulo analogico o discreto di I/O o di interfaccia di rete.

Si tratta di un bus passivo parallelo che non impone di posizionare alcun modulo in uno specifico slot (si può mettere il modulo che si vuole dove si vuole) e permette un arbitraggio del bus Multi-Master con accesso al bus secondo un meccanismo Round-Robin con priorità. La comunicazione è flessibile e permette di interfacciare dispositivi a 8, 16, 32 e addirittura 64 bit. Permette inoltre la rimozione ed inserzione del modulo anche sotto tensione (Riup).
Il sistema permette di avere un master clock che gestisce un tempo comune chiamato Cst. Ciascun modulo, si tratti del più stupido modulo di ingresso o del più intelligente modulo di controllo può comunicare col bus secondo i metodi ciclico (detto anche RPI) oppure al cambio di stato (Cos) oppure entrambi. Infine la modalità Message Passing permette di inoltrare informazioni anche a cavallo di reti differenti e senza conoscere le mappe di memoria senza alterare in alcun modo le performance del controllo utilizzando bridge e route realizzati per mezzo dei moduli di comunicazione che si possono utilizzare in quantità e tipologia desiderata.

I vantaggi del layer comune

La concomitanza in un sistema di reti aperte quali ControlNet. EtherNet o DeviceNet e di ControlLogix con il proprio ControlBus permette di realizzare quindi sistemi realmente producer/consumer con comunicazioni integrate e coerenti.
Quali sono dunque i vantaggi di un utente che approccia un sistema ove in tutti i livelli di comunicazione il layer Cip viene integrato?
Anzitutto nel controllo di I/O non ci troviamo più di fronte ad un classica comunicazione source-destination (tipica nel controllo di I/O implementata per esempio dai fielbus Profibus, Rio,…): tipicamente con il metodo source-destination un controllore centrale interrogava uno alla volta tutti gli slave ciclicamente con evidentemente traffici di comunicazioni inutili in quanto venivano molto spesso inviate informazioni inutili in quanto non portavano variazioni rispetto alle precedenti informazioni. Col metodo producer/consumer invece sono generate informazioni solo quando servono e inoltre la frequenza di comunicazione può essere diversa da modulo a modulo o da nodo a nodo (cosa non possibile con source-destination) introducendo così delle priorità tra differenti moduli o nodi.

Per quanto riguarda la configurazione di devices non è necessario andare a scrivere codice di programma nel Plc ma semplicemente attraverso bridge e route vengono indirizzati i dispositivi remoti per mezzo di un Pc. Tramite il dispositivo di programmazione e le reti di comunicazione si configurano quindi i device remoti senza alterare in alcun modo le performance del Plc.

Anche l’acquisizione dati cambia sostanzialmente in quanto non accade più che il Plc master interroga i devices remoti e quindi invia i dati al supervisore ma questo direttamente interroga gli slaves attraverso brides in ControlBus e le reti con Cip integrato, senza la necessità di scrivere del codice programma nei controllori.
In conclusione sono quindi evidenti i vantaggi introdotti utilizzando reti e controllori che permettano di utilizzare dei servizi di comunicazione comuni a sia a reti seriali di comunicazione che bus paralleli di Plc.

Scarica l'allegato

• 
• Tweet
• Pin It
• Condividi per email