Gestione dei Dati e Architettura

IronFlock fornisce un’infrastruttura completa end-to-end per la raccolta e l’archiviazione dei dati, progettata per scalabilità, sicurezza e chiara proprietà dei dati — dall’edge al cloud. Che tu stia instradando telemetria da migliaia di sensori o costruendo interfacce SCADA in tempo reale, l’architettura dei dati di IronFlock garantisce informazioni sicure, isolate e accessibili.

Routing dei messaggi e realm sicuri

Il cuore della comunicazione in tempo reale di IronFlock è un robusto cluster di routing dei messaggi. Questa infrastruttura di messaggistica collega tra loro i diversi dispositivi edge di un progetto e li connette all’infrastruttura cloud di IronFlock.

Per garantire sicurezza e isolamento stretti, il cluster di routing è partizionato semanticamente in realm sicuri. Un realm è una sotto-rete isolata in cui i messaggi sono strettamente contenuti; dati e comandi non possono né lasciare né attraversare i realm.

Le applicazioni in esecuzione sui tuoi dispositivi edge usano l’ironflock-sdk per comunicare su questi realm:

• Publish/Subscribe (Pub/Sub): ideale per trasmettere in continuo telemetria dei sensori o cambi di stato.
• Remote Procedure Calls (RPC): perfetto per attivare azioni dirette o interrogare in sicurezza lo stato dei dispositivi.

Database di progetto provisionati dinamicamente

Per l’archiviazione persistente e l’analisi storica, IronFlock provisiona un database TimescaleDB dedicato e fisico per ogni progetto.

Questo database di progetto funge da punto centrale di raccolta dati per ogni app installata nel progetto:

• Backend dati delle app: Tutti i backend dati delle app installate nel tuo progetto sono ospitati in sicurezza in questo database. Installa una seconda app e questa aggiunge le proprie tabelle accanto alla prima — un progetto che esegue diverse app raccoglie tutti i loro dati in un unico luogo, interrogabili insieme.
• Ingestione diretta: Quando le app sui dispositivi pubblicano dati con l’ironflock-sdk, quel flusso viene ricevuto e organizzato direttamente nel database del progetto.
• Accesso in lettura, con consenso: Per impostazione predefinita un’app legge solo i propri dati, ma con la tua approvazione un’app può anche leggere i dati di un’altra app nello stesso progetto — così le app possono basarsi sulle letture reciproche. Sei tu a controllare e revocare tale condivisione (vedi sotto).

Poiché il database del progetto funge da unica fonte di verità per le tue operazioni, sblocca funzionalità avanzate:

• Query SQL: Scrivi query potenti direttamente sulle tue tabelle grezze storiche.
• Integrazione Physical AI: Lascia che l’agente AI di IronFlock estragga, analizzi e interroghi i tuoi dati usando il linguaggio naturale.
• Fonti di visualizzazione: Il database del progetto è la fonte definitiva per live board, dashboard IoT e board SCADA.

Trasformazioni personalizzate

Le tabelle che un’app scrive hanno raramente la forma esatta della domanda che vuoi porre. L’efficienza complessiva degli impianti (OEE) combina disponibilità, prestazioni e qualità; un report di turno ha bisogno di bucket orari; confrontare due macchine significa unire le tabelle di due app diverse. Una trasformazione personalizzata risponde una volta per tutte a una domanda di questo tipo: è una query SQL, salvata sotto un nome, che da quel momento si comporta come qualsiasi altra tabella del progetto.

Crearne una non è un compito da sviluppatore di app. Qualsiasi membro del progetto con il privilegio Data Access — lo stesso che apre la console per le query SQL — può salvare una trasformazione, e l’assistente AI di IronFlock può crearne una su richiesta quando una board ha bisogno di un valore che nessuna tabella grezza contiene. Le trasformazioni vivono al di fuori di ogni app, nello spazio IronFlock del progetto stesso, così una singola trasformazione può leggere trasversalmente le tabelle di tutte le app installate nel progetto.

• Scrivi la query una volta sola. Sviluppala nella console per le query della vista dati del progetto e scegli Salva come trasformazione, oppure vai direttamente alla scheda Trasformazioni che trovi lì. Le tabelle sorgente si referenziano come databackend_<key>.<table> — i nomi che l’albero dei dati mostra accanto a ogni app.
• Scegli come viene calcolata. Una trasformazione materializzata memorizza il proprio risultato e lo ricalcola secondo una pianificazione che imposti tu, al massimo una volta al minuto. Una semplice vista viene calcolata a ogni lettura: sempre aggiornata, ma veloce quanto la sua query.
• Descrivi ciò che restituisce. La trasformazione porta con sé una descrizione, e ogni colonna del risultato ha a sua volta un nome visualizzato e una propria descrizione. Sono memorizzati insieme alla trasformazione nel database: è ciò che l’editor dei widget mostra ed è ciò che l’assistente AI legge — una trasformazione ben descritta è una trasformazione che l’assistente saprà usare correttamente anche mesi dopo.
• Collegala come una tabella. La trasformazione appare nel selettore dati dell’editor dei widget sotto IronFlock, accanto alle tabelle di ogni app, e alimenta lo stesso canale live: quando si aggiorna, si aggiornano anche le board a essa collegate.

Scrivere una trasformazione che si comporta bene

Una trasformazione restituisce esattamente le righe che il suo SQL seleziona. Le finestre temporali dei widget, i filtri di calendario e la modalità latest si applicano alle tabelle e qui vengono ignorati, il che rende utili tre abitudini:

• Limita l’intervallo temporale all’interno della query, ad esempio WHERE tsp > now() - interval '7 days'. Una singola lettura è inoltre limitata a 3000 righe, quindi aggrega nella query invece di selezionare la cronologia grezza.
• Ordina una serie temporale dalla più recente (ORDER BY <time column> DESC). I widget ricevono poi le righe dalla più vecchia alla più recente e, dove si applica un limite di righe, vengono mantenute le più recenti.
• Seleziona ogni colonna che vuoi rappresentare o usare come filtro. Una trasformazione non ha colonne timestamp o dispositivo nascoste: un widget può usare solo ciò che la query restituisce davvero.

Se una trasformazione smette di funzionare — un’app da cui legge è stata disinstallata, una colonna che usava è scomparsa — la scheda Trasformazioni ne mostra il motivo e le altre trasformazioni continuano a funzionare. Leggere una trasformazione su una board segue le stesse regole di accesso dei dati di qualsiasi app; Data Access governa solo chi può scriverne una.

Gli sviluppatori di app possono invece distribuire le trasformazioni insieme a un’app, dichiarandole nel suo schema dati — vedi Tabelle di Trasformazione. Entrambi i tipi si leggono allo stesso modo.

L’archivio file di progetto

Non tutto ciò che un’app produce entra in una tabella. Accanto al database del progetto, ogni progetto dispone di un archivio file privato per gli oggetti — fotogrammi delle telecamere, report PDF, immagini firmware, clip audio, esportazioni — governato esattamente dagli stessi principi del database.

• Ogni app ottiene automaticamente lo storage. Quando un’app viene installata, IronFlock le provisiona un’area di storage privata nell’archivio file del progetto, esattamente come provisiona le tabelle di database dell’app. Diverse app riuniscono i propri file nell’unico archivio del progetto, con gli oggetti di ciascuna app chiaramente separati da quelli delle altre.
• Valgono le stesse garanzie di proprietà. I file appartengono al proprietario del progetto, non allo sviluppatore dell’app. Puoi sfogliarli, scaricarli, limitarli ed eliminarli, e lo sviluppatore di un’app non può vedere i file che essa raccoglie mentre è in esecuzione nel tuo progetto.
• I file si collegano direttamente ai tuoi dati. Un oggetto archiviato porta con sé un URL permanente e con accesso controllato che un’app può scrivere in una colonna del database — così un widget di dashboard mostra l’immagine o il documento senza alcun lavoro aggiuntivo, e revocare a un utente l’accesso al progetto revoca anche la sua capacità di recuperare i file.
• Tu governi il budget. Le impostazioni di storage di ciascuna app mostrano quanto sta utilizzando e ti permettono di impostare un limite di storage, svuotare una tabella o eliminare tutti i file di un’app. E per gli strumenti esterni alla piattaforma — un analista con DuckDB, un backup notturno — puoi emettere credenziali S3 di sola lettura limitate ai file di una singola app.

L’archivio file è consultabile proprio accanto alle tabelle: la vista dati del progetto mostra una voce File per ogni app, elencando ogni oggetto archiviato con dimensione, tipo e data. Per i dettagli lato sviluppatore — dichiarazione dello storage, namespace, retention e le chiamate SDK — consulta Archiviazione dei file.

Condivisione dei dati tra app

Le app nello stesso progetto sono isolate per impostazione predefinita: ciascuna legge e scrive solo le proprie tabelle e i propri file. È questo il punto di partenza sicuro — un’app installata per misurare l’energia non ha motivo di leggere le foto di ispezione di un’altra app, a meno che tu non decida che debba farlo.

Ma spesso le app dovrebbero collaborare — un’app di analytics che legge lo storico di un’app di monitoraggio, un’app di reportistica che recupera le foto da un’app di qualità. IronFlock lo rende possibile attraverso un’unica decisione di consenso che controlli tu, nelle impostazioni dell’app consumatrice:

• Approvi esattamente quali provider un’app può leggere, e vedi la motivazione che l’app fornisce per voler accedere. Nulla viene condiviso senza la tua approvazione esplicita.
• Un’unica concessione copre entrambe le metà dell’hub — le tabelle condivise dell’app provider e i suoi file condivisi. Non gestisci separatamente i permessi di database e di file.
• L’accesso è di sola lettura. Un’app consumatrice può visualizzare i dati di un’altra app ma non può mai modificarli né eliminarli.
• Puoi revocare in qualsiasi momento, e l’accesso si interrompe immediatamente.

Ciò che viene addirittura offerto per la condivisione è una decisione dello sviluppatore dell’app, presa per ogni tabella e per ogni namespace di file — alcuni dati un’app li mantiene strettamente interni, e questi non compaiono mai come qualcosa che potresti concedere. Di ciò che è condivisibile, sei tu a decidere se condividerlo davvero. I meccanismi lato sviluppatore sono documentati in Consumare i dati di altre app.

Proprietà dei dati ed EU Data Act

IronFlock si basa su un principio chiaro: il proprietario del progetto è il proprietario dei dati — non lo sviluppatore dell’app.

Tutti i dati prodotti dalle app — flussi di telemetria dai dispositivi edge, log di eventi o analisi derivate — sono archiviati nel database del progetto che appartiene al proprietario del progetto. Lo sviluppatore scrive l’app, ma i dati che quell’app genera all’interno di un progetto sono proprietà esclusiva del progetto che la ospita.

Questo modello si allinea direttamente ai requisiti dell’EU Data Act, che concede agli utenti di prodotti connessi e servizi correlati il pieno controllo sui dati generati dai loro dispositivi. In IronFlock:

• Controllo esclusivo. Il proprietario del progetto ha pieno controllo amministrativo sul database del progetto — può leggere, esportare, eliminare e fare backup di tutti i dati.
• Nessuna raccolta silenziosa. Gli sviluppatori delle app non possono accedere ai dati di un progetto senza essere esplicitamente invitati. Non esistono pipeline nascoste dai progetti verso gli sviluppatori.
• Portabilità. Poiché tutti i dati risiedono in un’istanza TimescaleDB standard, possono essere interrogati con SQL, esportati in formati aperti e migrati a piacere — nessun vendor lock-in.
• Condivisione granulare. Il proprietario può invitare sviluppatori di app, partner di integrazione o altri stakeholder nel progetto e concedere privilegi di accesso granulari a specifiche aree di dati. Utile per sfruttare supporto tecnico di terze parti, manutenzione remota o analytics specializzati — alle condizioni definite dal proprietario e revocabili in qualsiasi momento.

In sintesi: le app producono dati, ma il proprietario del progetto li possiede, li controlla e li condivide. Questo modello di proprietà è un obiettivo di progettazione di primo livello della piattaforma IronFlock, non un ripensamento.

Opt-out: bypassare la pipeline dati IronFlock

Il livello di messaggistica IronFlock e il database del progetto sono la via raccomandata — offrono routing in tempo reale, archiviazione duratura, dati pronti per le dashboard e garanzie di proprietà integrate. Tuttavia, IronFlock non obbliga le app a usare questa pipeline.

Le app in esecuzione sui dispositivi gestiti da IronFlock sono normali workload container e mantengono piena libertà di rete e di sistema. Se un proprietario di progetto o uno sviluppatore preferisce un diverso stack di gestione dati, un’app può:

• Inviare a sistemi esterni. Mandare i dati direttamente a broker di terze parti (MQTT, Kafka, AMQP), a endpoint cloud di ingestione (AWS IoT, Azure IoT Hub, Google Cloud IoT) o ad API REST / gRPC personalizzate.
• Usare storage alternativi. Scrivere in un database esterno (InfluxDB, MongoDB, S3, TimescaleDB di proprietà del cliente, ecc.) — al posto o in aggiunta al database di progetto IronFlock.
• Collegare sistemi on-premises. Integrarsi direttamente con sistemi MES, ERP, historian o SCADA esistenti sulla rete locale, senza toccare il cloud IronFlock.
• Mixare. Pubblicare un sottoinsieme di dati su IronFlock per dashboard e AI analytics, mentre si trasmette la telemetria completa altrove.

Questa flessibilità rende IronFlock adatto sia a deployment greenfield che abbracciano la piattaforma end-to-end sia a integrazioni in architetture dati enterprise esistenti in cui la destinazione dei dati non è negoziabile.

Uso dei dati in dashboard IoT e board SCADA

Mettere i dati al lavoro visivamente è semplice. Quando configuri un widget sul tuo board IoT o SCADA, quasi tutte le proprietà (ad esempio titoli, valori, colori) possono essere associate dinamicamente a dati live dal database del progetto.

Durante la modifica di un widget nel Board Studio, troverai un interruttore di associazione dati sotto i campi di configurazione. Selezionare una colonna specifica di una tabella crea un canale in tempo reale per quella proprietà. Non appena arriva nuova telemetria nel database, le proprietà associate sulla dashboard si aggiornano automaticamente in tempo reale, senza refresh manuale.

Nota: Per un approfondimento sulla connessione delle proprietà dei widget al tuo database, consulta la sezione dedicata all’associazione dati nella documentazione delle Dashboard IoT.