Etna

1. Introduzione e Scopo

Etna è un progetto software per la creazione di una pipeline automatizzata per il monitoraggio multi-parametrico del Monte Etna. Lo scopo è acquisire dati da fonti aperte (sismici, infrasuoni, geochimici), elaborarli per estrarre caratteristiche significative e sperimentare l’uso di tecniche di Intelligenza Artificiale, come gli embeddings e i Large Language Models (LLM), per creare rappresentazioni “AI-ready” dei dati vulcanologici.

Il sistema gestisce l’intero ciclo di vita del dato:

2. Contesto e Motivazioni

Questo progetto non intende sostituire i sistemi di monitoraggio ufficiali dell’INGV. Nasce come un’esplorazione tecnica e didattica per affrontare le sfide legate al trattamento di dati eterogenei e per valutare come le moderne tecniche di AI possano arricchire l’analisi automatizzata e semi-automatizzata dei fenomeni vulcanici.

3. Architettura del Sistema

L’architettura è basata su microservizi containerizzati e orchestrati con docker-compose. Questa scelta garantisce modularità, scalabilità e portabilità.

I componenti principali sono:

Diagramma dell’Architettura

@startuml
!theme plain
title Diagramma dell’Architettura del Sistema Etna

cloud “Internet” as Cloud {
frame “FDSN Data Center” as FDSN
frame “Sorgenti Dati Gas” as GasSource
frame “API Telegram” as TelegramAPI
}

actor “Utente” as User
actor “Sviluppatore/Operatore” as Operator

node “Server / Host” as Host {
frame “Docker Engine” {

    rectangle "nginx" as Nginx {  
        artifact "www/index.html" as StaticPage  
    }  
    rectangle "etna-app (Streamlit)" as App  
    rectangle "etna-api (FastAPI)" as API  
    rectangle "etna-scheduler (APScheduler)" as Scheduler  
      
    database "File System (Volumi Docker)" as Storage {  
        folder "Dati Grezzi (.mseed)"  
        folder "Dati Elaborati (.parquet)"  
        folder "Embeddings (.pt)"  
        folder "Figure e Report"  
        folder "Modelli ML"  
    }  
}   }

User -->> Nginx
Nginx -->> App
Nginx -->> API

Operator -->> App
Operator -->> API

Scheduler --> FDSN : Richiede dati sismici/infrasuoni
Scheduler --> GasSource : Richiede dati geochimici
Scheduler --> Storage : Scrive dati grezzi ed elaborati
Scheduler --> TelegramAPI : Invia notifiche

App --> Storage : Legge dati, figure, embeddings
API --> Storage : Legge dati per servire le richieste

frame “Ollama (LLM)” as Ollama

App -> Ollama : (opzionale) Interroga agenti
Scheduler -> Ollama : (opzionale) Esegue agenti

@enduml

4. Flusso di Lavoro (Pipeline)

Il scheduler è il motore della pipeline e scandisce le seguenti fasi:

  1. Acquisizione Dati:
    • Sismico e Infrasuoni: Vengono scaricati i dati in formato mseed dai server FDSN (es. INGV) per le stazioni configurate in config/stations.yaml.
    • Dati Gas: Vengono recuperati dati sulla composizione dei gas da fonti web pubbliche.
    • I dati vengono salvati localmente con una struttura a directory basata sulla data.
  2. Elaborazione e Feature Extraction:
    • I dati grezzi vengono pre-processati (filtraggio, detrending).
    • Vengono calcolate diverse feature, tra cui:
      • SSAM (Seismic Spectral Amplitude Measurement): Misura l’ampiezza spettrale media in diverse bande di frequenza.
      • RMS (Root Mean Square): Calcola l’energia del segnale nel tempo.
      • Analisi di Polarizzazione: Stima la direzionalità e la rettilinearità del segnale sismico.
      • Cross-correlazione: Analizza la somiglianza tra i segnali di diverse stazioni.
    • I risultati vengono salvati in formato Parquet per efficienza.
  3. Generazione di Embeddings:
    • Le feature elaborate (es. spettrogrammi o SSAM) vengono date in input a un Autoencoder basato su PyTorch.
    • L’output dello strato latente (encoder) del modello costituisce l’embedding: una rappresentazione vettoriale densa e a bassa dimensionalità del dato originale.
    • Gli embeddings sono progettati per catturare le caratteristiche essenziali del segnale e vengono usati per analisi di similarità, clustering e classificazione.
  4. Monitoraggio e Notifiche:
    • Il sistema controlla i valori delle ultime feature calcolate.
    • Se vengono superate soglie predefinite, vengono inviati alert tramite un bot Telegram, allegando grafici significativi.
  5. Reporting:
    • Periodicamente, vengono generati report di sintesi e visualizzazioni che vengono inviati via Telegram.

5. Componenti e Tecnologie

6. Deployment

Il deployment è interamente gestito tramite Docker e docker-compose. I servizi sono definiti nel file docker-compose.yml.

Diagramma di Deployment

@startuml
!theme plain
title Diagramma di Deployment Semplificato

cloud “GitHub / Docker Registry” as Registry {
package “etna-app:latest”
package “etna-scheduler:latest”
package “etna-api:latest”
}

node “Server (VPS, On-premise)” as Server {

artifact "docker-compose.yml" as ComposeFile  
file ".env (variabili d'ambiente)" as EnvFile  
  
node "Docker Engine" as Docker {  
    container "nginx" as NginxContainer  
    container "etna-app" as AppContainer  
    container "etna-api" as ApiContainer  
    container "etna-scheduler" as SchedulerContainer  
}  
  
database "Storage Locale (Volumi)" as FS {  
    folder "Dati"  
    folder "Config"  
}

ComposeFile ..\> Docker : orchestra  
EnvFile ..\> Docker : configura  
  
AppContainer \--u-\> FS  
ApiContainer \--d-\> FS  
SchedulerContainer \--d-\> FS

NginxContainer \--\> AppContainer  
NginxContainer \--\> ApiContainer   }

actor “Amministratore” as Admin

Admin --> Server : `docker-compose up`
Registry ..> Docker : `pull` delle immagini

@enduml

7. Interfaccia Conversazionale: GPT Expert Assistant

Un’applicazione avanzata del sistema è la possibilità di collegare un GPT Expert (come un Custom GPT di OpenAI) all’API REST per creare un assistente conversazionale specializzato.

🧠 GPT Expert: Etna Tremor Monitor Assistant

📝 Descrizione e Modalità Operativa (Prompt di sistema)

Sei un assistente AI avanzato, specializzato nell’analisi di eventi sismici e dati geofisici relativi al vulcano Etna. La tua missione è agire come un ponte intelligente tra gli esseri umani (ricercatori, tecnici, operatori di protezione civile) e i dati grezzi, trasformando le loro domande in linguaggio naturale in query precise verso le API REST.

Il tuo processo operativo è il seguente:

  1. Ascolto e Interpretazione: Analizzi la domanda dell’utente per comprendere l’intento, i parametri e i dati di interesse.
  2. Query alle API: Traduci la richiesta in una o più chiamate mirate agli endpoint disponibili.
  3. Analisi e Sintesi: Ricevi i dati in formato JSON, li analizzi, li aggreghi e identifichi le informazioni salienti.
  4. Risposta Contestualizzata: Fornisci una risposta sintetica, chiara e scientificamente corretta. Arricchisci la risposta con spiegazioni contestuali per aiutare l’utente a comprendere il significato dei dati.

Le tue potenzialità:

I tuoi limiti:

🧭 Guida all’Interazione: Come Chiedermi le Cose (Istruzioni per l’Utente)

Puoi dialogare con me in modo naturale. Per ottenere i risultati migliori e più rapidi, segui questi esempi e consigli.

📅 Ottenere gli eventi sismici recenti

📊 Conoscere quali stazioni sono più attive

📈 Visualizzare l’andamento RMS di una o più stazioni

🧭 Analizzare la direzione media delle onde (polarizzazione)

📡 Ottenere i dati di ampiezza spettrale (SSAM)

🔗 Eseguire analisi di correlazione

📄 Consultare i bollettini ufficiali INGV

🕵️ Rilevare anomalie

📜 Accedere alla politica sulla privacy

📚 Riepilogo Endpoint Principali (Per Utenti Tecnici)

Questa è una sintesi delle chiamate API che eseguo per risponderti. Conoscere questi dettagli può aiutarti a formulare richieste ancora più precise.

8. Sviluppi Futuri e Aree di Miglioramento