3. i sistemi distribuiti - unibg controllano sensori e trasduttori ai quali sono collegati...

Sistemi Logico Programmabili – Cap. 3

Pag. 93

3. I Sistemi Distribuiti

3.1 Dai sistemi centralizzati a quelli distribuiti L’uso dei calcolatori è nel bel mezzo di una rivoluzione. Dal 1945, quando cominciò l’era dei calcolatori moderni, fino a circa il 1985, i calcolatori erano grandi e costosi e perfino i minicalcolatori costavano decine di migliaia di dollari ciascuno. Come risultato, nella maggior parte dei casi, il numero di calcolatori di una organizzazione era esiguo, e poiché non c’era modo di collegarli, questi calcolatori di solito operavano in modo indipendente l’uno dall’altro. A partire dagli anni ottanta, due innovazioni tecnologiche cominciarono a cambiare questa situazione. La prima fu lo sviluppo di potenti microprocessori. Inizialmente si trattava di macchine a 8 bit, ma presto divennero comuni CPU a 16, 32, e perfino 64 bit; molte di esse avevano la potenza computazionale di un mainframe di decenti (cioè grandi) dimensioni , ad una piccola frazione del suo prezzo. La seconda innovazione fu l’invenzione di reti locali o LAN (local area network) ad alta velocità. Questi sistemi permettevano il collegamento di dozzine, centinaia, di macchine in modo tale che piccole quantità di informazioni potessero essere scambiate in circa un millisecondo. Quantità maggiori di dati possono essere trasferite tra le macchine a ritmi maggiori di 10 milioni di bit al secondo. Il risultato di queste due tecnologie è che ora è non solo possibile, ma anche facile, mettere insieme sistemi di calcolo composti da un gran numero di CPU connesse da una rete ad alta velocità. Questi sistemi vengono di solito chiamati sistemi distribuiti, in contrapposizione ai precedenti sistemi centralizzati formati da una sola CPU, dalla sua memoria, dalle periferiche e da alcuni terminali. Il fatto che sia possibile costruire sistemi distribuiti porta a vantaggi e a svantaggi; tra i vantaggi si possono enumerare: la distribuzione intrinseca di alcune applicazioni che richiedono macchine separate e distanti, affidabilità, scalabilità, modularità, la crescita incrementale, la condivisione dei dati, la comunicazione in tempo reale…; sebbene i sistemi distribuiti abbiano i loro punti di forza, essi hanno anche i loro punti deboli, il principale dei quali è il software, molto più complesso che non quello dei sistemi centralizzati, e la dipendenza da un efficiente sistema di comunicazione in tempo reale. Come si è visto esaminando i vari settori del CIM, il vantaggio dell'automazione e della gestione computerizzata dei reparti è strettamente legato al concetto di integrazione e cioé una struttura aziendale viene snellita e resa più efficiente se i computer relativi ad una funzione possono comunicare in tempo reale con i computer relativi ad altre funzioni e magari dislocati in aree differenti. Ad esempio i computer addetti all'interfaccia uomo-macchina devono poter accedere a dati di tipo e

A. Flammini

provenienza diversa e tale "accesso" deve avvenire in tempo reale o perlomeno deve essere scandito da “tag” temporali; infatti per poter intervenire o anche solo analizzare un processo è necessario disporre dei dati di=di(t) in modo da poterli correlare correttamente. 3.1.1 Organizzazione dei sistemi distribuiti in azienda Solitamente troviamo almeno quattro livelli gerarchici in un sistema di comunicazione in ambito CIM (vedi figura).

Pag. 94

Livello 4

Livello 3

Livello 2

Livello 1

Controllo societario/finanziario

Controllo azienda/fabbrica

Direzione di settore Direzione di settore

Controllo di cella

Controllo di cella

Rete locale

Bus di campo

Tali livelli sono spesso indicati come: • AZIENDA (differenti fabbriche che possono trovarsi in località diverse, pur nell'ambito della

stessa organizzazione aziendale, devono essere tra loro interconnesse) • FABBRICA (tutti i minicomputer di ogni reparto devono essere tra loro collegati per consentire

un efficiente scambio di dati) • REPARTO (il minicomputer di ciascun reparto o ufficio deve coordinare le attività complessive

di tutti i sistemi computerizzati presenti nel reparto stesso) • ISOLE

(ogni parte delle attrezzature controllate da computer, macchine utensili, robot, terminali CAD, elaboratori testi, unità di programmazione,... deve poter comunicare in modo efficiente e rapido a seconda del settore applicativo)

A livello di comunicazione tra azienda, fabbrica e reparto operano i sistemi

informativi aziendali che in genere si appoggiano a Intranet, ossia una sottorete locale di Internet. Il principale requisito è la sicurezza, non nel senso della sicurezza rispetto alla propagazione del guasto o della salvaguardia o diagnostica dell’integrità dei dati rispetto a cause accidentali (disturbi), ma nel senso di sicurezza rispetto alle violazioni, cioè ad accessi non autorizzati. A livello di comunicazione tra isole operano le reti


locali (LAN), il cui principale requisito è la compatibilità e l’espandibilità dato che connettono sistemi standard e proprietari. Con l’avvento di Internet spesso i sistemi informativi poggiano direttamente sulle LAN che sono di fatto delle intranet, per cui si tende a parlare di LAN in senso lato. Nel caso si analizzi l’organizzazione CIM del solo reparto di produzione di una azienda manifatturiera, è possibile individuare la tipica struttura, detta piramide CIM, visibile in figura seguente. E

Tipicamente in questo ambito il livello 1 è costituito dai trasduttori (finecorsa, sensori, encoder,…) e attuatori (relè, motori, elettrovalvole, spie di segnalazione,…) posti sull’impianto di produzione; a livello 2 ci sono i controllori di cella (PLC, CNC) che controllano sensori e trasduttori ai quali sono collegati direttamente o tramite bus di campo. Tutti i PLC che coordinano le varie celle di un reparto di produzione sono collegati fra loro tramite rete locale alla quale si connette anche un sistema SCADA di supervisione (livello 3). Il livello 3 viene anche detto livello di sistema e/o celle e i sistemi di comunicazione vengono detti bus di processo o di cella. A livello 4, detto anche livello di controllo e di servizio, ho in generale i sistemi CAD/CAM e, utilizzando una terminologia più moderna, i sistemi ERP/MES. Tali sistemi elaborano i dati di produzione e li presentano in una forma adeguata al management, prelevandoli da tutti i sistemi SCADA della fabbrica ai quali sono connessi, sempre tramite LAN. Salendo nella piramide aumenta la quantità di dati e diminuiscono i requisiti in termini di aderenza stretta al tempo reale.

Piramide CIM ERP SCADA PLC SENSORI - MOTORI

3.1.2 Sistemi di comunicazione: reti Per l'implementazione di un sistema di comunicazione nell'ambito di un singolo stabilimento, si fa normalmente uso delle reti locali (LAN, Local Area Network). Le LAN sono reti private all’interno di un singolo edificio, di dimensione al più di qualche chilometro. Esse sono utilizzate per collegare i calcolatori, le stazioni di lavoro degli uffici o degli stabilimenti delle aziende per permettere la condivisione delle risorse e lo scambio di informazioni. Le LAN si distinguono dagli altri tipi di rete (MAN metropolitan area network, WAN wide area network...) per tre caratteristiche:

(1) le loro dimensioni, (2) la loro tecnologia

Pag. 95

A. Flammini

Pag. 96

(3) la loro topologia. Le LAN sono di dimensioni ridotte (pochi Km), che significa che il tempo peggiore di comunicazione è limitato e conosciuto a priori; permettono velocità di trasmissione che vanno dai 10 a100 Mbps, fanno pochi errori, hanno un basso ritardo (decine di microsecondi). Le LAN usano spesso una tecnologia di trasmissione ad un solo cavo al quale tutte le macchine sono collegate (ma ci sono eccezioni); sono possibili differenti topologie per le reti broadcast a bus o ad anello. I principali parametri che caratterizzano una LAN sono: • COMPATIBILITÀ (la rete deve essere in grado di supportare una serie di dispositivi diversi –nodi- ed eventualmente di collegarsi ad un'altra rete) • ESPANDIBILITÀ (la rete deve essere facilmente espandibile e riconfigurabile a costi contenuti) • AFFIDABILITÀ (L'intero processo di lavorazione dipende dal corretto funzionamento del sistema di comunicazione: tutti gli elementi della rete -nodi, interfacce, mezzi trasmissivi,..- devono essere progettati in modo tale che un guasto ad un componente agisca solo sul nodo corrispondente, senza bloccare l'intera rete) • PRESTAZIONI (velocità di trasmissione dei dati, numero di utenze, lunghezza massima del mezzo ..) 3.2 Architettura ISO-OSI , TCP-IP L'architettura di una rete locale, come di una qualsiasi altra rete , può essere descritta in termini di architettura a strati secondo il modello OSI-RM (Open System Interconnection Reference Model), definito nel 1978 dalla ISO (International Standard Organization) e ispirato alla rete telefonica a lunga distanza. Tale modello stabilisce 7 livelli di descrizione:

• FISICO Fa riferimento alla trasmissione dei singoli bit lungo un canale di trasmissione . Definisce le caratteristiche elettriche e meccaniche degli interfacciamenti: un esempio di definizione a livello fisico è costituita dagli standard EIA -RS232, RS422, RS485,..-

• DATA LINK Tale livello ha il compito di svolgere diverse funzioni ; queste includono una buona interfaccia di servizio al livello di rete , il raggruppamento dei bit del livello fisico in pacchetti (data-frame), la gestione degli errori di trasmissione e la regolazione del flusso dei pacchetti in modo che i riceventi lenti non siano travolti dai pacchetti dei mittenti rapidi, evita collisioni per trasmissioni su singolo canale di più utenti. Ad esempio, un pacchetto a questo livello potrebbe essere del tipo “ Flagstart(7EH) - indirizzo(1 byte) –Messaggio(n bit) – Controllo(1 byte) – Flagstop(7FH)”.

• RETE Il livello di rete si occupa di trasmettere pacchetti dalla sorgente alla destinazione . Per raggiungere la destinazione puo’ essere necessario attraversare lungo il percorso diversi router. E’ una funzione diversa dal livello due , il quale ha il compito di portare i pacchetti da un estremo all’altro di un cavo. Questo livello si occupa della trasmissione


tra nodi , punto-punto. Tale livello deve conoscere qualcosa sulla topologia della rete di comunicazione e deve scegliere percorsi appropriati attraverso essa.

• TRASPORTO La funzione principale del livello di trasporto è di accettare dati dal livello superiore, spezzarli in piccole unità se necessario , passare queste al livello di rete, e assicurarsi che tutti i frammenti giungano correttamente a destinazione , ricostruendo i messaggi indipendentemente dall’ordine di arrivo e dalla loro provenienza; deve inoltre gestire il riconoscimento dei dati persi, il controllo del flusso e il controllo di congestione della rete. Questo è un livello end-to-end , nel senso che gira solo sulle macchine mittente e destinatario (i livelli inferiori devono girare su tutte le macchine).

• SESSIONE Si occupa di spezzare la trasmissione di un unico trasferimento in piu’ sessioni; stabilisce la comunicazione tra gli utenti, verificando le autorizzazioni di accesso, attribuendo i costi della comunicazione,..

• PRESENTAZIONE Stabilisce la conversione dei dati in formati utilizzabili da terminali video e stampanti e cioé in forma direttamente manipolabile dall'operatore (ASCII, UNICODE).

• APPLICAZIONE E’ il livello di descrizione del programma utente. Si sentirà parlare più spesso di architetture, reti, backbone TCP/IP; questo perchè il modello ISO-OSI nonostante sia ottimo e molto pulito concettualmente, ha poca valenza pratica e applicativa. La presenza del PC e di Internet ha facilitato l’affermarsi del modello TCP-IP, basato su quattro livelli: host-rete, internet, trasporto e applicazione. Da come si vede in figura in questo modello mancano i livelli di presentazione e sessione del modello OSI, mentre il livello host-rete corrisponde ai primi due livelli dell’OSI. Più in generale al livello host-rete troviamo Ethernet o SLIP (Serial Line Internet Protocol), a livello rete troviamo tipicamente IP (Internet Protocol), mentre a livello trasporto si trovano i protocolli TCP (Transfer Control Protocol), mentre a livello applicazione vi sono i protocolli utilizzati dai PC, quali HTTP (Hyper Text Transfer Protocol) o ftp (file transfer protocol).

ISO/OSI

Applicazione Presentazione Sessione

Trasporto Rete Collegamento dati Fisico

TCP-IP

Applicazione Trasporto IP (Internet)

Host-rete (Ethernet, SLIP,…)

Pag. 97

A. Flammini

Pag. 98

Ma la principale differenza è che nel modello TCP-IP (1) sono stati standardizzati e vagliati solo i livelli di rete e di trasporto che sono effettivamente le parti che servono e possono rimanere stabili per più tempo perché poco legate all’hardware, (2) si è lasciata ampia libertà nel definire i protocolli a livello basso, sia a livello fisico che di linea. 3.2.1 Le Reti Industriali Le reti presenti in ambiente industriale si suddividono in LAN (ETHERNET, MAP-Manufactoring Automation Protocol-,..), principalmente basate sul modello TCP-IP e bus di campo (Field-bus), per lo più descritti ai livelli più bassi (1,2) e al livello di applicazione (7) del modello ISO-OSI. L'automazione dei processi industriali tende a strutture impiantistiche decentrate; ciò significa che un complesso sistema di controllo centrale può essere suddiviso in più parti di piccole dimensioni, il che permette di elaborare le informazioni in modo più veloce direttamente laddove siano necessarie, oltre a consentire una maggiore disponibilità degli impianti, poiché in caso di fuori servizio di una parte del sistema tutto il resto continua a funzionare. La stessa logica vale anche per i sistemi di comunicazione e pertanto si incontrano sempre più frequentemente sistemi di comunicazione a più bus (sistemi di comunicazione multibus). Tra i principali vantaggi di un sistema di comunicazione a bus ricordiamo la possibilità di effettuare una qualsiasi comunicazione tra le stazioni interconnesse (traffico dati incrociato a piacere), il ridotto onere di cavi grazie alla struttura a linee comuni, la possibilità di ampliare il sistema, aggiungendo una o più stazioni, senza dover modificare la struttura impiantistica già esistente. Il bus può essere a controllo (arbitro) centralizzato o decentralizzato: nel primo caso il diritto di accesso al bus viene gestito da un master centrale che quindi rappresenta il collo di bottiglia sia per le prestazioni che per l'affidabilità o la disponibilità del sistema, nel secondo caso, il più utilizzato, ogni stazione è in grado di gestire l'accesso al bus.

Il protocollo MAP (Manufactoring Automation Protocol), nato da General Electric con lo scopo di far comunicare i computer in ambiente industriale, è definito in più documenti: - FullMAP 3.0 (1987) - MiniMap (1988) è una versione contenente solo I livelli 1,2 e 7 (non full OSI standard) ed è un’architettura ridotta carrier band, single channel più veloce ed efficiente utilizzata per comunicare con i dispositivi - Una versione del MAP, EPA (Enhanced Performance Architecture) è stata sviluppata, ed è supportata dalla industria del controllo di processo (Full MAP in parallelo al MiniMAP) nel 1988. La principale caratteristica è il Broadband, ossia la possibilità di comunicazione tra più utenti sullo stesso cavo utilizzando differenti frequenze per i canali di trasmissione e ricezione. Usa cavi spessi (1 inch) con frequenze di trasmissione fino a 10 Megabits/sec. per canale. E’ possibile anche la comunicazione mediante il livello fisico Carrierband, che è più economico, usa cavi più piccoli a discapito della massima frequenza di trasmissione. A livello di data link utilizza il token passing (LAN IEEE 802.4 token-passing bus), mentre a livello applicazione vi sono più protocolli:


- FTAM (File Transfer Access Method) per il trasferimento di file - MMS (Manufacturing Message System) per la gestione di messaggi (modelli di

dispositivi e sistemi orientati all’accessibilità) - ACSE (Association Control for Service Elements) per la comunicazione tra i

programmi Per la rete di comunicazione a livello di cella si tende ad utilizzare sempre di più

Ethernet, grazie alla notevole presenza di sistemi basati su PC, mentre a livello di sensori e attuatori si utilizzano bus veloci anche se semplici, noti come bus di campo (field-bus). Di seguito viene rappresentata una gerarchia di bus: come si osserva l’Host o SCADA è il sistema mediante il quale l’area accede alle celle. Il bus a livello di cella viene differenziato da quello di campo in quanto ospita sistemi intelligenti con elevato flusso di informazioni, mentre il bus di campo ha decisamente messaggi più brevi, tuttavia la tendenza è quella di assimilare il bus di cella al livello superiore (Ethernet/Internet) o di ripartire gli utenti tra livello superiore e inferiore.

Pag. 99

A. Flammini

Pag. 100

3.2.3 I bus di campo I bus di campo, definiti nella normativa IEC61158, provvedono alle comunicazioni tra le unità preposte al comando (PLC) e la periferia, i sensori e gli attuatori. Tali reti sono caratterizzate da notevoli esigenze in termini di determinismo, ossia ridotto tempo di latenza della risposta, tuttavia la messaggistica è in genere semplice, il numero di utenti limitato (∼10) e tali reti poggiano il livello applicazione direttamente sul livello “data link”. Supportano semplici algoritmi di autodiagnostica, autoconfigurazione e controllo (PID). I principali requisiti di un bus di campo sono i seguenti:

• GESTIONE MESSAGGI - capacità di trasmissione adeguata (numero dati per messaggio) - garanzia dei tempi massimi di trasmissione

• SICUREZZA DEL SISTEMA - protezione rispetto alla propagazione del guasto - protezione all’integrità dell’informazione (codici di controllo e/o correzione)

• REQUISITI TECNOLOGICI - compatibilità verso altri sistemi di comunicazione e/o infrastrutture Verso gli anni 80 sono andati affermandosi bus di campo semplici e proprietari, tipicamente basati sullo standard di trasmissione seriale RS485 (1Mbaud, 1km). Si trattava di architetture a un solo master (tipicamente il PLC) e più slave (i sensori e gli attuatori) nelle quali il master interrogava ciclicamente gli slaves. Alcune di queste soluzioni sono evolute verso architetture multimaster, altre hanno modificato la strategia di accesso al bus per cui viene a cadere la distinzione tra utente master e utente slave. Oggi ai bus di campo vanno affiancandosi soluzioni tecnologicamente più avanzate quali protocolli basati su Industrial Ethernet o reti wireless.


Pag. 101

3.3 I bus di campo

“Bus di campo” è un’espressione generica che descrive una nuova forma di comunicazione digitale dedicata ai sistemi a basso livello, quali sensori o attuatori, la quale si prevede sostituirà nell’industria la tecnologia analogica per collegamenti punto a punto basata su segnali a 4-20 mA. Infatti, come si è detto, la modalità di trasmissione numerica presenta notevoli vantaggi in termini di possibilità di trasmettere più informazione e migliori potenzialità di interfacciamento. Già dai primi anni 80 i costruttori di sensori o attuatori di una certa complessità, come ad esempio telecamere o azionamenti, avevano fornito i propri sistemi di interfaccia numerica, seriale o parallela, per consentire una connessione punto a punto con i sistemi a più alto livello, quali PLC o PC. Tuttavia tale modalità di connessione, tipicamente una RS232 con un semplice protocollo ASCII, sebbene adatta per la fase di configurazione e predisposizione del trasduttore, durante la fase operativa nella quale il flusso informativo è più ridotto, comporta un numero di cavi confrontabile con la modalità analogica tradizionale. L’architettura a bus, nella quale un unico conduttore viene utilizzato per connettere più sistemi, consente invece una notevole riduzione dei cablaggi. Il bus rappresenta il mezzo fisico utilizzato per trasportare i dati. Tipicamente si tratta di un fascio comune di fili conduttori collegante assieme più dispositivi per permettere loro di comunicare scambiandosi dati. Contrariamente ad una connessione punto a punto, dove solo due circuiti si scambiano informazioni, un bus conta generalmente un numero di utenti superiore. Esistono molteplici modi per collegare insieme i vari elementi e, a seconda dell'applicazione, è consigliabile scegliere una topologia piuttosto che un'altra. Le più comuni sono quelle ad anello, a stella e a bus. Mentre una comunicazione punto a punto è limitata a due circuiti collegati ai due estremi del cavo, nel caso di un bus la flessibilità di estensione aumenta. In effetti, l’aggiunta di un nuovo trasduttore da collegare al bus esistente costituisce raramente un problema: la maggior parte dei bus di campo sono infatti in grado di rilevare autonomamente la lista degli utenti presenti. A livello di comunicazione, rispetto a connessioni tra soli due nodi, il modo di scambiare dati attraverso un bus di campo richiede regole più severe. Infatti, ad esempio, bisogna prevedere l'accesso contemporaneo al mezzo da parte di più elementi e regolamentare nel modo più rigoroso possibile tutto ciò che serve per poter trasmettere i dati in maniera rapida ed affidabile. Tali regole di convivenza vengono comunemente chiamate protocollo. Un aspetto di rilevante importanza nel protocollo di tutti i bus di campo lo riveste la sicurezza dei dati trasmessi e ricevuti. Spesso sono previsti più meccanismi che agiscono in contemporanea e a volte, specialmente negli ambienti più critici, tale aspetto diventa un fattore discriminante nella scelta del protocollo da usare. I primi bus di campo legati al mondo dei trasduttori sono stati sviluppati direttamente dai costruttori dei trasduttori stessi: si trattava in genere di reti master-slave basate sul livello fisico RS485. Lo standard EIA RS485, nato nel 1983 come raccomandazione tecnica dell’Electronic Industries Association (EIA), consente ad una stessa linea, tipicamente costituita da un doppino, di ospitare fino a 32 ricevitori e fino a 32 trasmettitori con frequenze di trasmissione fino a 10 Mbaud e lunghezze del collegamento fino a 10 km. L’architettura master-slave, dove un solo master interroga ciclicamente gli slave, ossia i trasduttori, è la più semplice e quella che previene da situazioni di conflitto, ossia di accesso contemporaneo al bus da parte di più utenti.

A. Flammini

Ipotizzando comunicazioni bidirezionali, si possono avere due tipi di connessione: 1) utilizzando driver e receiver 2) utilizzando transceiver

Nel primo caso (figura a sinistra), il master trasmette sulla linea Tx e riceve sulla linea Rx, mentre lo slave trasmette sulla linea Rx e riceve sulla linea Tx, proprio come avviene nei collegamenti RS232; nel secondo caso (figura a destra) vi è un’unica linea per cui viene a cadere la distinzione tra master e slave (half duplex) tuttavia vi è un decremento delle prestazioni in quanto non vi può essere trasmissione e ricezione simultanea.

MASTER

SLAVE SLAVE SLAVE

Tx/Rx

MASTER

SLAVE SLAVE SLAVE

Tx Rx

La presenza di tanti protocolli diversi tra loro costringeva ad un notevole lavoro di implementazione sul sistema a più alto livello (PLC, PC), impedendo di fatto l’intercambiabilità tra componenti di differenti costruttori. Per evitare di dover ogni volta implementare i vari protocolli proprietari sul PLC, spesso si ricorreva a dei convertitori di protocollo, ossia dei sistemi che agivano come master della rete proprietaria dei trasduttori e come slave della rete nota al PLC. Alcune di queste reti proprietarie master-slave sono evolute verso architetture multimaster, altre hanno modificato la strategia di accesso al bus per cui viene a cadere la distinzione tra utente master e utente slave. Nel primo caso (accesso al bus di tipo deterministico) i master sono autorizzati alla trasmissione per un tempo prestabilito (tempo di mantenimento del token), scambiandosi l’autorizzazione a trasmettere (token) secondo una sequenza prestabilita. Tale soluzione si dice deterministica perché è possibile calcolare un tempo massimo entro il quale l’informazione di qualsiasi utente verrà trasmessa: infatti il master avrà il token tipicamente ogni N*T (allocazione round robin del token), dove N è il numero dei master e T è il tempo di mantenimento del token per ogni master. Lo svantaggio di una simile configurazione è che manca una logica di priorità e cioè le segnalazioni urgenti possono essere inoltrate solo previo ottenimento del token. L’affidabilità di una simile rete è ottima, purché si preveda un meccanismo di sorveglianza del token e di eventuale reinizializzazione della rete. Nel secondo caso (accesso al bus di tipo casuale) ogni utente verifica se la rete è libera quindi accede alla rete e, in caso di collisione, tipicamente interrompe la trasmissione e attende nuovamente la condizione di rete libera (retry). Tale strategia di accesso è non deterministica in quanto il tempo che intercorre tra l’esigenza di inoltrare un messaggio e l’effettiva presenza del messaggio in rete non è nota a priori ma dipende dal traffico su rete. I bus proprietari di grandi costruttori sono diventati standard de facto, mentre altri costruttori si sono consorziati per stabilire delle modalità di trasmissione dell’informazione che fossero convenienti per più utenti. Molti costruttori di trasduttori hanno quindi abbandonato i bus proprietari per rivolgersi verso bus di campo più diffusi. Nella scelta di un bus di campo intervengono diversi fattori, tra i quali: Pag. 102


Pag. 103

1) capacità di trasmissione adeguata (numero dati per messaggio) 2) garanzia dei tempi massimi di trasmissione 3) protezione rispetto alla propagazione del guasto 4) protezione sull’integrità dell’informazione 5) compatibilità verso altri sistemi di comunicazione e/o infrastrutture

Nel caso dei sensori e attuatori i messaggi sono a volte molto semplici quindi la caratteristica (1) può non essere di fondamentale importanza, mentre la caratteristica (2), fondamentale nei sistemi in tempo reale, può non essere indispensabile in settori applicativi quali la domotica. E’ difficile quindi stabilire una graduatoria tra i bus di campo in quanto la loro validità dipende dall’applicazione. Di seguito vengono elencati, senza pretesa di esaustività, alcuni tra i bus di campo particolarmente interessanti a livello di trasduttori. Profibus è uno standard tedesco che oggi copre il maggior numero di applicazioni industriali in Europa. La sigla Profibus comprende tre diversi protocolli: - Profibus FMS (Fieldbus Message Specification), 1989

Implementato nei livelli ISO-OSI 1,2,7, consente la comunicazione tra i processi a livello di cella. E’ orientato alla comunicazione multimaster (token-passing); è versatile e consente una grande varietà di applicazioni

- Profibus DP (Device Peripheral), 1994 Implementato nei livelli ISO-OSI 1,2 -linee guida “users” invece del livello 7-, è dedicato alla comunicazione tra i processi veloci a livello di campo (sensori, attuatori,..). Veloce (fino a 12Mbit/s), efficiente ed economico (RS485, fibra ottica), supporta un notevole numero di utenti (126 max.), di tipo master o slave, su oltre 100m di distanza, dispone di funzioni diagnostiche e di autoconfigurazione -Plug and play-

- Profibus PA (Process Automation), 1995 Implementato nei livelli ISO-OSI 1,2 -linee guida “users” invece del livello 7- . Utilizza la tecnologia trasmissiva IEC 1158-2 (IEC61158-2), a sicurezza intrinseca (variante H1, 31.25kbit/s, 10 utenti, 1900m) che prevede l’alimentazione fornita dal bus stesso e consente la sostituzione dei dispositivi “in linea”. Utilizza una codifica Manchester con protocollo di tipo sincrono (frame).

CANbus, sviluppato dalla Bosch nel 1985 per le esigenze del settore automobilistico, è un bus semplice ed economico multi-master a rilevazione di collisione che consente la connessione a un massimo di 32 utenti (50m a 1Mbit/s, 100m a 500kbit/s). Sulla linea i dati vengono rappresentati con il formato NRZ (non return to zero) codificati a campi di bit, con un campo dati di massimo 8 bytes. Il livello applicazione più utilizzato in Europa è CANOPEN, mentre in America è più diffuso DeviceNet. Il BitBus, nato nel 1991 e noto anche come standard IEEE1118, consente la connessione a 375kbit/s a un massimo di 28 utenti per lunghezze di collegamento fino a 1200m. Utilizza il protocollo SDLC di Ethernet e quindi il suo principale vantaggio consiste nella “naturale” interfacciabilità verso il bus a livello superiore. Interbus-S, sviluppato nel 1984 dalla Phoenix Contact e noto come DIN 19258, consente la connessione a 500kbit/s a un massimo di 256 utenti per lunghezze di

A. Flammini

Pag. 104

collegamento fino a 400m per stazione. La struttura del collegamento è ad anello anziché a stella e il protocollo è autoconfigurante. LonWorks, nato nel 1991, consente la connessione a 1.25Mbit/s a un massimo di 100 “nodi” per lunghezze di collegamento fino a 2000m. La caratteristica del protocollo è di essere descritto a tutti i livelli ISO-OSI, cosa piuttosto insolita nei bus di campo. Il protocollo è stato pensato per architetture parallele o “neuronali”. WorldFIP, nato nel 1988 e noto come parte integrante della norma europea EN50170, consente la connessione a 1Mbit/s a un massimo di 64 utenti per lunghezze di collegamento fino a 1000m (la velocità massima varia al variare della lunghezza). Oltre alla trasmissione su conduttore intrecciato e schermato e su fibra ottica, WorldFIP trasmette anche su onde radio. Foundation Fieldbus, sviluppato nella prima metà degli anni 90 dalla Fieldbus Foundation org. (consorzio di più aziende tra le quali National Instruments, ABB,..) è un bus che connette fino a 32 utenti su distanze fino a 1900m con basse velocità di trasmissione (31.25kbit/s) e cavo economico (doppino telefonico). Come avviene nei bus a sicurezza intrinseca, l’alimentazione è fornita dal bus stesso. Modbus, sviluppato nel 1979 dalla Modicon, costruttrice di PLC, è un bus ad architettura master-slave a singolo master che permette di collegare fino a 247 utenti su distanze fino a 1900m con basse velocità di trasmissione (da 0.3 a 19.2kbit/s) e RS232 o RS485 su cavo economico (doppino). Grazie ad un protocollo molto semplice, viene largamente utilizzato per terminali, drivers,... Actuator Sensor Interface (AS-i), nato nel 1994 è un bus deterministico a singolo master dedicato alla connessione tra PLC (master) e fino a 31 trasduttori (slaves) a informazione molto limitata (4 bit per slave) Si utilizza un doppino non schermato, la velocità di trasmissione è di 167kbit/s e raggiunge lunghezze di collegamento di 100m. Si utilizza la codifica Manchester e, pur nella sua semplicità, è un bus a sicurezza intrinseca che supporta l’autoconfigurazione. A livello normativo nel 2000 è stato emesso lo standard IEC 61158 sui bus di campo (Fieldbus standard for use in industrial control system). Inizialmente (1993) ci si è proposto di regolamentare il livello fisico (IEC61158-2) e attualmente diversi bus (Worldfip, Profibus-PA) sono conformi a tale normativa, mentre la regolamentazione del livello dati (Data Link Layer), descritta in IEC61158-3 (1998), è stata molto più sofferta, tanto che si è giunti all’attuale edizione che prevede 8 tipi di bus:

• IEC61158-3 • ControlNet • Profibus • P-NET • Fieldbus Foundation –High Speed Ethernet • SwiftNet • Worldfip • Interbus


Pag. 105

In realtà si pensa che quest’elenco sia destinato ad allungarsi (Es. ProfiNET), cosa che favorisce l’affermazione dei protocolli di Internet i quali, pur non essendo nati per il settore dell’automazione, rappresentano però uno standard “de facto”, supportato da qualsiasi ambiente SW (RTOS). Sempre recentemente è stato emesso lo standard IEC62026 (Low-voltage switchgear and controlgear – Controller-Device Interfaces or CDIs) per la specifica dell’interfaccia digitale tra dispositivi di comando e sistemi a più alto livello (PLC, PC). Tale norma prende le distanze dai bus di campo utilizzati a livello di cella per la connessione di sistemi di una certa complessità, specificando componenti e requisiti delle CDIs. Lo standard supporta 3 bus: AS-I, DeviceNet e SDS (Smart Distributed Systems). Molti bus di campo non sono così “aperti” per cui il costruttore di sensori che vuole dotare il suo trasduttore di un’interfaccia verso bus di campo, spesso si vede costretto a consorziarsi per poter accedere ai dispositivi periferici inoltre a volte deve supportare i costi di certificazione dell’interfaccia sviluppata. Per questo ed altri motivi di tipo commerciale, i bus di campo stentano a entrare massicciamente nel mercato dei sensori economici e taluni ritengono che i bus di campo passeranno rapidamente dall’alba verso il tramonto a favore di soluzioni basate su Ethernet/Internet, che peraltro è già presente in ambiente industriale a livello di cella e di area. Ethernet/Internet sta diventando la soluzione unificata per gestire le comunicazioni di un’azienda, e viene già proposta in alternativa ai bus di campo. Contrariamente alla maggior parte dei bus di campo, generalmente definiti solo ai livelli 1,2 e 7 ISO/OSI, per Ethernet IEEE802.3 (livello 1 e 2) sono disponibili anche altri livelli standard, come per esempio tutti quelli di Internet. Rispetto ai bus di campo sopra citati, Ethernet risulta quindi penalizzata perchè non deterministica e a bassa efficienza (il numero di byte trasmessi è elevato rispetto al numero di byte che contengono effettivamente informazione) e questi sono i motivi che per lungo tempo ne hanno escluso l’uso come bus di campo. Oggi le nuove tecnologie (switches, GigaEthernet) riducono notevolmente la probabilità di collisione, e la bassa efficienza viene compensata dalla possibilità di interfaccia diretta verso i livelli superiori e utenti remoti (Internet), per cui molti bus di campo si stanno preoccupando della compatibilità verso Internet. Si assiste così al proliferare di studi per la gestione combinata dei bus di campo con le nuove tecnologie (Ethernet, wireless, Internet): ad esempio, alla ben nota procedura che permette di incapsulare messaggi Modbus in pacchetti TCP/IP liberi di circolare su Internet (Modbus over TCP), oggi si studia a come incapsulare messaggi CAN o Profibus in pacchetti TCP/IP o in pacchetti più direttamente destinati alla trasmissione wireless e, allo stesso tempo, a come far circolare pacchetti TCP/IP su bus di campo come Profibus. Anche dal punto di vista normativo, si sta facendo molto per regolamentare il settore noto come Real Time Ethernet (RTE), ossia le reti basate su Ethernet a 100Mbaud per applicazioni in tempo reale in ambito industriale. Nei paragrafi successivi si vuole approfondire alcuni tra i più utilizzati bus di campo valutando cosa significhi dotare un sensore di un’interfaccia verso bus di campo. Se infatti si valuta il solo aspetto progettuale, un sensore smart è già dotato per sua natura di un processore, tipicamente un microcontrollore (μC) per l’elaborazione del segnale e la compensazione delle non idealità della caratteristica di trasferimento tra misurando e segnale; per ottenere l’interfaccia su bus di campo si tratterebbe quindi di aggiungere il dispositivo periferico dedicato al bus di campo selezionato e gli eventuali dispositivi di interfaccia elettrica e isolamento, come indicato in figura e sviluppare il software sul processore relativo alla gestione del protocollo.

A. Flammini

In realtà la gestione del dispositivo periferico e il software per il supporto di tutte le funzionalità del protocollo possono comportare un notevole aggravio dei requisiti, in termini di capacità computazionale del processore e disponibilità di memoria variabili e codice, che si tradurrebbe in un inevitabile aumento dei costi. Vi possono essere, inoltre, ulteriori costi dovuti alla partecipazione a consorzi, che a volte si rende necessaria per poter disporre del supporto tecnico o, talvolta, degli stessi dispositivi periferici, oppure costi dovuti alla necessità di certificazione dell’interfaccia.

μC

Dispositivo periferico

Dispositivo di

isolamento

Dispositivo di

interfaccia elettrica SE

NSO

RE

Sensore smart

Spesso quindi l’interfaccia verso bus di campo viene offerta come opzione: a volte si tratta di un modulo aggiuntivo che comunque viene gestito dal processore che governa il sensore e che può essere offerto in alternativa alla tradizionale uscita analogica, a volte si tratta di un generico sistema che acquisisce la tradizionale uscita analogica del sensore (spesso tali sistemi fungono da collettori per più trasduttori) e la rende disponibile sul bus di campo. 3.3.1 Profibus Profibus (PROcess FIeldBUS) è un bus di campo fortemente voluto da Siemens, il cui sviluppo ed amministrazione è stato ufficialmente affidato ad un’organizzazione denominata Profibus Trade Organization (PTO), composta da membri provenienti dal settore costruttivo, da istituti di ricerca e dall’utenza finale. Attualmente vi sono anche altre organizzazioni per lo sviluppo di Profbus, quali Profibus User Organization (PNO) e Profibus International (PI); per l’Italia esiste il Profibus Network Italia (PNI) con sede a Brescia.

La tecnologia Profibus è nata come standard tedesco secondo la normativa DIN 19245 (1991), successivamente (1996) è stata riconosciuta conforme allo standard europeo (EN 50170). Profibus e’ riconosciuto come protocollo di tipo 3 dalla normativa IEC (International Electrotechnical Commision) 61158 (Digital data communication for measurement and control –Fieldbus for use in industrial control Systems), mentre il protocollo di tipo 10 è riservato a Profinet, la comunicazione basata su Ethernet. La norma IEC 61158 descrive i bus di campo secondo i livelli ISO/OSI, mentre la norma IEC 61784 (Profile sets for continuous and discrete manufactoring relative to fieldbus use in industrial control systems) descrive i profili che risiedono sopra il livello 7; Profibus occupa il CPF (Communication Profile Family) 3 e in particolare CPF3/1 si riferisce alla versione Profibus DP, CPF3/2 si riferisce a Profibus-PA mentre CPF3/3 è dedicato a Profinet.

Escludendo Profinet, che differisce in molti aspetti e merita un discorso a parte, la famiglia Profibus consiste di tre protocolli compatibili tra loro:

Pag. 106


Pag. 107

Profibus FMS (Fieldbus Message Specification): la prima versione di Profibus (1991), oggi in disuso e non previsto dalle norme IEC, rappresenta la soluzione “general-purpose” per la comunicazione anche a livello di cella. Il livello Applicazione è costituito dal Fieldbus Message Specification (FMS) e dal Lower Layer Interface (LLI). FMS contiene il protocollo verso l’applicazione e le fornisce una vasta gamma di servizi potenti. LLI comunica sopra con FMS e sotto con lo strato di collegamento dati (livello 2), implementa relazioni di comunicazione che permettono a FMS di accedere al livello 2 indipendentemente dal tipo di dispositivo. Il livello 2, FDL, implementa il controllo per l’acceso al bus e garantisce la sicurezza dei dati. Per la trasmissione fisica, il protocollo FMS permette di utilizzare sia la tecnologia basata su RS 485 (codifica del bit tramite segnale su tensione differenziale) che le fibre ottiche.

Profibus DP (Device Peripheral): nato nel 1994 (DIN 19245 parte 3) è ottimizzato

per collegamenti economici ad alte prestazioni. Questa versione Profibus, che è la più utilizzata, è rivolta soprattutto alla comunicazione tra sistemi di controllo e dispositivi distribuiti di I/O. Profibus DP utilizza gli strati 1 (PHY) e 2 (FDL) del modello a 7 strati ISO/OSI. Gli strati dal 3 al 7 non sono definiti per motivi di efficienza e le funzioni di comunicazione, previste dal protocollo e messe a disposizione dell’utente attraverso l’interfaccia utente, vengono mappate sul livello 2 da un applicativo denominato DDLM (Direct Data Link Mapper). Questa architettura razionalizzata assicura una trasmissione veloce ed efficiente. Per la trasmissione fisica, vale lo stesso discorso fatto con FMS. DP e FMS, utilizzando la stessa tecnologia trasmissiva e lo stesso protocollo di accesso al bus, possono operare simultaneamente sullo stesso cavo, anche se alle prestazioni del protocollo più lento (FMS).

Profibus PA (Process Automation): nato nel 1995 (DIN 19245 parte 4) e progettato

principalmente per l’automazione di processo, consente di collegare sensori ed attuatori su una linea di comunicazione comune in aree a sicurezza intrinseca (EExi). Con il protocollo PA è possibile trasmettere dati e alimentazione su un bus a due conduttori in accordo con lo standard internazionale IEC 61158-2 (codifica del bit tramite segnale di corrente), che consente di operare in condizioni di sicurezza intrinseca permettendo ai dispositivi di essere alimentati direttamente sul bus. A livello fisico Profibus PA può essere “interfacciato” con DP per mezzo di un bridge-accoppiatore. PA utilizza per la trasmissione dei dati un protocollo DP esteso oltre ad un Profilo PA nel quale viene definito il comportamento dei dispositivi di campo.

Profibus è il bus di campo più diffuso a livello europeo e consente di collegare i tipici utenti di cella (partner) anche se di differenti case costruttrici: computer industriali, PLC, dispositivi di programmazione, controlli per robot e macchine utensili, sensori, attuatori, azionamenti,... Si tratta di un bus ad accesso deterministico. Il successo di Profibus, che può vantare attualmente più di un milione di nodi installati ed una crescita vertiginosa in pochi anni, è dovuto al suo ampio spettro di applicabilità; dalla semplice connessione di attuatori e sensori fino al livello di cella, dall’industria manifatturiera al settore macchine utensili, dal settore del building al processo fino all’industria chimica e petrolchimica. E’ un bus di campo in grado di utilizzare, con lo stesso mezzo fisico, servizi per connessioni semplici orientate al byte e servizi per connessioni complesse (frame di configurazione, di parametrizzazione, di diagnostica ecc.) in modalità ciclica ed aciclica.

A. Flammini

ISO/OSI FMS DP PA User Profili FMS

Pag. 108

7 FMS

Profili DP

- 3-6 - 2 Fieldbus Data Link (FDL)

1 RS-485

Fibra ottica (plastica, vetro, PCF -Photonic Crystal Fiber-)

IEC61158-2 MPB (Manchester Encoded Powered Bus)

Tutte le versioni di Profibus (DP, FMS e PA) utilizzano un protocollo uniforme di

accesso al bus implementato al livello 2 del modello ISO/OSI. Per quanto riguarda i dispositivi, Profibus distingue tra:

• Dispositivi MASTER, che controllano la comunicazione sul bus. Un master può

spedire messaggi senza richiesta esterna quando detiene il controllo della linea di comunicazione (possesso del token). Vengono anche chiamati stazioni attive.

• Dispositivi SLAVE: sono unità periferiche che non possono accedere al bus

direttamente, se non per divulgare informazioni diagnostiche che lo riguardano. Possono solamente riconoscere messaggi ricevuti o spedire messaggi al master se richiesti esplicitamente. Dal momento che richiedono piccole porzioni di protocollo, la loro implementazione è particolarmente economica. Vengono anche chiamate stazioni passive. La gestione dell’accesso al bus viene implementata nel protocollo Profibus secondo

la filosofia mater/slave, mentre per quanto riguarda l’accesso al bus tra master, si utilizza una procedura basata su token passing.

La procedura token passing garantisce che il permesso di accesso al bus, concesso al master che possiede il token, sia definito per un intervallo di tempo preciso e costante; quindi il tempo che ogni master dovrà attendere per accedere al bus dipenderà dal numero di dispositivi attivi presenti nella rete e dal massimo tempo di utilizzo del bus permesso (token hold time). Il token viene passato da un master all’altro secondo un ordine prefissato (anello logico).

La procedura master/slave consente alla stazione attiva che in un preciso momento possiede il token di accedere alle stazioni passive a lui assegnate. Il master può spedire messaggi agli slave o richiedere messaggi dagli slave.

Durante la fase di inizializzazione del sistema, il compito del sottostrato MAC (Medium Access Control, sottolivello del livello 2) di ogni dispositivo master è di definire il proprio indirizzo all’interno dell’anello logico costituito da tutti i dispositivi attivi. Durante la fase operativa, i master malfunzionanti o spenti devono essere tolti dall’anello logico, mentre quelli attivati successivamente devono essere inseriti nell’anello logico.

IEC interface

Profili PA

DP –parte aciclica-

DP –parte ciclica-


Un altro compito importante del livello 2 (FDL) riguarda la sicurezza dei dati. Il formato delle trame utilizzato nel protocollo Profibus assicura elevata integrità dei dati grazie a telegrammi caratterizzati da distanza di Hamming HD=4 (i codici differiscono per minimo 4 bit) ottenuti secondo le norme dello standard IEC 870 5-1.

Lo strato di collegamento dati (DDLM) permette il trasferimento delle informazioni anche in modalità broadcasting, utilizzata per l’invio di trame a tutte le stazioni attestate sul bus, e multicasting per l’invio di dati ad un gruppo di stazioni.

Protocollo di accesso al bus, comune alle tre versioni Profibus

3.3.1.1 Profibus: Tecnologie Trasmissive Il protocollo Profibus, al fine di soddisfare diverse esigenze, in termini di velocità di

trasmissione, distanza raggiungibile, sicurezza e possibilità di alimentazione lungo il bus, supportare diverse soluzioni tecnologiche:

- Trasmissione RS-485 per DP/FMS; - Trasmissione con fibre ottiche per DP/FMS. - Trasmissione IEC 1158-2 conforme, per PA; RS-485 È la tecnologia trasmissiva più utilizzata nelle applicazioni Profibus e il suo impiego

include tutti quei casi in cui si rende necessaria una trasmissione ad alta velocità implementabile in maniera semplice. Utilizza come mezzo trasmissivo una coppia di conduttori attorcigliati e, se necessario, schermati. Si tratta quindi di una modalità di trasmissione molto economica e adatta a operare anche in ambienti sfavorevoli. La trasmissione del segnale avviene in corrente su tensione differenziale di 5V. Il transceiver di interfaccia viene protetto da eventuali situazioni di accesso simultaneo al segmento. Tutti i dispositivi sono connessi ad una struttura lineare e il medesimo segmento conduttore può ospitare fino a 32 unità. La modalità di connessione di Profibus è half-duplex e cioè ciascuna unità, master o slave, trasmette e riceve sulla

Pag. 109

A. Flammini

stessa coppia di conduttori. Il bus è terminato all’inizio ed alla fine di ogni segmento da terminazioni attive. Quando si utilizzano più di 32 stazioni su più segmenti, si ricorre all’impiego di ripetitori (amplificatori di linea) per raccordare le varie sottoparti. La tabella mostra le diverse velocità di impiego raggiungibili in funzione della distanza coperta e la tabella seguente elenca le specifiche di un cavo tipo A e di uno tipo B (i cavi di tipo B sono sconsigliati). Bisogna ricordare che Profibus-DP supporta velocità fino a 12 Mbit/s con distanze massime di 100m.

Baud rate (kbit/s) 9,6 19,2 93,75 187,5 500 1500 12000 Lungh. Cavo tipo A (m) 1200 1200 1200 1000 400 200 100 Lungh. Cavo tipo B (m) 1200 1200 1200 600 200 70 -

Relazioni tra prestazioni e lunghezza segmento con RS485

PARAMETRI Cavo tipo A Cavo tipo B Impedenza caratteristica da 135 a 165 Ω

f∈[3 MHz,20 MHz]Da 100 a 130 Ω f> 100 MHz

Capacità < 30 pf/m < 60 pf/m Resistenza 110 Ω/Km - Diametro > 0,64 mm > 0,53 mm

> 0,34 mm2 > 0,22 mm2 Area sezione Caratteristiche dei cavi utilizzabili con RS485 in Profibus

Anche se, come RS-485, Profibus non specifica circa il connettore da utilizzare, ma

si limita a descrivere i poli da usare, è tradizionale l’impiego di connettori 9-pin S sub la cui piedinatura è riportata in tabella.

N° pin Nome segnale Significato 1* SHIELD Protezione EMC 2* M24V Tensione di uscita – 24V 3 RxD/TxD-P Ricezione/trasmissione dati 4* CNTR-P Segnale di controllo per ripetitori 5 DGND Massa di Vp 6** VP Tensione positiva +5V 7* P24V Tensione di uscita + 24V 8 RxD/TxD-N Ricezione/trasmissione dati 9* CNTR-N Segnale di controllo per ripetitori

*) segnali opzionali **) segnale necessario solo per le stazioni di fine bus Il segnale è individuato da una tensione differenziale tra i due conduttori e la codifica

è del tipo Non Return to Zero (NRZ). In particolare il simbolo ‘1’ è rappresentato da una tensione differenziale positiva tra il pin 3 (RxD/TxD-P) ed il pin 8 (RxD/TxD-N) del connettore al bus, il simbolo ‘0’ da un tensione differenziale negativa. (Ck)

Dato

Pag. 110


Trattandosi di trasmissione asincrona, il clock non viene trasmesso e i messaggi vengono inviati a byte, preceduti dal bit di start (‘0’) e seguiti da parità e stop (‘1’) (efficienza pari a 8/11).

Parità Stop

Start Start

Indipendentemente dal numero di utenti connessi la linea deve essere terminata ai

due estremi secondo quanto riportato in figura.

Schema di collegamento e terminazioni di un bus con RS485

FIBRA OTTICA L’impiego di conduttori a fibra ottica può essere utile in ambienti ad alta interferenza

elettromagnetica oppure per aumentare la distanza massima raggiungibile o la velocità massima impiegabile. Il segnale digitale pilota un diodo emettitore di luce affacciato alla fibra ottica. All’altra estremità un dispositivo fotosensibile trasforma gli impulsi luminosi in impulsi elettrici. Ulteriori vantaggi in questo tipo di supporto riguardano la leggerezza, la resistenza meccanica, la larghezza di banda e quindi la velocità di trasmissione, che risulta inversamente proporzionale alla lunghezza del collegamento e non al suo quadrato, come nei conduttori metallici.

In particolare possono essere utilizzati due tipi di conduttori: • Un cavo economico di accoppiamento in fibra ottica di plastica per interno in

applicazioni di ridotte estensioni (distanze inferiori ai 50 m.). • Un cavo LWL (dal tedesco Lichtwellenleiter che significa “conduttore di onde

luminose”) in fibra in vetro per interno ed esterno con distanze inferiori al chilometro.

Molti costruttori realizzano connettori speciali che integrano convertitori da fibra ottica a RS-485 e viceversa, e ciò semplifica l’impiego di questa tecnologia.

IEC 1158-2 Lo standard IEC 1158-2 risponde alle esigenze dell’industria chimica e

petrolchimica che richiedono comunicazioni intrinsecamente sicure; si tratta di un protocollo basato sulla codifica dei bit per mezzo di segnali di corrente ed è spesso individuato con la sigla H1. La trasmissione è basata sui seguenti principi:

- ogni segmento ha una sola fonte di alimentazione, l’unità di alimentazione - non si riversa potenza sul bus quando una stazione invia dati

Pag. 111

A. Flammini

- ogni dispositivo consuma una corrente di base (tipicamente 10 mA) nel suo stato di attesa

- ogni dispositivo si comporta come un ‘pozzo’ passivo di corrente - ad entrambi i capi del bus sono presenti terminazioni passive ( RC serie, R=

100Ω, C=1μF ) - sono permesse reti lineari, ad albero o a stella - è possibile aggiungere tratti ridondanti di bus per aumentare l’affidabilità. I dispositivi devono essere alimentati con una corrente continua di almeno 10 mA,

mentre il segnale trasmesso deve essere caratterizzato da una modulazione di 9 mA sulla componente continua. Il numero massimo di unità collegabili è 32, anche se il numero in realtà è limitato dal tipo di protezione contro le esplosioni scelta. La tabella seguente riassume le caratteristiche dello standard IEC 1158-2 e la figura mostra una tipica configurazione utilizzata nell’automazione di processo. Va detto che la connessione di dispositivi alimentati sul bus e di dispositivi alimentati esternamente è possibile se questi ultimi sono dotati di un appropriato isolamento in accordo con lo standard EN50020. Come abbiamo già accennato, a livello fisico Profibus PA si interfaccia con Profibus DP per mezzo di bridge-accoppiatore.

Esempio di coesistenza tra protocolli DP e PA

Trasmissione dati Digitale, codifica di Manchester, bit sincrono

31,25 Kbit/s Velocità di trasmissione Preambolo, delimitatore finale, verifica di errore iniziale Sicurezza dati Coppia di conduttori attorcigliati (se necessario) schermati Mezzo fisico Opzionalmente attraverso la linea dati Alimentazione remota Possibili operazioni in condizioni di sicurezza intrinseca e non Protezione alle esplosioni Lineare, ad albero o miste Topologia 32 stazioni per segmento, max 126 con ripetitori Numero stazioni Massimo 4 ripetitori Ripetitori

Caratteristiche relative alla tecnologia trasmissiva basata sullo standard IEC 1158-2

Pag. 1123.3.1.2 Profibus-DP (Device Peripheral)


Pag. 113

La versione Device Peripheral (DP) del protocollo Profibus è stata pensata per la

comunicazione tra sistemi di controllo dell’automazione (i.e. PC e PLC) e dispositivi di ingresso/uscita distribuiti (i.e. sensori/attuatori) ed è ottimizzata per comunicazioni ad alte velocità e per connessioni poco costose. La maggior parte dello scambio di dati in questo contesto avviene in modo ciclico, tuttavia per permettere lo svolgimento di procedure di configurazione, di diagnostica o di gestione degli allarmi, il protocollo supporta anche funzioni di comunicazione aciclica.

L’aumento significativo di velocità rispetto al protocollo FMS deriva sostanzialmente dell’utilizzo del servizio SRD (Send and Receive Data) del secondo livello del protocollo, che consente la trasmissione di dati di ingresso e di uscita in un singolo ciclo di messaggio. Profibus-DP prevede due tipologie di master: DPM1 per la gestione degli slave, DPM2 per lo svolgimento delle funzioni di gestione (diagnostica e programmazione). Vi possono essere più DPM1 ciascuno con il suo gruppo di slaves anche se tra loro i DPM1 non comunicano; è possibile invece la comunicazione tra un DPM1 e un DPM2. Comunque, la velocità elevata di trasmissione non rappresenta l’unico elemento che ha determinato il successo della versione DP del protocollo Profibus; procedure di installazione e servizi semplici, potenzialità diagnostiche e trasmissioni senza errori sono caratteristiche altrettanto importanti per gli utilizzatori. La tabelle che segue illustra gli aspetti più salienti di Profibus DP.

Tecnologia di trasmissione: RS 485 con doppio conduttore attorcigliato (eventualmente schermato) o fibra ottica Velocità di trasmissione da 9.6 Kbit/s a 12 Mbit/s Accesso al bus: Token passing tra master, master/slave tra dispositivi attivi e passivi Possibili configurazioni mono-master e multi-master Dispositivi master e slave, massimo 126 stazioni per ogni segmento compatibilmentecon la tecnologia di trasmissione. Comunicazione: Peer to Peer per dati utente, Multicast per comandi di controllo Ciclica (trasmissione dati master/slave e master/master) Funzionalità: Trasmissione ciclica di dati utente tra DP master e DP slave Attivazione e disattivazione dinamica di singoli DP slave Verifica della configurazione dei DP slave Potenti funzioni diagnostiche (3 livelli gerarchici di messaggi diagnostici) Sincronizzazione degli ingressi e/o delle uscite Assegnamento degli indirizzi ai DP slaves sul bus (indirizzo di default = 126) Configurazione dei DP master (DPM1) sul bus per mezzo dei DP master (DPM2) Massimo 244 byte di dati in ingresso e in uscita per DP slave Sincronizzazione: Comandi di controllo consentono la sincronizzazione degli ingressi e delle uscite Modalità Sync: le uscite sono sincronizzate Modalità Freeze: gli ingressi sono sincronizzati

A. Flammini

Pag. 114

Funzioni di protezione e sicurezza: Tutti i messaggi sono trasmessi con distanza di Hamming HD = 4 Watchdog timer per i dispositivi DP passivi Protezione d’accesso in ingresso e in uscita per Master DPM1 e per Slave. Funzioni di controllo dei dati utente trasmessi (Data_Control_Timer) Tipi di dispositivi: DP master di classe 2 (DPM2): dispositivi di programmazione, configurazione,

diagnostici DP master di classe 1 (DPM1): controllori programmabili come PLCs, PCs, ecc. DP slave: dispositivi con ingressi e uscite analogiche o digitali, trasmettitori ecc. Modalità operative (DPM1): Operate: Trasferimento ciclico di dati in ingresso ed in uscita Clear: gli ingressi dei DPslave vengono letti, a ogni uscita viene assegnato valore

“0” Stop: è permessa la sola trasmissione di dati tra master e master

Off-line: nessuna forma di trasmissione permessa

TIPI DI DISPOSITIVI

Ogni sistema Profibus DP riconosce tre differenti tipi di dispositivi:

• DP Master Class 1 (DPM1): è un controllore centrale che scambia informazioni con le stazioni decentralizzate a lui assegnate (DP slave) all’interno di un ben definito ciclo di messaggio. Gestisce la trasmissione dei dati utente e può comunicare con i dispositivi DP Master (classe 2). Tipicamente appartengono a questa classe PLCs, PCs o sistemi VME.

• DP Master Class 2 (DPM2): vengono utilizzati nella fase di configurazione del

sistema DP o nelle necessarie operazioni di monitoraggio e diagnostiche. Appartengono a questa classe i dispositivi di programmazione, di configurazione e pannelli di controllo.

• DP Slave: sono stazioni periferiche (dispositivi di I/O, trasmettitori, Human

Machine Interface HMI, valvole ecc.) che ricevono dati in input (richieste) e/o spediscono in output informazioni al controller (risposte). Sono indirizzabili da entrambi i tipi di master.

I master sono spesso denominati come stazioni attive, mentre gli slave sono detti

stazioni passive. CONFIGURAZIONE DI SISTEMA

Profibus DP gestisce sistemi mono-master/slave o multi-master/slave e

implementa tipiche forme di comunicazione “uno a uno”(punto-a-punto) o “uno a molti” (broadcast, multicast).


Può essere utilizzata una modalità di comunicazione multicast (uno a molti), solo per diffondere comandi di controllo globali da parte di entrambi i tipi di master verso un gruppo di slave DP, o da parte di un dispositivo DPM2 verso un gruppo di DPM1. Profibus DP opera senza connessione, tuttavia sia a livello di sorgente che a livello di destinazione, è possibile accedere a dei servizi specificando nel telegramma i service access point (SSAP, DSAP).

Su un unico bus possono essere connessi fino a 126 dispositivi (master e/o slave) e, dato che vi deve essere almeno un master di tipo DPM1, in una rete possono essere collegati fino a 125 slave DP.

In una comunicazione di tipo master/slave è il master (DPM1 o DPM2) a possedere il controllo, mentre in una comunicazione master/master è il dispositivo DPM2 e gestire l’interazione. Non è definita nessuna forma di comunicazione tra dispositivi della stessa categoria (ES. Non è permessa la comunicazione tra DPM1 e DPM1).

La quantità di informazione scambiata tra stazioni dipende dai tipi di dispositivi in comunicazione; al massimo si possono trasferire 246 byte di dati sia in input che in output.

Nei sistemi mono-master un solo master è attivo durante la fase operativa. Solo in questo tipo di configurazione è possibile ottenere i più corti cicli di bus permessi dal protocollo Profibus DP, quindi le prestazioni migliori in termini di velocità di trasferimento dati. A titolo di esempio, Profibus-DP a 12Mbit/s (Tbit=83ns, Tbyte=11Tbit∼1μs) connette 32 stazioni ciascuna che scambia con il master 2 byte di ingresso e 2 byte di uscita. Il tempo di ciclo viene calcolato considerando che per ogni slave viene speso un tempo Tmc pari alla somma del tempo del telegramma di richiesta che contiene le uscite da master a slave, del tempo Tsdr di risposta dello slave (11Tbit min. a 12Mbit/s) e del tempo del telegramma di risposta: considerando anche i tempi nei quali la linea deve rimanere inattiva per separare un telegramma e il successivo, si ha che Tmc∼28μs+TdataI/O, quindi, nel caso in esame, Tmc∼32μs e Tciclo=32*Tmc∼1ms.

Struttura di un sistema mono-master

Nei sistemi multi-master più stazioni attive sono collegate al bus in fase operativa.

L’accesso al mezzo è consentito alla sola stazione attiva che possiede il token, il quale viene trasmesso tra i master presenti in rete lungo un anello logico, definito in fase di inizializzazione del sistema. Ciascun master, insieme agli slave che può indirizzare, rappresenta un sottosistema indipendente. C’è da precisare che gli ingressi e le uscite degli slave possono essere lette da qualsiasi master. Le restrizioni esistono solo in fase di scrittura, operazione permessa al solo master (DPM1) a cui uno specifico slave è

Pag. 115

A. Flammini

stato assegnato durante la configurazione di sistema. Le comunicazioni tra master di classe 1 sono limitate ai messaggi di scambio del token. Ogni master possiede una lista dei master attivi nella quale compare lui stesso (TS), il master che gestisce il token prima (PS) e dopo (NS) di lui. Tale lista è dinamica, nel senso che se ad esempio TS riceve per 3 volte il token da un master diverso da PS allora aggiorna PS e, analogamente, se non riesce a trasmettere il token a NS, verifica se un altro master ha preso possesso del bus e, in caso contrario, riprova per 2 volte poi passa al master successivo a NS in LAS. Il master che ha il token può scambiare dati con gli slave per metà del tempo di mantenimento del token (Th). Il tempo di ciclo è definito dal tempo Ttr di rotazione del token. Le prestazioni non eguagliano quelle ottenibili con una configurazione mono-master, soprattutto se il numero di master supera le tre unità.

Struttura di un sistema multi-master

E’ importante sottolineare che è possibile connettere/sconnettere in linea un nuovo

utente (attivo o passivo) e la configurazione di rete vi si adatta; in particolare ogni nodo attivo ha la responsabilità di rilevare eventuali nodi aggiunti tra il proprio indirizzo (TS) e il successivo (NS).

Tutte le stazioni di un sistema Profibus DP devono aver assegnato un indirizzo sul bus. Per i dispositivi DP slaves tale indirizzo potrà essere definito anche via bus dai soli dispositivi DPM2.

Quando un dispositivo passivo non possiede ancora un proprio indirizzo gli viene assegnato provvisoriamente il 126 (di default). Attraverso tale indirizzo una stazione DPM2 può successivamente accedere al DP slave e modificare il valore identificativo con uno alternativo al 126. I dispositivi attivi non possono avere un indirizzo di default. Per motivi di sicurezza un dispositivo DPM1 non può scambiare dati con un dispositivo DP slave indirizzato col 126. L’indirizzo 127 è riservato al broadcast.

La configurazione di sistema consiste nel definire il numero di stazioni, assegnare gli indirizzi delle stazioni e quelli di I/O, il formato dei dati di I/O, il formato dei messaggi diagnostici ed i parametri del bus utilizzati.

Un DPM1 può essere configurato localmente o attraverso il bus da un DPM2. Un DPM1 può trovarsi in 3 stati: Stop (non comunica dati con gli slave), Clear (legge dati dagli slaves ma ne mantiene le uscite in uno stato di sicurezza), Operate (comunica ciclicamente con gli slave scambiando ingressi e uscite). Come si è detto, un DPM2 può comunicare con un DPM1 leggendo o scrivendo i dati di configurazione, abilitando o disabilitando la comunicazione con uno slave o forzando il suo stato.

Pag. 116


Uno slave può trovarsi in 3 stati: parametrizzazione, configurazione e trasferimento dati. Durante la parametrizzazione lo slave riceve alcune informazioni fondamentali riguardo il suo pieno o parziale supporto delle funzionalità previste, nonché il numero di identificazione, e verifica tali informazioni con quelle in suo possesso dando eventuali segnalazioni di difformità. Nella configurazione vengono specificati il numero dei byte di ingresso e uscita, mentre nella fase di scambio dati avviene appunto lo scambio dati con il master selezionato. Quindi, ricapitolando, se una stazione master DP vuole comunicare con un dispositivo slave DP, deve innanzitutto verificarne lo stato attuale (es. se il dispositivo è collegato in rete, o se è occupato da un DPM2) attraverso la richiesta delle informazioni diagnostiche (funzione DDLM_Slave_Diag). Se non emerge alcun problema, si passa alle successive fasi di parametrizzazione (funzione DDLM_Set_Prm) e di verifica dei dati di configurazione (funzione DDLM_Chk_Cfg), al termine delle quali dovranno essere richieste nuovamente le informazioni diagnostiche per verificare se sono presenti errori di parametrizzazione e/o configurazione o se lo slave DP è già occupato con un altro master DP oppure se lo slave DP non è ancora pronto per comunicare. Nei primi due casi, il master DP ripete la procedura dall’inizio, nel terzo richiede le ultime informazioni diagnostiche finché il messaggio non scompare. Se non si verificano errori, può iniziare lo scambio dei dati tra master e slave (funzione DDLM_Data_Exchange).

Per la sincronizzazione di tutti o parte degli slave (multicast) un DPM1 può utilizzare comandi di SYNC/UNSYNC (i dati relativi alle uscite vengono effettivamente scritti nelle uscite solo all’istante del prossimo comando di sync) e di FREEZE/UNFREEZE (gli ingressi non vengono più aggiornati fino al prossimo comando di freeze).

Profibus-DP prevede 2 tipi di di servizi di trasmissione: - SRD (Invio e richiesta dati con conferma, con scambio bidirezionale di dati in un

solo ciclo di telegramma) - SDN (Invio di dati senza conferma, utilizzato per la comunicazione broadcast o

multicast) Durante il servizio SRD il master invia i dati in uscita allo slave e riceve in risposta i

dati in ingresso entro un periodo di tempo specificato o, se lo slave non ha ingressi, con un telegramma di conferma breve (Codice hex “E5”).

Un messaggio o telegramma è costituito da più bytes l’uno adiacente all’altro (non sono permessi idle bit tra i caratteri UART di un frame) preceduti da uno stato di inattività di almeno 33Tbit durante il quale la linea è a 1.

Esistono 4 tipi di telegrammi, distinguibili attraverso il primo byte (SD):

frame con campo dati di lunghezza variabile

SYN SD2 LE LEr SD2 DA SA FC DATA FCS ED

A) Frame di richiesta

SD2 LE LEr SD2 DA SA FC DATA FCS ED

B) Frame di risposta

Pag. 117

A. Flammini

SYN: periodo di sincronizzazione (33 bits (idle bits) ciascuno di valore “1”). SD2: (Start Delimiter) delimitatore iniziale, di valore esadecimale pari a 68H. LE: numero di byte da DA incluso fino a FCS escluso; valori permessi [4…249]. LEr: numero di byte da DA incluso fino a FCS escluso (ripetizione di LE) DA: (Destination Address) indirizzo del destinatario [0…127]. SA: (Source Address) indirizzo del mittente [0…126]. Il bit b8 di SA e DA individua la presenza di un’estensione del campo di indirizzamento dei dispositivi. FC: (Frame Control) frame di controllo. FC realizza un controllo sul tipo di frame (richiesta –MSB=1- o conferma/risposta –MSB=0-), su eventuali perdite o moltiplicazioni di messaggi e sul tipo di stazione. Inoltre contiene informazioni circa il tipo di funzione implementata nel frame (SDN, SDR, ecc.). DATA: campo dati caratterizzato da un numero massimo di byte pari a 246. FCS: (Frame Check Sequence) frame di controllo della sequenza dei bit. ED: (End Delimiter) delimitatore finale, di valore esadecimale pari a 16H.

frames di lunghezza fissa con campo dati

SYN SD3 DA SA FC DATA_UNIT FCS ED


SD3 DA SA FC DATA_UNIT FCS ED

B) Frame di risposta

SD3: (Start Delimiter) delimitatore iniziale, di valore esadecimale pari a A2H. DATA_UNIT: campo dati caratterizzato da 8 byte

frames di lunghezza fissa senza campo dati

SYN SD1 DA SA FC FCS ED


SD1 DA SA FC FCS ED

B) Frame di conferma

SC

C) Frame di conferma rapida

SD1: (Start Delimiter) delimitatore iniziale, di valore esadecimale pari a 10H. SC: (Single Character) carattere singolo di valore esadecimale pari a E5H.

Pag. 118


token frame

SYN SD4 DA SA

Token frame

SD4: (Start Delimiter) delimitatore iniziale, di valore esadecimale pari a DCH. Per quanto concerne la diagnostica, ogni slave è provvisto di watchdog, che deve

essere sovradimensionato rispetto al tempo di ciclo, mentre il master gestisce un timer per ogni slave a garanzia che almeno una trasmissione valida venga effettuata entro un certo tempo. L’integrità dei messaggi o telegrammi è assicurata da un penultimo byte di Frame Chech Sequenze, dal bit di parità per ogni byte che, grazie ad un’opportuna scelta dei codici funzionali o alla ridondanza di informazioni, garantisce distanza di Hamming pari a 4.

Per quanto riguarda la segnalazione di anomalie e guasti di una stazione, si distingue tra guasti a livello di stazione, modulo e canale.

Oltre a queste funzionalità di base (Profibus DP versione 0 –DPV0-), Profibus-DP prevede un’estensione (DPV1) verso la possibilità di svolgere comunicazioni acicliche o funzioni di interrupt parallelamente alla trasmissione ciclica dei dati: in questo modo si permette ad un master di classe 2 (DPM2) di riconfigurare dinamicamente slave complessi. Ovviamente la comunicazione aciclica, che in genere avviene una volta ogni tanto, deve avere priorità inferiore rispetto alla comunicazione ciclica di scambio dati. La comunicazione aciclica segue la logica delle connessioni e pertanto può avvenire solo dopo che è stata stabilita una connessione tra i comunicanti (SAP 40-48 per gli slave e SAP 50 per un DPM2 per stabilire una connessione MSAC_2). Grazie all’attivazione del servizio con SAP=51, anche un DPM1 può gestire contemporaneamente una comunicazione ciclica (MSCY_C1) e aciclica (MSAC_C1) con i suoi slave. La funzionalità aciclica permette lo scambio di blocchi di dati tra master e slave: il master invia una richiesta DDLM_Read/write quindi interroga mediante servizio SRD (Send and Request Data with reply) lo slave fino a quando non arriva la risposta.

La versione 2 di Profibus (DPV2) aggiunge funzionalità quali la possibilità di comunicazione tra slaves (DXB) utilizzando messaggi broadcast secondo una logica publisher-subscriber. Un’altra importante funzionalità introdotta da DPV2 è il modo isocrono. Grazie ad un messaggio broadcast di “global control” con un proprio codice progressivo, tutte le stazioni possono sincronizzarsi con l’inizio del ciclo. In pratica il messaggio di global control apre ogni ciclo che prosegue con la fase di scambio dati, con la possibilità di accesso per i DPM2 e quindi con un tempo riservato. Grazie a DPV2 è possibile far funzionare l’intero sistema secondo un orologio comune.

L’organizzazione dei dati di una stazione avviene per moduli, indirizzati dallo Slot Number, suddivisi in blocchi dati, puntati da Index, di lunghezza massima pari a 256 bytes. Slot Number = 0 identifica la stazione nel suo complesso. Una richiesta DDLM_Read, ad esempio, è strutturata da Function Number, Slot Number, Index, Length (così da poter accedere a parti di blocchi dati), mentre la relativa risposta sarà composta da Function Number, Slot Number, Index, Length e dati.

Pag. 119

A. Flammini

Pag. 120

DPV0 permette ad uno slave di trasferire eventi spontaneamente al master mediante messaggi diagnostici; DPV1 ha migliorato queste funzionalità consentendo al master di mandare l’acknowledge dell’allarme ricevuto (DDLM_Alarm_Ack).

Per permettere il Plug&Play dei dispositivi, DPV0 prevede una sorta di data sheet elettronico del dispositivo, detto file GSD, che contiene le caratteristiche del dispositivo (Es. Baud rate supportati, servizi supportati, lunghezza dei dati, caratteristiche dinamiche –Tsdr = tempo max, dopo il quale lo slave deve rispondere-,…). Per la configurazione di una rete Profibus esistono software specifici che prelevano i dati di configurazione dai file GSD e li utilizzano per la configurazione di sistema. Ogni slave o DPM1 deve avere un numero di identificazione, da richiedersi al Profibus User Organization (PNO), specificato nel file GSD. A livello di World Wide Web sono disponibili i file GSD di tutti i dispositivi Profibus certificati come conformi della Profibus User Organization. Il protocollo Profibus definisce come vengono scambiati i dati tra le stazioni presenti sul bus. In aggiunta è possibile realizzare dei ‘profili’ che permettono di stabilire il significato dei dati scambiati sul bus, soprattutto nelle parti definite dall’utente e relative a una specifica applicazione, e come il dispositivo profibus-DP debba essere utilizzato in un certo ambito di applicazione. Per assicurare una certa interoperabilità, Profibus prevede quindi dei profili che descrivono la struttura, il tipo di dati e le assegnazioni dei dispositivi raggruppati per tipologia (Es. Sensori/attuatori, Azionamenti a velocità variabile, Apparecchi di manovra a bassa tensione, Automazione degli edifici,...).

L’utilizzo dei profili permette di ridurre il costo di ingegnerizzazione, visto che i parametri relativi all’applicazione sono specificati dettagliatamente.

Alcuni tra i principali profili a oggi specificati sono i seguenti: NC/RC Profile (3.052); Encoder Profile (3.062); Variable_Speed_Drive Profile (3.071); Operator_Control_and_Process_Monitoring Profile (HMI).

Nel complesso Profibus può essere considerato più come un bus di cella che come un bus specificatamente dedicato ai sensori e attuatori di tipo semplice; inoltre qualsiasi costruttore che fornisca il proprio sensore di interfaccia Profibus slave, deve subire un costoso processo di certificazione. Questo rappresenta uno dei vincoli che limita la comparsa sul mercato di sensori con interfaccia Profibus. Se ci si limita all’analisi dell’aggravio dei costi inerenti l’implementazione di un’interfaccia Profibus-DP di tipo slave per un sensore, esistono dispositivi periferici che gestiscono i livelli 1 e 2 ISO-OSI (Livello fisico e Data Link) in modo trasparente all’utente. Il costo di tali dispositivi si aggira sui 10€, tuttavia la gestione comporta un notevole dispendio di spazio codice (∼10kBytes) e di spazio RAM (∼200bytes) per cui risulta piuttosto gravosa per un microcontrollore a 8 bit. Un tipico dispositivo periferico è il Siemens SPC3, operante a 48 MHz e dotato di 1.5 kbytes di memoria RAM a doppia porta, in grado di realizzare un’interfaccia slave, mentre la presenza di isolatori ottici, quali gli HCPL7100, permette di alimentare il ricetrasmettittore RS485 mediante l’alimentazione di rete, limitando le interferenze tra rete e sensore. Un connettore a 9 poli (DB9) porta la linea differenziale dei dati, la tensione di alimentazione con la massa e lo stato di abilitazione del trasmettittore RS485. Profibus-DP si rivela un’interfaccia piuttosto gravosa, tanto che ad oggi non vi sono microcontrollori di uso


comune che lo integrano a bordo come periferica. L’interfaccia di sensori economici verso Profibus-DP viene oggi realizzata o indirettamente attraverso i PLC, o mediante appositi moduli concentratori, che sono moduli di ingresso e uscita, logica e analogica, con interfaccia Profibus gestita mediante firmware residente. Tali moduli, dedicati all’interfaccia di sensori economici, sono veloci e non troppo costosi e, dato che l’interfaccia diretta di un sensore economico su Profibus-DP sarebbe comunque piuttosto gravosa, in questo modo il costo del concentratore viene ripartito su più sensori. L’interfaccia diretta di un sensore economico su Profibus-DP non comporta enormi vantaggi sul profilo architetturale, in quanto il flusso dati è ridotto ed è pesantemente condizionato dal master che tende ad essere “proprietario”. Al contrario, Profibus-DP è presente come interfaccia diretta di PLC, sensori e attuatori di una certa complessità.

3.3.1.3 Profibus-PA (Process Automation) Molto interessante e che va diffondendosi soprattutto negli ambienti dove la sicurezza è importante è Profibus-PA., per il quale vale la tecnologia trasmissiva IEC61158-2 vista prima. Nato nel 1995 sulla base delle esperienze acquisite dall’ISP (Interoperable Systems Project) nella ricerca di un sistema di trasmissione a sicurezza intrinseca, Profibus-PA prevede una topologia lineare con alimentazione autonoma del bus. Profibus-PA utilizza una codifica Manchester con protocollo di tipo sincrono (frame).

“0” “1”

FC DAD/SAD CO Data Unit FCS Frame

FC Frame Control (Es. lunghezza pacchetto –1 o 4 byte-) DAD/SAD Destination o Source Address (2 byte) CO Control Field (tipo di frame –1byte-) FCS Frame Check Sequence (2 byte –CRC-) Il frame è preceduto da un preambolo di sincronizzazione.

Sono supportati 5 diversi formati di frame: - frame di lunghezza fissa senza dati (6 bytes) - frame di lunghezza fissa con dati (14 bytes) - frame di lunghezza variabile con dati (da 10 a 255 byte)

Pag. 121

- Token (5 bytes) - Ricevuta rapida (3 byte) Profibus-PA prevede dei profili che usano un’interfaccia verso blocchi funzionali: il

comportamento del dispositivo viene descritto mediante delle variabili. Ad esempio per un analog input function block relativo ad un sensore di pressione si avrebbe:

A. Flammini

Parametro Raed Write Funzione OUT x Valore di pressione PV_SCALE x x Unita di scala PV_FTIME x x Tempo di salita (s) ALARM_HYS x x Isteresi delle funzioni di allarme (%FS) HI_HI_LIM x x Soglia superiore di allarme (alarm, status) HI_LIM x x Soglia superiore di warning (warning, status) LO_LIM x x Soglia inferiore di warning (warning, status) LO_LO_LIM x x Soglia inferiore di allarme (alarm, status) … … … …

Profibus-PA viene utilizzato per i campi a rischio di esplosione dell’industria di processo. Vi è rischio di esplosione in presenza di tre componenti: scintilla, comburente, combustibile e quindi in tutti quei settori che trattano talune sostanze chimiche in presenza di cavi energizzati che connettono sistemi a diverse tensioni. Per ampliare Profibus di un segmento Profibus-PA nelle applicazioni a rischio di esplosione, si rende necessario un accoppiatore di segmenti con sezionatore dell’alimentazione. Questo dispositivo provvede alla conversione delle PDU (Protocol Data Unit). I dispositivi connessi a Profibus-PA possono essere sostituiti durante il servizio. 3.3.2 AS-I (Actuator Sensor Interface) Un bus che costituisce una sorta di semplificazione “monomaster” dei bus di campo di tipo deterministico master-slave è il bus Actuator Sensor Interface (ASI). Da un punto di vista logico si tratta di una connessione a stella (point-multipoint), dove tutte le informazioni sono controllate dall’unico master centrale in modo rigorosamente deterministico. E’ un bus del 1994 dedicato alla connessione tra un PLC e più sensori e attuatori che scambiano informaizoni binarie (fino a 31 slaves –4bit per slave-). Si utilizza un doppino non schermato, la velocità di trasmissione è di 167kbit/s e raggiunge lunghezze di collegamento di 100m. Si utilizza la codifica Manchester e di fatto vengono trasmesse solo le variazioni di stato del segnale. Il flusso delle informazioni è organizzato in modo ciclico e un ciclo può contenere da 1 a 31 messaggi. Alla fine del ciclo il master effettua una speciale interrogazione di uno slave selezionato ciclicamente così che dopo un massimo di 31 cicli, ciascuno slave sarà stato interrogato una volta in modo speciale (aciclico).

MD01 MP SD SP MD02 MP SD .... SP Pausa MD01 MP

messaggio

ciclo

Pag. 122


MD Master Data (richiesta del master, può essere una chiamata dati, parametri, indirizzamento o comando). E’ composta da 14 bit (Start bit S=0, Control bit C, 5 address bit Ai, 5 data bit Di, Parity bit P e end bit E=1). S C A4 A3 A2 A1 A0 D4 D3 D2 D1 D0 P E MP Master Pause SD Slave Data (risposta dello slave. Formata da 8 bit: start bit S, 4 Data bit, Parity bit P e end bit E) SP Slave Pause La durata di un bit è pari a 6μs e la pausa slave va da 1 a 1.25 la durata del bit, mentre la pausa master è pari a 3 volte la durata del bit (stato sincronizzato) o 5 volte la durata del bit (stato non sincronizzato). La permanenza del livello pause hanno una durata massima di 3ms. Questo implica che il master si accorge che lo slave chiamato è assente dopo 3ms. Se lo slave non risponde a due chiamate successive viene eliminato dalla lista dei componenti attivi. Una stringa riconosciuta errata viene ripetuta. Il livello applicativo prevede sostanzialmente due processi: la fase di trasmissione (inizializzazione, avviamento, mantenimento della comunicazione con gli slaves) e la fase di gestione che elabora i task del livello master (un task alla volta). Se nel master è presenta la funzione di configurazione, un eventuale slave aggiunto durante il servizio può essere riconosciuto e integrato nella comunicazione. Se, come per Profibus si vuole calcolare l’efficienza nel caso di flusso di informazione minimo (1 bit trasmesso dallo slave), si ottiene 1/(14+3+8+1)=3.8%. 3.3.3 CANbus CANbus2.0b (Controller Area Network) è un bus a rilevazione di collisione sviluppato dalla Bosh per il collegamento in rete di dispositivi di comando, sensori e attuatori nelle linee di produzione del settore automobilistico. CANbus è uno standard ISO del 1985 nato per le esigenze del settore “automotive” e poi approdato al più classico ambiente industriale. All’inizio del 92 è stata fondata l’organizzazione internazionale di utenti e produttori CAN in Automation (CiA). Si tratta di un bus semplice ed economico multi-master a rilevazione di collisione che consente la connessione a un massimo di 32 utenti (50m a 1Mbit/s, 100m a 500kbit/s). Sulla linea i dati vengono rappresentati con il formato NRZ (non return to zero) codificati a campi di bit e la sincronizzazione è assicurata dal meccanismo di bit-stuffing. bit-stuffing

Pag. 123

A. Flammini

Tale meccanismo prevede l’inserzione automatica di un bit di polarità opposta (bit di stuffing) dopo 5 bit uguali. Il bit rate viene quindi ridotto di un fattore che dipende dalla stringa di dati e che, nel peggiore dei casi, può essere pari a 4/5 (stringa originaria = 000001111000011110000...-> 0000011111000001111100000..). La tecnica adottata da CANbus, detta Carrier Sense Multiple Access/Collision Avoiding (CSMA/CA), è ad accesso casuale, ossia ogni utente può inoltrare un messaggio quando lo ritiene opportuno (contrariamente ai sistemi master-slave): secondo questa logica tutti gli utenti si comportano da “master”, anche se CAN prevede comunque degli “slave” (SLIO) con funzionalità ridotte che possono comunicare in seguito a richiesta o ad un particolare evento (“event-driven”). CSMA/CA prevede che in caso di collisione un solo messaggio venga interrotto mentre il messaggio dominante (quello con il bit a “0”) possa proseguire. Ne consegue che un messaggio a bassissima priorità non può sapere a priori dopo quanto tempo arriverà a destinazione (non-determinismo).

CSMA/CA A B A B

CANbus supporta 4 tipi di frame:

• Data Frame, • Remote Frame (richiesta di invio), • Error Frame (segnalazione errori di trasmissione), • Overload Frame (segnalazione di impossibilità temporanea a ricevere messaggi).

Il data frame permette la trasmissione di un numero di byte dati d variabile tra 0 e 8 e, nel caso peggiore ha lunghezza pari a 154 bit, compresi i bit di stuffing e i bit che devono trascorrere tra un frame e il successivo (Interframe). Nell’equazione riportata di seguito viene riportato il tempo relativo al frame e l’efficienza, che è massima proprio per d=8.

⎩⎨⎧

==

≈×+×+

××=

⎩⎨⎧

==

=×+×+=)8(%42)2(%17

)867(8

)8(154)2(95

)867(dd

TbitndTbitd

dsds

TbitndTstuf

CANstufCAN ημμ

La struttura del frame (trama estesa) è riportata in figura seguente (CANbus 2.0b) e, come si può osservare, è sempre compresa entro 128 bit. Senza entrare nel dettaglio della struttura della trama, si noti come il bit IDE permette di riconoscere se si tratta di una trama estesa (identificatore a 11+18 bit) o standard (identificatore a 11bit, Arbitration Field a 12 bit). Da notare come il bit RTR (Remote Trasmission Request) consenta la richiesta di invio di un messaggio: il nodo richiedente invia il frame con l’identificatore settato al messaggio di cui ha bisogno e RTR=1. Ciascun ricevitore controlla se l’identificatore è tra quelli abilitati (messaggio per il quale c’è interesse) e, in caso positivo, pone a “0” il bit di acknowledge. Pag. 124


SOF

= 0

SRR

= 1

IDE

= 1 ID

11 bit

EID

18 bit RTR

= 0

RB

1 =

0

RB

0 =

0 DLC

4 bit

DATA

0-64 bit

CRC

15 bit CR

Cd

= 1

AC

K

AC

Kd

= 1 EOF

(=1)

7 bit

arbitraggio controllo dati CRC e fine messaggio

Sempre riferendo all’architettura indicata per il sensore interfacciato su bus di campo, un tipico dispositivo periferico è l’Intel AN82527, operante a 16 MHz e dotato di 256 bytes di memoria RAM a doppia porta, in grado supportare trame standard o estese, con frequenza di trasmissione massima di 1Mbaud e gestione fino a 15 messaggi indipendenti filtrabili attraverso maschere, tuttavia oggi molti microcontrollori a 8 bit (Microchip, Motorola) integrano direttamente un’interfaccia CANbus per cui l’aggiunta di hardware si limita agli isolatori ottici, quali ad esempio i 6N137, e al ricetrasmettittore CAN, come il dispositivo Philips PCA 82C250. Un connettore a 9 poli (DB9) porta la linea differenziale dei dati, la tensione di alimentazione e la massa. Contrariamente a quanto osservato nel caso di Profibus-DP, la gestione di un dispositivo periferico CAN risulta molto più snella, nell’ordine di un quinto in quanto a spazio di memoria richiesto. Il livello applicazione più utilizzato in Europa è CANopen (v. CiA, CAN in Automation), mentre in America è più diffuso DeviceNet (v. ODVA, Open DeviceNet Vendor Association); vi sono poi altri livelli applicazione, tra i quali CANKingdom o SDS. Di seguito viene riportata una tabella che descrive sommariamente i principali livelli applicativi: CANopen e DeviceNet. E’ importante sottolineare che per entrambi lo scambio dei dati avviene secondo il modello del produttore e del consumatore, in cui ogni partecipante alla comunicazione conosce a priori l'utilizzo dei dati che vengono trasmessi. Uno dei principali vantaggi di DeviceNet è il supporto della frammentazione dei messaggi, superando il limite degli 8 byte, mentre CANopen dispone di potenti servizi diagnostici (Es. node/life guarding). Entrambi i protocolli supportano caratteristiche interessanti quali una struttura a oggetti, l’allocazione fissa o dinamica degli identificatori, diversi meccanismi di controllo e diagnostica della rete e modelli e/o profili per la caratterizzazione del nodo.

Pag. 125

A. Flammini

Pag. 126

Caratteristiche CANopen DeviceNet Nome dell’oggetto comunicazione

“Process Data Object” (PDO) Messaggi di I/O

Massimo numero di oggetti di comunicazione per nodo

512 PDO di trasmissione 512 PDO di ricezione

27 messaggi per la trasmissione 1701 per la ricezione

Massima lunghezza del campo dati

8 byte 8 byte Col protocollo frammentato si ha un numero arbitrario di dati

Protocollo per la trasmissione dei messaggi di I/O

Non frammentato Non c’è “overhead” Senza risposta

Non frammentato Non c’è “overhead” Tre classi di trasporto supportate: senza risposta risposta dell’oggetto connessione risposta dell’oggetto applicazione (1 byte overhead)

Modalità di produzione dei messaggi

Su richiesta di una applicazione remota o del nodo. Modalità sincrona ciclica o aciclica

Ciclica “Change of state” Specifica dell’applicazione

Mappatura degli oggetti applicazione rispetto alle istanze di connessione

Il massimo numero di oggetti applicazione mappabili per PDO dipende dalla dimensione dei dai dell’oggetto. Questo può essere ottenuto attraverso l’”Object Dictionary” Supportata la mappatura dinamica

Può essere mappato un numero arbitrario di oggetti applicazione con il protocollo frammentato. E’ ottenuto attraverso l’oggetto assembly. Supportata la mappatura dinamica

Nome del canale per la comunicazione peer to peer

“Service Data Object”, SDO Messaggi espliciti

Massimo numero di canali per ogni dispositivo

127 SDO “client” 127 SDO “server”

27 per la trasmissione 1701 per la ricezione per ogni dispositivo

Protocollo per la trasmissione dei messaggi peer to peer

< 5 byte Non frammentato con risposta >4 byte Frammentato (7bytex frammento)Si risponde ad ogni pacchetto

<7 byte Non frammentato con risposta >6 byte Frammentato (6byte x frammento) Si risponde ad ogni pacchetto

Modalità di connessione Connessione dinamica attraverso il gestore SDO. Connessione di default predefinita

Connessione dinamica attraverso “Unconnected Message Manager”Per i dispositivi del gruppo 2 è prevista un’allocazione attraverso messaggi espliciti

Servizi principali supportati attraverso tali connessione

Inizia, termina la comunicazione Carica scarica dati

Apri/chiudi la trasmissione Crea Configura, inizia, ferma, resetta i diversi oggetti

Indirizzi necessari per la richiesta

Indice e sottoindice dell’indirizzo presente nell’“Object Dictionary”

“Access path” dell’attributo dell’oggetto voluto e argomenti del servizio

I livelli applicativi, più che operare nel campo dati, operano a livello di identificatore, e, ad esempio, CANopen e DeviceNet differiscono nel sistema per l’assegnamento dell’identificatore dei messaggi.


CANopen prevede un insieme di identificatori disponibili a tutti i nodi della rete e un DBT (DistriBuTor), elemento implementato secondo la struttura master-slave (ovvero è presente un solo DBT master che gestisce le richieste di tutta la rete), che provvede ad allocare dinamicamente gli identificatori a disposizione a seconda delle richieste dei dispositivi. Questa modalità permette l'utilizzo più efficiente possibile degli identificatori, visto che questi ultimi sono tutti a disposizione dei vari dispositivi. CANopen mette a disposizione 1760 identificatori per usi generali mentre i rimanenti sono utilizzati per la gestione della rete (in particolare 128 identificatori servono per gestire i 128 nodi che possono essere indirizzati in una rete CANopen). Questa però non è l’unico tipo di allocazione degli identificatori prevista da CANopen. Infatti è prevista dalle specifiche anche una configurazione minima del sistema (adatta ad un sistema caratterizzato dal rapporto master-slaves); in questo caso l'identificatore del messaggio è diviso in due parti: una composta da 4 bit che specifica il codice della funzione, l'altra di 7 bit (questo schema è adatto alla connessione tra un master e 126 slave, l’indirizzo 0 è riservato). Le 16 funzioni identificate dal codice comprendono la ricezione e la trasmissione dei dati, la gestione del canale peer-to -peer, il controllo dello stato del nodo, la gestione del nodo, gli avvisi di errore, la ricezione delle sincronizzazioni e dei messaggi per la temporizzazione. Visto che la priorità dipende dal tipo di funzione, tale codice sta nei bit più significativi.

L’identificatore CANopen nella configurazione minima

In DeviceNet l’allocazione degli identificatori è diversa in quanto ogni nodo della rete possiede in esclusiva un gruppo di identificatori che poi vengono suddivisi in diversi gruppi ognuno dei quali viene utilizzato per scopi precisi. In questo caso l’allocazione degli identificatori è meno efficiente rispetto al caso precedente visto che se uno slave non utilizza tutti gli identificatori ad esso associati non possono essere in alcun modo utilizzati per la comunicazione di altri dispositivi. In figura viene rappresentata la differente organizzazione dell’identificatore tra DeviceNet (gruppo 2) e CANopen (configurazione minima).

Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Pag. 127

La tabella riportata di seguito indica gli identificatori predefiniti in CANopen.

Campo che identifica il gruppo

MAC ID Identificatori del tipo di messaggio DeviceNet

Identificatore del nodo CANopen Identificatore della

funzione

A. Flammini

Pag. 128

Identificatore CAN Oggetti 0 Servizi NMT 128 Messaggi di sincronizzazione 129...255 Messaggi di emergenza 256 Messaggio “time stamp” 385...511 641...767 T_PDOs 513...639 769...895 R_PDOs 1405...1535 1537...1663 SDOs 1793...1919 Messaggi “node guard” 2015...2031 Riservati TPDO = Process data Objects in trasmissione (trasferimenti veloci di dati) RPDO = Process data Objects in ricezione (trasferimenti veloci di dati) SDO = Service data Objects (scrittura e lettura di messaggi a dizionario) Per quanto riguarda CANopen la trasmissione dei dati avviene attraverso i PDO (”Process Data Objects”), ovvero pacchetti caratterizzati da una ben preciso identificatore. CANopen prevede le seguenti modalità per l’acquisizione dei messaggi:

• sull’evento • su richiesta dell’applicazione • con ricezione di un messaggio di sincronizzazione specifico

La prima modalità viene eseguita quando si rileva un particolare evento, relativo al profilo oppure all’applicazione (quale la ricezione di un PDO Asincrono). La trasmissione di un PDO può essere anche dovuta alla ricezione di una richiesta di messaggio remota. I PDO sincroni invece sono inviati ciclicamente in seguito alla ricezione di un certo numero di messaggi di sincronizzazione (il tutto stabilito nella fase iniziale di configurazione della rete da parte del master). Inoltre i messaggi di sincronizzazione possono essere usati per la sincronizzazione nell'acquisizione dei dati da tutti i nodi della rete, ovvero i diversi nodi della rete sincronizzano il momento in cui campionano i dati con il messaggio inviato in “broadcast”. In DeviceNet la comunicazione dei dati avviene attraverso i messaggi di I/O, ovvero dei pacchetti inviati in rete dai nodi, contenenti nel campo dati della trama CAN i dati che devono essere cambiati, mentre l’identificatore viene assegnato in fase di connessione. Questo permette lo scambio di dati tra i diversi dispositivi, in quanto tutte le informazioni necessarie alla ricezione dei dati (e al loro contenuto), sono determinate dall’identificatore del messaggio. E’ utile chiarire, nel caso del protocollo non frammentato, quali sono le classi di trasporto supportate, ovvero se in fase di ricezione del messaggio lo slave (“server”) deve rispondere o meno al messaggio ricevuto dal master (“client”), con ovvie ripercussioni sull’efficienza della trasmissione. Le classi di trasporto sono:

• senza risposta (il master invia i dati allo slave) • con risposta dell'oggetto di connessione (in più lo slave invia acknowledge) • con risposta dell'applicazione (in più lo slave invia acknowledge + dati)

Queste ultime due classi possono essere utilizzate per un efficiente polling dei dispositivi; il master implementa gli oggetti connessione associati con i comandi di “poll”, mentre ogni slave implementa gli oggetti connessione necessari per ricevere il comando e per trasmettere i dati richiesti. Per quanto concerne la modalità in cui vengono acquisiti i messaggi. DeviceNet supporta diverse soluzioni:


Pag. 129

• la modalità ciclica • il cambio di stato(“Change-of-State”, COS) • l’acquisizione decisa dall’oggetto applicazione

Con la prima, la trasmissione dei dati avviene alla scadenza del tempo di acquisizione deciso in fase di configurazione dal master. Con il COS la trasmissione avviene quando viene rilevato un cambiamento di stato dell'oggetto applicazione. Con l'ultima modalità di acquisizione è l'oggetto applicazione a decidere quando acquisire e trasmettere i dati. Inoltre un messaggio può anche essere trasmesso quando passa un certo intervallo di tempo senza alcuna trasmissione (questo viene effettuato per rilevare eventuali nodi guasti). I nodi della rete di solito sono costituiti da più di un oggetto applicazione e spesso più di uno di essi viene associato ad un oggetto comunicazione (PDO o messaggi I/O). Per poter associare gli oggetti applicazione ai relativi oggetti di comunicazione i protocolli ad alto livello seguono strade diverse. CANopen specifica gli oggetti applicazione mappati in un PDO attraverso una struttura chiamata “PDO-Mapping Record” contenuta nell’OD (“Object Dictionary”), un raggruppamento di oggetti indirizzati attraverso un indirizzo a 16 bit che caratterizza ogni nodo CANopen. Questa struttura specifica i dati degli oggetti applicazione in forma di una lista che contiene gli identificatori di ogni oggetto, il tipo e la lunghezza dei dati scambiati. In DeviceNet invece l’associazione degli oggetti applicazione alle istanze della connessione di comunicazione avviene invece attraverso un oggetto, l’oggetto assembly. Questo oggetto si occupa di definire il formato di dati che devono essere trasmessi su un certo canale di comunicazione e a quale oggetto applicazione questi dati appartengono. Questo permette di stabilire quali e quanti oggetti applicazione debbano essere connessi ad una istanza di connessione. Nella gestione di una rete che comprende numerosi dispositivi digitali è necessario poter disporre di un canale di comunicazione che permetta la configurazione dei nodi per stabilire una connessione efficace. CANopen fornisce un canale di servizio (“Service Channels”) attraverso cui gli SDOs (“Service Data Objects” ) possono essere scambiati tra due qualsiasi dispositivi attraverso un protocollo che prevede la risposta ad ogni pacchetto trasmesso. Ogni oggetto CANopen deve implementare almeno una connessione SDO con due identificatori di messaggi (uno per la richiesta ed uno per la risposta) per permettere la configurazione del dispositivo. Per le applicazioni che necessitano di una gestione dinamica della connessione SDO, le specifiche prevedono un gestore SDO, che si occupa di stabilire, su richiesta di altri dispositivi, la relativa connessione necessaria per la comunicazione. Anche DeviceNet fornisce un canale di connessione che permette la comunicazione tra due dispositivi attraverso cui possono essere forniti servizi, quali la configurazione degli oggetti. DeviceNet utilizza i messaggi espliciti, ovvero dei messaggi che vengono scambiati tra due dispositivi per permettere al nodo master di poter accedere ai servizi offerti dagli slave, in particolare la lettura e la scrittura degli attributi degli oggetti che li costituiscono (per poter accedere agli attributi deve essere incluso nel messaggio oltre al codice del servizio richiesto anche l’”access path”, ossia l’identificatore dell’attributo). Se ne conclude che l’interfaccia CANbus2.0b è un’interfaccia a basso costo, mentre un’implementazione pienamente compatibile dello strato applicazione (Es. CANOPEN) risulterebbe più gravosa. CANbus, grazie alla sua semplicità e alla sua effettiva apertura come standard, si è andato molto affermando e oggi esistono molteplici possibilità di accesso da PLC o PC per mezzo di schede dedicate. E’ disponibile un’ampia gamma di

A. Flammini

Pag. 130

sistemi di sviluppo di ausilio per la messa in servizio e la diagnosi di reti CAN, o per la progettazione di interfacce CAN. 3.3.4 Modbus Il protocollo MODBUS è stato rilasciato all’inizio degli anni ’80 dalla Modicon, una società del gruppo Schneider Electric. Le specifiche rilasciate fanno si che MODBUS possa essere utilizzato come un protocollo per l’integrazione dei sistemi basati su PC e PLC con regolatori, sensori ed attuatori tramite un'unica linea di comunicazione. In effetti MODBUS non è un vero e proprio bus di campo, sia per quanto riguarda l’architettura master/slave che, soprattutto, per quanto riguarda la velocità di trasferimento dei dati. Un utilizzo standard di MODBUS è il collegamento di vari dispositivi come termoregolatori, oppure sensori od attuatori (gli slave del sistema), direttamente ad un terminale SCADA (il master del sistema). Lo standard MODBUS non definisce rigorosamente il livello fisico della rete, ma si concentra solo sui protocolli al livello di trasferimento dati, al livello di rete ed al livello applicazione. Il protocollo fa riferimento comunque ad un mezzo trasmissivo seriale asincrono e definisce alcune caratteristiche. Il costruttore, infatti, può scegliere a suo piacimento il mezzo trasmissivo, il baud rate, se inserire o meno il bit di parità, il numero di bit di stop ed il modo di trasmissione (RTU- Remote Terminal Unit oppure ASCII). I mezzi trasmissivi più comunemente utilizzati sono RS232, RS485 half duplex (due fili), RS485 full duplex (quattro fili), Current Loop. I baud rate più comuni spaziano tra 1200 a 19200 baud. Per quanto riguarda il modo di trasmissione il protocollo MODBUS descrive due modi di trasmissione: ASCII oppure RTU.

Caratteristiche ASCII (7 bit) RTU (8 bit) Sistema di codifica Codifica esadecimale: viene

inviato il codice ASCII del carattere (0-9,A-F).

Codifica binaria ad 8 bit.

Numero di bit per carattere: bit di start: bit di dati: bit di parità: bit di stop:

1 7 1 o nessuno 1 o 2

1 8 1 o nessuno 1 o 2

Controllo degli errori: LRC (Longitudinal Redundancy Check )

CRC (Cyclical Redundancy Check)

Bisogna ricordare che i caratteri vengono inviati partendo dal bit meno significativo sino ad arrivare al bit più significativo. In particolare il modo di trasmissione RTU consente di inviare un byte così come si trova, utilizzando gli 8 bit a disposizione per la trasmissione del carattere. Nel modo ASCII, invece, il byte da trasmettere viene diviso in due parti: il nibble più significativo ed il nibble meno significativo. Ogni nibble è quindi rappresentabile tramite un numero esadecimale compreso tra 0 e F. Il modo di trasmissione ASCII invia due caratteri a 7 bit che non sono altro che la rappresentazione, secondo il codice ASCII a 7 bit, dei due numeri esadecimali che formano il byte. Il protocollo MODBUS prevede che sulla rete sia presente un solo master e fino a 247 slave. Naturalmente il numero degli slave può essere inferiore e dettato da motivazioni di carattere tecnico dovute alla scelta del mezzo trasmissivo. Ad esempio, se viene


Pag. 131

utilizzata l’ RS232, il numero di dispositivi slave sarà pari ad uno. Questo perché RS232 è un collegamento punto-a-punto e quindi un collegamento tra un master ed uno slave. Ad ogni slave è associato un indirizzo che lo individua in maniera univoca. Solo il master può iniziare la comunicazione. La trasmissione avviene secondo lo schema di domanda/risposta in cui solo un singolo slave risponde, oppure broadcast/nessuna risposta, dove il master ha inviato un messaggio broadcast a tutti gli slave, i quali però non devono rispondere. In pratica una singola comunicazione è fatta o da una sola domanda alla quale segue una sola risposta, oppure da un messaggio broadcast. Le domande e le risposte sono formattate secondo la seguente struttura:

Slave Address Function Data Check 1 byte 1 byte N byte 2 byte

Dove il campo Function è specificato come segue:

01, 02 Lettura di n bit 03, 04 Lettura n word (registri) 05 Scrittura di un bit 06 Scrittura di una word (registro) 15 Scrittura di n bit 16 Scrittura di n word (registri)

Ad esempio per la lettura di un bit nel campo dati deve essere inserito l’indirizzo dal quale iniziare a leggere i bit ed il numero di bit da leggere: · Indirizzo di partenza a 16 bit (byte più significativo); · Indirizzo di partenza a 16 bit (byte meno significativo); · Numero di byte da leggere (byte più significativo); · Numero di byte da leggere (byte meno significativo); Una query per leggere nove bit partendo dall’indirizzo 0000 dallo slave 1 avrà il seguente formato:

01h 01h/02h 00h 00h 00h 09h Grazie a questa funzione è possibile leggere, tramite una sola interrogazione, lo stato di più bit. In particolare la risposta data dallo slave nel campo dati conterrà le seguenti informazioni: · Numero di byte inviati; · N byte contenenti il valore dei bit raggruppati in byte; Il numero massimo di word che può essere letto con un singolo messaggio è pari a 125. Ciò implica che il più lungo messaggio MODBUS avrà una lunghezza pari a 250 byte più il byte relativo all’indirizzo, quello relativo alla funzione, quello relativo al numero di byte restituiti dallo slave ed i due byte che compongono il CRC. Particolarmente interessante è la presenza di un livello presentazione che permette a messaggi Modbus di essere incapsulati in reti TCP/IP (Modbus over TCP). La definizione di questo protocollo, compreso tra il livello TCP (di trasporto) ed il livello

A. Flammini

Pag. 132

applicazione, permette di utilizzare una qualsiasi rete TCP/IP per il trasporto dei messaggi MODBUS. Tale protocollo è stato rilasciato nel settembre del 1997 dalla Schneider Electric ed è diventato uno standard “de-facto”. In particolare, grazie a questo protocollo, è possibile fare viaggiare i messaggi MODBUS attraverso reti Intranet oppure tramite Internet. Anzitutto è bene dire che il messaggio MODBUS strutturato come visto in precedenza rimane molto simile. L’unico campo che viene tolto è quello relativo al Check. Il fatto che il protocollo MODBUS/TCP si appoggi direttamente su TCP, che rende la rete affidabile, fa sì che questo campo risulti superfluo. Tale protocollo ha standardizzato anche un numero di porta che è assegnato ai processi server. Il numero di porta è il 502. In pratica, come un Web Server è sempre “in ascolto” per rilevare richieste di connessione sulla porta 80, un processo server MODBUS/TCP dovrà rimanere “in ascolto” sulla porta 502. La formattazione dei messaggi è la seguente: · Byte zero: transaction identifier (normalmente 00h); · Byte uno: transaction identifier (normalmente 00h); · Byte due: protocol identifier (00h); · Byte tre: protocol identifier (00h); · Byte quattro: lunghezza del messaggio MODBUS in byte (byte più significativo=00); · Byte cinque: lunghezza del messaggio MODBUS in byte (byte meno significativo); · Messaggio MODBUS (identico a quello specificato nei paragrafi precedenti ma senza il campo Check).

3. i sistemi distribuiti - unibg controllano sensori e trasduttori ai quali sono collegati...

Documents