Gestion des données & Architecture

IronFlock fournit une infrastructure de collecte et de stockage de données complète et de bout en bout, conçue pour la scalabilité, la sécurité et une propriété des données claire — de l’edge au cloud. Que vous routiez de la télémétrie de milliers de capteurs ou construisiez des interfaces SCADA en temps réel, l’architecture de données d’IronFlock garantit des informations sûres, isolées et accessibles.

Routage de messages et realms sécurisés

Au cœur de la communication temps réel d’IronFlock se trouve un cluster de routage de messages robuste. Cette infrastructure connecte les divers appareils edge d’un projet entre eux et à l’infrastructure cloud IronFlock.

Pour garantir une isolation et une sécurité strictes, le cluster est partitionné sémantiquement en realms sécurisés. Un realm est un sous-réseau isolé dans lequel les messages sont strictement contenus ; les données et les commandes ne peuvent ni quitter ni traverser les realms.

Les applications exécutées sur vos appareils edge utilisent le ironflock-sdk pour communiquer sur ces realms :

• Publish/Subscribe (Pub/Sub) : idéal pour diffuser en continu de la télémétrie de capteurs ou des changements d’état.
• Remote Procedure Calls (RPC) : parfait pour déclencher des actions directes ou interroger en toute sécurité l’état d’un appareil.

Bases de données de projet provisionnées dynamiquement

Pour le stockage persistant et l’analyse historique, IronFlock provisionne une base TimescaleDB dédiée et physique pour chaque projet.

Cette base de données de projet sert de point central de collecte pour chaque app installée dans le projet :

• Backends de données des apps : Tous les backends de données des apps installées dans votre projet sont hébergés en sécurité dans cette base. Installez une seconde app et elle ajoute ses propres tables à côté de la première — un projet exécutant plusieurs apps se retrouve avec toutes leurs données rassemblées au même endroit, interrogeables ensemble.
• Ingestion directe : Quand les apps d’appareil publient des données via le ironflock-sdk, ce flux est directement reçu et organisé dans la base du projet.
• Accès en lecture, avec consentement : Par défaut, une app ne lit que ses propres données, mais avec votre accord une app peut aussi lire les données d’une autre app du même projet — les apps peuvent ainsi s’appuyer sur les relevés les unes des autres. Vous contrôlez et révoquez ce partage (voir ci-dessous).

La base de données du projet agissant comme unique source de vérité pour vos opérations, elle débloque des capacités avancées :

• Requêtes SQL : Écrivez des requêtes puissantes directement sur vos tables brutes historiques.
• Intégration Physical AI : Laissez l’agent IA IronFlock extraire, analyser et interroger vos données en langage naturel.
• Source de visualisation : La base du projet est la source ultime pour les live boards, les tableaux de bord IoT et les boards SCADA.

Transformations personnalisées

Les tables qu’une app écrit ont rarement exactement la forme de la question que vous voulez poser. Le taux de rendement synthétique combine disponibilité, performance et qualité ; un rapport d’équipe a besoin de tranches horaires ; comparer deux machines revient à joindre les tables de deux apps différentes. Une transformation personnalisée répond une fois pour toutes à ce genre de question : c’est une requête SQL, enregistrée sous un nom, qui se comporte ensuite comme n’importe quelle autre table du projet.

En créer une n’est pas une tâche de développeur d’app. Tout membre du projet disposant du privilège Accès aux données — le même qui ouvre la console de requêtes SQL — peut enregistrer une transformation, et l’assistant IA IronFlock peut en créer une sur demande lorsqu’un board a besoin d’un chiffre qu’aucune table brute ne contient. Les transformations vivent en dehors de toute app, dans l’espace IronFlock propre au projet : une seule transformation peut donc lire les tables de toutes les apps installées dans le projet.

• Écrivez la requête une seule fois. Mettez-la au point dans la console de requêtes de la vue de données du projet et choisissez Save as transform, ou rendez-vous directement sur l’onglet Transforms. Les tables sources se référencent sous la forme databackend_<key>.<table> — les noms que l’arborescence de données affiche à côté de chaque app.
• Choisissez son mode de calcul. Une transformation matérialisée stocke son résultat et le recalcule selon une planification que vous définissez, au plus une fois par minute. Une simple vue est calculée à chaque lecture : toujours à jour, mais seulement aussi rapide que sa requête.
• Décrivez ce qu’elle retourne. La transformation porte une description, et chaque colonne de résultat porte son propre nom d’affichage et sa propre description. Ils sont stockés avec la transformation dans la base de données : c’est ce qu’affiche l’éditeur de widget et ce que lit l’assistant IA — une transformation bien décrite reste utilisable correctement par l’assistant des mois plus tard.
• Liez-la comme une table. La transformation apparaît dans le sélecteur de données de l’éditeur de widget sous IronFlock, à côté des tables de chaque app, et alimente le même canal live : quand elle se rafraîchit, les boards qui y sont liés se rafraîchissent.

Écrire une transformation qui se comporte bien

Une transformation retourne exactement les lignes que son propre SQL sélectionne. Les fenêtres temporelles des widgets, les filtres de calendrier et le mode latest s’appliquent aux tables et sont ignorés ici, d’où trois habitudes à prendre :

• Bornez la plage de temps dans la requête, par exemple WHERE tsp > now() - interval '7 days'. Une lecture unique est en outre plafonnée à 3000 lignes : agrégez donc dans la requête plutôt que de sélectionner l’historique brut.
• Triez une série temporelle de la plus récente à la plus ancienne (ORDER BY <colonne de temps> DESC). Les widgets reçoivent alors les lignes de la plus ancienne à la plus récente, et lorsqu’une limite de lignes s’applique, elle conserve les plus récentes.
• Sélectionnez toutes les colonnes que vous voulez tracer ou filtrer. Une transformation n’a pas de colonnes d’horodatage ou d’appareil cachées : un widget ne peut utiliser que ce que la requête retourne réellement.

Si une transformation cesse de fonctionner — une app qu’elle lit a été désinstallée, une colonne qu’elle utilisait a disparu —, l’onglet Transforms en indique la raison et les autres transformations continuent de tourner. Lire une transformation sur un board suit les mêmes règles d’accès que les données de n’importe quelle app ; Accès aux données ne régit que qui peut en écrire une.

Les développeurs d’apps peuvent au contraire livrer des transformations avec une app, déclarées dans son schéma de données — voir Tables de transformation. Les deux sortes se lisent de la même manière.

Le magasin de fichiers du projet

Tout ce qu’une app produit ne tient pas dans une table. Aux côtés de la base de données du projet, chaque projet dispose d’un magasin de fichiers privé pour les objets — images de caméra, rapports PDF, images de firmware, extraits audio, exports — régi exactement par les mêmes principes que la base de données.

• Chaque app reçoit automatiquement du stockage. Lorsqu’une app est installée, IronFlock lui provisionne une zone de stockage privée dans le magasin de fichiers du projet, tout comme il provisionne les tables de base de données de l’app. Plusieurs apps regroupent leurs fichiers dans l’unique magasin du projet, les objets de chaque app étant clairement séparés de ceux des autres.
• Les mêmes garanties de propriété s’appliquent. Les fichiers appartiennent au propriétaire du projet, pas au développeur de l’app. Vous pouvez les parcourir, les télécharger, les plafonner et les supprimer, et le développeur d’une app ne peut pas voir les fichiers qu’elle collecte pendant son exécution dans votre projet.
• Les fichiers se lient directement à vos données. Un objet stocké porte une URL permanente et à accès contrôlé qu’une app peut écrire dans une colonne de base de données — ainsi un widget de tableau de bord affiche l’image ou le document sans travail supplémentaire, et révoquer l’accès d’un utilisateur au projet lui retire aussi la capacité de récupérer les fichiers.
• Vous gouvernez le budget. Les paramètres de stockage de chaque app indiquent combien elle utilise et vous permettent de définir une limite de stockage, de vider une table ou de supprimer tous les fichiers d’une app. Et pour les outils extérieurs à la plateforme — un analyste avec DuckDB, une sauvegarde nocturne — vous pouvez émettre des identifiants S3 en lecture seule limités aux fichiers d’une seule app.

Le magasin de fichiers est consultable juste à côté des tables : la vue de données du projet affiche une entrée Fichiers pour chaque app, listant chaque objet stocké avec sa taille, son type et sa date. Pour les détails côté développeur — déclarer le stockage, les namespaces, la rétention et les appels SDK — voir Stockage de fichiers.

Partager des données entre apps

Les apps d’un même projet sont isolées par défaut : chacune lit et écrit uniquement ses propres tables et ses propres fichiers. C’est le point de départ sûr — une app que vous avez installée pour mesurer l’énergie n’a aucune raison de lire les photos d’inspection d’une autre app, sauf si vous en décidez ainsi.

Mais les apps devraient souvent collaborer — une app d’analytique lisant l’historique d’une app de surveillance, une app de reporting récupérant les photos d’une app de qualité. IronFlock rend cela possible via une seule décision de consentement que vous contrôlez, dans les paramètres de l’app consommatrice :

• Vous approuvez précisément quels fournisseurs une app peut lire, et vous voyez la raison invoquée par l’app pour vouloir cet accès. Rien n’est partagé sans votre approbation explicite.
• Une seule autorisation couvre les deux moitiés du hub — les tables partagées de l’app fournisseur et ses fichiers partagés. Vous ne gérez pas séparément les permissions de base de données et de fichiers.
• L’accès est en lecture seule. Une app consommatrice peut consulter les données d’une autre app mais jamais les modifier ni les supprimer.
• Vous pouvez révoquer à tout moment, et l’accès cesse immédiatement.

Ce qui est même proposé au partage relève de la décision du développeur de l’app, prise par table et par namespace de fichiers — certaines données, une app les garde strictement internes, et elles n’apparaissent jamais comme quelque chose que vous pourriez accorder. Parmi ce qui est partageable, c’est vous qui décidez de le partager réellement. Les mécanismes côté développeur sont documentés dans Consommer les données d’autres apps.

Propriété des données & EU Data Act

IronFlock repose sur un principe clair : le propriétaire du projet est le propriétaire des données — pas le développeur de l’app.

Toutes les données produites par les apps — flux de télémétrie d’appareils edge, journaux d’événements ou analytique dérivée — sont stockées dans la base de données du projet, qui appartient au propriétaire du projet. Le développeur écrit l’app, mais les données générées par cette app à l’intérieur d’un projet sont la propriété exclusive du projet qui l’héberge.

Ce modèle s’aligne directement avec les exigences du EU Data Act, qui accorde aux utilisateurs de produits connectés et services associés le plein contrôle des données générées par leurs appareils. Dans IronFlock :

• Contrôle exclusif. Le propriétaire du projet a un contrôle administratif total sur la base de données du projet — lecture, export, suppression, sauvegarde de toutes les données.
• Aucune collecte silencieuse. Les développeurs d’apps n’accèdent pas aux données d’un projet sans y être explicitement invités. Il n’existe aucune pipeline cachée des projets vers les développeurs.
• Portabilité. Comme toutes les données résident dans une instance TimescaleDB standard, elles peuvent être interrogées en SQL, exportées dans des formats ouverts et migrées à volonté — pas de verrouillage fournisseur.
• Partage granulaire. Le propriétaire peut inviter des développeurs, partenaires d’intégration ou autres parties prenantes dans le projet et leur accorder des droits d’accès fins sur des zones de données spécifiques. Utile pour bénéficier de support technique tiers, de maintenance à distance ou d’analytique spécialisée — aux conditions définies par le propriétaire et révocables à tout moment.

En résumé : les apps produisent les données, mais le propriétaire du projet les possède, les contrôle et les partage. Ce modèle de propriété est un objectif de conception de premier ordre de la plateforme IronFlock — pas une réflexion après coup.

Opt-out : contourner la pipeline de données IronFlock

La couche de messagerie IronFlock et la base de données du projet sont la voie recommandée — elles offrent routage temps réel, stockage durable, données prêtes pour les tableaux de bord et garanties de propriété intégrées. IronFlock n’impose cependant pas aux apps d’utiliser cette pipeline.

Les apps exécutées sur des appareils gérés par IronFlock sont des workloads conteneur classiques et conservent toute leur liberté réseau et système. Si un propriétaire de projet ou un développeur préfère une autre stack de données, une app peut :

• Pousser vers des systèmes externes. Envoyer les données directement à des brokers tiers (MQTT, Kafka, AMQP), à des endpoints d’ingestion cloud (AWS IoT, Azure IoT Hub, Google Cloud IoT) ou à des API REST / gRPC sur mesure.
• Utiliser un stockage alternatif. Écrire dans une base externe (InfluxDB, MongoDB, S3, TimescaleDB client, etc.) au lieu de — ou en plus de — la base du projet IronFlock.
• Ponter vers des systèmes on-premises. S’intégrer directement à des systèmes MES, ERP, historian ou SCADA existants sur le réseau local, sans passer par le cloud IronFlock.
• Combiner. Publier un sous-ensemble de données sur IronFlock pour les tableaux de bord et l’analyse IA, tout en streamant les données complètes ailleurs.

Cette flexibilité fait d’IronFlock un bon choix aussi bien pour les déploiements greenfield adoptant la plateforme de bout en bout que pour les intégrations dans des architectures de données existantes où la destination des données n’est pas négociable.

Utiliser les données dans les tableaux de bord IoT et SCADA

Transformer vos données en visuels est simple. Lors de la configuration d’un widget sur votre board IoT ou SCADA, presque toutes les propriétés (p. ex., titres, valeurs, couleurs) peuvent être liées dynamiquement à des données live de la base du projet.

En éditant un widget dans le Board Studio, vous trouverez un interrupteur de liaison de données sous les champs de configuration. Sélectionner une colonne précise d’une table établit un canal temps réel pour cette propriété. Dès que de nouvelles données arrivent dans la base, les propriétés liées du tableau de bord se mettent à jour automatiquement en temps réel, sans rafraîchissement manuel.

Note : Pour un approfondissement sur la connexion des propriétés de widgets à votre base de données, voir la section détaillée sur la liaison de données dans la documentation des tableaux de bord IoT.