251
Conclusioni
Ripercorriamo i passi seguiti per la creazione di questo lavoro di tesi.
In primo luogo c’è stata l’identificazione del problema, cioè l’esigenza di creare una sorta di “hub” logico nel sistema di supervisione di una Centrale Eolica ENEL, cioè costruire una applicazione in grado di gestire e pubblicare ogni tipologia di dato reso disponibile dall’impianto, utile ai fini della gestione da remoto dell’impianto stesso.
Nei sistemi attuali, per questo tipo di processi, le regole di comunicazione più diffuse sono sostanzialmente IEC 60870-5-104, OPC e MODBUS.
Da un’analisi del mercato abbiamo visto che erano disponibili solamente dei semplici “ponti” tra questi protocolli. Non si trovavano quindi applicazioni di tipo Data Gateway, cioè applicazioni in grado di gestire il processo di raccolta e re distribuzione dati.
252
Il nostro scopo è stato quindi quello di creare una piattaforma software in grado di interconnettere le apparecchiature che per comunicare utilizzano questi protocolli.
Ci siamo dunque prefissi di mettere in comunicazione macchine che con i sistemi attuali non si parlano: gestire i dati pubblicati dalla master station del sistema SCADA di ciascun produttore, combinarli ad esempio con quelli della stazione elettrica o dalla stazione meteo e pubblicare il tutto nel formato in cui il nostro client ce lo richiede, con possibilità di gestire anche situazioni multi client.
A questo punto è stato fatto uno studio di fattibilità, abbiamo cioè selezionato il software per sviluppo che il mercato ci metteva a disposizione.
Abbiamo scelto il Visual Basic come linguaggio di programmazione, poiché non solo rappresenta un ambiente di sviluppo in grado di dare vita ad applicazioni client/server anche di grande complessità, ma ci permette di associare una interfaccia grafica alla nostra applicazione una volta ultimata. Questo fatto è fondamentale perché non appena il sistema andrà in campo la sua gestione sarà con ogni probabilità affidata ad un operatore, di conseguenza ecco che le opzioni di configurazione dovranno essere di comprensione immediata: una interfaccia grafica risponde perfettamente a tale esigenza.
253
Per quanto riguarda invece la gestione dei database, abbiamo scelto di utilizzare MS SQL server. La scelta di un motore così complesso è dovuta al fatto che noi vogliamo riuscire a gestire anche istanze multiple che facciano riferimento al solito Database. Con MS SQL server non corriamo il rischio che tali istanze diventino concorrenziali.
Veniamo adesso alla realizzazione del progetto: lo sviluppo è stato per prima cosa orientato a mettere a punto la piattaforma in grado di rispondere a quelli che erano i nostri scopi, cioè uno strato software solido che consentisse mediante semplice upgrade di gestire eventuali nuove esigenze in termini interfacce del Data Gateway. Successivamente abbiamo iniziato la costruzione di tali interfacce.
Il fuoco del lavoro è stato posto inizialmente sulla creazione di un database pubblico che potesse essere aggiornato mediante uno o più serventi OPC, ed in grado di pubblicare il dato per uno o più clients 104, questo perché tale interazione era quella di maggiore rilievo per i nostri scopi. Tale interazione avrà un notevole impatto in termini di mercato.
Successivamente abbiamo inserito l’interfaccia IEC 60870-5-104 client, e le interfacce MODBUS client e MODBUS server in modo da dotare la nostra applicazione di piena operatività per il contesto in cui dovrà lavorare. La fase di test, condotta
254
per un periodo di tempo significativo nella nostra rete locale, non ha evidenziato problemi. Allo stato attuale dell’arte possiamo dunque ritenere l’applicazione solida, anche se per motivi di tempo le interfacce MODBUS TCP Client e Server non sono ancora state dotate di piene funzionalità.
Concludiamo dicendo che il lavoro di tesi termina a questo punto perché gli scopi preposti sono stati raggiunti, ma il Data Gateway realizzato si propone sul mercato anche per un utilizzo su spettro molto più ampio.
