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
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
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
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.
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
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
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.
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:
|
|
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
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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...
