Progettazione ed implementazione della logica di controllo per la gestione delle richieste di prenotazione di un ascensore

Progettazione ed implementazione della logica di controllo per la gestione delle richieste di prenotazione di un ascensore

Lorenzo Gagliani^∗ (14/06/2021)

Abstract— Il presente documento descrive le fasi di proget- tazione e implementazione della logica di controllo su scheda a microcontrollore Arduino UNO per il funzionamento di un ascensore che gestisca le richieste di prenotazione provenienti da quattro piani.

L’obiettivo principale è la gestione smart delle prenotazioni che permetta l’ottimizzazione dei tempi di attesa e la riduzione del carico di lavoro dell’ascensore, inoltre si vuole rendere l’implementazione della logica di controllo generica, ovvero non legata al numero di piani del caso di esempio, in modo da poterla utilizzare anche per il controllo di ascensori in edifici di altezza differente.

I. INTRODUZIONE

Gli ascensori sono qualcosa che si da ormai per scontato:

si preme il pulsante, si aspetta (magari lamentandosi un po’

per l’attesa) e appena si aprono le porte si può salire e si viene trasportati nel piano in cui si vuole andare.

Ma gli ascensori sono qualcosa di piuttosto complesso:

l’algoritmo che li governa deve scegliere a che piano fer- marsi, se dare precedenza a una chiamata che viene da un piano più vicino o una chiamata che è stata fatta per prima, ma che proviene da un piano più lontano. Ci sono volte in cui il sistema deve decidere se dare priorità al risparmio di energia o all’efficienza: volte cioè in cui esiste la possibilità di servire più velocemente più chiamate che provengono da piani diversi, ma farlo è molto dispendioso energicamente.

Sono due le regole alla base del funzionamento dell’ascen- sore e spesso sono indicate come “regole dell’ascensore”:

1) “finché nell’ascensore c’è qualcuno che vuole andare nella direzione attuale, continuare ad andare in quella direzione”.

2) “se si sono soddisfatte tutte le richieste nella direzione attuale, cambiare direzione in caso ci siamo chiamate, altrimenti fermarsi e aspettare nuove richieste”.

Queste due regole sono alla base della logica di controllo che si è progettata ed implementata, però al fine di sem- plificare il caso di studio non si è considerata la pulsantiera dei piani posizionata all’interno dell’ascensore, ma solamente i pulsanti di prenotazione fermata presenti ad ogni piano.

Questa semplificazione non ha permesso di implementare una terza regola che renderebbe l’ascensore più smart e cioè

“se le persone nell’ascensore raggiungono un peso molto vicino al limite concesso le successive chiamate non possono essere servite fin quando qualche persona non scende alle successive fermate”. Inoltre, la mancanza della pulsantiera

∗Studente del corso di Sistemi Multiagente, docente prof. F. Vasca, Dipartimento di Ingegneria, Università del Sannio, email:

[email protected], matricola 399000329

interna porta ad immaginare l’ascensore come un’ascensore montacarichi utilizzato nelle cucine di ristoranti a più piani per servire le richieste di prenotazione per il trasporto di cibo.

Per sopperire alla mancanza della terza regola si è comunque implementato un sistema di allarme per garantire sicurezza:

quando l’ascensore risulta essere fermo al piano il sistema monitora il peso in modo da non sovraccaricare l’ascensore e generare possibili malfunzionamenti.

Il sistema che si vuole realizzare, quindi, è composto da una parte fisica e da una parte software che corrisponde alla programmazione del microcontrollore che gestisce la logica di controllo dell’ascensore.

II. SETUPSPERIMENTALE

Il sistema di base è realizzato utilizzando la scheda mi- crocontrollore Arduino UNO, sette diodi LED, di cui quattro di colore verde e tre di colore rosso, e quattro interruttori.

Tali componenti, ad eccezione della scheda, sono utili a realizzare un modello con lo scopo di verificare l’effettivo funzionamento della logica di controllo senza costi eccessivi;

una volta dimostrato che il comportamento del modello è quello desiderato è possibile applicarlo ad un contesto realistico.

I diodi LED rappresentano le fasi di funzionamento dell’a- scensore: ogni LED verde, quando acceso, indica la fermata dell’ascensore al piano corrispondente (ogni LED verde rap- presenta un singolo piano), invece, ogni LED rosso, quando acceso, rappresenta la fase di movimento dell’ascensore tra i due piani adiacenti. Per evidenziare la differenza tra la fase di movimento tra due piani e la fase di stazionamento in un singolo piano, tra due LED verdi è posizionato un LED rosso.

I quattro interruttori SMD rappresentano i pulsanti utilizzati per prenotare la fermata dell’ascensore ai vari piani. Ognuno di essi è rappresentativo di un singolo piano, quindi sono disposti da sinistra verso destra sulla breadbord in ordine crescente e rappresentano gli input del sistema: il primo interruttore da sinistra rappresenta il piano terra e quello più a destra l’ultimo piano.

Inoltre, alla componentistica base del sistema è necessa- rio aggiungere un sensore che permette di riconoscere la posizione dell’ascensore all’accensione del sistema ed un sensore di peso all’interno dell’ascensore per verificare il potenziale sovraccarico. Per quanto riguarda il sensore di rilevamento della posizione si è utilizzata una fotoresistenza per simulare la presenza dell’ascensore ad un determinato piano in base al livello di irraggiamento; invece, per quanto riguarda il sensore di peso si è sfruttato un altro interruttore il quale permette di simulare, quando premuto, il superamento

della soglia di peso massima consentita e far scattare così l’allarme. In Tab. I sono elencate le componenti necessarie per la realizzazione del sistema il cui schema circuitale è mostrato in Fig. 1 .

TABLE I

COMPONENTI UTILIZZATE PER L’IMPLEMENTAZIONE DEL SISTEMA

Componente Q.tà

Arduino UNO 1

Resistore da 220Ω 8 Resistore da 10KΩ 6

Interruttore SMD 5

Diodo LED verde 4

Diodo LED rosso 3

Fotoresistenza GL5528 1

Buzzer passivo 1

Breadboard 2

Jumper −

Fig. 1. Schema circuitale del sistema realizzato tramite software Frizting [1].

A. Collegamenti circuitali con Arduino UNO

Tutte le componenti sono connesse alla scheda Ardui- no UNO, la quale integra il microcontrollore ATmega328P, e grazie alla quale si è in grado di programmare delle logiche di controllo per la gestione del processo. La scheda, oltre a controllare opportunamente i componenti utilizzati, funge anche da alimentatore per l’intero circuito per mezzo dei pin etichettati con 5V e GN D. Il microcontrollore Arduino UNO (Fig. 2) ha una tensione di lavoro di 5V e presenta pin di ingresso/uscita sia digitali che analogici; in

particolare ha 14 pin digitali I/O (di cui 6 PWM) e 6 pin di ingresso analogico.

Gli ingressi digitali sono dei pin che permettono di cam- pionare e codificare delle tensioni in ingresso come 1 logico oppure 0 logico. I livelli di tensione devono essere in un certo range per essere riconosciuti come 1 o 0 logico. Per Arduino UNO si ha uno 0 logico se la tensione è minore di 500mV (0.1 · V_cc) mentre si ha un 1 logico se la tensione è maggiore di 3.5V (0.7 · Vcc).

Gli ingressi analogici sono dei pin che permettono il cam- pionamento delle tensioni in ingresso e la discretizzazione tramite dei livelli di quantizzazione. Il numero di livelli di quantizzazione dipende dal numero di bit utilizzati per la codifica; in generale si hanno 2ⁿ − 1 livelli dove n è il numero di bit usati per la codifica che in Arduino UNO corrisponde a 10. Per questo motivo i valori di tensione letti dal microcontrollore (che variano da 0 a Vcc) saranno compresi tra 0 e 1023.

Fig. 2. Dettaglio della scheda Arduino UNO: pin di input e output.

Dalla figura dello schema circuitale del sistema si può intuire che i pin digitali utilizzati sono stati cablati in parte come ingressi e in parte come uscite: gli interruttori SMD per la prenotazione della fermata dell’ascensore, essendo gli input del sistema, sono stati collegati ai pin digitali 9 − 12 i quali sono stati opportunamente mappati come pin di ingresso alla scheda, invece, i 7 diodi LED e il buzzer passivo sono stati collegati rispettivamente ai pin digitali 2−8 e 13 i quali sono stati mappati come pin di uscita alla scheda. Per quanto riguarda gli ingressi analogici sono stati utilizzati i pin A0 e A1: il primo è collegato al sensore di peso dell’ascensore che nel caso di studio si traduce in un semplice interruttore SMD, il secondo, invece, è collegato al sensore di rilevamento posizione dell’ascensore che nel caso di studio si traduce in un resistore collegato in serie ad una fotoresistenza.

La fotoresistenza ha un valore di resistenza che si mi- sura attraverso una resistenza variabile a seconda dell’ir- raggiamento luminoso: maggiore è l’irraggiamento minore è il valore della resistenza. Nel caso di studio si sfrutta la fotoresistenza F collegata in serie con un resistore R da 10KΩ (Fig. 3) per simulare la posizione dell’ascensore all’avvio del sistema. Misurando la tensione su R fissa si ha:

v_R= R

R + FV_cc (1)

quindi, si può notare che vRè tanto più grande quanto più piccola è F , ovvero la tensione in ingresso al pin analogico sarà tanto più alta (massimo 5V) quanto più la fotoresistenza sarà irradiata. Nel caso di studio irraggiamento massimo corrisponde alla posizione dell’ascensore all’ultimo piano, invece irraggiamento minino al piano terra.

Fig. 3. Schema circuitale del collegamento in serie tra fotoresistenza F e resistenza R per simulare il sensore di rilevamento posizione.

III. PROGRAMMAZIONE DEL MICROCONTROLLORE

La scheda a microcontrollore Arduino UNO può essere programmata in diversi modi. In questo lavoro non si utilizza il classico linguaggio di programmazione di Arduino con il proprio IDE, ma si vuole modellare la logica decisionale usando macchine a stati; per questo scopo si utilizza il tool- box Stateflow [2] integrato in Matlab Simulink che fornisce un linguaggio grafico che include diagrammi di transizione di stato, diagrammi di flusso, tabelle di transizione di stato e tabelle di verità. La logica decisionale può essere simulata come blocco in un modello Simulink o eseguita come oggetto in Matlab.

Dovendo programmare il microcontrollore, quindi rilascia- re la logica di controllo su Arduino UNO, si utilizza il modello Stateflow come blocco in Simulink e con il supporto di una libreria Arduino per Simulink [3] si mappano i pin di Arduino (digitali e analogici) con gli ingressi e le uscite della logica di controllo. In Fig. 4 si mostra il risultato del modello Simulink con uso del blocco Stateflow per la macchina a stati. Nel modello si fa uso di blocchi per l’interfacciamento di Arduino, blocchi Demux per poter splittare i segnali vetto- riali in scalari e blocchi di To_Workspace per la successiva analisi dei segnali in postprocessing (dopo l’esperimento).

Sarà compito di Matlab effettuare la traduzione in codice per Arduino di quanto sviluppato con il linguaggio grafico a blocchi.

A. FSM in Stateflow

L’obiettivo che ci si è posti è stato quello di progettare una logica di controllo che fosse in grado di funzionare con ascensori collocati in edifici di qualunque altezza, ov- viamente dopo una opportuna configurazione del numero di piani da servire. La FSM in questione presenta 6 in- gressi e 6 uscite, nello specifico gli ingressi sono i quat- tro pulsanti dei singoli piani (button1 − button4), il peso del carico dell’ascensore (weight) e la misura del sensore di rilevamento posizione (sensorF loor); le uscite, invece,

Fig. 4. Modello Simulink del sistema ascensore.

sono tre di tipo funzionale per poter comandare i LED dei piani (ledF loor), dei relativi interpiani (ledInterF loor) e azionare l’allarme in caso di sovraccarico (alarm), le altre tre uscite sono per poter effettuare una analisi dei dati in postprocessing e dimostrare il funzionamento della logica di controllo, infatti si trova un segnale che indica il piano di fermata dell’ascensore (f loorStop), le varie pre- notazioni di fermata dei piani (booking) e il piano corrente dell’ascensore (currentF loor).

Gli stati della FSM progettata e mostrata in Fig. 5 sono essenzialmente 3, nello specifico WARM_UP rappresenta lo stato iniziale della macchina necessario per il warm up del sistema, SETTING_START_FLOOR rappresenta uno stato transitorio all’interno del quale viene impostato il piano di start dell’ascensore e CALL_SERVICE rappresenta lo stato di funzionamento a regime dell’ascensore, all’interno del quale si trova una FSM per la logica di controllo.

Nello stato transitorio SETTING_START_FLOOR viene letto dall’ingresso sensorF loor il valore del sensore di rilevamento posizione e in base al range al quale appartiene viene settato il currentF loor ad uno specifico piano; pre- cisamente viene settato al piano terrà se valore ≤ 250, primo piano se 250 < valore ≤ 500, secondo piano se 500 < valore ≤ 750 ed ultimo piano se valore > 750. E’ uno stato transitorio per via della presenza dell’unica transizione con condizione sempre ve- rificata che permette di uscire da questo stato ed entrare nello stato di CALL_SERVICE, ovvero nello stato di regime.

All’interno di quest’altro stato è presente l’algoritmo di controllo per il corretto funzionamento.

Fig. 5. Macchina a stati della logica di controllo dell’ascensore in Matlab Stateflow.

B. Algoritmo di controllo

L’implementazione realizzata prevede un algoritmo in grado di gestire le prenotazioni di fermata ai piani, le quali vengono memorizzate dal microcontrollore durante la permanenza nello stato di CALL_SERVICE: infatti, dalla Fig. 5 è possibile osservare l’aggiornamento della variabile vettoriale booking in base alle richieste che arrivano dagli ingressi (button1 − button4). La logica di controllo è semplice: all’arrivo di una richiesta, l’ascensore si muoverà nel raggiungimento del piano target e se dovessero arrivare richieste di fermata intermedie saranno servite prima del piano target; nel caso in cui le richieste risultano essere in direzione opposta saranno servite dopo il raggiungimento del piano target.

L’algoritmo di controllo prevede a sua volta un’altra FSM la quale ha 4 stati: FLOOR è lo stato che indica la presenza dell’ascensore al piano (piano che sarà rappresentato dalla variabile currentF loor), ALARM_WEIGHT_ON è lo stato che mette fuori uso l’ascensore in caso di sovraccarico di peso dello stesso, MOVE_DOWN e MOVE_UP sono gli stati che evidenziano la fase di discesa e salita dell’ascensore, in pratica quando uno di questi stati risulterà essere attivo l’ascensore si troverà in un interpiano. Lo stato iniziale di

quest’altra FSM risulta essere FLOOR. Durante la permanen- za in questo stato vengono eseguite in loop delle istruzioni come l’accensione del LED relativo al piano corrente tramite il setting dell’uscita vettoriale ledF loor, il soddisfacimento della richiesta di fermata per currentF loor in quanto appena servita ed il controllo di quale debba essere la direzione (tramite la variabile up booleana) della successiva richiesta di fermata da servire. La direzione, up o down, viene scelta in base alla presenza di prenotazioni, ovvero se al di sopra del piano corrente ci sono richieste (sumU p > 0) e al di sotto nessuna richiesta (sumDown == 0) allora la direzione da prendere è verso l’alto (up = true), se al di sopra non ci sono richieste ma al di sotto si allora la direzione da prendere è verso il basso (up = f alse). Nel caso in cui sia sumU p sia sumDown risultano essere entrambe pari a 0 o maggiori di 0 allora la variabile up rimane inalterata, in modo da continuare a servire le richieste nella stessa direzione in cui si stava servendo. In questo modo è possibile discriminare, in caso di presenza di richieste di fermata, in quale stato spostarsi. Al soddisfacimento di una transizione di uscita per lo stato FLOOR viene eseguita l’azione riportata nella sezione exit e quindi viene spento il LED verde relativo al piano corrente.

Entrando in uno dei due stati di movimento, vengono eseguite azioni solamente in ingresso ed in uscita dallo stato.

In entry viene acceso il LED rosso relativo all’interpiano di riferimento e in exit, esattamente dopo 3 secondi (tempo di spostamento tra un piano e l’altro), viene spento il LED rosso relativo all’interpiano che si sta abbandonando. Come si nota dalla FSM, dagli stati di movimento si torna allo stato FLOOR solamente quando si giunge ad un piano da servire.

Infine, quando si è al piano, il sensore di peso potrebbe rilevare un valore che il sistema considera come sovraccarico.

Il valore di peso massimo consentito è pari a 500, però al fine di evitare oscillazioni nel sistema, occorre impostare il punto di commutazione a 520 e il punto di reset a 480, cioè si definisce un’isteresi che consenta un controllo stabile.

IV. ANALISI DATI DI UN ESPERIMENTO

Terminata la fase di progettazione e di implementazione del sistema, si è proceduto con un esperimento per il testing della logica di controllo implementata. In Fig. 6 è possibile osservare la realizzazione fisica del sistema in questione.

Per dimostrare l’esito positivo dell’esperimento, la scheda Arduino UNO è rimasta collegata al PC (tramite il cavo USB type-B) per tutta la durata dell’esperimento in modo da poter trasferire a Matlab, a fine esperimento, i segnali di uscita della FSM salvati sulla scheda (si ricorda che questo è stato reso possibile grazie all’aggiunta dei blocchi To_Workspace di Simulink).

I segnali raccolti durante l’esperimento, dopo un’opportu- na modifica in postprocessing tramite script in Matlab, hanno reso possibile il grafico in Fig. 7 che rappresenta:

1) l’andamento dell’ascensore nel tempo, tramite un segnale lineare a tratti;

Fig. 6. Realizzazione dello schema circuitale del progetto.

2) gli istanti temporali delle richieste di prenotazione fermata dei vari piani;

3) gli istanti temporali in cui vi è lo stato di allarme (generato dalla presenza di sovraccarico di peso).

Il grafico mostra sull’asse delle ascisse il tempo espresso in secondi e sull’asse delle ordinate sia il numero di piani sia lo stato di warm up e di allarme. Dopo un intervallo di tempo pari ad 1 secondo il sistema esce dalla fase di warm up e in base al valore letto dal sensore di rilevamento posi- zione, imposta, secondo la logica discussa, il piano corrente dell’ascensore che nell’esperimento corrisponde al piano 1.

Si nota che ad un certo istante temporale (circa 6 secondi) arriva la richiesta di fermata dal piano 3, quindi l’ascensore entra nella fase di movimento per raggiungere il piano 3, ovvero il target. Durante tale fase, prima di raggiungere il piano 2, riceve la richiesta di fermata dal piano 2 (all’istante temporale 7.2 secondi), quindi, non essendo ancora arrivato al piano 2 ed essendo una richiesta intermedia, l’ascensore serve prima quest’ultima richiesta per ottimizzare i tempi di attesa. All’istante temporale 10, quando l’ascensore è ancora al piano 2 ed è in salita per soddisfare la richiesta del piano 3, si riceve la richiesta di fermata del piano 0, ma essendo presente una richiesta da parte del piano 3 ed essendo ancora in direzione verso l’alto, l’ascensore continuerà a salire e servirà il piano 3. Raggiunto l’ultimo piano, la logica di controllo permette all’ascensore di servire le richieste in direzione opposta, quindi potrebbe servire la richiesta del piano 0, ma prima di abbandonare il piano 3 il carico dell’ascensore supera la soglia del peso massimo consentito (salita di un carico) e viene innescato l’allarme facendo rimanere l’ascensore fermo al piano. Solamente dopo un intervallo di tempo pari a 4 secondi circa il peso del carico dell’ascensore rientra in un valore ammissibile (discesa di

un carico) e quindi si può continuare con il soddisfacimento delle richieste. L’ascensore scende verso il piano 0 e quando risulta essere quasi al piano 1 riceve una prenotazione dal piano 2, ma ancora una volta essendo in direzione di discesa dovrà prima soddisfare la richiesta del piano 0 e solo una volta raggiunto il target potrà servire la richiesta del piano 2 (quando l’ascensore si trova al piano 0, nell’esperimento in esame, scatta l’allarme come nel caso precedente a causa del sovraccarico di peso).

Fig. 7. Grafico andamento ascensore nel tempo e istanti temporali di ricezione prenotazione fermata da parte dei piani.

V. CONCLUSIONI

Le prove sperimentali effettuate hanno mostrato che il funzionamento del sistema corrisponde a quello previsto dall’algoritmo e che gli obiettivi prefissati sono stati rag- giunti. Un possibile sviluppo futuro del presente lavoro po- trebbe essere focalizzato sulla realizzazione della pulsantiera di prenotazione interna all’ascensore per poter distinguere richieste interne da richieste esterne. In questo modo si potrebbe implementare una logica di controllo che permette di realizzare la terza regola discussa nel paragrafo intro- duttivo, ovvero rendere l’ascensore più smart ottimizzando le fermate (non far fermare l’ascensore ad un piano che ha richiesto la fermata se il peso del carico dell’ascensore è molto vicino alla soglia limite e nessuno dei passeggeri scende a quel piano). Un ulteriore sviluppo futuro potrebbe essere focalizzato sulla realizzazione di un prototipo che simuli il comportamento reale con l’inserimento di motori ed encoder per l’attuazione del movimento.

REFERENCES

[1] Fritzing Electronics. Accessed: 21.05.2021. [Online]. Available:

https://fritzing.org/

[2] Matlab Stateflow. Accessed: 13.05.2021. [Online]. Available:

https://it.mathworks.com/products/stateflow.html

[3] Arduino Support from Simulink. Accessed: 13.05.2021. [Onli- ne]. Available: https://it.mathworks.com/hardware-support/arduino- simulink.html