Al fine di ottenere una comunicazione efficiente fra i vari componenti del sistema è stato necessario decidere due protocolli con livelli di complessità differenti: uno per il livello di campo, ovvero per la comunicazione con i FEIM, ed uno per il livello di supervisione, ovvero per la comunicazione fra le unità di supervisione e con le inter-facce grafiche.
Entrambi i protocolli utilizzano connessioni di tipo TCP/IP e quindi sono perfetta-mente compatibili ed integrabili in una rete Ethernet/IP standard.
5.4.1 Protocolli a livello di campo
A livello di campo i protocolli più diffusi nell’automazione industriale e domestica sono essenzialmente:
• contatto pulito;
• 0–10 V;
• 0–1 V;
• 4–20 mA;
• 0–20 mA;
• RS-485.
Un contatto pulito non è altro che un interruttore comandato, sul quale non è presente una tensione imposta dal dispositivo. Possono quindi essere letti dai sistemi di super-visione come circuiti aperti o chiusi senza nessuna restrizione, se non nelle tensioni e correnti massime e minime supportate. In pratica la quasi totalità dei dispositivi di sicurezza, ovvero sensori di movimento, contatti magnetici, barriere a infrarossi, sensori di fumo per sistemi di sicurezza (non di tipo analogico indirizzato), sensori di allagamento, . . . utilizzano come uscite di campo uno o più contatti puliti per se-gnalare le condizioni di allarme, guasto, manomissione. Per quanto riguarda i sensori con uscita analogica, quali sensori di temperatura, umidità relativa, luminosità, . . . essi utilizzano vari standard, che possono essere suddivisi a grandi linee in: uscite in tensione ed uscite in corrente.
Nel mondo industriale vengono utilizzate sovente uscite in corrente, in quanto hanno una maggiore immunità ai disturbi elettromagnetici anche su distanze elevate. Inoltre l’utilizzo di standard “a zero vivo”, ovvero nei quali il valore minimo della grandez-za misurata non corrisponde ad un’assengrandez-za di corrente, permettono di alimentare il dispositivo utilizzando il cavo di segnale e al tempo stesso verificare la condizione di guasto, in cui il cavo è interrotto o il dispositivo è guasto, in quanto il valore nullo di
corrente non è un valore ammesso nel normale funzionamento.
Nel mondo dell’automazione domestica sono invece diffusi gli standard in tensione, in quanto i collegamenti sono in genere più corti ed in ambiente meno ostile di quel-lo industriale dal punto di vista delle interferenze. Inoltre questo standard consuma meno energia ed i dispositivi di lettura non richiedono resistenze tarate per una con-versione precisa dei valori letti.
Il protocollo RS-485 viene utilizzato per il collegamento con strumenti di misu-ra utilizzati nel mondo industriale o con piccoli pannelli di intemisu-razione utente che utilizzano poi protocolli standard di livello superiore, come ad esempio il Modbus [47].
5.4.2 Protocollo di gestione del campo
Per la scelta del protocollo del livello di campo sono stati vagliati diversi protocolli standard, fra i quali il più adatto sembrava essere l’SNMP (Simple Network Mana-gement Protocol, RFC 1157) [48, 49]. Il limite di quel protocollo risiede però nella necessità di codificare i messaggi trasmessi utilizzando una speciale codifica: ASN.1 (ISO 8824-1:2002). Tale codifica risultava essere relativamente complessa per il ti-po di applicazione che si stava sviluppando e la richiesta di risorse di elaborazione e memoria non erano giustificate per le necessità di comunicazione. Inoltre l’uso standardizzato dell’SNMP richiedeva la costruzione di un albero di definizione rela-tivamente complesso, cui doveva essere ufficialmente richiesta l’aggiunta di un nodo specifico per la nostra applicazione.
Sulla base di queste considerazioni si è deciso di sviluppare un semplice protocollo di livello applicazione, che sfruttasse la garanzia di consegna ed integrità del TCP/IP per trasmettere le informazioni. Il protocollo è di tipo binario e supporta un modello di tipo master-slave, in cui i sistemi di supervisioni operano come master, inviando comandi, ed i FEIM operano come slave, eseguendo i comandi. I FEIM possono in-viare notifiche non sollecitate su variazioni di eventi di campo predefiniti secondo le configurazioni fornite. Inoltre, il protocollo, oltre al paradigma master-slave, suppor-ta anche un paradigma P2P, che consente a ciascun modulo di agire come master nei confronti degli altri, nel momento in cui deve richiedere la scrittura di nuovi valori su
altri oggetti in conseguenza delle regole impostate. Le operazioni consentite in moda-lità P2P sono limitate, al fine di garantire l’esecuzione dei soli comandi strettamente indispensabili in condizioni specifiche. In particolare non sono accettate variazioni di configurazioni non provenienti dall’unità LMP preposta alla gestione di quello spe-cifico FEIM.
Oltre ai normali comandi per il controllo del FEIM è anche definito nel protocollo uno specifico pacchetto, definito di “Keep Alive”, che deve essere inviato dall’LMP a tutti i FEIM connessi, se questi non sono stati contattati da più di uno specifico intervallo di tempo (timeout). Ciò serve a dimostrare al FEIM che la connessione con l’LMP è ancora possibile. Se non viene ricevuto un comando od un pacchetto di Keep Alive entro il timeout, il modulo cambia profilo di funzionamento ed entra in modalità “Orphan” (orfano) (cfr. sez. 5.7).
Attualmente il protocollo è di tipo binario in chiaro, senza crittografia o autenticazio-ne, sebbene venga supportata l’identificazione di mittente e destinatario.
5.4.3 Protocollo di supervisione
Il protocollo di supervisione realizzato è simile, nella filosofia, a quello progettato per il livello di gestione del campo. Si tratta di un protocollo basato sull’XML (eX-tensible Markup Language, un formato di file di testo mediante il quale è possibile rappresentare le informazioni in modo gerarchico e mediante il quale è anche pos-sibile rappresentare complesse basi di dati) che utilizza il TCP/IP come livello di trasporto. In questo caso un entità stabilisce una connessione TCP con un’altra, dopo di che quest’ultima stabilisce a sua volta una connessione verso la prima. La con-nessione iniziale viene utilizzata per l’invio di comandi e la ricezione delle risposte, mentre la seconda viene utilizzata per la ricezione di eventi da parte dell’unità con-tattata. In questo modo vengono limitati al minimo i problemi di concorrenza nella comunicazione.
Definita “connessione comandi” la prima connessione instaurata e “connessione trap”
la seconda, si può descrivere a grandi linee il funzionamento del protocollo: sulla con-nessione comandi un’entità può richiedere letture o scritture di variabili su Oggetti presenti sull’entità contattata o può richiedere di registrarsi per la ricezione di
varia-zioni dello stato di alcune Variabili. Se viene inviata una richiesta di notifica, ogni volta che avviene una variazione delle Variabili registrate, il server contattato invierà una notifica utilizzando la connessione trap.
Se l’entità contattata è il SP, allora possono anche essere richieste informazioni (IP ed ID) dei server in carico per la gestione di specifici Oggetti, al fine di permettere all’unità di contattare direttamente tali server per ottenere informazioni o controllare gli Oggetti in questione.
Nel caso la connessione venga effettuata da una GUI verso l’SP è anche possibile, sempre utilizzando questo protocollo, richiedere l’assegnazione di un ID dinamico, che rimane assegnato all’interfaccia finché la connessione comandi con la stessa è attiva.
Nel momento in cui, per qualunque motivo, una delle due connessioni viene chiusa, anche l’altra viene interrotta e tutte le registrazioni per la ricezione delle variazioni delle Variabili vengono annullate. Se viene interrotta la connessione fra la GUI e l’SP, il sui ID dinamico viene rilasciato.