I bus di campo:

dalla teoria alla pratica

Testo di Matteo Mondada, Ingegnere elettrotecnico STS/ATS

Indice

Indice Elenco delle figure 1. Preambolo 2. Primo approccio 2.1. Cos’è un bus di campo? 2.2. Perché un bus di campo? 2.3. Chi è interessato ai bus di campo? 2.4. Qual è l’origine della "moda" dei bus di campo? 3. Basi di teoria 3.1. Il modello OSI 3.2. Elementi di comunicazione 3.2.1. Repeater 3.2.2. Bridge 3.2.3. Router 3.2.4. Gateway 3.3. Topologia di rete 3.3.1. Struttura ad anello (Ring) 3.3.2. Struttura a stella 3.3.3. Struttura ad albero

3.4. Aspetti fisici 3.5. Aspetti dei protocolli 3.5.1. Codifica dei segnali 3.5.2. Componentistica ed interfacce 3.5.2.1. RS-232 3.5.2.2. RS-422 3.5.2.3. RS-485 3.5.2.4. ISO 11519 / ISO 11898 3.5.3. Componenti di protezioni supplementari 3.5.3.1. Separazione galvanica 3.5.3.2. Protezione contro le sovratensioni 3.5.4. Protezione dei dati trasmessi 3.5.4.1. Parità 3.5.4.2. Distanza di hamming, ridondanza, CRC 3.5.4.3. Protocolli orientati a trame 3.5.5. Meccanismi di comunicazione 3.5.5.1. Master-slave 3.5.5.2. Multi-master 3.5.5.3. Token passing 3.5.5.4. Altri meccanismi 3.5.6. Scambio di dati 3.5.6.1. Messaggistica 3.5.6.2. Client-Server 3.5.6.3. Accesso a variabili e memoria remote 3.5.6.4. Download e upload 3.6. La piramide CIM 3.7. Schedatura dei diversi sistemi di comunicazione 3.7.1. I bus di cella 3.7.2. I bus di campo 3.7.3. I bus "sensori/attuatori" 3.7.4. I bus dedicati 4. Caratteristiche principali di qualche bus di campo 4.1. Il Bitbus 4.2. L’Interbus-S 4.3. Il CAN 4.4. Il Sercos 5. Evoluzioni future 6. Conclusioni 7. Riassunto Annesso 1: Bibliografia Annesso 2: Indirizzi utili Annesso 3: Formulario di feedback

Elenco delle figure

Fig. 1: categoria di professionisti interessati ai bus di campo Fig. 2: evoluzione della tecnica nel campo dell’automazione Fig. 3: modello OSI Fig. 4: flusso dei dati e relazioni logiche Fig. 5: repeater Fig. 6: splitter, una variazione del repeater Fig. 7: bridge Fig. 8: router Fig. 9: gateway

Fig. 10: struttura ad anello Fig. 11: struttura a stella Fig. 12: struttura ad albero Fig. 13: struttura ad albero consigliata Fig. 14: codifica NRZ Fig. 15: codifica RZ Fig. 16: codifica NRZI Fig. 17: interfaccia RS-232 Fig. 18: interfaccia RS-422 Fig. 19: interfaccia RS-485 Fig. 20: interfaccia ISO 11898 Fig. 21: esempio di separazione galvanica per RS-485 Fig. 22: esempio di protezione contro le sovratensioni Fig. 23: esempio di trama di comunicazione CAN Fig. 24: struttura della piramide CIM Fig. 25: confronto tra il modello TCP/IP ed il modello OSI

1. Preambolo

L’industria nel suo assieme copre una vastità di campi notevole. Parlando di industrie in genere si accenna a fabbriche di produzione, sì, ma anche ad industrie alimentari, di imballaggio, farmaceutiche e chimiche, di produttori e distributori di energia (elettrica e non) e via dicendo. In genere, tutti questi campi ed altri ancora sono toccati dal fenomeno dell’automazione e quindi, indirettamente, dai sistemi di comunicazione industriali, meglio conosciuti come bus di campo. Ovviamente certi settori sono maggiormente coinvolti da questo fenomeno, mentre in altri campi l’implicazione in queste tecnologie è più legata al fatto che i bus di campo sono parte integrante dei prodotti che si sviluppa e commercializza. Ne deriva quindi un interesse fondamentalmente diverso. L’approccio ai bus di campo deve avvenire tenendo conto di questi aspetti.

Il testo che segue vuole essere una base teorica e pratica utile a tutti gli interessati, destinata a far riflettere colui che si troverà confrontato a delle scelte nel settore. Lo scopo non è quello di creare ulteriori dubbi in merito, bensì di formare una base di nozioni e criteri di valutazione che aiutino a selezionare il bus più appropriato all’applicazione da realizzare. Proverò ad essere il più neutro possibile nelle mie affermazioni. Tuttavia in un contesto di interessi economici e tecnici molto pronunciato, mi sarà magari difficile tenere sempre eque distanze dai vari sistemi che citerò. D’altra parte mi limiterò a far riferimento in particolare ai bus di campo che meglio conosco e sui quali mi considero sufficientemente competente. Che i fautori di altri sistemi non me ne vogliano!

2. Primo approccio

2.1. Cos’è un bus di campo? Innanzitutto, per mettersi tutti d’accordo sull’argomento di questo testo, mi sembra giusto rispondere ad una domanda spontanea e fondamentale:

"Cos’è un bus di campo?"

Il concetto di "campo" fa pensare in modo chiaro a qualcosa di limitato, non solo geograficamente, ma forse ancor più concettualmente. Un campo, inteso come settore di una certa materia, rappresenta senz’altro bene il dominio a cui si applica il bus, e questo a diversi livelli di astrazione, come lo vedremo più avanti, al momento in cui si parlerà di integrazione della produzione secondo i concetti CIM. D’altra parte, in questo luogo voglio ancora spendere due righe sulla parola "bus", che ovviamente non ha nulla a che fare con i mezzi di trasporto pubblici. Nulla? Ebbene, paradossalmente invece sì! Un bus, in un contesto legato all’informatica o all’elettronica, svolge un ruolo identico ai comuni veicoli: il bus (informatico) è un mezzo di trasporto pubblico dei dati. Fisicamente si tratta di un fascio di conduttori collegante assieme più circuiti per permettere loro lo scambio dei dati.

Senza voler entrare troppo nei dettagli, sottolineo la relazione tra il concetto di "più circuiti" ed il fascio "comune" di conduttori. Contrariamente ad una connessione "punto-a-punto", dove solo due circuiti si scambiano informazioni, un bus conta generalmente un numero di utenti superiore. D’altro canto un bus (di campo) trasferisce generalmente i dati in modo seriale, ovvero un bit dopo l’altro, ad eccezione di qualche applicazione specifica come il bus SCSI o il noto IEEE-488, largamente usato per l’interconnessione di strumenti di misura. In questi due casi i dati vengono inviati per pacchetti di bit (byte o più), in modo parallelo. Entrambi i sistemi, però, non possono essere considerati come bus di campo, ma piuttosto come bus per comunicazioni informatiche dedicate.

Per una trasmissione seriale, dunque, un numero di conduttori molto limitato basta allo scopo. Generalmente, infatti, dei cavi a due o tre conduttori sono sufficienti. Inoltre, grazie alla maggiore facilità di immunizzare i cavi dalle perturbazioni esterne e reciproche, si può coprire delle distanze maggiori che non con dei cavi piatti ad un

numero maggiore di conduttori.

Anche qui un confronto con le connessioni punto-a-punto è spontaneo: la topologia stessa del bus, ovvero la forma che assume fisicamente il cavo che collega i vari circuiti, ha un aspetto fondamentalmente distinto. Mentre una comunicazione punto-a-punto è limitata ai due circuiti collegati ai due estremi del cavo, nel caso di un bus la flessibilità di estensione aumenta. In effetti, generalmente non pone nessun problema l’aggiunta di un nuovo circuito da collegare al bus esistente.

Per far sì che la comunicazione funzioni, il modo di scambiare dati attraverso un bus cambia radicalmente rispetto alla comunicazione punto-a-punto. Se su di una linea collegante due nodi, magari in modo full-duplex, questi sono praticamente liberi di trasmettere quello che vogliono, come vogliono (esempi: due terminali collegati tra loro da una RS-232, oppure un terminale Videotex collegato via modem alla centrale VTX, dove addirittura le cadenze di trasmissione e di ricezione sono distinte!), l’accesso ad un bus comune esige delle regole di convivenza più severe. L’insieme di queste regole si chiama protocollo.

D’altra parte, e questo è particolarmente importante per un bus di campo, si ricorre sempre ad un meccanismo supplementare di sicurezza in modo da poter garantire un trasporto corretto dei dati da un punto all’altro della rete. Vi sono diversi modi di realizzare questa protezione. Spesso vengono usati diversi di questi meccanismi per una sicurezza maggiore.

Insomma, per poter comunicare attraverso un bus di campo esistono regole severe, misure di sicurezza ed esigenze tecniche non indifferenti. La comunicazione dei dati che ne deriva non è così triviale come in un sistema punto a punto o in un sistema che ne fa direttamente a meno, tramite un cablaggio più esteso e centralizzato della sensorica, delle periferie e degli azionatori. Allora, perché bisognerebbe scegliere un bus, se questo comporta degli impegni e delle difficoltà tecniche a volte difficili da dominare?

2.2. Perché un bus di campo? Fondamentalmente ci sono due argomenti a favore dei bus di campo che stanno alla base di tutti gli altri vantaggi:

la comunicazione tramite bus di campo permette lo scambio di dati che sarebbero più difficilmente o non affatto trasmissibili in un altro modo lo scambio di dati si effettua secondo un meccanismo standard

Da questi due spunti scaturisce tutta una serie di argomenti spesso utilizzati anche a fini commerciali dai produttori e distributori dei vari sistemi di comunicazione. Eccone alcuni dei più correnti:

flessibilità di estensione raccordo di moduli diversi su di una stessa linea possibilità di collegamento di prodotti di fabbricanti diversi distanze coperte dal bus superiori a quelle raggiunte mediante cablaggio tradizionale riduzione massiccia dei cavi e relativo costo estensione dei campi di applicazione riduzione dei costi globali semplificazione della messa in servizio riduzione dei costi di engineering (una volta acquisita l’esperienza necessaria) disponibilità di strumenti di messa in servizio e diagnosi

Esistono pure, ovviamente, qualche svantaggi che mi sembra giusto segnalare in questo luogo, in contrapposizione agli aspetti positivi appena citati:

necessità di conoscenze superiore investimento in strumenti ed accessori (tool di monitoraggio e diagnosi, ecc.) abbastanza onerosi costi apparentemente maggiori compatibilità tra prodotti di fornitori distinti non sempre priva di problemi come si vuol spesso far credere

Gli svantaggi principali sopracitati, in particolare i primi due, sono generalmente temporanei, in quanto legati al fatto di dover accedere ad una nuova tecnologia. Tuttavia, con il tempo e la pratica i vantaggi non dovrebbero farsi attendere. Per questa ragione è vivamente consigliato a tutti i potenziali utilizzatori di interessarsi al tema sufficientemente presto, per non arrivare a dover improvvisare soluzioni con mezzi che non si riesce a comprendere.

2.3. Chi è interessato ai bus di campo? La domanda che a questo punto ci si chiede è effettivamente: chi è, o dovrebbe essere, interessato a questa tecnologia? Si può rispondere classificando in tre categorie di professionisti i potenziali interessati:

da un lato ci sono i "consumatori", ovvero le persone che lavorano su installazioni o macchine costruite facendo ricorso a questi sistemi di comunicazione. Orbene, fintanto che tutto funziona correttamente, la pratica insegna che queste persone non sono neppure a conoscenza della stretta dipendenza dai bus di campo che ha la loro attività. Andrei fino ad affermare che queste persone non sanno e non hanno bisogno di sapere quale soluzione tecnica hanno tra le mani. la seconda categoria comprende le persone e ditte che, mediante apparecchiature, circuiti o altro materiale disponibile sul mercato realizzano dei sistemi di automazione facenti ricorso ai bus di campo. Queste ditte sono designate in inglese quali System Integrator. Tipicamente in questa fascia professionale sono compresi gli uffici di ingegneria che realizzano progetti per terzi. l’ultima categoria è quella dei produttori e fornitori di elementi collegabili ai bus di campo. Fanno parte di questa classe i fabbricanti di PLC, controlli numerici, sensori ed azionatori "intelligenti", ecc.

Fig. 1: categoria di professionisti interessati ai bus di campo

Le esigenze dei membri di queste tre categorie sono ovviamente diverse. Per i primi il fatto che l’installazione funzioni grazie ad un bus di campo o meno è totalmente indifferente, o quasi. Per questa ragione questa categoria di persone può essere tranquillamente eliminata dalla lista dei professionisti che nutrono interessi per i bus di campo. Fanno eventualmente eccezione in questo caso le persone che si dedicano alla manutenzione degli impianti, le quali però possono essere classificate nella seconda categoria. Questa seconda categoria comprende persone per cui, benché siano sensibili all’aspetto del costo, non fosse altro che per rimanere concorrenziali nelle offerte e prestazioni che possono offrire, fanno ricorso ai bus di campo per semplificare il più possibile la progettazione e realizzazione degli impianti, in modo da ridurre soprattutto i costi di sviluppo, messa in servizio e manutenzione. In quest’ottica saranno particolarmente interessati a strumenti di diagnosi, monitoraggio e configurazione della rete. D’altra parte preferiranno ovviamente i sistemi di comunicazione che offrono una semplicità d’uso maggiore. Grazie all’impiego dei bus di campo, chi appartiene a questa categoria potrà vantare una grande flessibilità di concezione e innumerevoli facilitazioni di estensione o modifica successive.

Chi invece deve realizzare apparecchiature capaci di comunicare attraverso i bus di campo, o in genere tutti coloro che si trovano a dover sviluppare dei moduli di comunicazione per bus di campo sono piuttosto interessati alla complessità del loro compito, alla disposizione sul mercato di chip che integrano il più possibile della funzionalità di comunicazione, al supporto allo sviluppo (SW in particolare), ecc. Per loro è primordiale riuscire a realizzare un circuito semplice che non richieda particolari sviluppi sia HW che SW, possibilmente mediante componenti buon mercato. Come si intravede già sin d’ora, data la natura diversa di interessi che spinge la gente ad approdare ai bus di campo, le scelte di impiego di un sistema piuttosto che un altro risulta abbastanza soggettiva.

2.4. Qual è l’origine della "moda" dei bus di campo? Non è proprio corretto parlare di moda, anche se negli ultimi anni l’argomento "bus di campo" è stato effettivamente sfruttato a scopi commerciali in modo molto pronunciato. È forse più corretto chiedersi qual è l’origine della tendenza a passare da dei sistemi tradizionali a dei sistemi basati sui bus di campo. Questa tendenza, totalmente indipendente da aspetti di moda o propaganda, è infatti reale. L’approccio ai bus di campo e, in generale, ai sistemi di comunicazione è più naturale di quanto ci si possa immaginare in un primo tempo. In effetti questa tendenza non è altro che il frutto di un’evoluzione delle tecnologie che ha cominciato all’inizio del 1900, con l’era industriale, e che si protrae ancora oggi, lungi dall’essere terminata. Tuttavia nel campo delle comunicazioni (intese come trasporto di dati) si nota un percorso in senso inverso dell’evoluzione meccanica, dapprima, e elettrotecnica in seguito. Mi spiego: dai livelli più astratti di scambio di dati, la comunicazione è stata applicata al livello gestionale, poi agli automatismi, ed in seguito anche al livello dei sensori ed azionatori. Graficamente il concetto risulterà più chiaro, per cui vi rimando all’immagine seguente:

Fig. 2: evoluzione della tecnica nel campo dell’automazione

All’inizio del secolo, con la scoperta della potenza del vapore, si è scatenata una serie di innumerevoli invenzioni ingegnose. Ben presto i più astuti hanno cominciato ad elaborare dei sistemi a leve e camme per permettere l’automatismo di alcuni processi semplici. Uno dei primi frutti è stato il motore a vapore, usato sia in ferrovia che nelle industrie. In questo caso si trattava di commutare automaticamente l’immissione del vapore da una parte o dall’altra dello stantuffo, in modo da automatizzare l’andirivieni di quest’ultimo. Altri sistemi a bilanciere permettevano la regolazione della pressione e della velocità.

Questi meccanismi hanno conosciuto innumerevoli variazioni e sono evoluti fino ai sistemi a camme, di cui ci si serve ancora oggi, in particolare nei motori a combustione, ma anche ancora su certe macchine utensile. Tuttavia, per alcune applicazioni, ci si rese presto conto che la meccanica non offriva sufficiente flessibilità. Ecco allora che una nuova tecnica fece apparizione: la pneumatica. Grazie a questa tecnica si guadagnava infatti un’enorme flessibilità, grazie al ridirezionamento attraverso tubi di segnali logici. In effetti, la pneumatica è stata il primo passo nella direzione della trasformazione di parametri fisici in parametri logici di comando. Nacque così rapidamente l’idea di combinare i vari segnali mediante valvole pneumatiche per automatizzare processi più complessi.

L’elettricità ha poi portato tutto ciò che si desiderava per poter ridurre ulteriormente il volume e la complessità dei sistemi pneumatici, permettendo non solo di conservarne la flessibilità ma, anzi, di aumentarla ancora notevolmente. L’invenzione dei relais permise di sostituire a meraviglia le valvole pneumatiche, specialmente per le funzioni "logiche". In un primo passo, d’altronde, la pneumatica e l’elettricità si completarono in modo eccellente. Ancora oggi si sfrutta questo binomio in un numero elevato di applicazioni. I relais furono poi i precursori delle centraline programmabili (PLC in inglese, o CPI - componente programmabile integrato in italiano). Il passo decisivo verso una struttura programmabile fu infatti possibile unicamente grazie all’elettronica. È inutile sottolineare l’immensa flessibilità aggiunta grazie a questa ulteriore fase di astrazione... I PLC (userò la sigla inglese in quanto maggiormente conosciuta e diffusa in italiano) hanno conosciuto anch’essi una vera e propria successione di rivoluzioni. Da semplici sostituti dei relais sono diventati nel corso degli anni dei veri e propri computer capaci di elaborare un numero sempre crescente di informazioni. In generale, l’arrivo dei processori, l’evoluzione dell’elettronica e dell’informatica hanno contribuito in modo determinante ad aumentare la flessibilità e la vastità dei campi di applicazione, da una parte, mentre che dall’altra hanno reso più complesso l’insieme del sistema. L’elaborazione dei dati, infatti, richiede un numero sempre maggiore di cavi e collegamenti, che incidono sempre più sull’ingombro e sul prezzo dell’impianto. Per fortuna, queste stesse tecnologie hanno permesso lo sviluppo e l’evoluzione dei sistemi di comunicazione.

Un primo passo nel campo della comunicazione dei dati è stato quello di distribuire l’accesso ai calcolatori, grazie a delle reti a stella, dove un gran numero di utenti erano collegati all’unità centrale mediante una connessione punto-a-punto (la nota RS-232). Gli esempi maggiormente conosciuti (ed anche più vicini a noi) erano i sistemi VAX con i terminali VT-100, diventati nel frattempo uno standard de-facto. Anche qui, grazie all’apporto tecnologico, il passo verso dei sistemi di comunicazione aventi delle topologie più moderne è stato rapido. Dalla struttura a stella si è passati a quella ad albero. La grande differenza risiede nel fatto che gli utenti sono collegati ad un unico cavo in comune. Le informazioni che hanno da trasmettere sono semplicemente multiplexate nel tempo.

L’evoluzione delle tecniche di trasmissione ha permesso lo sviluppo di nuovi protocolli di comunicazione, riducendo i tempi necessari alla comunicazione stessa, pur migliorando nel contempo la sicurezza e l’integrità dei dati trasmessi. Questo ha permesso dapprima un impiego dei sistemi di comunicazione per sincronizzare dei processi industriali indipendenti, poi una discesa verso il "campo" (la produzione), in modo sempre più capillare e dedicato, al punto di giungere al livello più basso (e più critico) dei sensori ed azionatori. A questi livelli, malgrado esistano dei bus "sensori-attuatori" già da alcuni anni, la loro diffusione conosce un vero e proprio boom solo negli ultimissimi anni, mentre che i bus che si occupano di compiti ancora più critici, come quello della sincronizzazione di movimenti in tempo reale, sono ancora relativamente giovani ed ai loro primi passi in applicazioni industriali al di fuori dei laboratori di ricerca universitari.

Write me

3. Basi di teoria

3.1. Il modello OSI Ogni qualvolta si parla di comunicazione in termini tecnici, si fa referenza al modello OSI. Orbene, questo modello è spesso mal capito, non conosciuto o addirittura sfruttato per indurre a credere che il sistema di comunicazione commercializzato è conforme ad uno standard internazionale. Mi sembra quindi indispensabile esporre qualche concetto a questo proposito.

Fig. 3: modello OSI

Il modello OSI (Open System Interconnection) è stato ideato in seno all’ISO (International Standard Organisation) ed è una base di referenza (un modello, appunto) per identificare e separare i vari gruppi funzionali di un ogni sistema di comunicazione. La funzione di modello, quindi serve unicamente da punto di riferimento e confronto. NON è dunque una norma alla quale un sistema di comunicazione deve aderire!

Questo modello suddivide in sette livelli (layer) le funzioni di un sistema di comunicazione. Non è comunque indispensabile di disporre di tutte e sette i livelli in ogni sistema: a seconda delle funzionalità necessarie qualche livello intermediario è spesso omesso. Vi illustro brevemente qui di seguito i ruoli che corrispondono ad ogni livello in un sistema di comunicazione:

livello 1: (physical layer) questo livello definisce le caratteristiche fisiche della parte di comunicazione di un circuito. In particolare in questo livello sono specificati i livelli elettrici, le correnti, i connettori, il sistema di codifica elettrica o ottica dei bit nel tempo, eccetera. Il cavo di collegamento di per sé non è compreso in questa specifica, in quanto il modello OSI si applica unicamente alle caratteristiche di comunicazione di un nodo della rete, e non alla rete stessa. livello 2: (data link layer) definisce il formato delle trame ed la loro codifica logica, così come i meccanismi di protezione quali il CRC e la loro verifica, l’inserzione automatica di bit per evitare trasmissioni di sequenze troppo lunghe senza variazione di livello elettrico (bit stuffing), ecc. livello 3: (network layer) in questo livello sono descritte le caratteristiche della topologia della rete, al fine di garantire che le trame di informazione siano istradate secondo il percorso scelto, dalla sorgente al consumatore. Questo livello è indispensabile qualora più percorsi fossero a disposizione ed attivi simultaneamente. livello 4: (transport layer) questo livello definisce il modo di procedere alla connessione ed alla sconnessione di due o più nodi, così come il modo di stabilire un canale di comunicazione tra questi nodi attraverso la rete. livello 5: (session layer) una volta stabilito il canale logico di comunicazione tra due punti, questi possono

iniziare a sincronizzare le loro applicazioni, rispettivamente ad aprire una sessione di lavoro. Queste operazioni si determinano a questo livello. livello 6: (presentation layer) quando i due nodi in comunicazione usano un sistema di presentazione dei dati diverso, come ad esempio il codice ASCII ed un codice esteso a 16 bit, è a questo livello che avviene la dovuta conversione e la scelta delle corrispondenze opportune. livello 7: (application layer) l’ultimo livello concerne la descrizione dell’interfaccia verso l’applicazione. Tuttavia questo livello non comprende l’applicazione stessa, in quanto essa non fa parte del sistema di comunicazione.

Fig. 4: flusso dei dati e relazioni logiche

Il flusso dei dati attraverso un sistema di comunicazione subisce un trattamento a tappe simile a quello di un oggetto che si desidera inviare per posta: ad ogni livello del modello OSI corrisponde un trattamento ben preciso, simile alle diverse fasi di imballaggio dell’oggetto. La trasmissione attraverso la rete corrisponde allora alla spedizione del pacco, mentre che alla ricezione, ogni livello del modello OSI si occupa di spacchettare le informazioni aggiunte all’imballaggio, procedendo in senso inverso, come per un pacco iniziando dal cartone esterno, poi dalla carta di imballaggio, e così via. In pratica, ogni livello alla ricezione si occupa di spacchettare ciò che è stato aggiunto ai dati originali al momento della trasmissione dal livello corrispondente. Vi è dunque un flusso dei dati fisici verticale, mentre vi sono delle corrispondenze logiche orizzontali tra i livelli OSI delle due stazioni comunicanti.

3.2. Elementi di comunicazione In una rete di telecomunicazione di una certa dimensione, non è sempre sufficiente collegare i vari nodi che partecipano alla comunicazione mediante un semplice cavo elettrico. A causa delle distanze elevate, del numero alto di nodi o per qualunque altra ragione può dunque essere necessario prendere provvedimenti affinché la comunicazione possa effettivamente aver luogo correttamente, adattando la rete alle esigenze pratiche. A questo scopo può essere necessario dover inserire dei circuiti che separano i diversi segmenti della rete in modo da migliorarne le caratteristiche. In altri casi il bus deve poter interagire anche con altri sistemi di comunicazione. Ecco allora che altri apparecchi devono essere utilizzati. Insomma, vi sono diversi accorgimenti da prendere nella pratica che si scostano leggermente dal concetto iniziale di bus visto come conduttore comune a più circuiti...

Tuttavia anche qui si può avere un approccio teorico abbastanza semplice, proprio grazie al modello OSI al quale farò largamente riferimento nelle pagine che seguono.

3.2.1. Repeater

Un repeater, o amplificatore, permette di migliorare i segnali elettrici presenti sulla rete in modo da poter coprire delle distanze maggiori tra i nodi oppure per permettere di collegare un numero superiore di nodi ad una stessa rete, ripartendo il carico delle singole stazioni sui diversi segmenti di rete così realizzati. Un altro compito che spesso incombe al repeater è quello di adattare la comunicazione a dei mezzi fisici diversi. L’esempio più classico è quello della deportazione di un segmento di rete ad una relativamente grande distanza tramite fibre ottiche: da rete basata su cavi elettrici, un primo repeater converte la comunicazione in un sistema ottico. Dall’altra parte della fibra ottica un secondo repeater può effettuare la conversione inversa, oppure può essere collegato un apparecchio con interfaccia ottica. Facendo riferimento al modello OSI, si nota come questo elemento di comunicazione si occupi unicamente di decodificare il livello 1, ovvero il livello fisico. Tutto quanto concerne il contenuto delle trame non influenza minimamente il funzionamento del repeater, rispettivamente il repeater non lo interpreta. È infatti noto che generalmente un repeater non ha una propria intelligenza ma è formato unicamente da circuiti elettronici semplici.

Fig. 5: repeater

Una variazione dei repeater più semplici, formati da due connettori per i due segmenti di rete che sono destinati a collegare, è lo splitter. Quest’ultimo è identico ad un repeater comune, ad eccezione del fatto che è munito di un numero superiore di connettori. Il principio di funzionamento è semplice: lo splitter "ascolta" tutti i segmenti di rete ad esso collegati. Non appena rileva segnali di comunicazione su uno di essi, commuta tutti gli altri in trasmissione e riporta i segnali entranti dal segmento attivo sugli altri.

Fig. 6: splitter, una variazione del repeater

3.2.2. Bridge

Il bridge, o ponte, interpreta sia il livello 1 che il livello 2 del modello OSI. Esso è quindi in grado di collegare due segmenti di reti diverse, con delle caratteristiche elettriche e di codifica distinte, pur permettendo, ovviamente, a certe applicazioni distribuite sui due segmenti di comunicare tra loro. Tuttavia la rete più rapida è costretta ad

abbassarsi al livello di quella meno efficiente, simulando o emulando la comunicazione di quest’ultima. Dato che il bridge non è un apparecchio intelligente, per un messaggio ricevuto da un sistema viene generato un messaggio equivalente sull’altro.

Fig. 7: bridge

3.2.3. Router

Il router, come il suo nome lo lascia facilmente intuire, si occupa di deviare le trame di comunicazione verso i diversi segmenti di rete appropriati, definendo così l’istradamento necessario delle trame. Allo scopo di effettuare tale compito, il router deve interpretare i messaggi fino al livello 3 del modello OSI. Va da sé che i sistemi di comunicazione che prevedono l’impiego di apparecchi di questo tipo dispongono pure del livello 3 del modello OSI, nello stack di comunicazione proprio al sistema.

Fig. 8: router

3.2.4. Gateway

Il nome gateway, che in italiano potrebbe essere chiamato "passerella", fa pensare a qualche cosa di simile al bridge. Tuttavia, a differenza di quest’ultimo, il gateway ha abbastanza intelligenza per decodificare i messaggi di comunicazione fino al livello 7 del modello OSI, ovvero fino al livello dell’applicazione. Come lo vedremo più avanti, questo tipo di apparecchio permette di collegare in modo ottimale dei bus di tipo e caratteristiche completamente diversi, mantenendo pur sempre una canale di comunicazione aperto tra le applicazioni che girano sui due sistemi collegati. Il gateway, grazie alla sua configurabilità, le sue risorse e la sua "intelligenza", è in grado di ottimizzare la comunicazione da entrambi i lati, sfruttando appieno le caratteristiche tecniche dei due sistemi di comunicazione che collega.

Fig. 9: gateway

Questo tipo di apparecchio, malgrado la sua importanza ed in parte a causa della sua complessità nonché della fetta di mercato limitata che rappresenta, risulta comunque essere piuttosto raro. Spesso capita di trovare chi, sotto il nome di gateway, spaccia dei semplici bridges. Evidentemente non si tratta per nulla della stessa cosa...

3.3. Topologia di rete La comunicazione tra due nodi si effettua attraverso una linea punto-a-punto unicamente nel caso in cui solo questi due nodi sono presenti. In tal caso la connessione avviene mediante un protocollo proprietario che sfrutta un livello basso standard quale l’RS-232 o l’RS-422 (ricordatevi il modello OSI: i tipi di comunicazione RS-232 e RS-422 definiscono unicamente il livello 1 del modello). In questo caso la topologia del sistema di comunicazione è lineare (da un punto all’altro, appunto). L’unica limitazione a cui si va generalmente in contro è la distanza tollerata che, se importante, può richiedere un adeguamento verso il basso della cadenza di trasmissione.

Tutto questo interessa però poco nel settore dei bus di campo. Qui, infatti, il numero di nodi collegati assieme dal sistema di comunicazione è generalmente superiore. Si pone allora un’altra questione, cioè quella dell’aspetto della topologia della rete. La topologia non è altro che la forma fisica che prende la rete in base agli elementi di comunicazione impiegati , ai nodi collegati ed il modo in cui tutti questi apparecchi sono interconnessi.

Esistono diversi modelli di topologie tipiche. I più ricorrenti sono i seguenti:

la struttura ad anello (ring) la struttura a stella la struttura ad albero

3.3.1. Struttura ad anello (Ring)

La struttura ad anello, o ring, permette di collegare in serie e successivamente tutti i nodi della rete. Tipicamente tra un nodo ed il successivo la comunicazione unidirezionale. Il nodo successivo si occupa di ripetere il segnale ricevuto, estraendone nel contempo le parti che lo riguardano ed immettendo al momento appropriato le informazioni che vuole inviare. Questa struttura presenta due vantaggi principali: innanzitutto il segnale è rigenerato in ogni nodo, per cui ogni nodo gioca anche il ruolo di repeater e permette quindi di coprire senza costi aggiuntivi delle distanze notevoli. D’altra parte la comunicazione unidirezionale è ideale per la messa in servizio di fibre ottiche, in quanto ogni segmento di rete rappresenta in pratica un collegamento punto-a-punto unidirezionale. Questo permette, in certe condizioni, pure un risparmio notevole di materiale di cablaggio.

I due svantaggi principali di questa topologia non sono tuttavia trascurabili: dapprima si deve sottolineare la difficoltà di estendere la rete. Non è infatti possibile aggiungere un nuovo nodo senza interrompere anche solo momentaneamente la comunicazione, in quanto è indispensabile aprire l’anello per inserirvi il nuovo venuto. D’altra parte se un componente del circuito non funziona più o un segmento di rete è danneggiato, tutta la rete non funziona più! Se questo è magari accettabile in una rete di PC negli uffici, dove i singoli PC possono continuare a lavorare in modo locale anche se manca per un breve tempo il collegamento con gli altri, nelle applicazioni in

tempo reale legate ad automatismi e sincronismi ogni ritardo può essere causa di danni diretti o indotti notevoli. La topologia ad anello è quindi raramente utilizzata nel dominio dei bus di campo.

Fig. 10: struttura ad anello

3.3.2. Struttura a stella

La struttura a stella presenta delle caratteristiche diametralmente opposte a quelle della struttura ad anello. In effetti la struttura a stella si basa su di un punto centrale della rete dove si situa generalmente un nodo avente delle funzioni speciali (quali il ruolo di master o di server della rete) dal quale partono un numero di collegamenti bidirezionali pari al numero di nodi decentralizzati che la rete conta. Questa configurazione permette quindi facilmente e senza dover interrompere la comunicazione di aggiungere un nuovo nodo alla rete, ammesso che il nodo centrale disponga ancora di connessioni libere. Inoltre, in caso di guasto di un componente, gli altri nodi possono proseguire senza interruzione, dato che la comunicazione con gli altri nodi non viene perturbata, ammesso che il nodo guasto non sia proprio quello centrale. Tuttavia, come è facile intuirlo, una centralizzazione dei cablaggi richiede una quantità notevole di cavi e non permette di coprire grandi distanze.

Fig. 11: struttura a stella

3.3.3. Struttura ad albero

La struttura ad albero rappresenta una specie di compromesso tra i vantaggi e gli svantaggi delle due topologie viste sopra. In linea di massima una struttura ad albero permette delle biforcazioni, dunque delle strutture simili a quella a stella. Come in questa configurazione la comunicazione sulle linee è bidirezionale. Tuttavia in una struttura ad albero sui vari segmenti creati si possono collegare più nodi. D’altra parte la struttura ad albero ideale dovrebbe essere formata da un unico troncone sul quale si collegano tutti i nodi. Questo richiama vagamente la struttura ad anello, dove però i nodi non sono allacciati in cascata e l’anello non ha bisogno di essere chiuso. I vari nodi, infatti, sono collegati in parallelo sulla stessa linea, e non in serie, come in una struttura ad anello.

Quest’ultima caratteristica è fondamentale per permettere alla comunicazione di proseguire anche in caso di guasto di un nodo. Anche l’estensibilità della rete può avvenire facilmente senza dover interrompere la comunicazione. Addirittura è possibile aggiungere un intero nuovo segmento di rete con un numero anche importante di nuovi nodi, esattamente in modo analogo alla semplice aggiunta di un singolo nodo. La libertà di estensione, sia in fatto di numero di elementi connessi che in fatto di forma e distanza, risulta quindi enorme. Vedremo comunque più avanti come e con quali restrizioni tali estensioni possono essere effettuate. Questa topologia, come senz’altro avrete già immaginato, è la più diffusa nel settore dei bus di campo, proprio per le sue caratteristiche vantaggiose. Il livello fisico impiegato in questo tipo di rete è spesso eseguito secondo la norma RS-485 o in maniera simile.

Fig. 12: struttura ad albero

3.4. Aspetti fisici Orbene, contrariamente a quanto spesso si crede, non basta collegare in qualsiasi modo i nodi in parallelo, limitandosi a verificare la polarità delle connessioni. Esistono delle teorie abbastanza complesse sulle linee elettriche, sulla trasmissione di segnali, sulle riflessioni e su altri argomenti ancora che avrete magari già seguito in altri ambiti. Non voglio riportarle in questo testo, perché al di fuori del tema principale. Tuttavia desidero richiamare qualche indicazione utile e pratica per realizzare una rete senza intoppi. È infatti noto che la maggior parte dei problemi di messa in servizio di un impianto è causata dalla leggerezza con la quale l’aspetto fisico della rete di comunicazione viene trattato. Ecco quindi di seguito alcuni punti fondamentali da ricordare al momento della concezione e realizzazione di una rete:

Su di una linea un segnale a frequenza elevata causa ad ogni estremo della linea stessa una riflessione del segnale che ritorna sulla linea e si sovrappone al segnale originale, disturbandolo. Anche se la cadenza di trasmissione è bassa, tale fenomeno si presenta, in quanto un segnale digitale puro ha un gran numero di armoniche ed una larghezza di banda ben superiore alla cadenza pura e semplice della trasmissione. Per eliminare le riflessioni vi sono due metodi:

i segnali emessi sulla rete vengono "arrotondati", in modo da ridurre notevolmente il numero di armoniche che lo compongono. A questo scopo esistono chip di interfaccia appositi, specialmente usati in sistemi dove si può lavorare con cadenze di trasmissione basse. Tuttavia questo provvedimento deve essere preso dal fabbricante dei circuiti e deve essere previsto nella norma del bus in questione. L’utente beneficia quindi di un sistema di cui non deve più preoccuparsi. Per eliminare le riflessioni basta aggiungere una resistenza terminale ad ogni estremità di ogni segmento di rete.

Le biforcazioni della rete aumentano il rischio di problemi di perturbazione dovuti alle riflessioni. I vari segmenti di rete devono essere il più lineari possibili. La creazione di nuove diramazioni dovrebbe invece essere realizzata mediante splitter (repeater multi-port). Più vi sono elementi collegati ad un segmento di rete, più questo risulta caricato. Generalmente per i bus di campo che utilizzano un’interfaccia RS-485 un numero di circa 32 nodi corrisponde al limite accettabile (vi sono tuttavia nuovi componenti di interfaccia con impedenza più alta, in modo da permettere

l’interconnessione di un numero maggiore di nodi che può andare fino a 64). Anche se la rete sembra funzionare con un numero superiore di nodi, pianificatelo in modo corretto, introducendo dei repeater. I repeater ritardano leggermente la propagazione dei segnali. È quindi indispensabile ridurre al minimo il numero di ritardi consecutivi tra le paia di nodi comunicanti assieme. Alcuni bus, in particolare quelli multi-master come il CAN, sono molto critici in fatto di ritardi: l’introduzione anche di un solo repeater impone una riduzione della cadenza di trasmissione massima, a volte anche importante. Si eviti quindi di inserire dei repeater in cascata, preferendo invece una struttura a stella, dove da un segmento principale si diramano i vari segmenti aggiuntivi. Oltretutto tale struttura potrebbe essere realizzata addirittura mediante uno splitter. La lunghezza di ogni cavo deve essere ottimalizzata per ridurre la dispersione del segnale e la probabilità che esso sia perturbato da disturbi elettromagnetici esterni. Le riserve di cavi nelle canaline, spesso fatte dagli elettricisti in previsione di modifiche, devono essere evitate. Oltre ad aumentare le probabilità di perturbazioni non servono generalmente mai a nulla ed impediscono eventualmente di poter poi raggiungere dei nodi distanti. Facendo passare un cavo di comunicazione in parallelo ad un cavo di alimentazione si è praticamente sicuri di aumentare le perturbazioni elettromagnetiche sulla rete. Separate fisicamente il più possibile le linee di comunicazione dai cavi di potenza, laddove è fattibile. La schermatura dei cavi è una misura molto efficace per premunirsi da ogni forma di perturbazione. È però altrettanto vero che una schermatura non effettuata correttamente può addirittura essere fonte di maggior disturbo, specialmente quando la rete si estende su grandi distanze (da qualche centinaia di metri in su)! Per essere utile, la schermatura deve collegare tutte le diramazioni della rete e, cosa assai importante, deve assolutamente essere messa a terra in UN unico punto. Una messa a terra in più punti può in effetti causare delle correnti residue dovute alla differenza di potenziale delle terre che possono anche essere parecchio rilevanti. Ogni rete deve essere concepita e pianificata in anticipo, in modo da essere tracciata lungo un percorso il più ideale possibile. Una documentazione aggiornata regolarmente facilita enormemente ogni attività relativa alla messa in opera ed alla manutenzione della rete.

Fig. 13: struttura ad albero consigliata

Prendendo in considerazione questi semplici aspetti, un cavo formato da un semplice doppino (più un conduttore per la massa di referenza) schermato è sufficiente nella maggior parte dei casi, anche in ambienti particolarmente ostili. Questo permette di evitare di ricorrere a cavi coassiali o a fibre ottiche ancor più onerose, anche in ambiti

dove ci si immagina che le perturbazioni esterne sono inevitabili. Questo è stato dimostrato dalla pratica, in installazioni montate su macchine ad elettroerosione e in laboratori di elettrofisica. In quest’ultimo caso venivano generati dei fulmini artificiali che arrivavano fin a cancellare le EPROM di alcuni print disseminati nel laboratorio. Tuttavia la comunicazione attraverso il bus (si trattava del Bitbus nel caso specifico) funzionava senza problemi!

3.5. Aspetti dei protocolli Come accennato all’inizio, vi sono numerosi sistemi di comunicazione che ricadono sotto la denominazione di bus di campo. In comune hanno praticamente ben poco. L’aspetto che forse è più marcante è quello di poter collegare con un mezzo fisico comune un numero più o meno importante di circuiti. A parte quest’aspetto si potrebbe sottolineare la nozione di tempo reale comune a tutti i bus di campo. Tuttavia a seconda del bus e dell’applicazione, anche questo concetto è molto variabile. Vi sono sistemi che considerano un tempo "reale" quando è di qualche decina di microsecondi. Altri sistemi accettano dei tempi di risposta che possono andare fino a qualche secondo. Parlando di caratteristiche tecniche ed aspetti dei protocolli sono quindi di nuovo costretto a fare astrazione e presentare in forma teorica i concetti che più sono diffusi. Lo farò iniziando dal basso del modello OSI, ovvero dal livello 1, passando dal livello 2 e terminando con alcune referenze al livello 7.

3.5.1. Codifica dei segnali

Il concetto di comunicazione è strettamente legato all’idea di "codifica". Per poter trasmettere un’informazione, infatti, questa deve essere codificata in modo opportuno. La codifica è l’operazione che consiste nel trasformare delle informazioni da un certo repertorio di segni verso un altro. La codifica e la relativa decodifica sono operazioni che modificano la forma dei segnali, ma non il contenuto.All’ultimo stadio della preparazione di un’informazione da trasmettere, al momento di convertire i dati ordinati a blocchi di bit in una sequenza seriale, i singoli bit ricevono un’ultima codifica utile a facilitare il trasporto della trama dalla sorgente verso i consumatori.

Vi sono diversi modi di codificare una sequenza seriale dei bit: la più semplice è la codifica denominata NRZ (Non Return to Zero). Nel codice binario NRZ i singoli bit sono allineati successivamente e non sono separati da alcun segnale. L’aspetto della sequenza ricalca fedelmente il contenuto stesso, in quanto i bit a ‘1’ sono effettivamente rappresentati da un segnale di una certa ampiezza, rispettivamente i bit a ‘0’ vengono rappresentati da una tensione diversa. La cadenza di trasmissione prestabilita permette di individuare i singoli bit in base al tempo trascorso. Il problema principale si presenta quando una serie prolungata di bit dello stesso tipo viene trasmessa: non avendo più nessun fianco positivo o negativo, diventa difficile risincronizzare i tempi, per cui si può incappare in un conteggio errato dei bit. Gli UART tradizionali (usati su tutte le apparecchiature munite di RS-232, ma anche su altri sistemi) rimediano a questo problema introducendo alcuni limiti: i bit di dati massimi trasmessi vanno dai 5 (non più usato) ai 10 bit. Questi vengono impacchettati con un bit di start (a zero) ed uno o più bit di stop (a ‘1’). La linea, da parte sua, quando non è occupata si trova a ‘1’. Ogni invio di blocco inizia così con un fianco negativo che permette la risincronizzazione dei due apparecchi. Dato che la lunghezza del blocco è ridotta (12 bit al massimo) la tolleranza degli orologi dei due sistemi non è più così critica. Lo svantaggio è però che i dati da trasmettere devono venire frammentati (generalmente a byte) ed inviati con una aggiunta relativamente importante di segnali. Di conseguenza si ha una perdita di tempo abbastanza rilevante.

Fig. 14: codifica NRZ

Il codice RZ (Return to Zero), invece, garantisce un ritorno a zero per ogni bit. I bit ‘0’ non subiscono modifiche, mentre che i bit ‘1’ vengono accorciati nel tempo, in modo da garantire un ritorno a zero del segnale ad ogni bit. Con questa meccanica si aggiunge un numero considerevole di fianchi al segnale trasmesso, in modo da facilitare la risincronizzazione. Tuttavia un’emissione di una sequenza prolungata di zeri pone lo stesso problema visto sopra. A questo scopo, quando si utilizza questo tipo di codifica, si dispone di un dispositivo automatico che, all’emissione, inserisce automaticamente un bit a ‘1’, quando un certo numero prestabilito di zeri si sono susseguiti. Alla ricezione il corrispondente automatismo elimina automaticamente il bit a ‘1’ quando ha contato lo stesso numero di bit a zero. Questo modo di inserzione automatica è conosciuto sotto il nome di bit stuffing (inserzione di bit). Lo svantaggio della codifica RZ è quello di causare un numero di fianchi elevato pari, nel caso di una trasmissione di soli ‘1’, al doppio dei bit inviati. Questo, come abbiamo visto, non è propriamente vantaggioso, specialmente dal profilo delle perturbazioni.

Fig. 15: codifica RZ

Proprio per ridurre il numero di fianchi si è quindi immaginato un altro sistema di codifica, chiamato NRZI (Non Return to Zero Inverted). L’NRZI è un metodo di codifica dei dati e della cadenza di trasmissione ideale per la trasmissione di trame lunghe di dati. Esso specifica infatti che il livello di tensione presente sulla linea non viene modificato se si trasmette un ‘1’, mentre che cambia alla trasmissione di uno zero. In tal modo il numero di fianchi è limitato, mentre che se si desidera inviare una sequenza prolungata di ‘1’ viene adottato anche qui il metodo di bit stuffing, dove però si inserisce automaticamente uno zero. Con questo metodo si ha nel peggiore dei casi un fianco ogni bit, dunque una frequenza pari alla metà della cadenza dei bit. In media, comunque, si ha un numero di fianchi pari alla metà dei bit trasmessi (ammettendo una probabilità del 50% di trasmissione di ‘1’ e zeri), quindi una frequenza pari ad un quarto della cadenza dei dati.

Fig. 16: codifica NRZI

Si noti comunque che la tecnica dell’inserzione automatica di bit (bit stuffing), viene sempre più comunemente utilizzata per evitare di dover usare un meccanismo del tipo start-stop tipico dell’UART. A tal proposito viene anche impiegata in taluni sistemi usando la codifica NRZ.

D’altra parte non bisogna dimenticare che se i tre sistemi di codifica illustrati sono i più diffusi, esistono pure altri metodi. Ne esistono anche diversi che utilizzano un numero superiore di potenziali elettrici per definire i singoli bit. Dato che però tali meccanismi risultano più onerosi, non vengono generalmente impiegati nei bus di campo.

3.5.2. Componentistica ed interfacce

Lo stream di bit (sequenza di bit) preparata in base ad uno di questi metodi di codifica è quindi pronto ad attraversare la rete. Tuttavia, i segnali logici 0 - 5V non sono molto appropriati per l’invio di segnali su distanze lunghe. Questo non tanto per il loro potenziale relativamente basso, ma perché soggetti a perturbazioni esterne che devono essere separate il meglio possibile dal resto dei circuiti di un apparecchio elettronico. A questo scopo esistono diversi meccanismi di codifica elettrica atta a migliorare l’affidabilità della trasmissione, da una parte, ed altri per proteggere maggiormente i circuiti che stanno a monte della comunicazione.

3.5.2.1. RS-232

Cominciamo quindi dai circuiti più vecchi (non per questo però più semplici). Ai tempi si considerò il livello di 5 Volt insufficiente per trasmettere dei dati. Partendo da questo presupposto è stato optato per una tensione di 12 Volt, generalmente già presente nelle apparecchiature. Le norme V.24 e V.28 corrispondenti all’RS-232 definiscono infatti i seguenti livelli di tensione:

segnale logico ‘0’ (stato "attivo" per i circuiti di comando): da +3 a +15 Volt segnale logico ‘1’ (stato "non attivo" per i circuiti di comando): da - 3 a - 15 Volt

Si noti che non è un errore tipografico! Il segnale logico ‘1’ è effettivamente codificato con una tensione negativa generalmente situata a -10 o -12 V.

Fig. 17: interfaccia RS-232

Nei circuiti moderni non sempre si dispone di tutte queste tensioni, per cui i produttori di circuiti integrati si sono dati da fare per produrre un integrato che, con pochi condensatori esterni, riuscisse a generare tutte le tensioni necessarie a partire da una alimentazione semplice a 5 Volt. I più famosi circuiti sono i MAX-232 della MAXIM di cui esistono comunque diversi second source.

Write me

3.5.2.2. RS-422

Ben presto però ci si accorse che la trasmissione tramite potenziali riferiti ad una massa non dava sufficienti garanzie di immunità. Un semplice campo magnetico lungo il cavo di trasmissione può indurre una tensione tale da bastare ad indurre in errore la decodifica. È stata così concepita la linea differenziale. Se da una parte questo tipo di connessione necessita di un numero doppio di cavi, per la comunicazione full duplex, dall'altra offre una maggiore sicurezza. Non viene infatti più fatto un confronto tra il segnale ricevuto e la massa, ma un confronto tra due linee di dati che trasmettono ad un livello di 5V circa, ma sempre una l'inverso dell'altra (trasmissione differenziale). In tal modo, se sulla linea DATA+ il segnale è superiore alla linea DATA-, allora significa che si trasmette un segnale '1'. Viceversa, se il potenziale di DATA+ risulta inferiore a quello di DATA-, allora si interpreta uno '0'. Il vantaggio di questo modo è proprio la grande immunità alle perturbazioni. Infatti, se la linea si trova in un campo magnetico, le perturbazioni presenti sui due conduttori sono identiche, per cui la differenza di potenziale tra i due segnali rimane pressoché immutata. Come detto, per una trasmissione punto-a-punto del tipo RS-422 si necessita di 4 conduttori (più la massa, come sempre, per livellare le differenze). Quali trasceiver si utilizza generalmente gli SN65176 della Texas Instrument. Esistono anche qui numerose alternative. Nel caso dell'impiego di IC SN65176 ce ne sono bisogno due per apparecchio: uno per la trasmissione ed uno per la ricezione. Esistono comunque altre variazioni del chip.

Fig. 18: interfaccia RS-422

3.5.2.3. RS-485

Sia l'RS-232 che l'RS-422 sono degli standard per la comunicazione punto-a-punto. Per una rete multiutente, invece, viene spesso utilizzata la norma RS-485. Questa norma esige però un accesso coordinato alla rete. Solo una stazione alla volta può emettere, mentre tutte le altre devono rimanere in ascolto. Questo modo di comunicare è denominato halfduplex. Sta al protocollo definire il meccanismo di accesso in emissione dei singoli nodi presenti sulla rete. A parte ciò, le caratteristiche elettriche dell'RS-485 sono identiche a quelle dell'RS-422, tant'è vero che vengono impiegati gli stessi chip. Si noti che dal momento che la comunicazione è halfduplex, bastano solo due conduttori (e la famosa massa) per il collegamento di tutti i nodi. D'altro canto un solo chip per nodo è sufficiente.

Fig. 19: interfaccia RS-485

3.5.2.4. ISO 11519 / ISO 11898

L'ISO (International Standardization Organization) ha standardizzato il livello fisico del CAN sotto due norme che differiscono tra loro per la velocità massima di trasmissione ammessa ed altri aspetti minori derivanti dal primo:

l'ISO 11519 specifica il livello fisico per delle cadenze fino a 125 kbit/s (CAN low speed) l'ISO 11898 ammette cadenze fino a 1 Mbit/s (CAN high speed)

Questa differenza, che porta poi sui segnali e sulle tensioni da adottare, non importa più di tanto in questo luogo. Basti sapere che generalmente nel campo dell'automazione viene adottata la caratteristica conforme all'ISO 11898 (high speed). Quello che interessa, invece, è vedere come viene realizzata un'interfaccia per un bus multiutente dove tutti possono prendere l'iniziativa di trasmettere. Il problema principale sta infatti proprio nel dare la possibilità al circuito che realizza il protocollo di rendersi conto immediatamente quando una collisione ha luogo. Nel caso del CAN, per esempio, questa reazione deve avvenire in un lasso di tempo inferiore alla trasmissione di un solo bit (quindi, ad una cadenza di 1 Mbit/s, entro un microsecondo!). Anche qui esistono, per fortuna, numerosi chip di interfaccia quali l'82C250, l'80C251 ed altri sostituti compatibili. Verso l'esterno, sul bus, queste interfacce sono molto simili all'RS-485, in quanto basate su di un segnale differenziale. Tuttavia, a differenza dell'RS-485, i segnali presenti indicano un bit "dominante" (CAN-H > CAN-L) o un bit "recessivo" (CAN-H <= CAN-L). I transceiver non operano in modo halfduplex, bensì in modalità full duplex. In tal modo il chip di protocollo può effettivamente verificare che quanto lui emette corrisponde a quanto presente sulla linea. Nel caso in cui ciò non fosse vero, rileva una collisione in cui non ha precedenza, per cui interrompe immediatamente la trasmissione in favore dell'altro nodo che sta emettendo.

Fig. 20: interfaccia ISO 11898

3.5.3. Componenti di protezioni supplementari

I transceiver visti nei paragrafi precedenti permettono di adattare le tensioni necessarie alla comunicazione. Questo adattamento viene realizzato solitamente in un chip distinto da quello che integra il protocollo di comunicazione, in quanto deve presentare delle caratteristiche più robuste di quanto sopporta generalmente un circuito ad alta integrazione. Tuttavia il circuito di interfaccia non è in grado di assorbire e filtrare da solo tutte le perturbazioni captate dalla linea. A questo scopo può avverarsi necessario aggiungere alcuni componenti per filtrare o attenuare l'influsso esterno sul resto del circuito stampato. Nei prossimi paragrafi figurano gli accorgimenti più comuni usati in relazione all'RS-485. Queste soluzioni sono comunque valide con pochi ritocchi per tutte interfacce illustrate sinora.

3.5.3.1. Separazione galvanica

Sebbene i transceiver siano generalmente concepiti per essere in grado di sopportare almeno in parte le perturbazioni elettromagnetiche provenienti dalla linea di comunicazione (che funge da vera e propria antenna), spesso si preferisce aggiungere una separazione galvanica che isoli i circuiti di comunicazione dal resto della piastra. In tal modo tutta la parte di circuito che si trova isolata dalla linea di comunicazione rimane maggiormente protetta. È data preferenza a questa separazione specialmente quando si vuole isolare la parte logica (processore, memorie, circuiti digitali) dal mondo esterno per garantirne il buon funzionamento anche in ambienti critici. A questo scopo è dunque necessario disporre di un'alimentazione con più circuiti secondari isolati ed indipendenti, oppure di un convertitore DC/DC (da 1 W è sufficiente ed esiste in versione DIL-8) per alimentare la logica da una parte e i chip di interfaccia dall'altra. Le masse delle due parti non sono collegate tra loro, ovviamente. Con questo provvedimento si riesce a realizzare un'isolazione galvanica di 500, 1000 o più volt . L'utilità della separazione galvanica è comunque da valutare di volta in volta in quanto non è sempre necessaria. Talvolta, inoltre, a dipendenza del sistema di comunicazione realizzato, essa non è possibile, per via dei ritardi di trasmissione dovuti all'attraversamento dei circuiti. Si impone allora una rinuncia oppure una scelta di cadenze di trasmissione inferiori. La qualità degli optocoupler, in questi casi, è determinante.

Fig. 21: esempio di separazione galvanica per RS-485

3.5.3.2. Protezione contro le sovratensioni

Le scariche elettrostatiche (ESD) rappresentano comunque un pericolo sia per i transceiver, sia per la separazione

galvanica che comunque non reggerebbe una tensione così elevata. Per ovviare a questo problema, presente in particolare modo sulle linee in cui avvengono spesso collegamenti e scollegamenti, ogni nodo dovrebbe essere munito di protezioni adeguate su ogni connessione (ogni linea di segnale) presente tra i circuiti interni dell'apparecchio ed il mondo esterno. Esistono infatti dei diodi speciali (transzorb) bidirezionali che si comportano in modo simile ai diodi zener: al di sotto di una certa tensione essi rappresentano una impedenza infinita. Quando però la tensione ai poli di questi diodi raggiunge un determinato valore (positivo o negativo, non importa dato che sono bidirezionali), essi formano un cortocircuito in grado di scaricare l'impulso verso la terra.

Fig. 22: esempio di protezione contro le sovratensioni

3.5.4. Protezione dei dati trasmessi

3.5.4.1. Parità

I soli provvedimenti elettrici non permettono comunque di garantire una correttezza dei dati trasmessi. Per questa ragione ogni sistema di comunicazione prevede alcuni accorgimenti che permettano da una parte di individuare quando si sta ricevendo dei dati e come sincronizzarsi (vedi anche sopra, i diversi metodi di codifica), dall'altra di verificarne la consistenza. Sulle connessioni RS-232 ci si limita spesso ad un controllo minimo mediante i bit di start e di stop. Tuttavia viene spesso utilizzato anche il controllo mediante il bit di parità. Mediante la parità è possibile intercettare ogni trasmissione di un pacchetto di bit (generalmente un byte) in cui vi sia un numero dispari di bit errati. La sicurezza che questo mezzo offre è comunque molto limitata, dato che per un byte con due bit corrotti, per esempio, non viene rilevato nessun errore!

Per questa ragione esistono dei protocolli che, oltre alla parità trasversale, cioè su ogni byte, aggiungono un byte alla fine della trasmissione di un blocco che contiene una parità longitudinale, che porta cioè su tutta la lunghezza dei byte trasmessi. La combinazione delle due parità è detta parità incrociata. Questo semplice meccanismo permette una migliore protezione ed in teoria, in caso di un semplice ed unico errore su di un pacchetto, una correzione automatica. Questi protocolli, oltre a ciò, devono comunque disporre anche di meccanismi per indicare l'inizio e la fine di un pacchetto, il formato dei dati all'interno dello stesso, ecc. La protezione dei dati mediante inserzione di bit di parità risulta pertanto insufficiente.

3.5.4.2. Distanza di hamming, ridondanza, CRC

Come si può intravedere però, queste soluzioni sono abbastanza primitive e di una sicurezza estremamente limitata, dato che con pochi bit consecutivi errati il meccanismo di riconoscimento degli errori si sbaglia già. Esiste un modo abbastanza intuitivo per classificare il livello di sicurezza di un protocollo: si indica il numero massimo di bit (consecutivi o meno, è indifferente) che un sistema è in grado di individuare con il 100% delle probabilità. Questo numero è conosciuto come distanza di hamming. Nel caso del bit di parità trasversale, la distanza di hamming è pari a 1 in quanto già con due bit divergenti il sistema non riconosce più l'errore.

Si può quindi immaginare a piacimento sistemi di rilevamento degli errori. Tuttavia ci si rende presto conto che questi meccanismi esigono uno spazio che può diventare importante all'interno del tempo di trasmissione disponibile. Con più si aggiunge informazioni utili alla protezione dei dati, meno la comunicazione è efficace. La parte aggiunta per la protezione dei dati è chiamata ridondanza. Il tasso di ridondanza, dal canto suo, indica il rapporto tra i dati utili ed il numero di dati effettivamente inviati.

Per evitare una ridondanza eccessiva destinata all'intercettamento di eventuali errori di trasmissione, è stato inventato un meccanismo assai efficace: il CRC (Circular Redondancy Check, anche chiamato FCS, Frame Check Sequence). Con l'aggiunta di un numero limitato di bit ad un pacchetto di dati (chiamato trama, o in inglese frame) si riesce a raggiungere una distanza di hamming di 4, vedi anche 6.

Il CRC è un valore lungo normalmente 16 bit pari al resto della divisione della sequenza di bit contenuta nella trama per un numero costante predefinito. Esistono alcuni CRC standard di cui i più diffusi sono:

3.5.4.3. Protocolli orientati a trame

Questo meccanismo di CRC è utilizzato unicamente nella comunicazione orientata a trame, come il protocollo HDLC ed il suo subset SDLC. Esistono infatti dei chip che preparano la trama e calcolano automaticamente il CRC. Non è infatti pensabile una soluzione SW veramente efficace. Inoltre i protocolli orientati a trame hanno il grosso vantaggio di avere una ridondanza molto limitata: per un pacchetto di dati di lunghezza variabile si ha una ridondanza di soli pochi byte.

La forma delle trame può variare notevolmente. Di solito comunque si ha un identificatore unico di inizio di trama (flag) preceduto unicamente da un'eventuale sequenza di sincronizzazione, alcuni campi che seguono immediatamente il flag di inizio ed il cui contenuto specifica la lunghezza ed il formato della trama, un blocco facoltativo contenente i dati da trasmettere ed il CRC per concludere, seguito unicamente da un flag di fine trama ed un eventuale silenzio di linea obbligatorio, per staccare una trama dalla successiva.

Fig. 23: esempio di trama di comunicazione CAN

3.5.5. Meccanismi di comunicazione

La definizione del formato dei dati che transitano sulla rete non permette ancora un sicuro scambio di dati tra i vari utenti. A questo scopo bisogna anche definire un insieme di regole comuni che definiscono il modo di accedere al bus. Questo insieme di regole, assieme alla definizione del formato delle trame, è chiamato protocollo.Anche per quanto concerne i meccanismi di accesso alla rete vi sono diverse soluzioni di cui illustro di seguito le più usate.

3.5.5.1. Master-slave

Il modo più semplice di stabilire l'accesso è quello di attribuire un ruolo di gestione ad un solo nodo della rete, il maestro o padrone (o in inglese master) che è l'unico ad avere il potere di decidere chi e quando può accedere alla

CRC-16 CRC-CCITT

X+X+X+1 X16+X12+X5+1

rete. Gli altri nodi, chiamati schiavi (in inglese slave) sono in costante ricezione. Nel meccanismo master-slave, generalmente ogni slave ha un proprio identificatore (indirizzo di nodo), per cui di tutta la massa di dati ricevuti, solo quelli destinati allo slave specifico vengono ricevuti (questo filtraggio avviene addirittura a livello HW, in modo da evitare un flusso di dati altrimenti troppo grande). Al momento in cui uno slave riceve un messaggio, nel messaggio stesso è codificata l'informazione che permette o meno allo slave di rispondere. Fintanto che non riceve una esplicita autorizzazione, lo slave non ha il diritto di inviare niente. Normalmente l'applicazione che gira sul nodo master determina la comunicazione da effettuare, inviando dei comandi (trame che partono dal master e sono destinate ad uno slave specifico) alle quali lo slave è invitato a rispondere mandando una risposta. In tal modo circolano sulla rete solo i dati di cui l'applicazione principale e centrale ha bisogno. D'altro canto, per permettere agli slave di inviare dati o eventi propri, spesso si integra un servizio di interrogazione ciclica degli slave, dove il master domanda a intervalli determinati ad ogni slave presente sulla rete se ha dei dati da comunicare. Lo slave, in questo caso, risponde inviando i dati che ha eventualmente da mandare o indicando che non ha nulla. Questo meccanismo è chiamato poll o cyclic polling. La comunicazione master-slave presenta l'indubbio vantaggio di garantire che non vi siano problemi di accesso al bus, in quanto l'accesso stesso è sorvegliato dal master. Anche il flusso dei dati, per un'applicazione principale centralizzata, è ottimale. Gli svantaggi imputati a questa struttura sono però legati alle limitazioni imposte. La comunicazione può avvenire solo tra il master e gli slaves, e mai tra altri nodi. Non è quindi adatta a soluzioni di intelligenza decentralizzata. Inoltre se il master ha un guasto, non c'è più nessuna comunicazione. A seconda delle applicazioni, vi sono comunque delle variazioni di questa struttura. Esistono soluzioni di master alternativo che, in caso di panne di quello principale, individuata grazie ad una mancanza di comunicazione per un determinato tempo, interviene sostituendosi a quello originario. Anche le forme di comunicazione sono state estese per permettere l'invio di un messaggio dal master a più slaves simultaneamente (broadcast). Ovviamente in questo caso nessuno dei destinatari è autorizzato a rispondere.

Esempio di bus di campo: BITBUS.

3.5.5.2. Multi-master

Altre reti si basano su protocolli multi-master. Queste reti si distinguono da quelle master-slave proprio perché chiunque sulla rete ha il diritto di inviare messaggi quando ne ha voglia. Un nodo non può comunque emettere le proprie informazioni quando un altro sta già trasmettendo. Tuttavia, quando sulla rete non circola nulla, possono esserci due o più nodi che iniziano a trasmettere simultaneamente. Per risolvere l'accesso in caso di collisione, esistono diverse soluzioni. La prima, adottata su Ethernet, si chiama CSMA/CD (Carrier Sense Medium Access/Collision Detection) che, come il suo nome lo indica, verifica che il medio fisico sia libero per inviare dati, ed in caso di collisione è in grado di individuarla. In quest'ultimo caso, i nodi che hanno causato la collisione sospendono immediatamente l'invio ed aspettano per un tempo variabile e casuale. Dopodiché riprovano. Dato che la durata del tempo è causale, difficilmente si riproduce di nuovo una collisione. Tuttavia la rete non può venir sfruttata in modo troppo intensivo, in quanto aumentano sensibilmente le probabilità di collisione che, malgrado tutto se frequenti, rallentano tutta la comunicazione. Si parla di un tasso di sfruttamento pari a circa il 30%, quale soglia di accettabilità!

Il vantaggio principale di questo accesso sta nel fatto che chiunque può comunicare con chiunque. In tal modo non si dipende più da un nodo nevralgico e l'applicazione può essere distribuita in modo uniforme (ed anarchico). Tuttavia, proprio per il rischio di intasamento della rete, questa tecnica è usata solo marginalmente nel settore dei bus di campo, in quanto le applicazioni in tempo reale non possono permettersi delle attese imprevedibili.

L'alternativa al CSMA/CD è l'accesso CSMA/CA (Carrier Sense Medium Access/Collision Avoiding). Rispetto al primo, l'accesso CSMA/CA è in grado di riconoscere una collisione e risolverla in favore del messaggio avente la priorità superiore. Questo proseguirà la trasmissione senza dover ripetere nulla, mentre che l'emittente che stava mandando il messaggio con priorità meno importante aspetterà la fine per poter accodare immediatamente dopo la propria trama.

Esistono già un paio di bus di campo che sfruttano questa proprietà. I vantaggi sono notevoli, dato che la rete può essere caricata maggiormente. Inoltre in tal modo si ottiene una flessibilità totale e, grazie ai livelli di priorità dei messaggi, è possibile distribuire in modo adeguato alle esigenze le risorse di rete.

Esempio di rete CSMA/CD: Ethernet. Esempio di bus di campo con CSMA/CA: CAN.

3.5.5.3. Token passing

Una specie di compromesso è stato raggiunto mediante il metodo di token passing (passaggio del testimone). Le reti che sfruttano questo principio hanno sì più master, ma solo uno di essi è attivo in ogni momento. In tal modo la comunicazione viene eseguita sempre secondo il meccanismo master-slave, ma il master attivo può cedere il testimone ad un altro master (che quando non è attivo reagisce come slave). La cessione del testimone può avvenire in modo voluto, ciclico, o in caso di panne del master attivo. In quest'ultimo caso un altro master è configurato per intervenire automaticamente.

Data la soluzione ibrida, il compromesso permette delle buone prestazioni. Tuttavia non si profila sempre come soluzione ideale per le applicazioni che, anch'esse, devono essere concepite in modo ibrido: ad una gestione centrale si alterna una distribuita. Inoltre la libertà di comunicare liberamente tra i nodi è limitata ai soli potenziali master e solo quando ottengono il token.

Esempio di bus di campo: PROFIBUS.

3.5.5.4. Altri meccanismi

Ci sono poi diverse altre soluzioni specifiche ad alcuni bus. Queste soluzioni sfruttano una caratteristica fisica del bus (esempio: bus ad anello), dell'applicazione o di entrambe per trarre un maggior profitto dalle risorse impiegate. Generalmente sono utilizzate delle soluzioni specifiche per tutti i bus cosiddetti deterministici, ovvero che permettono un calcolo e garantiscono un certo tipo di accesso nel tempo. Questa nozione è indispensabile per realizzare delle applicazioni distribuite ma sincroni.

Esempi di bus di campo: Interbus-S, Sercos, Fip, ecc.

3.5.6. Scambio di dati

Dal punto di vista elettrico e fisico con quanto descritto nei paragrafi precedenti si ha una panoramica abbastanza completa delle soluzioni usate nella pratica. All'utente normale, comunque, la maggior parte di questi argomenti interessa solo marginalmente. La cosa più importante da sapere è quella di cosa ed in che modo si può trasmettere. Lo scambio di dati si basa su alcuni servizi (livello 7 del modello OSI) previsti dai singoli sistemi di comunicazione. Qui di seguito ne vengono presentati alcuni.

3.5.6.1. Messaggistica

Uno dei servizi più semplici ma più pratici è lo scambio di messaggi. Un messaggio utilizza una buona parte o tutto il campo dei dati di una trama e permette all'applicazione di inserirvi i dati liberamente. Il contenuto sarà trasferito e consegnato all'applicazione remota senza essere interpretato o manipolato. Questo servizio di comunicazione è particolarmente utile per lo scambio di informazioni generiche tra applicazioni distribuite in cui l'utente stesso sceglie cosa inviare.

3.5.6.2. Client-Server

La struttura client-server è assai diffusa nel mondo informatico e non necessita di grandi spiegazioni. In pratica si tratta di una chiamata di servizi remota. Permette il controllo di servizi distribuiti prestabiliti. L'applicazione passa tutt'al più solo qualche parametro e riceve in cambio la risposta desiderata.

3.5.6.3. Accesso a variabili e memoria remote

Un servizio molto diretto è quello che permette la lettura e la scrittura di variabili o zone di memorie su nodi remoti. In questo caso il nodo remoto è spesso non intelligente, ovvero non programmabile con una applicazione propria. Tuttavia il servizio di accesso alle variabili è anche messo a disposizione su sistemi intelligenti quale mezzo di verifica e debug.

3.5.6.4. Download e upload

Un servizio molto utile per un'applicazione distribuita è quello del download. Con esso è possibile redigere un nuovo programma di applicazione e scaricarlo nel nodo remoto direttamente attraverso la rete che lo collega. Inversamente, grazie al servizio di upload, è possibile collegarsi al nodo attraverso la rete e leggere il programma contenuto nel nodo.

I servizi di download ed upload sono anche usati a volte per il trasferimento di dati o zone di memoria, oltre che per i programmi veri e propri, specialmente quando si deve trasferire dei blocchi importanti di dati.

Questi servizi, a differenza di quelli visti sopra, sono meno critici nel tempo, in quanto al momento della loro esecuzione l'applicazione non è normalmente attiva. Inoltre una sequenza di download usa diverse trame ed è implementata in modo da garantire il trasferimento corretto, anche se spezzettato su più invii.

3.6. La piramide CIM Abbiamo visto che esistono numerosi bus di campo dalle caratteristiche più svariate. Prima di scegliere un sistema è quindi indispensabile fare un'analisi del tipo di applicazione che si vuole realizzare, in modo indipendente da ogni influsso economico, politico e di parte. Ovviamente l'aspetto commerciale rimane importante e di difficile astrazione. Tuttavia, almeno in una prima valutazione, dovrebbe essere messo in secondo piano.

In una fabbrica o un'unità di produzione esistono vari livelli di trattamenti dei dati. Ad ogni livello le esigenze sono ben distinte: a livello gestionale (nel campo degli uffici) la quantità di dati trattati attraverso le reti informatiche è enorme, dell'ordine di grandezza di diversi megabyte. Tuttavia i tempi di risposta non sono per nulla critici, in quanto si situano facilmente tra i qualche minuti, fino a ore o addirittura giorni (i backup, per esempio, sono effettuati una volta al giorno; l'invio di un rapporto al proprio superiore può anche tardare qualche ora senza causare problemi particolari, ecc.).

Se si scende nel campo della produzione dove si trovano appunto i bus di campo, le cose sono ben distinte. A livello di una cella di produzione, per esempio, si gestisce sì numerosi messaggi di lunghezza importante, ma dato che servono principalmente a raccogliere i dati di produzione e sincronizzare i vari apparecchi presenti, i tempi di reazione sono dell'ordine di qualche decina di millisecondi. Un ritardo superiore causerebbe una diminuzione della produttività che si ripercuoterebbe sensibilmente sul rendimento della fabbrica! Scendendo ancor più in basso nella catena, troviamo dei bus che trasferiscono solo pochi byte, ma che devono farlo in sole poche decine di microsecondi!

Queste differenze costituiscono un primo ed importante criterio di scelta del tipo di bus di campo da adottare. In effetti i due parametri tempo e quantità dei dati sono generalmente conosciuti per una specifica applicazione, anche se non si integra in un contesto così ben strutturato e completo come quello rappresentato dal modello a piramide CIM.

Fig. 24: struttura della piramide CIM

Questa rappresentazione ideale serve unicamente di riferimento. In realtà, specialmente presso le ditte locali di piccola e media dimensione, l'integrazione è ancora lontana dall'essere realizzata. Le necessità stesse di integrazione sono solo parziali, dato che la taglia delle installazioni non raggiunge che raramente la massa critica sufficiente a giustificare provvedimenti in tal senso. Tuttavia localmente ed in modo circoscritto alcune applicazioni richiedono già una struttura modulare basata su di un sistema di comunicazione. Inquadrando il problema nell'ottica della piramide CIM si mira ad una scelta tecnica razionale che nel futuro può permettere un'estensione riducendo al minimo i problemi di integrazione del sistema in un contesto più ampio.

3.7. Schedatura dei diversi sistemi di comunicazione Tralasciando i bus di cella peraltro poco diffusi, è pratica comune classificare sotto l'insegna di "bus di campo" praticamente tutti i bus di comunicazione industriali. Tra i diversi bus di campo esistenti ci sono però delle variazioni anche importanti delle caratteristiche. Una suddivisione più specifica dei bus di campo si rende quindi necessaria. I Tedeschi nel loro vocabolario distinguono già due classi di bus di campo:

Feldbus: i bus di campo veri e propri Sensor-Aktor-Bus: i bus di campo del livello più basso, che chiamerò in seguito bus sensori/attuatori

Questa suddivisione permette effettivamente di distinguere abbastanza bene le due categorie principali di bus di campo. Si potrebbe affiancare a queste una terza categoria che raggruppi i bus di campo speciali, destinati a causa delle loro caratteristiche specifiche ad applicazioni ben precise: la categoria dei bus dedicati. Ovviamente anche in presenza di tre categorie distinte la classificazione dei vari bus di campo non è sempre evidente, in quanto le caratteristiche di ogni bus hanno qualcosa di specifico ed i servizi disponibili sconfinano spesso tra le diverse categorie.

3.7.1. I bus di cella

La classifica di tutti i bus di comunicazione industriali dovrebbe iniziare dai bus di cella. Dato però che questi non fanno parte dei bus di campo e sono oltretutto abbastanza poco diffusi, mi limiterò a presentare solo qualche considerazione succinta.

Uno dei bus più diffusi a questo livello della gerarchia è il MAP. Questo bus utilizza come mezzo fisico l'Ethernet. Le caratteristiche principali del sistema sono il servizio di messaggistica messo a disposizione delle applicazioni e la definizione di una macchina virtuale che permette di rappresentare una macchina qualunque ed i suoi accessi, facilitando così la comunicazione tra le macchine reali. A questo livello si sincronizzano le diverse aree di produzione. Dato che in Svizzera la dimensione delle industrie è relativamente piccola, a parte quella di un numero sempre più piccolo di grandi ditte, la ragione d'essere di questo livello gerarchico della piramide è spesso messo in causa. Una soluzione alternativa abbastanza frequente è rappresentata dall'estensione della rete informatica del livello superiore, con per esempio il protocollo TCP/IP su Ethernet, collegata a dei PC industriali che svolgono il ruolo di gateway verso i livelli inferiori. In questo caso, tuttavia, è consigliato di separare il segmento di rete dell'officina da quello degli uffici mediante un bridge, in modo da separare il traffico di comunicazione delle due aree e renderle indipendenti l'una dall'altra.

3.7.2. I bus di campo

Questa categoria di sistemi di comunicazione raggruppa i bus che permettono l'invio di trame della dimensione variante tra qualche decina di byte fino a 256 byte. Al livello gerarchico coperto dai bus di campo i tempi di reazione si situano generalmente nell'ordine di qualche decina di millisecondi. Il ruolo fondamentale dei bus di campo è quello di collegare tra loro diverse unità intelligenti che collaborano nell'esecuzione di un lavoro comune. Per questa ragione i tempi di risposta richiesti sono più critici di quelli del livello gerarchico direttamente superiore. Dato che diversi nodi cooperano all'esecuzione di un lavoro comune, nella maggior parte dei casi uno di questi nodi si occupa della coordinazione globale e ripartizione dei compiti. Per questa ragione i bus di campo hanno spesso una gerarchia master-slave o vengono utilizzati in tal modo. Il master dirige le operazioni e la comunicazione interrogando ciclicamente gli slaves. Questi ultimi hanno diritto a rispondere unicamente quando master lo permette loro esplicitamente. In questo modo la comunicazione è ben organizzata e non prevede problemi dovuti a collisioni, dato che queste non si presentano mai. Questa struttura piuttosto rigida ha un tallone d'Achille: se il master ha un guasto non funziona più niente! I bus di campo più recenti quali il Profibus FMS o il nuovo Bitbus (IEEE-1118) prevedono la possibilità volontaria o automatica di passaggio del testimone del master ad un altro nodo della rete. Un bus di campo può pure essere impiegato per coprire anche una parte del livello gerarchico superiore, specialmente in un contesto di ditta dalle dimensioni assai contenute. Diventa però importantissimo valutare ed ottimalizzare la quantità dei dati da trasmettere, in modo da evitare un sovraccarico della rete. Inoltre ciò rischia di compromettere una estensione degli impianti, in quanto il carico della rete risulterebbe facilmente già ai limiti dell'accettabile. D'altra parte praticamente tutti i bus di campo offrono la possibilità di accedere direttamente alle risorse del livello gerarchico inferiore, quali le entrate ed uscite digitali o analogiche di un PLC. Sebbene questi accessi siano dedicati in particolare alla messa in servizio e manutenzione degli impianti, vengono spesso utilizzati anche per coprire parzialmente o interamente il livello gerarchico inferiore, quello dei sensori/attuatori. Anche qui è indispensabile valutare un simile impiego, per evitare di ritrovarsi con un impianto la cui capacità di reazione a segnali provenienti da sensori distribuiti sia insufficiente. Inoltre ciò implica che si presti particolare attenzione affinché il carico della rete sia tenuta ad un livello il più basso possibile, in modo da reagire sufficientemente svelto ad un cambiamento di stato di uno di questi segnali.

3.7.3. I bus "sensori/attuatori"

I bus sensori/attuatori hanno quale compito quello di collegare nodi con intelligenza limitata o nulla tra loro a ad un nodo centrale in modo da permettere a quest'ultimo di elaborare i dati più elementari quali gli stati delle entrate o delle uscite alle quali sono collegati dei sensori i degli azionatori. L'applicazione classica in questo senso è quella dei PLC muniti di moduli di entrate/uscite analogiche e/o digitali decentralizzati. Colui che deve occuparsi di programmare il PLC, in questo caso, non ha generalmente mai da preoccuparsi della comunicazione. Il firmware o il sistema operativo del PLC integra già tutta la problematica legata all'acquisizione dei dati decentralizzati, accessibili dal programma del PLC attraverso delle variabili di sistema. Per la realizzazione di questa struttura una gerarchia master-slave può essere valida. Per permettere un migliore sfruttamento delle risorse di comunicazione, però, al posto di un polling continuo da parte del master di tutti gli slave, ci sono soluzioni orientate ad eventi: ogni nodo ha il diritto di accedere alla rete quando lo ritiene opportuno, in particolare modo per segnalare delle

modifiche di stati delle proprie variabili. In questo modo la comunicazione è veramente ridotta all'indispensabile e permette quindi delle prestazioni superiori, anche con una cadenza inferiore a quella di un sistema master-slave. In ogni caso le velocità di trasmissione utilizzate sono superiori a quelle dei bus di campo, mentre che la lunghezza delle trame è ridotta. Il fatto di sfruttare delle cadenze più rapide per la comunicazione è anche legato al fatto che le distanze da coprire sono nella maggior parte dei casi abbastanza limitate. Le soluzioni adottate per ogni bus di questa categoria sono molto variate al punto da determinare caratteristiche specifiche ad ogni sistema. Il confronto tra di essi risulta difficile proprio per mancanza di punti comuni. A seconda dell'applicazione un sistema può essere più idoneo di un altro, mentre che per un'altra applicazione è l'inverso.

In alcuni casi è pure possibile utilizzare uno di questi bus per realizzare anche funzioni tipiche dei bus dell'ordine superiore, dei bus di campo, per esempio per collegare assieme più macchine. Questo impiego rischia però di far calare notevolmente le prestazioni del sistema. Inoltre ci si può ritrovare ben presto con un carico di rete troppo importante che frena il flusso dei dati più critici nel tempo.

3.7.4. I bus dedicati

Questa categoria di bus potrebbe ben evidentemente essere suddivida ulteriormente, in particolare in base ai campi di applicazione a cui sono dedicati i vari bus. Ciò comporta però il rischio di creare una categoria per bus o delle categorie raggruppanti un solo bus... D'altra parte quando parlo di bus dedicati non voglio parlare delle soluzioni proprietarie lanciate sul mercato da singoli produttori (e purtroppo ve ne sono un gran numero...). Il mio intento è quello di citare dei bus sviluppati appositamente per delle applicazioni specifiche, come è il caso dell'IEEE-488 per gli strumenti di misura, per esempio (si noti tuttavia che questo bus non può essere schedato come bus di campo). Ecco allora alcuni campi di impiego di tali bus che, come si vede, coprono temi molto variati:

il controllo di movimentazioni e posizionamenti, in particolare per il controllo in posizione dei motori di assi di macchine utensili l'illuminazione degli stabili, dove le informazioni che circolano sono piuttosto limitate ma dove è indispensabile mantenere un prezzo per nodo assai basso l'automazione di veicoli, campo di origine del CAN ed altri bus la tecnica di misura e di test il settore militare e dell'aviazione che hanno di per sé delle esigenze di sicurezza ancora più spinte ecc.

La varietà di settori in cui si impiegano i bus di campo lascia immaginare che effettivamente ogni sistema di comunicazione, anche nelle altre categorie di bus, ha un suo campo di applicazione in cui è migliore di tutti gli altri. I produttori e sostenitori di alcune soluzioni che affermano che il "loro" bus è universale e può essere impiegato per tutte le applicazioni di tutti i livelli gerarchici sono quindi sicuramente poco credibili. D'altra parte, chi per realizzare un bus dedicato ad un tipo di applicazione ne prende uno standard e lo adatta o lo impiega senza accorgimenti particolari per questo suo nuovo compito rischia di non raggiungere il livello qualitativo desiderato e quindi fornire un funzionamento di impianto insoddisfacente per il proprio cliente...

Write me

4. Caratteristiche principali di qualche bus di campo

4.1. Il Bitbus Questo bus dovrebbe avere diritto ad una attenzione tutta particolare in ogni presentazione concernente i bus di campo. Il suo merito non è quello di essere migliore di tutti gli altri (lo abbiamo appena visto, non esiste il bus perfetto), ma piuttosto di essere il primo dei sistemi di comunicazione industriali accessibile a tutti. In effetti, nella storia dei bus di campo, esistevano già ben prima del Bitbus numerose soluzioni proprietarie. Il settore automobilistico ne era il principale artefice, sviluppando da tempo delle soluzione orientate principalmente a migliorare la produttività ed il grado di automazione dei propri impianti. Ma proprio per questa ragione, per mantenere una distanza di vantaggio rispetto alla concorrenza, le soluzioni realizzate non venivano divulgate e, sebbene se ne fosse tutti a conoscenza, non era possibile ottenere né componenti, né supporto nello sviluppo. Così ognuno sviluppava la propria soluzione, in modo che ogni marca automobilistica aveva il proprio sistema. Il Bitbus è stato concepito dalla Intel in collaborazione con altre ditte all’inizio degli anni ’80 quale sistema aperto. Le sue specifiche furono pubblicate nel 1983. Su questa base la Intel sviluppò un chip integrante tutte le funzionalità della comunicazione, offrendo così per la prima volta a chi doveva sviluppare interfacce di comunicazione un accesso molto semplice a questa tecnologia. Questo aspetto ha fatto sì che la sua diffusione è stata immediata e vastissima, a livello mondiale. Ancora oggi lo si può considerare sul podio dei bus più utilizzati al mondo, con i suoi milioni di nodi installati dovunque. Nel 1991 una commissione internazionale ha convertito questo standard de-facto in una norma, la IEEE-1118, aggiungendo qualche nuova caratteristica che non ha comunque compromesso la piena compatibilità con apparecchiature già presenti sul mercato e basate sulle specifiche Intel.

Malgrado sia il più anziano bus di campo aperto, si basa su di una tecnologia a quei tempi avanguardista ed ancora oggi sulla cresta dell’onda grazie alle reti di comunicazione informatiche e telefoniche digitali: il protocollo SDLC. Le caratteristiche principali del Bitbus possono essere riassunte come segue:

norma IEEE-1118 struttura master-slave (un master; con la nuova norma possibilità di passaggio del testimone del master ad un altro nodo) messaggi della dimensione di fino a 248 byte di dati utili trasmissione a 62,5 o 375 kbit/s (esistono versioni che vanno fino a 2 Mbit/s) distanze fino a 13,5 km per segmento, a 62,5 kbit/s, o 1200 m a 375 kbit/s mezzo fisico RS-485 con cavo a doppino attorcigliato (preferibilmente blindato) una interfaccia di applicazione definita (funzioni RAC = livello 7 del modello OSI) possibilità di broadcast e multicast di messaggi dal master verso tutti o un gruppo di slave (secondo le nuove norme) possibilità di inserire fino a 2-3 repeater in cascata diffusione a livello mondiale

4.2. L’Interbus-S L’Interbus-S è stato creato dalla ditta tedesca Phoenix Contact. Questa è specializzata nella fabbricazione di morsettiere. Grazie alla sua esperienza in questo settore ha voluto contribuire a semplificare la vita ai montatori elettricisti, realizzando un sistema di comunicazione che permetta una riduzione massiccia dei cavi senza complicare l’esistenza a chi deve occuparsi della messa in servizio. Partendo da questo presupposto non poteva che nascere un bus del livello più basso, del tipo sensori/attuatori. Il concetto di base di questo bus, che possiede caratteristiche uniche nel suo genere, è simile ad un registro di shift ben conosciuto in elettronica. In effetti l’Interbus-S può essere visto come un grande anello in cui il master si occupa di spostare di un numero di bit corrispondente alla taglia della rete una trama contenente tutti gli stati delle uscite. Questi, transitando attraverso i nodi, sono sostituiti dagli stati delle entrate, al momento in cui attraversano il nodo corrispondente. Il vantaggio di questa architettura è proprio quello di aggiornare ciclicamente tutte le entrate e tutte le uscite, con un tempo di ciclo calcolabile esattamente in base alla dimensione della rete (numero di nodi e numero di entrate/uscite). Come la Intel ha fatto con il Bitbus, la Phoenix Contact ha capito ben presto che l’unico modo di diffondere rapidamente e

con un certo successo il suo sistema era quello di offrire un supporto a chi sviluppa le interfacce. Anche questa ditta, quindi, ha sviluppato un chip integrante tutta la funzionalità del bus. L’altro passo obbligato, per evitare di ritrovarsi con una soluzione proprietaria, è stato quello di affrettarsi a trovare chi era ben disposto a convertire in norma tale protocollo. Attualmente il bus è anche conosciuto sotto lo standard DIN 19258.

In poche parole ecco le caratteristiche fondamentali di questo bus:

norma DIN 19258 struttura master-slave (un solo master) grande capacità di estensione della rete (fino a 13 km), dovuta alla rigenerazione del segnale tra ogni nodo (in pratico ogni nodo è anche repeater) distanze tra due nodi fino a 400 m interfaccia verso l’applicazione definita (memoria-copia degli stati delle entrate/uscite) slave principalmente senza intelligenza mezzo fisico RS-485, con andata e ritorno dell’anello nello stesso cavo trasmissione a 500 kbit/s fino a 4096 entrate/uscite collegabili ad un anello diffusione principalmente in Europa

4.3. Il CAN Il CAN è interessante a causa della sua origine, ma anche per via delle sue caratteristiche. Iniziamo dalla sua origine: il CAN è stato concepito dalla Bosch tra il 1983 ed il 1985 con lo scopo di ridurre fortemente il cablaggio all’interno stesso dei veicoli (automobili e camion). L’idea di base consisteva nell’ottimalizzare la comunicazione in modo da ottenere una flessibilità totale. Non si voleva dover realizzare una tipica e scomoda struttura master-slave, ma nel contempo si doveva poter garantire l’invio di informazioni critiche, per esempio riguardanti una frenata. L’idea che ne è scaturita è quindi stata quella di identificate il contenuto dei messaggi, piuttosto che non i nodi di destinazione. In tal modo un nodo qualunque può essere collocato per generare un determinato messaggio (chiamato oggetto) che viene trasmesso a tutti gli altri. Chi degli altri ha bisogno di tale informazione permette al messaggio di entrare. Nel caso contrario lo ignora semplicemente. Esiste addirittura la possibilità di filtrare tale informazione in modo da permettere l’entrata unicamente dei messaggi che si attende, mentre che quelli non desiderati vengono occultati. Chi accetta un messaggio può reagire di conseguenza, senza tuttavia essere obbligato a rispondere. Questa grande libertà di accesso permette di ridurre la comunicazione limitandola alla trasmissione indispensabile, per cui garantisce delle caratteristiche veramente apprezzabili. D’altra parte l’accesso multi-master pone un problema di collisione se due nodi cominciano a trasmettere simultaneamente. La Bosch ha risolto questo problema in modo molto elegante: ogni messaggio è identificato da un numero trasmesso in inizio di trama. I messaggi con numero più basso hanno una priorità più elevata. In caso di collisione, solo il nodo che sta trasmettendo il messaggio di priorità più bassa se ne accorge e sospende momentaneamente la trasmissione, mentre che l’altro nodo può proseguire senza dover ripetere nulla (CSMA/CA). Le caratteristiche necessarie nel settore automobilistico hanno spinto a realizzare questo bus orientato verso il livello basso dei sensori/attuatori. Per questa ragione i messaggi CAN hanno una dimensione massima di 8 byte di dati. La Bosch si è alleata con la Intel per realizzare fisicamente questo bus. Assieme hanno sviluppato un chip che integra tutta la comunicazione. Da allora, sotto licenza, un numero impressionante di produttori di componenti elettronici offre dei chip con interfaccia CAN. Esistono sia chip di interfaccia, da collegare quale periferici ad un processore, sia processori con interfaccia CAN integrata, sia circuiti integranti tutta la funzionalità ed in grado di lavorare da soli (moduli di entrate/uscite autonomi). Purtroppo l’interfaccia utente è libera. Si può dunque utilizzare il CAN pur mantenendo un protocollo proprietario. D’altro canto, però, esistono diverse specifiche standard che permettono di realizzare delle installazioni con prodotti di diversi fornitori.

Le altre caratteristiche principali sono:

norma ISO 11898 struttura multi-master ad accesso multiplo trasmissione standard a 20 kbit/s trasmissioni possibili: fino a 1 Mbit/s difficoltà di inserire dei repeater

capacità di estensione limitata (40 m con 1 Mbit/s, 1 km con 50 kbit/s) mezzo fisico simile all’RS-485 con cavo a doppino attorcigliato (preferibilmente blindato) 2048 livelli di precedenze dei messaggi error handling interamente realizzato nei chip vari standard di interfaccia verso l’applicazione grande sicurezza di trasmissione ed immunità alle perturbazioni diffusione mondiale

4.4. Il Sercos Il Sercos fa parte della categoria di bus di campo dedicati ad applicazioni specifiche. È stato concepito da un istituto tedesco con lo scopo di ridurre il cablaggio dei motori ed offrire nel contempo un’interfaccia standard per il controllo degli stessi. A differenza di altri bus che permettono il controllo di movimenti, il Sercos è orientato alla fetta di mercato delle macchine utensile, laddove la sincronizzazione degli assi è essenziale. Si tratta di uno dei più recenti bus (è stato presentato nel 1989) e permette l’interpolazione di fino ad 8 assi simultaneamente. La sincronizzazione avviene attraverso il bus. Un numero di nodi superiore può tuttavia essere collegato, per esempio per integrare anche parte dei periferici del PLC, quali le entrate ed uscite. La sua topologia è ad anello, in quanto la connessione tra i nodi avviene mediante una fibra ottica unidirezionale, per permettere delle trasmissioni estremamente rapide. Il bus prevede un’interfaccia verso l’applicazione completa di numerosi parametri di configurazione che lo rendono un po’ complesso ma completo per lo scopo per il quale è stato ideato.

Anche per questo bus è stato sviluppato un chip e la sua diffusione, considerando la sua giovane età, è tutt’altro che limitata.

Le caratteristiche fondamentali del Sercos sono:

norma IEC 1491 struttura master-slave topologia ad anello mezzo fisico rappresentato da una fibra ottica indirizzamento possibile di fino a 254 slave lunghezza dei segmenti di linea fino a 60 m per una fibra ottica sintetica (250 m se la fibra ottica è di vetro) trasmissione a 2 o 4 Mbit/s accesso al bus tramite finestre di tempo predefinite diffusione ancora limitata ma in forte espansione (attualmente principalmente in Europa)

5. Evoluzioni future

Come abbiamo visto, esiste un numero impressionante di bus di campo, di cui ne ho citato solo una minima parte. Sebbene tutti siano più o meno standardizzati, nessuno si profila in modo abbastanza forte all’interno della sua categoria per prendere sopravvento sui suoi rivali... Se si fa un confronto con le reti informatiche, si nota che in questo campo c’è una tendenza generale a convergere verso il protocollo TCP/IP su Ethernet. Come mai, dunque, le applicazioni industriali non convergono in modo analogo su di un numero limitato di soluzioni? Le ragioni attuali vanno anche cercate nella grande diversità delle applicazioni che si riscontra in quest’ambito, per cui un bus è preferito in un contesto, mentre che in un altro cede il posto ad un altro. Spesso però, non sono gli argomenti tecnici ad imporre una scelta, quanto più aspetti commerciali ed anche politici. Nel settore dei bus di campo, per esempio, il nazionalismo è ancora molto forte: la Germania trionfa con vari bus tra i quali troviamo il Profibus che ha beneficiato largamente di sussidi statali volti a diffonderlo. In Francia il FIP ha un posto preferenziale rispetto ad altri. Gli Americani, dal canto loro, provano con un marketing abbastanza aggressivo a divulgare il LON.

In questa battaglia, che si è tuttavia attenuata specialmente negli ultimissimi anni, non è emerso nulla di buono. L’unico spiraglio che taluni sperano si avveri, rifacendosi al detto che "tra i due litiganti il terzo se la gode", è quello di una nuova soluzione che soppianti tutte quelle correnti. Lo sviluppo di un nuovo bus, se non realizzato da

un colosso industriale che possa imporlo su vasta scala, difficilmente avrà possibilità di essere avviato.

Guardando cosa avviene nel mondo dei PC, la creazione del USB (Universal Serial Bus) quale bus unico per collegare tutte le periferiche del PC all’unità centrale potrebbe apportare qualcosa di nuovo nel mondo dei bus di campo. Il boom che conoscono i PC da qualche anno a questa parte ha causato una caduta dei prezzi dei componenti usati in tale settore, per cui un nuovo sistema di comunicazione realizzato ed utilizzato da tutti in quest’ambito potrebbe essere "portato" nel contesto dei bus di campo e rappresentare una nuova soluzione a bassissimo costo ed alte prestazioni. Occorrono però ancora alcuni anni prima di vedere se questa tecnica può effettivamente essere usata anche al di fuori dell’ambito PC, sia per aspetti puramente tecnici che per motivi di disponibilità ed interesse delle persone coinvolte.

Ci sono però già diverse persone che sostengono intravedere un potenziale di applicazione di un altro sistema di comunicazione già diffusissimo nell’ambito dei PC: il protocollo TCP/IP usato nel settore dell’automazione utilizzando i suoi servizi di livello più basso, conosciuti sotto la designazione di socket BSD! Come mai questo sistema di comunicazione, se effettivamente adatto a tale scopo, appare solo adesso nei dispositivi di automazione quali i PLC? Ci sono due ragioni fondamentali: il TCP/IP è largamente diffuso sulle reti informatiche e, da qualche anno, sempre più anche sui computer di piccola dimensione quali i PC. D’altra parte proprio l’architettura PC sta varcando la soglia dell’officina, dove un sempre maggior numero di PC industriali viene impiegato. La loro presenza favorisce in modo naturale la presenza di una rete Ethernet con TCP/IP in tale ambiente. L’altro argomento ha un carattere più tecnico: il protocollo TCP/IP richiede una potenza di elaborazione che solo processori di una certa capacità possono consacrare, specialmente se si vuole sfruttare i diversi servizi disponibili. In parallelo, quindi, per questo protocollo risulta necessario disporre di più memoria. Questi due aspetti, fino a poco tempo fa, erano abbastanza critici per delle apparecchiature di automazione, basate per lo più su microcontrollori limitati e memorie statiche ridotte. Grazie alla caduta vertiginosa dei prezzi ed alla parallela ascesa delle capacità di calcolo e memorizzazione, dal punto di vista tecnico non vi sono più argomenti che possano impedire l’implementazione del TCP/IP anche in apparecchi finora non predisposti a questo tipo di comunicazione.

Un’evoluzione in questa direzione permetterebbe di facilitare un’integrazione completa di tutti i sistemi di comunicazione. Per il TCP/IP esistono sufficientemente componenti di comunicazione, quali repeater, bridge, router e splitter per separare a dovere i diversi segmenti di rete ed isolare così le diverse comunicazioni.

Comunque, il prezzo di queste soluzioni rimane attualmente ancora abbastanza elevato. In più vi è un rischio abbastanza grande di veder realizzare reti senza le dovute sicurezze di protezione dei dati, di isolamento dei segmenti e di segretezza reale, dato che sempre più spesso queste reti sono collegate tra loro, in particolare attraverso Internet. Il calcolo stesso del carico di rete non è così semplice. Insomma, rispetto a molti bus di campo, con TCP/IP non basta tirare un cavo tra i nodi e credere che tutto funzioni a dovere, senza problemi.

Fig. 25: confronto tra il modello TCP/IP ed il modello OSI

Il ricorso a TCP/IP quale bus di campo è quindi destinato sin dall’inizio a scomparire? Non lo credo per nulla. Rimango comunque dell’idea che una soluzione unica per più livelli gerarchici, come già scritto più volte nelle pagine precedenti, non potrà mai essere valida, salvo, come è possibile con il TCP/IP, se i vari livelli gerarchici vengono separati a dovere mediante router e se i servizi impiegati sono confacenti al livello gerarchico in cui si situano le apparecchiature collegate alla rete. Questo comunque richiede grande coscienza nello sviluppare nuovi dispositivi e nuove installazioni.

Tutto ciò non mi impedisce di affermare che i bus attualmente disponibili hanno davanti a loro ancora ampi spazi da contendersi per un futuro ancora abbastanza lungo e sicuro, tale da garantire loro addirittura una ulteriore crescita, mentre che la nascita di nuovi standard dovrebbe limitarsi a settori ed applicazioni specifici. Difficilmente intravedo la possibilità di concepire un nuovo prodotto atto a fare diretta concorrenza ai bus esistenti.

6. Conclusioni

Abbiamo visto che esistono diverse categorie di bus di comunicazione (non solo di bus di campo) ordinate gerarchicamente in base al volume di dati che permettono di trasmettere, rispettivamente in base ai tempi di risposta tipici:

livello 0: bus sensori/attuatori livello 1: bus di campo livello 2: bus di cella o di officina livello 3: reti informatiche (LAN) livello 4: reti informatiche a grandi distanze (WAN)

I livelli 0, 1 e 2 coprono il settore industriale nel quale si situano i bus di campo, in particolare ai livelli 0 ed 1. In una categoria parallela si trovano inoltre ancora i bus dedicati a compiti specifici. Malgrado questa classificazione sistematica, ciò che si scopre analizzando le caratteristiche di un bus appartenente ad una categoria specifica è proprio che il limite separante una categoria dall’altra è piuttosto fosco e dipende fortemente anche dall’applicazione che si desidera realizzare, e non solo dal bus scelto. Benché la tentazione di adottare un bus unico in grado di coprire più livelli gerarchici sia forte, riveste una capitale importanza la valutazione oggettiva di ciò che si desidera realizzare. È evidente che il metodo di classificazione secondo i criteri della piramide CIM (quantità dei dati e tempi di reazione) non si adatta sempre ed in ogni caso, specialmente perché nella maggior parte dei casi una struttura a più livelli non si presenta neanche. Tuttavia esso costituisce l’unico strumento neutro di valutazione. Come è stato accennato nell’introduzione, i bus di campo non sono impiegati unicamente con lo scopo di automatizzare una parte di una catena produttiva, ma sono applicati in misura sempre maggiore in tutti i campi. Ne cito alcuni quali la tecnica degli impianti negli stabilimenti ("domotica"), le installazioni di sicurezza, ma anche il controllo di antenne e ripetitori radiotelevisivi, installazioni di misura di ogni tipo, le casse automatiche dei posteggi sotterranei, i semafori, impianti di illuminazione e sorveglianza in opere quali le gallerie ed i ponti, eccetera. In breve si può dire che i bus di campo sono utilizzati in quasi tutti i campi (appunto!). Proprio per questo diventa indispensabile acquisire le nozioni tecniche di base adeguate, per affrontare serenamente l’argomento e padroneggiarlo nel modo più confacente alle esigenze delle proprie applicazioni. Anche se questo passo può sembrare oneroso in una prima istanza, a medio e lungo termine l’investimento porterà numerosi profitti: non solo sarà possibile un risparmio di materiale e cablaggio, ma la messa in servizio e la diagnosi di impianti esistenti saranno semplificati e permetteranno una localizzazione rapida e dettagliata di eventuali guasti. A questo scopo, al momento di scegliere un bus di campo, le necessità dell’applicazione devono essere accompagnate da una valutazione dei servizi, degli strumenti e degli accessori di cui i vari bus dispongono. In linea di massima esistono per tutti i bus di campo degli attrezzi di monitoraggio del traffico di comunicazione e, in certi casi dove è necessario, esistono pure degli strumenti di configurazione. Il passaggio dalle tecniche di cablaggio tradizionale alla tecnica dei bus di campo, indipendentemente dal o dai bus scelti, si rivela così essere un mezzo per affrontare questo periodo di crisi, per riconquistare la credibilità e la competitività a livello nazionale ed internazionale.

7. Riassunto

I bus di campo fanno parte di una realtà industriale sempre più presente in un numero crescente di campi tecnici e meno tecnici. Nati dalle esigenze dell’industria automobilistica, i bus di campo sono oggi impiegati in tutte le installazioni in cui esiste la necessità di elaborare dei dati in tempo reale. Con questo testo ho voluto illustrare le ragioni principali di questa espansione, sottolineando l’importanza e la responsabilità che hanno le diverse classi di potenziali interessati a queste tecniche. Da una parte gli utenti finali sono in fin dei conti i meno coinvolti, in quanto beneficiano dei vantaggi dei bus di campo unicamente indirettamente grazie a dei costi di installazione meno elevati e delle prestazioni più affidabili. Essi non hanno quindi bisogno di conoscere le tecniche impiegate. I produttori di apparecchiature che comunicano tra loro attraverso i bus di campo sono invece confrontati a dei problemi di disponibilità di mezzi di sviluppo, sia HW che SW e di componenti specifici. Il loro compito di realizzare l’interfaccia di comunicazione idonea all’apparecchiatura non deve soccombere alla facile tentazione di realizzare delle soluzioni facili da sviluppare, sì, ma inadeguate alle esigenze dell’applicazione finale. Per finire, chi si serve di queste apparecchiature per realizzare delle installazioni automatizzate è responsabile della scelta del o dei bus di campo ideali da impiegare per svolgere il compito previsto. Risulta quindi evidente che tutte le persone confrontate nel loro lavoro con i bus di campo devono sforzarsi di acquisire una base di conoscenze tecniche teoriche e pratiche abbastanza vaste per permettere loro una valutazione lucida al di fuori di qualsiasi influenze commerciali e politiche, purtroppo molto forti in quest’ambito.

Ho quindi illustrato alcune nozioni fondamentali della comunicazione digitale, quali il modello OSI, la topologia delle reti ed una breve e parziale panoramica sulle interfacce più diffuse. Sono pure stati elencati in modo sintetico qualche consigli pratici per la pianificazione di una rete, in particolare del tipo RS-485 che è il più diffuso mezzo fisico utilizzato in molti bus di campo.

Un altro aspetto presentato è quello della classificazione in diverse categorie dei bus di campo, sulla base della posizione ideale che assumerebbero nella gerarchia CIM. Benché questo metodo di classificare i bus in base alla quantità di dati trasmessi ed il tempo di reazione previsto sia abbastanza sommario, costituisce uno strumento di valutazione semplice ed applicabile anche al di fuori di un contesto di produzione industriale integrato.

L’ultimo argomento da considerare, ma non per questo il meno importante, è la disponibilità di strumenti di messa in servizio e di monitoraggio della comunicazione. Grazie ad un modesto investimento in tal senso, diventa ben presto vantaggioso utilizzare i bus di campo, anche in installazioni non per forza distribuite su grandi distanze.

Dopo la descrizione di qualche bus di campo rappresentanti bene le diversità esistenti, ho gettato uno sguardo verso il futuro dei sistemi di comunicazione industriali. Benché si senta sempre più spesso parlare dell’impiego del protocollo TCP/IP quale protocollo unico per coprire tutti i livelli della gerarchia, l’immediato futuro resta ancora in mano ai bus di campo attualmente presenti sul mercato. Una soluzione unica per tutti i problemi di comunicazione non è immediata e, ammettendo sia possibile, rischia di avverarsi nettamente più complessa rispetto alle soluzioni attuali, già di per sé non sempre semplici! La nascita di nuovi sistemi è da escludere parzialmente: in qualità di bus di campo difficilmente ci sarà chi investe soldi nel progettarne uno nuovo. Vi è invece la possibilità che, come è successo per il CAN, un bus sviluppato per un certo tipo di applicazione venga traslato nel mondo dei bus di campo. In quest’ottica si sta profilando l’USB (Universal Serial Bus), un bus per periferiche di Personal Computer che ha fatto parlare di sé stesso già ben prima di apparire sul mercato.

La raccomandazione finale che mi permetto avanzare è di non esitare a compiere il passo in direzione dei bus di campo, in quanto è proprio nel settore dell’automazione moderna che è ancora possibile recuperare una certa competitività sia tecnica che economica a livello internazionale, ma anche regionale. L’importante è fare tale passo nel modo corretto, per cui è indispensabile abbordarlo in conoscenza di causa.

Scritto da Matteo Mondada Ingegnere elettrotecnico STS/ATS impiegato presso il CIMSI, Centro CIM della Svizzera Italiana

Centro Galleria 2 6928 Manno Tel: +41 / 91 / 610 89 60 Fax: +41 / 91 / 610 89 70

mmondad@cimsi.cim.ch

Write me

Annesso 1: Bibliografia

Frank J. Furrer (Hrsg.) BITBUS-Grundlagen und Praxis Hüthig Buch Verlag, Heidelberg (D)1994 ISBN 3-7785-2250-7 Frank J. Furrer Ethernet-TCP/IP für die Industrieautomation Syslogic Press (CH)1996 ISBN 3-9520919-0-1 Wolfhard Lawrenz (Hrsg.) CAN-Grundlagen und Praxis Hüthig Buch Verlag, Heidelberg (D)1994 ISBN 3-7785-2263-9 Dominique Paret Le bus CAN: De la théorie à la pratique Edition Dunod, Paris (F)1996 ISBN 2-10-003164-3 OSI The Open Systems Networking Standard Computer Technology Research Corp., Charleston (USA) 1993 ISBN 1-56607-014-7 Feldbus Forum, 22 und 23 März 1995 FAEL, Uster (CH) 1995 Christoph Stoppok, Helmut Sturm Comparative Study of Field Buses for Sensor and Actuator Systems... VDI/VDE Technologiezentrum Informationstechnik GmbH, Berlin (D) 1990 IEEE Standards Board IEEE Standard Microcontroller System Serial Control Bus Institute of Electrical and Electronics Engineers Inc., New York (USA) 1990 IEEE Std 1118-1990 PROFIBUS-Process Field Bus DIN Deutsches Institut für Normung E.V., Berlin (D) 1988 DIN V19245-1988 (Teil 1+2) C. Türke Interbus-S - LAN-Architektur für Sensoren und Aktoren Phoenix Elektrizitätsgesellschaft, Blomberg (D) Best. Nr.: 27 67 53 2

Annesso 2: Indirizzi utili

Esistono tanti bus di campo. Per ognuno di questi vi sono delle associazioni di utenti e produttori che si sono riuniti per diffondere la propria tecnologia. Queste associazioni sono dei punti di contatto preziosi per accedere alla conoscenza dei sistemi, prima, ed ai prodotti, in seguito. Ecco quindi una lista delle associazioni senza scopo di lucro a mia conoscenza. Non posso tuttavia garantirvi la consistenza dei dati riportati, date le frequenti modifiche che subiscono. Inoltre non mi illudo proporre una raccolta di indirizzi completa. Chiedo di conseguenza esplicitamente scusa a chi non si trova elencato in questa lista:

Bus: ASI

Norma:-

AS-International Association Geschäftsführer Dr. O.W. Madelung Auf dem Broich 4a D - 51519 Odenthal 3

Tel.: +49 2174 40756 Fax.: +49 2174 41571 Web: - e-mail:-

Bus: BITBUS

Norma: IEEE-1118

BEUG - Bitbus European Users' Group Fürstenbergallee 22 D - 76532 Baden-Baden Tel.: +49 7221 65726 Fax.: +49 7221 181976 Web: http://www.cimsi.cim.ch/beug e-mail:beug@cimsi.cim.ch

Bus: CAN Norma: ISO

11898

CiA - CAN in Automation Am Weichselgarten 26 D - 91058 Erlangen Tel.: +49 9131 601091 Fax.: +49 9131 601092 Web: http://www.can-cia.de/ e-mail:headquarters@can-cia.de

Bus: EiB Norma:

EIBA - EIB Association Swiss Postfach 7190 CH - 8023 Zürich Tel.: +41 1 2719090 Fax.: +41 1 2719292 Web: - e-mail:-

Bus: Interbus-S

Norma: DIN 19258

INTERBUS-S Club - Switzerland Kontaktstelle Postfach 84 CH - 8610 Uster Tel.: +41 1 9409367 Fax.: +41 1 9409363 Web: - e-mail:-

Bus: Interbus-S

Norma: DIN 19258

InterBus-S Club Geschäftstelle Postfach 2347 D - 67611 Kaiserslautern Tel.: +49 631 79424 Fax.: +49 631 97658 Web: http://www.ibsclub.com/ e-mail:interbus@ibsclub.com

Bus: LON Norma:

SwissLON Team c/o Bircher AG Wiesengasse 20 CH - 8222 Beringen Tel.: +41 52 6871121 Fax.: +41 52 6871122 Web: - e-mail:-

Bus: LON Norma:

LON Users International c/o Echelon Ltd. 4015 Miranda Avenue USA - Palo Alto, CA 94304 Tel.: +1 415 8557400 Fax.: +1 415 856 6153

Web: http://www.lonworks.echelon.com/ e-mail:lonworks@echelon.com

Bus: PROFIBUS

Norma: DIN 19245

PNO - PROFIBUS Nutzerorganisation Geschäftsstelle Haid-und-Neu-Str. 7 D - 76131 Karlsruhe Tel.: +49 721 9658590 Fax.: +49 721 9658589 Web: http://www.profibus.com/data/membinfo/pnoger.html e-mail:101644.2006@compuserve.com

Bus: PROFIBUS

Norma: DIN 19245

PNI - PROFIBUS Network Italia c/o GISI Via G. Barinetti, 1 I - 20145 Milano Tel.: + 39 2 33600927 Fax.: + 39 2 314996 Web: - e-mail:-

Bus: PROFIBUS

Norma: DIN 19245

PNO - PROFIBUS Nutzerorganisation Schweiz Fritz-Käserstr. 10 CH - 4562 Biberist Tel.: + 41 65 324915 Fax.: + 41 65 324917 Web: http://www.isbe.ch/~wwwfbus/profibus.html e-mail:profibus@thenet.ch

Bus: SERCOS

Norma: IEC 1491

IGS - Interessengemeinschaft SERCOS Interface Im Mühlenfeld 28 D - 53123 Bonn Tel.: +49 228 646670 Fax.: +49 228 6420396 Web: http://www.cimsi.cim.ch/sercos e-mail:mailto:sercos@cimsi.cim.ch

Bus: WorldFIP

Norma: EN50170

WorldFIP Headquarters 2, Rue de Bône F - 92160 Antony Tel.: +33 1 46114430 Fax.: +33 1 46114431 Web: http://www.worldfip.org/ e-mail:wfinfo@worldfip.imaginet.fr