Snap4City per la creazione di Smart City Control Room, SCCR (ITA)

Una Smart City Control Room (SCCR) è una soluzione ed una struttura in cui tutti i dati e gli indicatori della città/metropoli sono raccolti e aggregati per produrre visioni di sintesi, indicatori, previsioni, precursori, indicatori di anomalie, etc., spesso tali dati calcolati tramite Big Data Analytic, e prodotti a supporto dei decisori e degli operatori, in modo che in tempi brevi possano comprendere la situazione a pieno ed agire, anche attraverso delle simulazioni per scenari con condizioni WHAT-IF, per esempio per supportare le esercitazioni della protezione civile, e per sondare cause effetto delle varie azioni/interventi che vengono proposti a fronte di accadimenti. Pertanto, è necessario poter aggregare i dati in ingresso per produrre risultati di sintesi in tempo reale in base agli obiettivi di controllo e monitoraggio della città. 

 

si veda:     Scenario: Firenze Smart City Control Room

vedi anche:     Scenario: Control Room vs Video Wall

 

Snap4City e' la soluzione che ingloba gli strumenti che sono stati usati per lo sviluppo della Smart City Control Room, SCCR della citta' di Firenze. (Sindaco Nardella allo Smart City Expo World Conference 2018). Per meglio dire, Snap4City ha integrato e ampliato lo strumento che e' stato sviluppato nel progetto REPLICATE H2020 per la smart city di Firenze, come spiegato in seguito. Il progetto REPLICATE H2020 Smart City FlagShip della comissione europea, per la parte ICT, ha preso la spinta da altri sviluppi open source (come Sii-Mobility Km4City del MIUR SCN, RESOLUTE H2020 ed altri componenti sviluppati da DISIT Lab di UNIFI) per produrre una soluzione per la SCCR di Firenze. Con Snap4City (progetto che vede il suo sviluppo di Pilot su Helsinki e Antwerp, nel contesto del progetto Select4Cities PCP) e' stato possibile aggiungere molti altri componenti che sono fondamentali per la gestione di una SCCR completa e sostenibile ma che possono essere considerati opzionali in una smart city ridotta come: il supporto per il Living Lab, la gestione  di IOT App, la gestione di una community, le gestione di soluzioni Multi Organizzazione, la gestione delle risorse, il supporto completo GDPR, le gestione di heatmap, i modelli predittivi delle variabili ambientali, la ricostruzione del traffico (da Sii-mobility), gli algoritmi di routing (da Sii-Mobility), i modellli di simulazione What-IF, le ricerche full text, le knowledge base e Smart City API federate, la gestione scabile di processi in container, il data analytic scalabile, la gestione dell'utenza, le App Mobile, la gestione IOT MultiBroker e MultiProtocollo, etc. Il sistema Snap4City e' 100% open source, modulare e scalabile, in modo che nello sviluppo e nella realizzazione di una Smart City si possa partire con una installazione semplice e minimale e crescere con le esigenze della citta' semplicemente aggiungendo componenti, riconfigurando, e sfruttando i componenti che sono gia presenti nel territorio, senza nessun Vendor-lock-in, protocol-lock-in, technology-lock-in e solution lock-in.  

 

Nelle grandi città metropolitane, l'SCCR comprende grandi pannelli/monitor (che coprono grandi pareti) in cui viene riportato lo stato della città in tempo reale attraverso alcune rappresentazioni di sintesi, previsioni, allarmi dei dati riguardanti: mobilità, trasporti pubblici, energia, sicurezza, attività sociali, ambiente, meteo, flussi di persone, salute, acqua, ICT, governo, pronto soccorso, protezione civile, polizia (118/112/911), vigili del fuoco, pronto soccorso e quindi lo stato del consumo delle risorse della città viene espresso tramite: KPI (Key Performance Indicator), metriche che mettono in evidenza il funzionamento e/o che sono precursori/predittori dell’evoluzioni come di condizioni critiche. I KPI sono generalmente rappresentativi dello stato delle risorse/servizi della città, del volume delle richieste rispetto alla media, del carico di lavoro, il numero delle risorse attivate rispetto alle disponibili, la qualità del servizio, ecc. Alcune delle/dei risorse/servizi della città devono essere intese come infrastrutture critiche per la funzionalità della città e per la vita degli utenti: trasporti, energia, sicurezza, salute, acqua, protezione civile, ICT, ecc. che possono presentare meccanismi di cascata/concatenazione (e.g., se la nettezza non viene raccolta allora…., se manca la corrente per 15 minuti allora ……, se arriva l’acqua alta allora …..). Nella maggior parte dei casi, la gestione quotidiana delle risorse della città viene eseguita dai singoli operatori (TPL, parking, municipale, raccolta nettezza, FFVV, Prot civile, etc.), anche a fronte di alcuni degli accadimenti descritti sopra, visto che questi sono in una certa misura codificati essendo eventi in qualche misura previsti e/o prevedibili. Tali operatori, gestiscono autonomamente le loro sale di controllo, accedendo e rappresentando i propri dati per prendere decisioni che riguardano direttamente i loro servizi, e possono essere limitate nello scopo, spesso non tenendo conto in modo preciso delle risorse e delle azioni di altri enti. Ad esempio, quando la rete di energia ha un problema in un'area della città, l'energia viene reindirizzata per raggiungere tutte le subaree possibili attraverso un percorso diverso; quando la rete idrica presenta un problema sui principali tubi di distribuzione, ove possibile, l'acqua è fornita in altri modi; in presenza di congestione del traffico, la temporizzazione dei semafori viene modificata per facilitare il flusso e i percorsi dei mezzi pubblici. La gestione autonoma degli incidenti è un valore in molte situazioni, ma quando si è di fronte a situazioni critiche ed ampia copertura, le decisioni vanno concertate per contenere i costi ed uscire velocemente dalla crisi.

 

Si nota che in questo contesto, il sistema dei trasporti (pubblici e privati, terrestri e lagunari, etc.) sono l’infrastruttura primaria (si veda RESOLUTE H2020 coordinato da DISIT Lab UNIFI), infatti il sistema dei trasporti è il mezzo attraverso il quale si possono propagare alcuni effetti in cascata (per esempio, una disfunzione in un’area si propaga in altre tramite il collasso l’allungare delle code, e la disfunzione della rete dei trasporti). La stessa rete dei trasporti è anche il veicolo primario per la risoluzione delle criticità (arrivo dei soccorsi, lo sgombero delle macerie, etc.). Pertanto, se la rete dei trasporti non funziona a dovere questa è essa stessa il punto critico primario per il funzionamento della città e per la sua sicurezza.

Quando la città cresce i suoi sistemi diventano complessi, inoltre, vi sono città che sono morfologicamente complesse per la loro storia, morfogenesi e struttura, e pertanto diventa assolutamente importante avere una SCR integrata, e che sia in grado di:

  1. gestire la raccolta dei dati, la loro integrazione ed il calcolo di indicatori di sintesi e predizione (nel caso di previsione e preallarme, anomalie), ma anche per effettuare delle simulazioni, a fronte di ipotesi su eventi.
  2. Attivare ed eseguire algoritmi di data analytic che possano produrre in modo sistematico o all’occorrenza previsioni in tempo reale, identificazione di anomalie, in grado di comunicarle agli operatori e in ottica Early Warning e studio. Pertanto, in grado di generare segnalazioni anche in anticipo.
  3. visualizzare su Dashboard Primaria lo stato e della città e la sua evoluzione e aspetti critici ai diversi operatori (in una sala operativa comune, come nella o nelle situation room), lasciando che anche alcuni operatori remoti nelle loro sedi possano accedere ad alcune informazioni di sintesi, predizione, stato del servizio, etc.
  4. Permettere di effettuare direttamente su Dashboard Operatore specifiche gli approfondimenti necessari con tecniche di drill down (spazio temporale, e per relazioni), con simulazioni WHAT IF sui problemi e sulle soluzioni, con algoritmi di routing, con modelli predittivi, con strumenti di approfondimento specifici per l’area di competenza dell’operatore, e pertanto personalizzati. Su questi deve essere possibile aprire delle discussioni/chat con altri operatori anche remoti (via radio, voce, e chat), e porre all’attenzione di tutti gli operatori a supporto delle decisioni anche tramite eventuali viste di Dashboard Operatore nella Dashboard Primaria (sul wall primario).
  5. Gestire eventi e segnalazioni che possono arrivare dai vari operatori: mobilità, trasporti, rifiuti, energia, Social Media, FFSS, autostrade, TPL, VVFF, etc., in vari standard e tramite vari canali di comunicazione. Gestire in questi casi significa: prendere in considerazione, concertare le eventuali azioni congiunte fra più operatori, agire, seguire la loro evoluzione, tenere traccia degli accadimenti, fino ad arrivare alla loro conclusione/risoluzione, per poterne tenere conto per le prossime azioni.

 

Questo approccio di integrazione, analisi, predizione, sintesi deve passare dall'aggregazione dei dati e dal ricavare deduzioni dall'analisi dei dati raccolti in tempo reale, dallo storico, per essere più rapidi e più precisi nella reazione a situazioni critiche e nella gestione del funzionamento ordinario. Fino a poter affrontare e risolvere con successo non solo eventi pianificati (come quelli identificati nelle mappe di rischio e nei piani della protezione civile), ma anche quelli che possono essere non previsti. Lavorando pertanto in ottica di resilienza, come descritto dalle linee guida per la resilienza dei sistemi di Trasporto prodotte dal Progetto RESOLUTE H2020 per la Commissione Europea a guida UNIFI DISIT Lab.

 

La SCCR è uno strumento a supporto delle decisioni, in grado di fornire evidenze dell’arrivo/occorrenza di condizioni critiche in tempo reale e/o di precursori di tali condizioni ed offrire soluzioni (supporto alle decisioni, per esempio proponendo scelte multiple sui piani di evacuazione, sul routing, sull’attivazione di piani di attuazione, anche con simulazioni e data analytic). Una SCCR può svolgere il suo ruolo solo se ben integrata con il territorio. Nella maggior parte dei casi, vi è una tendenza a considerare questi tool come parte integrante dell'SCCR poiché l'attività dell'SCCR e il controllo della città possono essere eseguiti solo quando sono integrati ed efficaci.

 

 


        

Video with Live demonstration      

see on You Tube:

I processi di controllo della città sono molto complessi da gestire poiché la quantità di informazioni è eterogenea e ampia e deve essere facilmente/velocemente compresa dagli operatori della SCCR. Non è solo un problema di usabilità, ma un problema di identificazione degli indicatori, dei precursori/predittori, di algoritmi big data, di modelli di simulazione delle situazioni WHAT-IF, di comprensibilità, di rappresentazione dei dati, di formazione degli osservatori/operatori e dei decisori che devono essere allenati alla veloce comprensione delle rappresentazioni grafiche. Queste devono essere sintetiche, non ambigue, e rappresentative della complessità del problema, qualora questo sia effettivamente complesso. Nella maggior parte dei casi, devono essere addestrati per comprendere i dati e le corrispondenti rappresentazioni grafiche. I decisori, come gli operatori, devono diventare confidenti su ciò che vedono per capire in profondità tutti i singoli dettagli rappresentati sugli schermi, e nelle simulazioni. Ad esempio, siamo abituati a capire: (i) una rappresentazione del traffico osservando la mappa della città con segmenti rossi, arancioni, gialli e verdi sulle strade; (ii) una temperatura e la percentuale di umidità, un segnale relativo ad un sottopassaggio o ponte, ecc., mentre è più difficile leggere le tabelle di inquinamento, pollinazione, andamento del flusso del traffico attraverso numeri (queste devono essere riportate in percentuale, riferite ai valori di soglia, mediani, etc.), ecc. Segnali di allarme in rosso, segnale lampeggiante, ecc., possono aiutare nell'apprendimento e comprensione rapida.

Alcuni Aspetti: della soluzione Snap4City

  1. acquisizione dati (Data Gathering) da ogni tipo di sorgente con ogni tipo di protocollo ed in ogni formato. I dati possono essere real time, stream (TV cam, etc.), data/event driven, statici/quasi-statici, Open Data o proprietari, provenienti da qualsiasi sorgente, file, webservice, IOT/IOE e da Social Media. I dati vengono acquisiti e riconciliati rispetto alle entità della citta. Le sorgenti vengono integrate e sono accedute da vari strumenti di Big Data Analytics. Questa soluzione permette di gestire la conoscenza in modo centralizzato. Tutte le funzioni smart sono disponibili tramite le Smart City API che sono il punto di accesso per servizi IOT, mobile e web app, per applicazioni mobili, totem informativi, dashboard, etc.  Alcuni dati complessi possono essere pre-ingeriti e processati tramite soluzioni e strumenti Snsp4City come: (i) processi ETL Penthao Kettle, (ii) IOT Secure cluster che supporta un elevato numero di IOT Protocol, o (iii) soluzioni di terzi. In questo modo si superano le limitazioni dei sistemi GIS per l’accesso a data complessi, come a sensori con protocolli vari e sicuri. Questa ultima parte fornita dalla soluzione Snap4City/Km4City FiWare con IOT App Node-RED/NodeJS. I dati prima di arrivare in GIS possono esser acquisiti e riconciliati rispetto alle entità della citta sulla base del modello ontologico (Km4City https://www.km4city.org). Questo permette di effettuare delle ricerche semantiche con inferenza geo-spaziale, temporale, per relazioni/concetti, e testi. Questa soluzione permette di acquisire dati in qualsiasi formato, qualsiasi sorgente, con qualsiasi protocollo, anche con protocolli end-to-end encrypted come HTTPS, TLS, WSs. Questa soluzione supera i limii presenti nelle soluzioni che usano solamenti strumenti GIS.
  2. data analytic in tempo reale dal modulo di Big Data Analytic Engines Snap4City in HA DRS FT. Per esempio, per: la stima di predizioni (per parcheggi, flussi di veicoli e persone, condizioni critiche), l’identificazione di anomalie, la ricostruzione del traffico, la stima di matrici di origine destinazione (O/D), la stima di flussi primari pedonali e mezzi in navigazione, il calcolo di precursori e predittori, il calcolo di KPI, etc. I processi possono essere data/event driven, o periodici. I processi data/event driven possono essere guidati da eventi sporadici, dai dati, da eventi IOT, dagli operatori o da eventi di allarme di cui al punto (3). In questo modo si supera i limiti dei sistemi GIS con modelli predittivi (o di anomaly detection) tramite machine learning dei suddetti algoritmi/dati complessi. Alcuni algoritmi semplici di clusterizzazione, calcolo heatmap, etc. Tutti risultati di Data Analytic vengono resi disponibili per le Dashboard tramite API e storicizzati anche in Snap4City Big Data Store. Inoltre, per gli aspetti di data analytic relativi al:
    1. routing che permette il calcolo di percorsi di routing tenendo conto di elementi e caratteristiche stradali e di vincoli di vario tipo ma anche elementi dinamici per le simulaizoni come barriere, con i numeri civici e le aggiunte di OSM (svolte, etc.), Open Street Map, permettendo simulazioni anche lato client per gli scenari WHAT-IF.
    2. IOT evoluto con IOT Application su Snap4City, sono direttamente connesse alle Dashboard e svolgono operazioni di elaborazione dati in tempo reale, event/data driven. Per esempio per processi complessi in stream ed anche per l’identificazione il riconoscimento di condizioni di allarme. Anche IOT Application come MicroService che sono pubblicate nella suite Snap4City su JS Foundation (come aggionamento della suit smart city di Snap4City del Disit lab). MicroService di base di NodeRED/NodeJS per la creazione di applicazioni IOT, i servizi avanzati per applicazioni IOT in ambito Smart City di Snap4City accessibili da JS Foundation, l’editor Node-RED per la costruzione delle applicazioni IOT, con le estensioni Snap4City, rilasciato in Open Source). Le applicazioni IOT Snap4City possono essere inserite in IOT Edge in PC Windows e Linux, Raspberry pi, Android, etc. (tutto compatibile con soluzioni SigFOX, LoraWAN, OneM2M, NGSI, e molti altri protocolli, etc.). Sono rilasciati anche IOT Button che possono essere utilizzati per attivare situazioni di emergenza rilasciandole direttamente alle persone fragili, agli ospedali, etc. tutto tramite device certificati che comunicano su canali encrypted, HTTPS, con mutua autenticazione.   
    3. Data Analytics in R studio, (anche utilizzando Tensor Flow, se predisponete di Host con schede GPU), Java, Python, etc., per lo sviluppo di algoritmi predittivi, di anomaly detection con tecniche statistiche e di machine learning, come processi periodici o sporadici/even-driven gestiti da DISCES oppure da IOT. La soluzione snap4city permette di fornire ai vostri sviluppatori o a terze parti l’accesso come sviluppatore per creare algoritmi e poter trasformare direttamente gli algoritmi in MicroServizi  accessibili per applicazioni IOT. Per esempio, si possono utilizzare i seguenti algoritmi:
      1. Modelli predittivi che sfruttano variabili storiche provenienti da serie storiche diverse tramite algoritmi di machine learning. Https://www.km4city.org
        1. Predizioni sui parcheggi a sbarra e lungo strada: a breve e lungo termine
        2. Predizioni sulle presenze in banchine: a breve e lungo termine
        3. Predizioni sulle presenze in città di persone: a breve e lungo termine; comprensione delle zone delle città che presentano un simile comportamento di uso da parte delle persone e/o dei mezzi di trasporto.
      2. Modelli di mobilità: Https://www.km4city.org
        1. Mappe di origine destinazione da dati telefonia mobile, da dati wifi, da dati operativi e conteggi sui mezzi, da tornelli, etc.
          1. Rappresentazioni con spider e matrici, per ogni orario, mappe inflow e outflow interattive.
        2. Traiettorie primarie dei percosi preferiti degli utenti in città, per la regolazione dei servizi
        3. punti caldi in funzione del tempo, e comportamenti tipici H24 dei cityuser in città: per la regolazione dei servizi.
        4. analisi della domanda di mobilita', analisi dell'offerta di mobilita' e confronti fra domanda ed offerta. 
        5. calcolo in real time dei flussi entranti ed uscenti in citta' 
      3. Modelli di calcolo differenziali integrati ad algoritmi di machine learning ottimizzazione come:
        1. Ricostruzione del traffico con predizioni. Per esempio https://firenzetraffic.km4city.org/ ma anche da altre dashboard pubbliche
        2. predizioni degli andamenti di variabili ambientali come NOX, PM10, PM2.5, tenendo conto della struttura 3D della citta' delle previsioni del tempo, della produzione di inquinanti, ed in particolare del traffico. 
      4. Modelli e strumenti di simulazione
        1. una valutazione di cosa dovrebbe essere fatto per riprendere la situazione normale il più velocemente possibile, in ottica di resilienza. Per esempio, intensificando altri tipi di servizi di trasporto (le frequenze di altri traghetti, il loro numero, etc.)
        2. Scenari WHAT-IF su mobilita' e comportamenti utenti
        3. sistema di informazione, verso le persone con delle APP speciali, verso gli stakeholder con le loro dashboard ridotte, etc.
      5. Detection di anomalie in base ai dati precedenti non solo:
        1. identificazione di condizioni anomale per early warning su traffico, dati ambientali, etc. 
    4. Smart City API (Km4City) possono essere interrogate da web e mobile app, come da IOT Application tramite MicroServizi, e accederanno direttamente allo Storage SpatioTemporal Big Data. Vi sono svariate applicazioni per queste API che sono usate e monitorate nella loro applicazioni di Firenze anche da E015 di Regione Lombardia. Questa istanza su Firenze è stata utilizzate nell’Hackathon del team di Piacentini verso il DAF nazionale, etc. Tali Smart City API sono documentate con standard internazionali come Swagger, e testate/testabili in automatico con Postman. Sono state inoltre utilizzate nell'Hackathon si Sii-Mobility e nel recente Hackathon 2019 di Snap4City per Antwerp e Helsinki
  3. Sistema delle Dashboard: Dati acquisiti, elaborati ed eventi vengono visualizzati su Dashboard di controllo che sono adatte per essere visualizzate su video wall, e/o su schermi operatori su PC, e anche su sistemi mobili. Ogni punto operatore può avere accesso a tutti i dati (in base alle se credenziali) e può presentare dati aggiornati in automatico in tempo reale, data driven, anche provenienti da stream video, IOT, etc. e pertanto da processi data/event driven. Le stesse dashboard possono avere una logica di controllo IOT in NodeJS/Node-RED o essere semplicemente delle visualizzazioni interattive. Sono già state realizzate numerose dashboard per varie Smart City, iniziando dalla città di Firenze, alcune sono pubbliche e attualmente reperibili su https://www.km4city.org/?controlRoom#realtimeData 

Dashboard possono essere composte in modo semplice e visuale da un sistema di Authoring (denominato Dashboard Builder, in Open Source, GITHUB/DISIT) che presenta un gran numero di widget e paradigmi grafici con o senza animazioni, come: tabelle, grafici, mappe e mappe 3D, bottoni, immagini, grafi strade, mappe con PIN, percorsi, aree, etc.; selettori, dimer, semafori, notifiche testuali, tachimetri, barre multicolore, heatmap, torte, digrammi di kiviat, grafici multitrend, istogrammi orizzontali e verticali, matrici O/D, etc. Manuale scaricabile da: http://www.disit.org/7074  Il manuale completo della soluzione Snap4City, che include il sistema di Dashboard, Dashboard builder, notificator, il gestore delle IOT App, etc. è accessibile da Https://www.snap4city.org .

    1. Si compongono come un insieme di widget grafici che possono essere impostati separatamente assegnando una serie di parametri: origine dati, dimensioni, colori, forma, font, allarmi, relazioni con altri, ecc .;
    2. Sono uno strumento di visual analytics che mostra dati su widget autonomi e connessi / sincronizzati, permettendo di creare sistemi connessi di dashboard completamente interattive;
    3. Rappresentano widget con diversi paradigmi grafici (tabelle, grafici, istogrammi, mappe, kiviat, elenchi, telecamere, heat-map, eventi critici della città, semafori, traiettorie tipiche, ecc.) con livello di interattività ,animazione e attuazione (selettori, pulsanti, dimer, tastiere numeriche, testo, cursori, previsioni meteo, stato di allerta, triage, probabilità di accadimento di eventi, livello di servizio, ...);
    4. Premettono di creare delle vere e proprie applicazioni interattive, multipagina/multidashboard, e non semplici storie monopagina da scrollare (cosa alquanto sconsigliabile in una control room, o su totem o pannelli operatore);
    5. Possono avere widget attuatori per produrre azioni che possono propagarsi in semplici cambi di parametri come azioni sul campo, messaggi IOT, messaggi sui pannelli a messaggio variabile, cambi di cartelli stradali dinamici, insieme alla visualizzazione dei grafici, all'integrazione con l'applicazione IOT e ai cruscotti digitali;
    6. fornire supporto per la produzione collaborativa di dashboard e per coworking;
    7. fornire supporto per incorporare la dashboard in pagine Web di terzi, di partecipate, per esempio;
    8. integrare le singole dashboard come i singoli widget in dashboard più complesse;
    9. raccogliere, mostrare e mantenere aggiornati i dati sullo schermo con aggiornamento automatico per ogni vista;
    10. permettere la condivisione di Dashboard con altri utenti anche fuori dalla SCR tramite canali autenticati e protetti in HTTPS, in accordo al GDPR
    11. attivare Chat private con i referenti che possono accedere alle dashboard;
    12. incorporare nella dashboard viste di altri servizi esterni forniti da terzi;
    13. si consiglia di vedere alcuni esempi su https://main.snap4city.org/management/dashboards.php
  1.