Livello di raccolta dati

Struttura e composizione del livello di raccolta dati

Il livello di raccolta dati è un componente chiave di Piattaforma IIoT che assicura l’integrazione con i dispositivi. Comprende un insieme di applicazioni specializzate, ciascuna progettata per interagire con un tipo specifico di dispositivo IoT (contatori, sensori e così via). Queste applicazioni funzionano come servizi di rete, gestendo le connessioni in ingresso tramite porte dedicate e governando il trasferimento dei dati tra i dispositivi e la piattaforma. Questa architettura garantisce scalabilità e flessibilità nel lavoro con apparecchiature eterogenee.

La struttura e la composizione delle applicazioni del livello di raccolta dati sono riassunte di seguito:

flowchart TD
    A(Household energy meters) <-->|Data transfer| B("Data collection daemon (Type-J)")
    C(Industrial energy meters) <-->|Data transfer| D("Data collection daemon (Type-T)")
    E(Smart sensors) <-->|Data transfer| F("Data collection daemon (DDT)")
    subgraph " "
    B("Data collection daemon (Type-J)") <--> I{"Balancer (Pgbouncer)"}
    D("Data collection daemon (Type-T)") <--> I{"Balancer (Pgbouncer)"}
    F("Data collection daemon (DDT)") <--> I{"Balancer (Pgbouncer)"}
    X@{ shape: braces, label: "Data Polling Subsystem" }
    end
    I{"Balancer (Pgbouncer)"} <--> J[(DBMS PostgreSQL)]

Gli scambi con i dispositivi terminali avvengono tramite una connessione TCP, e ciascun daemon di raccolta implementa il proprio protocollo applicativo di scambio per servire un particolare tipo di dispositivo IoT.

Questi daemon condividono alcune caratteristiche architetturali comuni, descritte di seguito.

Caratteristiche dell’architettura

• Ogni container include un’applicazione specializzata per un determinato protocollo.
• Si utilizzano immagini di base leggere (alpine nella configurazione di base) per ridurre al minimo l’overhead. È tuttavia possibile creare immagini per il sistema operativo del cliente.
• Per gestire le dipendenze tra i servizi (come l’accesso al database), in Docker Compose vengono specificate le sezioni depends_on e health-check.
• I daemon definiti in Compose vengono eseguiti in più istanze (repliche) per distribuire il carico. In questo modo, ogni daemon di raccolta è in grado di servire contemporaneamente decine di migliaia di connessioni.
• Un bilanciatore (HAProxy, Nginx Stream) indirizza il traffico verso i daemon disponibili utilizzando gli algoritmi Round Robin o Least Connections.
• Negli ambienti cloud è possibile aggiungere il ridimensionamento automatico basato su metriche (CPU, numero di connessioni).
• Tutte le comunicazioni con i dispositivi vengono registrate in dettaglio su file, così da poter essere analizzate qualora vengano rilevati problemi o guasti.

Principi di scambio dei dati

Di seguito è riportato lo schema di una sessione di comunicazione tra un dispositivo IoT e il daemon di raccolta:

sequenceDiagram
    autonumber
    participant D as IoT device
    participant I as Data collection <br/>daemon
    Note over I,D: Stages of interaction
    D->>I: Session start, authentication
    I-->>D: Sending request parameters
    D->>I: Data acquisition
    I-->>D: Sending the next session time

Principi di organizzazione dello scambio dei dati:

• Avvio di una sessione di comunicazione.
  Una sessione di comunicazione è sempre avviata dal dispositivo IoT. Dopo aver stabilito una connessione con il daemon di raccolta dati, il dispositivo trasmette un pacchetto di identificazione.

• Procedura di autenticazione
  Il daemon di raccolta dati autentica il dispositivo. Se l’autenticazione ha esito positivo, esegue:

  • Il recupero dal database della configurazione salvata del dispositivo.
  • L’invio al dispositivo delle impostazioni correnti dell’interfaccia.

• Trasferimento dei dati
  In base alla richiesta ricevuta, il dispositivo trasferisce al server di raccolta:

  • Le letture correnti del dispositivo.
  • Le registrazioni archiviate (se presenti).

• Pianificazione della sessione successiva
  Una volta completata la ricezione dei dati, il daemon di raccolta:

  • Genera il timestamp della sessione successiva.
  • Trasmette al dispositivo il timestamp della sessione successiva.
  • Avvia la chiusura della connessione.

• Elaborazione e archiviazione dei dati
  Le informazioni ricevute vengono:

  • Aggregate in oggetti JSON strutturati.
  • Memorizzate in un database PostgreSQL intermedio.
  • Formattate secondo la specifica di protocollo di un particolare daemon.

• Integrazione con il sistema di controllo
  I dati diventano disponibili al livello superiore del sistema (sottosistema di gestione) per:

  • L’ulteriore elaborazione analitica.
  • La visualizzazione nelle interfacce di gestione.
  • La generazione di report automatici.

Interazione con il livello di gestione della piattaforma

Architettura di interconnessione dei sottosistemi

I daemon di raccolta dati si integrano con il sistema di livello superiore (livello di gestione) attraverso un database intermedio. Per abilitare questa interazione si utilizza un container Docker con un DBMS PostgreSQL installato.

I risultati delle interazioni andate a buon fine con i dispositivi vengono salvati automaticamente dai daemon in una tabella dedicata dello stesso database, garantendo la trasparenza del trasferimento dei dati tra il livello di controllo e i dispositivi.

Lo schema di interazione dei sottosistemi è mostrato di seguito:

flowchart LR
A@{ shape: procs, label: "Data Polling Subsystem"} -->|Readings data| B[(DBMS PostgreSQL)]
B[(DBMS PostgreSQL)] -->|Configuration| A@{ shape: procs, label: "Data Polling Subsystem"}
B[(DBMS PostgreSQL)] -->|Readings data| C@{ shape: procs, label: "Control Subsystem"}
C@{ shape: procs, label: "Control Subsystem"} -->|Configuration| B[(DBMS PostgreSQL)]

Configurazione del dispositivo

La configurazione del dispositivo include le seguenti informazioni:

• Date delle ultime letture per archivio: orario, giornaliero, mensile. Questi parametri indicano la data a partire dalla quale devono essere letti i dati dell’archivio corrispondente.
• Codice del dispositivo di misura (per i dispositivi IoT che utilizzano il protocollo Type-T). Questo parametro è richiesto solo per i daemon di raccolta che servono il protocollo Type-T e indica al server di raccolta quale algoritmo utilizzare per lavorare con il dispositivo.
• Velocità della porta seriale (per i dispositivi IoT che eseguono il protocollo Type-T). Questo parametro indica al dispositivo IoT con quale velocità deve comunicare con il contatore. Il daemon di raccolta lo invia all’inizio di una sessione di scambio.
• Pianificazione delle comunicazioni. Il sottosistema di gestione salva tutte le pianificazioni in un database intermedio, e il daemon di raccolta calcola la data più prossima a partire dalle pianificazioni ricevute e la invia al dispositivo.
• Comandi di controllo del dispositivo. A seconda del tipo di dispositivo IoT e delle sue capacità, i comandi di gestione comprendono:
  • Un comando per aggiornare il software della parte di telemetria del dispositivo IoT. Alla ricezione di questo comando, il dispositivo scarica il nuovo firmware dal server ed esegue l’aggiornamento.
  • Un comando per rileggere la configurazione del dispositivo di misura.
  • Un comando per chiudere o aprire la valvola (se è presente una valvola ed è supportata dal software del dispositivo IoT).
  • Un comando per impostare i parametri operativi del dispositivo di misura (dipende dal modello).
  • Un comando per riavviare il dispositivo IoT.

La parte principale della configurazione del dispositivo è archiviata in un database intermedio in formato JSON.

Di seguito è riportato un esempio di configurazione:

{
  "settings": "1",
  "day_event": 1706140800,
  "hour_event": 1706140800,
  "month_event": 1673857740,
  "net_address": 58
}

Qui day_event, hour_event e month_event sono timestamp in formato unixtime delle registrazioni salvate più di recente rispettivamente degli archivi giornaliero, orario e mensile.

Le pianificazioni vengono archiviate separatamente, anch’esse in formato JSON. La stringa di pianificazione vera e propria viene composta ed elaborata in formato CRON. Questo approccio offre flessibilità nell’impostazione e nell’elaborazione di qualsiasi pianificazione.

Di seguito è riportato un esempio di archiviazione di diverse pianificazioni per un dispositivo:

[
  { "crontab": "10 * * * *", "schedule_id": 6 },
  { "crontab": "40 * * * *", "schedule_id": 7 }
]

Secondo queste pianificazioni, il dispositivo deve connettersi al minuto 10 e al minuto 40 di ogni ora. Il daemon stesso determina la pianificazione più adatta al momento della comunicazione con il dispositivo e ne trasmette quella più prossima.