Funzionalità |
||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Sono stati sviluppati due codici sorgenti: uno per la centralina e uno per il client. I due codici condividono parte delle strutture e funzioni. Sorgente Client: Ogni client è già a conoscenza del suo programma di lavoro. Si è ipotizzato un programma di lavoro suddiviso in quattro fasi (ad esempio: riscaldamento, mantenimento temperatura, regolazione successiva e raffreddamento) nelle quali viene definita la potenza massima e il corrispettivo tempo di esecuzione. Nel Grafico 1 riportato qui sotto, viene rappresentato il ciclo di funzionamento di un dispositivo.
Una volta avviato il client, questo invierà alla centralina un pacchetto contenente i suoi dati di riconoscimento ed i relativi dati di funzionamento. Di seguito vengono riportati i campi del pacchetto.
Tabella 1: Contenuto pacchetti informativi inviati dai client Fatto ciò il dispositivo resterà in attesa di una conferma all'avvio da parte della centralina. Durante tutta l'operatività del client, questo rimarrà comunque in ascolto di eventuali aggiornamenti sui suoi parametri, in particolare quello della potenza massima di fase. Che dati manda la centralina in questo caso? Analizziamo il comportamento del codice lato centralina. (centralina.cpp) Sorgente Centralina: Una volta avviata la centralina, questa resterà in ascolto di eventuali richieste di accensione o modifica da parte dei client. Ogni qualvolta dovesse ricevere un nuovo pacchetto, dovrà analizzare il campo serial_number e lo confronterà con quelli già presenti nella lista di tutti i dispositivi di tipo client. Il client che ha stabilito la comunicazione, potrebbe infatti essere sia un nuovo dispositivo, che vuole comunicare la richiesta di accensione, sia uno già noto, che ha la necessità di comunicare con il nodo centrale, ad esempio per chiedere l'autorizzazione a modificare uno o più parametri. Ci sono dunque due casi, qui descritti e in seguito schematizzati nel flow chart: 1) Dispositivo non presente nella lista: Per prima cosa la centralina lo inserirà di default nella classe Wait: questa classe contiene l'insieme dei dispositivi ancora in attesa di accensione. La classe che contiene i dispositivi già in esecuzione è denominata Active. Dopodich&ecute eseguirà un controllo sulla possibilità di accendere il nuovo dispositivo. In particolare, ricevuti i dati riguardanti la potenza e il Delta, la centralina sarà in grado di prevedere se in una qualsiasi delle quattro fasi programmate del client, la potenza richiesta sommata a quella totale dei dispositivi già accesi, eccederà il limite (nel caso studio di 4000 Watt). Per fare tale previsione è sufficiente il valore centrale delle potenze che il dispositivo può richiedere nell'intero processo e, da questo, ricavare il Delta tra valore massimo/minimo e centrale. La centralina, in seguito, calcola la potenza in eccesso e la confronta con il delta degli n dispositivi attivi. Cercherà poi nella classe Active un dispositivo il cui Delta risulti maggiore uguale alla potenza in eccesso (questa è la potenza che “manca” al nuovo client). Se la verifica avrò successo, sarà inviato al dispositivo trovato il comando di riduzione della potenza (non compromettendone la funzionalità). Verrà infine data conferma al nuovo dispositivo, che potrà ora accendersi. Abbiamo ottenuto un nuovo dispositivo attivo e un contestuale abbassamento di potenza di uno dei dispositivi attivi, ottenendo un risparmio energetico e una migliore ridistribuzione della potenza disponibile. Inotre, abbiamo massimizzato il numero di elementi in grado di lavorare contemporaneamente. 2) Dispositivo presente nella classe List: In questa situazione la centralina si limiterà a ricevere un pacchetto che conterrà informazioni relative al funzionamento del dispositivo già in funzione. Ad esempio, ogni volta che un dispositivo passerà da una fase all'altra, ne darà comunicazione alla centralina. Un altro caso in cui il dispositivo acceso potrebbe voler comunicare è alla fine del processo: manderà, infatti, una conferma di fine ciclo. Segue ora un diagramma degli stati in cui vengono mostrate le fasi di funzionamento dal lato centralina; tale diagramma sarà poi riproposto anche in versione esempio, in modo che ci sia anche una versione più realistica di quanto succede all'interno del programma.
|
