By I semafori smart – Parte 2
In questa seconda parte si andrà a descrivere nel dettaglio l’idea precedentemente esposta nell’articolo I semafori smart – Parte 1, con tutti gli strumenti necessari al fine di far comprendere a tutti la logica implementata all’interno dei semafori dinamici.
Implementazione
Il nostro lavoro si è basato su due aspetti importanti:
- Gestione dei conflitti
- Dinamicità del tempo
Analizzando il funzionamento del semaforo, infatti, si è notato che i principali problemi consistono nella cattiva gestione di alcuni casi specifici di conflitto, molto frequenti nella vita quotidiana, e nella poca flessibilità dei tempi di verde, generando così un lento deflusso veicolare.
Partendo da queste considerazioni, si è cercato di risolvere il problema della gestione dei conflitti tramite l’utilizzo di appositi sensori e strutture, volti a regolamentare l’accesso concorrente dei veicoli in strada. Per quanto riguarda invece la gestione dinamica del tempo, sono state sviluppate due linee di progettazione: la prima più lineare, la seconda più articolata.
Questa suddivisione è stata pensata per avere una scelta tra una gestione dinamica, che non sconvolge eccessivamente l’attuale funzionamento del semaforo, e una più azzardata.
I due algoritmi implementati per la scelta dinamica dei tempi di verde sono stati denominati “dynamic1” e “dynamic2”.
Normal
L’ implementazione consiste nella simulazione del reale funzionamento del semaforo.
Si è quindi andati ad analizzare il completo funzionamento del semaforo codificando la sua logica all’interno del simulatore. In sostanza il funzionamento si basa su alcuni tempi pre-calcolati che vengono inseriti all’interno della logica del semaforo e convertiti da quest’ultimo in segnali luminosi, rimanenti attivi per quel lasso di tempo. Un ulteriore funzionalità aggiunta, inserendo un parametro denominato shifting, è quella dell’onda verde che viene modellata con dei valori che permettono uno shifting temporale dei tempi pre-calcolati creando un certo sfasamento dello scatto del verde tra due semafori consecutivi, in modo tale da permettere al veicolo di riuscire ad attraversare più incroci possibili, proseguendo ad una certa velocità consigliata dalle apposite apparecchiature.
Lo sviluppo di questo ramo è stato necessario in quanto, grazie ad esso, si è potuta effettuare una raccolta di dati reali, da poter mettere a confronto con i risultati ottenuti dalle simulazioni di dynamic1 e dynamic2.
Dynamic – 1
Realizzato con l’intento di trovare un giusto compromesso tra efficienza e costi di installazione, il dynamic1 è più limitato e semplice rispetto al dynamic2 ma, allo stesso tempo, molto più facile da implementare ed economicamente più conveniente. Il dynamic1, infatti, è capace di funzionare con risorse di calcolo limitate. Il tutto si basa su due algoritmi:
Gestione dei conflitti
Si basa su due importanti variabili, ovvero carNS e carEO. Tali variabili sono incrementati e decrementati secondo un trigger dei sensori posizionati lungo il tratto stradale interessato. Questi sensori sono collegati con il semaforo al quale comunicano l’entrata o l’uscita di un vicolo dalla strada, in modo tale da aggiornare le precedenti variabili. Facendo questo controllo possiamo avere delle informazioni sul traffico istantaneo.
L’algoritmo effettua quindi tre tipi di controlli:
– il primo consiste nel controllare se carNS e carEO siano uguali 0. Se così fosse, nell’incrocio non vi è conflitto e di conseguenza il semaforo rimarrà nello stato di default.
– si verifica poi se una delle variabili risulta > 0 e l’altra = 0. In questo caso si va nello stato di “lascia passare”, cioè il semaforo in corrispondenza della variabile > 0 rimarrà verde.
– nell’ultimo stato invece, entrambe le variabili risultano essere diverse da 0, e l’algoritmo quindi va in uno stato più complesso, che prevede il calcolo totale delle macchine e, dopo un certo periodo di tempo, il calcolo dinamico di un nuovo tempo di verde.
Statechart diagram dynamic1
Calcolo dinamico del tempo di verde
In questa fase dell’algoritmo vi sono 4 variabili necessarie, ovvero totEO, totNS, timeUnit e updateTime. Le prime 2 servono per calcolare il numero di macchine totali che entrano nella strada. Questo numero, a differenza di carEO e carNS, non viene mai decrementato ma viene semplicemente azzerato durante l’aggiornamento dei tempi di verde per ricalcolare il numero totale di macchine. Il tempo dinamico in questo algoritmo viene calcolato andando a moltiplicare il numero di macchine totali (totNS o totEO) per il timeUnit.
Questo calcolo viene effettuato allo scadere del tempo di campionamento e quindi matematicamente ogni volta che il tempo di simulazione sia un suo multiplo. TimeUnit e tempo di campionamento sono stati scelti in maniera sperimentale e quindi catalogabili come variabili di tecnologia. La scelta di distinguere carEO/NS con totEO/NS è fondamentale per la gestione, in maniera indipendente, delle due fasi dell’algoritmo. Il dynamic2 infatti va a variare solo la seconda parte lasciando invariata la prima, e rendendola autonoma e quindi utilizzabile in altri algoritmi. I tempi di verde calcolati secondo l’algoritmo comunque non possono andare a sforare dei range di tempo che prevedono un minimo di 35 secondi e uno massimo di 120.
Ai fini del progetto sono state inserite due variabili, mintime e maxTime, che rappresentano appunto i limiti temporali sopra citati. Tutto l’algoritmo si basa dunque sul principio per cui il tempo di verde deve essere proporzionale al numero di macchine presenti nell’incrocio.
Dynamic – 2
Questa gestione è un’evoluzione dell’algoritmo dynamic1, evoluzione in quanto la base resta uguale ma la complessità e l’efficienza va ad aumentare.
Anche il dynamic2 si basa quindi sulle due fasi del dynamic1 ma va a modificare l’algoritmo di dinamicità del tempo di verde, il tutto andando a sfruttare delle architetture più solide. I principi e le implementazioni su cui si basa il dynamic2 sono:
Gestione conflitto e campionamento
La gestione dei conflitti è uguale a quella trovata nell’algoritmo del dynamic1.
Per quanto riguarda il campionamento questo avviene ogni tempo di campionamento, nel quale vengono salvati due importanti valori, il primo corrispondente al numero di macchine che sono entrate nella strada, il secondo invece indica il numero di macchine che sono riuscite ad attraversare la strada con successo. Tramite questi, ogni semaforo andrà a calcolare quanto tempo di verde sarebbe stato necessario affinché tutti i veicoli fossero riusciti ad attraversare l’incrocio con successo. Il calcolo viene dato dalla formula:
Il risultato verrà immagazzinato in una memoria presente all’interno del semaforo, con lo scopo di contenere questi dati ed elaborarli. Nel caso in cui tutti i veicoli riuscissero ad attraversare l’incrocio, il nuovo tempo calcolato risulterà uguale al tempo “vecchio”. Questo non implica però che il tempo di verde sia necessariamente corretto, in quanto può anche succedere che il suo valore sia esagerato rispetto al numero di macchine effettivamente presenti. Si andrà così a calcolare un “wasted_time” che rappresenta il tempo di verde “sprecato”, e sarà sottratto al tempo di verde corrente in modo tale da creare un nuovo valore. Questo è necessario affinché il semaforo possa capire che il flusso in quella strada è diminuito. Importante è, inoltre, l’inserimento di un tempo minimo pari a 35 secondi nel caso in cui non vi siano macchine nell’incrocio, per rimanere coerenti con le altre implementazioni.
Calcolo dinamico del tempo
Ogni “n” tempi di campionamento, si andrà poi ad effettuare una media dei valori raccolti. Tale media, viene poi utilizzata per aggiornare il tempo dei semafori, tramite la seguente espressione:
Quest’ultima, è stata sviluppata ispirandosi allo Smoothed Round Trip Time (SRTT). L’SRTT è una stima dei valori di RTT, e fornisce una media pesata di tali valori privilegiando i valori dei campioni RTT più recenti. L’RTT corrisponde al tempo di andata e ritorno tra sorgente e destinazione impiegato da un’unità dati, ovvero il tempo che passa tra l’invio di un segmento e la ricezione del relativo ACK. Elemento caratteristico dell’SRTT è il valore “A” (con 0≤ A ≤1). Tanto più il valore di “A” è vicino a 1, tanto maggiore sarà il peso dato all’ultima osservazione di RTT. Nell’SRTT, i valori tipici di “A” sono da 0.8 a 0.9 basandosi sulla storia locale. Questo valore di A nella nostra equazione è calcolato matematicamente in quanto la storia non è locale ma è basata sulla media di tutti i semafori. È quindi utile andare a modellare la A in modo da garantire il giusto peso per ogni semaforo secondo la seguente equazione:
Comunicazione tra semafori
La comunicazione tra semafori è realizzata in modo centralizzato grazie ad un database che, comunicando con i semafori stessi, fornisce dati condivisi e modulati in base ai tempi di ogni semaforo, realizzando così una struttura dati globale alla quale tutti i semafori vanno ad accedere sia in scrittura che in lettura. Il “tempo_tabella” dell’espressione è un tempo preso da questa struttura dati contenuta nel database e composta da X righe una per ogni fascia oraria scelta, e sette colonne, corrispondenti invece ai giorni della settimana. La tabella contiene dunque per ogni fascia oraria di ogni giorno la media dei tempi di verdi dei semafori.
Ad inizio giornata il semaforo deve richiedere al server i dati presenti nella tabella relativa alla giornata corrente. Il protocollo usato è quello TCP/IP.
I tempi e le richieste sono inseriti nel campo data del pacchetto TCP. Questo pacchetto a sua volta va incapsulato in quello IP. A fine giornata il semaforo invierà i dati modificati al server, il quale attuerà un merge tra tutti i dati per ricavare un tempo finale ed inserirlo nella tabella.
Questo merge è dato dall’equazione:
Si è scelto di utilizzare il protocollo TCP in quanto più affidabile. Esso, infatti, assicura l’arrivo dei pacchetti in ordine numerico, e comunica l’avvenuta ricezione dei pacchetti tramite il meccanismo degli ACK. Attuare questi meccanismi farà però aumentare l’overhead di comunicazione, che non sarà troppo costoso in quanto si avranno poche comunicazioni tra i semafori e il server. Caratteristica importante del protocollo IP è la sua portabilità, in quanto lo si può implementare su qualsiasi hardware, e la possibilità di usare i suoi metodi di trasporto e frammentazione. Nel caso in cui fosse infatti necessaria l’implementazione di una nuova rete semaforica, questo sarà possibile in modo agevole.
Statechart diagram dynamic2
