L’analisi dati include tutte le procedure di visualizzazione, analisi e archiviazione dei dati relativi a uscite in mare. Il progetto (Audace Mothics Analytics) include un’interfaccia web, basata su un backend in Python.
Nome
Di seguito, Audace Mothics (Audace Moth analytics) verrà usato al posto del meno elegante “software di analisi dati post-mortem”. Si accettano proposte migliori!
Con Mothics, si fa riferimento all’insieme di
Aggregator(gestione di dati raw daCommunicatore salvataggio, o gestione di track da file)WebApp(interfaccia web)- API e script di avvio e spegnimento.
Struttura generale
Il software dell’UC è una versione ridotta e specializzata di Mothics; dunque, la codebase è essenzialmente analoga, così come la struttura dell’interfaccia.
Deployment
Attualmente, Mothics e Mothics Analysis sono due software separati, viste le divergenze emerse nello sviluppo degli applicativi.
Disaccoppiamento e stream di dati
Allo stato attuale, Aggregator è a tutti gli effetti la fonte dei
dati; con l’aggiunta di un metodo o attributo per la lettura di track
già esistenti e di un “orologio interno” (i.e. un loop di durata
pari a quella della track, o a suoi multipli), è possibile emulare il
“comportamento dei dati” in tempo reale e di visualizzarli in maniera analoga.
Stream dei dati non-live
Il passaggio dei dati raccolti in tempo reale alla WebApp avviene
grazie a una Track creata e aggiornata in tempo reale da
Aggregator e richiamata attraverso un getter.
Per mostrare i dati presenti su un file .json, Aggregator non è
utile ai nostri scopi: occorre semplicemente una Track con un metodo
get_current() che fornisce incrementalmente i dati a ogni chiamata.
Il metodo get_current() mantiene un’indice interno delle chiamate
ricevute; a ogni chiamata, è generata una traccia fittizia che
contiene un numero di DataPoint pari al numero di chiamate ricevute da
get_current(). In pratica, a ogni chiamata del metodo è inserito un
nuovo punto dati, agendo come se esso fosse stato appena inserito da
Aggregator.
Stato delle UR
Un altro elemento da disaccoppiare è la verifica dello stato dei sensori.
I tre possibili stati delle unità remote sono:
- online (verde): l’UR è attiva e prende attivamente dati
- non-communicating (giallo): l’UR non ha inviato dati negli ultimi 30s, o c’è un problema di comunicazione con l’UC
- offline (rosso): l’UR non comunica con l’UC.
In una certa misura, lo stato dei sensori è un’informazione derivata
dai dati ottenuti dai sensori stessi, ergo può essere ricavata in
maniera indipendente, e non necessariamente in fase di presa dati.
Dunque, è necessario memorizzare in fase di aggregazione
(Aggregator.aggregate) il timestamp dell’ultimo dato raccolto da un
dato sensore e il timestamp dell’istante nel quale è avvenuta
l’aggregazione dei dati dei sensori; l’informazione è recuperata in
WebApp e, attraverso una funzione helper, convertita nello stato
del sensore.
Questo disaccoppiamento permette di implementare più facilmente le routine necessarie per caricare un file da analizzare post-mortem.
Funzionalità
Al minimo, Mothics Analysis deve:
- gestire un database locale (e potenzialmente remoto) di tracks, i.e. dati raccolti durante un’uscita in mare
- permettere la selezione di una singola track e di visualizzarne i dati in maniera sintetica e interattiva
- confrontare i dati (perlomeno medi) fra varie tracks (obiettivo successivo).
Database
Le varie tracks possono essere esportati in .json ed essere gestiti
con TinyDB o un database relazionale più serio. Pare che TinyDB
sia abbastanza versatile per giocare coi dati.
Alcuni riferimenti:
Salvataggio
Il salvataggio dei dati concerne esclusivamente la versione di Mothics sulle UC. Esso deve avvenire in diversi momenti
- periodicamente, con una certa frequenza (checkpoint) per tutelarsi da eventuali avarie dell’UC (batterie scariche, danni, …)
- al termine del ciclo di
Aggregator - su segnale fornito dall’utente.
Queste necessità suggeriscono l’introduzione di due modalità operative
- campionamento continuo dall’attivazione allo spegnimento dell’UC
- campionamento on demand, iniziato e terminato dall’utente a piacimento.
La scelta della modalità di campionamento avviene con l’attributo
save_mode di Aggregator.
Campionamento continuo (Aggregate.save_mode='continuous')
Questa è la modalita “di default” in fase di testing di Mothics e dell’hardware, in particolar modo in assenza della pulsantiera di bordo per comunicare direttamente con l’UC.
Si divide in due fasi:
- presa di checkpoint a un intervallo di tempo deciso dall’utente
- salvataggio finale al termine del ciclo di
Aggregator.
Campionamento on demand (Aggregate.save_mode='on-demand')
Questa è la modalità finale, prevista sull’implementazione di produzione dell’UC.
Di default, Aggregator non registra i dati fino alla pressione di un
pulsante di avvio nell’interfaccia grafica (e fisica, attraverso una
pulsantiera); essa termina in maniera analoga alla pressione di un
pulsante di interruzione. Per far ciò, occorrono due metodi di
Aggregator (e.g. start_save, stop_save) che
- all’avvio del campionamento, attivano la procedura di checkpointing
- all’interruzione, salvano la track finale e disattivano il checkpointing.
Artefatti
I checkpoint sono artefatti del campionamento associati a ogni track,
utili in caso di spegnimento improvviso dell’UC.
Per entrambe le procedure di salvataggio, essi vanno rimossi solamente
al termine del ciclo di Aggregator, ovvero dopo che la track è stata
registrata.
Interfaccia web
Si mantiene l’interfaccia basata su flask e HTML
jinja-templating. Le due versioni del software differiscono sia in
funzionalità proposte, che in logica.
Visualizzazione
Quali dati devono essere visualizzati nelle due versioni del codice? (…inserire note da lavagne delle riunioni di novembre/dicembre 2024)
Flask: applicazioni web con Python
Alcuni riferimenti:
Grafici interattivi: Flask e Bokeh
In linea di massima è possibile mostrare grafici interattivi su pagine web con Bokeh. Sono disponibili due modalità principali:
- standalone documents: script indipendenti, che non richiedono un server Bokeh attivo e garantiscono un livello limitato di interazione; non si aggiornano dinamicamente, e.g. all’arrivo di nuovi dati
- Bokeh applications: applicazioni totalmente interattive, che si appoggiano a un server Bokeh in background; possono aggiornarsi dinamicamente.
Un’alternativa ben più efficace in termini di tempi di esecuzione e
carico di lavoro per il processore è basata su JavaScript (sigh) e
su pacchetti come Plotly, attualmente adoperati per mostrare i
grafici in tempo reale su WebApp.
Alcuni riferimenti:
