Datenverwaltung & Architektur

IronFlock bietet eine vollständige, durchgängige Infrastruktur für Datenerfassung und -speicherung, die auf Skalierbarkeit, Sicherheit und klare Datenhoheit ausgelegt ist — vom Edge bis in die Cloud. Ob Sie Telemetriedaten von tausenden Sensoren routen oder Echtzeit-SCADA-Oberflächen aufbauen: Die Datenarchitektur von IronFlock garantiert sichere, isolierte und zugängliche Informationen.

Nachrichten-Routing und sichere Realms

Im Zentrum der Echtzeit-Kommunikation von IronFlock steht ein robuster Nachrichten-Routing-Cluster. Diese Messaging-Infrastruktur verbindet heterogene Edge-Geräte innerhalb eines Projekts sowohl untereinander als auch mit der IronFlock-Cloud-Infrastruktur.

Zur strikten Datensicherheit und -isolation ist der Routing-Cluster semantisch in sichere Realms unterteilt. Ein Realm ist ein abgeschottetes Sub-Netzwerk, in dem Nachrichten strikt enthalten bleiben; Daten und Befehle können einen Realm weder verlassen noch überschreiten.

Anwendungen auf Ihren Edge-Geräten nutzen das ironflock-sdk, um über diese Messaging-Realms zu kommunizieren:

• Publish/Subscribe (Pub/Sub): Ideal zum kontinuierlichen Broadcasting von Sensor-Telemetrie oder Zustandsänderungen.
• Remote Procedure Calls (RPC): Perfekt, um Aktionen direkt auszulösen oder Gerätestatus sicher abzufragen.

Dynamisch bereitgestellte Projektdatenbanken

Für persistente Speicherung und historische Analysen provisioniert IronFlock für jedes Projekt eine dedizierte, physische TimescaleDB-Datenbank.

Diese Projektdatenbank dient als zentrale Datensammelstelle für jede im Projekt installierte App:

• App-Daten-Backends: Alle Daten-Backends der in Ihrem Projekt installierten Apps liegen sicher in dieser Datenbank. Installieren Sie eine zweite App, legt diese ihre eigenen Tabellen neben denen der ersten an — ein Projekt mit mehreren Apps sammelt so alle deren Daten an einem Ort, gemeinsam abfragbar.
• Direkte Ingestion: Wenn Geräte-Apps mit dem ironflock-sdk Daten publizieren, wird dieser Strom direkt in die Projektdatenbank geschrieben.
• Lesezugriff mit Einwilligung: Eine App liest standardmäßig nur ihre eigenen Daten, doch mit Ihrer Zustimmung kann eine App auch die Daten einer anderen App im selben Projekt lesen — so können Apps auf den Messwerten der jeweils anderen aufbauen. Sie steuern und widerrufen diese Freigabe (siehe unten).

Da die Projektdatenbank die Single Source of Truth Ihrer Operationen ist, eröffnet sie zahlreiche Möglichkeiten:

• SQL-Abfragen: Schreiben Sie leistungsfähige Queries direkt gegen Ihre historischen Rohtabellen.
• Physical-AI-Integration: Lassen Sie den IronFlock-AI-Agenten Ihre Daten via natürlicher Sprache extrahieren, analysieren und abfragen.
• Visualisierungsquelle: Die Projektdatenbank ist die Datenquelle für Live Boards, IoT-Dashboards und SCADA-Boards.

Benutzerdefinierte Transformationen

Die Tabellen, die eine App schreibt, haben selten genau die Form der Frage, die Sie stellen möchten. Die Gesamtanlageneffektivität verbindet Verfügbarkeit, Leistung und Qualität; ein Schichtbericht braucht Stundenintervalle; zwei Maschinen zu vergleichen heißt, die Tabellen zweier verschiedener Apps zu verknüpfen. Eine benutzerdefinierte Transformation beantwortet eine solche Frage ein für alle Mal: Sie ist eine SQL-Abfrage, unter einem Namen gespeichert, die sich danach wie jede andere Tabelle im Projekt verhält.

Sie anzulegen ist keine Aufgabe für App-Entwickler. Jedes Projektmitglied mit der Berechtigung Datenzugriff — derselben, die die SQL-Abfragekonsole öffnet — kann eine Transformation speichern, und der IronFlock-KI-Assistent kann auf Wunsch eine erstellen, wenn ein Board eine Kennzahl braucht, die in keiner Rohtabelle steht. Transformationen liegen außerhalb jeder App, im projekteigenen Bereich IronFlock, sodass eine einzige Transformation über die Tabellen aller im Projekt installierten Apps hinweg lesen kann.

• Schreiben Sie die Abfrage einmal. Entwickeln Sie sie in der Abfragekonsole der Datenansicht des Projekts und wählen Sie Save as transform, oder gehen Sie dort direkt auf den Reiter Transforms. Quelltabellen werden als databackend_<key>.<table> referenziert — die Namen, die der Datenbaum neben jeder App anzeigt.
• Wählen Sie, wie sie berechnet wird. Eine materialisierte Transformation speichert ihr Ergebnis und berechnet es nach einem von Ihnen festgelegten Zeitplan neu, höchstens einmal pro Minute. Eine einfache View wird bei jedem Lesezugriff berechnet: immer aktuell, aber nur so schnell wie ihre Abfrage.
• Beschreiben Sie, was sie zurückgibt. Die Transformation trägt eine Beschreibung, und jede Ergebnisspalte trägt einen eigenen Anzeigenamen und eine eigene Beschreibung. Sie werden gemeinsam mit der Transformation in der Datenbank gespeichert — das ist es, was der Widget-Editor anzeigt und was der KI-Assistent liest. Eine gut beschriebene Transformation kann der Assistent auch Monate später noch korrekt verwenden.
• Binden Sie sie wie eine Tabelle. Die Transformation erscheint in der Datenauswahl des Widget-Editors unter IronFlock, neben den Tabellen jeder App, und speist denselben Live-Kanal: Aktualisiert sie sich, aktualisieren sich die daran gebundenen Boards.

Eine Transformation schreiben, die sich gut verhält

Eine Transformation gibt genau die Zeilen zurück, die ihr eigenes SQL auswählt. Zeitfenster von Widgets, Kalenderfilter und der Modus latest gelten für Tabellen und werden hier ignoriert — daraus ergeben sich drei Gewohnheiten, die sich lohnen:

• Grenzen Sie den Zeitbereich in der Abfrage ein, zum Beispiel WHERE tsp > now() - interval '7 days'. Ein einzelner Lesezugriff ist zudem auf 3000 Zeilen begrenzt; aggregieren Sie daher in der Abfrage, statt die Rohhistorie auszuwählen.
• Sortieren Sie Zeitreihen mit den neuesten Zeilen zuerst (ORDER BY <Zeitspalte> DESC). Widgets erhalten die Zeilen dann von der ältesten zur neuesten, und wo ein Zeilenlimit greift, behält es die neuesten.
• Wählen Sie jede Spalte aus, die Sie darstellen oder nach der Sie filtern möchten. Eine Transformation hat keine verborgenen Zeitstempel- oder Gerätespalten: Ein Widget kann nur verwenden, was die Abfrage tatsächlich zurückgibt.

Funktioniert eine Transformation nicht mehr — eine gelesene App wurde deinstalliert, eine verwendete Spalte ist verschwunden —, zeigt der Reiter Transforms den Grund an, und die übrigen Transformationen laufen weiter. Das Lesen einer Transformation auf einem Board folgt denselben Zugriffsregeln wie die Daten jeder App; Datenzugriff regelt nur, wer eine schreiben darf.

App-Entwickler können Transformationen stattdessen mit einer App ausliefern, deklariert in deren Datenschema — siehe Transformationstabellen. Beide Arten werden auf dieselbe Weise gelesen.

Der Projekt-Dateispeicher

Nicht alles, was eine App erzeugt, passt in eine Tabelle. Neben der Projektdatenbank erhält jedes Projekt einen privaten Dateispeicher für Objekte — Kamerabilder, PDF-Berichte, Firmware-Images, Audioclips, Exporte —, der nach genau denselben Prinzipien verwaltet wird wie die Datenbank.

• Jede App erhält automatisch Speicher. Wird eine App installiert, provisioniert IronFlock für sie einen privaten Speicherbereich im Dateispeicher des Projekts — genauso, wie es die Datenbanktabellen der App provisioniert. Mehrere Apps legen ihre Dateien im einen Projekt-Dateispeicher zusammen, wobei die Objekte jeder App klar von denen der anderen getrennt bleiben.
• Es gelten dieselben Eigentumsgarantien. Die Dateien gehören dem Projekteigentümer, nicht dem App-Entwickler. Sie können sie durchsuchen, herunterladen, begrenzen und löschen, und der Entwickler einer App kann die Dateien nicht sehen, die sie beim Betrieb in Ihrem Projekt erfasst.
• Dateien verknüpfen sich direkt mit Ihren Daten. Ein gespeichertes Objekt trägt eine dauerhafte, zugriffskontrollierte URL, die eine App in eine Datenbankspalte schreiben kann — so rendert ein Dashboard-Widget das Bild oder Dokument ohne zusätzlichen Aufwand, und entzieht man einem Nutzer den Zugriff auf das Projekt, verliert er zugleich die Möglichkeit, die Dateien abzurufen.
• Sie steuern das Budget. Die Speichereinstellungen jeder App zeigen, wie viel sie belegt, und lassen Sie ein Speicherlimit festlegen, eine Tabelle leeren oder alle Dateien einer App löschen. Und für Werkzeuge außerhalb der Plattform — einen Analysten mit DuckDB, ein nächtliches Backup — können Sie schreibgeschützte S3-Zugangsdaten ausstellen, die auf die Dateien einer einzelnen App beschränkt sind.

Der Dateispeicher lässt sich direkt neben den Tabellen durchsuchen: Die Datenansicht des Projekts zeigt für jede App einen Eintrag Dateien, der jedes gespeicherte Objekt mit Größe, Typ und Datum auflistet. Für die Details auf Entwicklerseite — das Deklarieren von Speicher, Namespaces, Aufbewahrung und die SDK-Aufrufe — siehe Dateispeicher.

Daten zwischen Apps teilen

Apps im selben Projekt sind standardmäßig isoliert: Jede liest und schreibt nur ihre eigenen Tabellen und ihre eigenen Dateien. Das ist der sichere Ausgangspunkt — eine App, die Sie zur Energiemessung installiert haben, hat keinen Grund, die Inspektionsfotos einer anderen App zu lesen, es sei denn, Sie entscheiden sich dafür.

Doch oft sollten Apps zusammenarbeiten — eine Analytics-App liest die Historie einer Monitoring-App, eine Reporting-App zieht Fotos aus einer Qualitäts-App. IronFlock ermöglicht das über eine einzige Einwilligungsentscheidung, die Sie kontrollieren, in den Einstellungen der konsumierenden App:

• Sie genehmigen genau, welche Anbieter eine App lesen darf, und sehen die Begründung, die die App für den gewünschten Zugriff angibt. Nichts wird ohne Ihre ausdrückliche Genehmigung geteilt.
• Eine einzige Freigabe umfasst beide Hälften des Hubs — die geteilten Tabellen und die geteilten Dateien der bereitstellenden App. Sie verwalten Datenbank- und Dateiberechtigungen nicht getrennt.
• Der Zugriff erfolgt nur lesend. Eine konsumierende App kann die Daten einer anderen App einsehen, sie aber niemals ändern oder löschen.
• Sie können jederzeit widerrufen, und der Zugriff endet sofort.

Was überhaupt zum Teilen angeboten wird, entscheidet der App-Entwickler — pro Tabelle und pro Datei-Namespace. Manche Daten hält eine App streng intern, und diese erscheinen nie als etwas, das Sie freigeben könnten. Von dem, was teilbar ist, entscheiden Sie, ob es tatsächlich geteilt wird. Die Mechanik auf Entwicklerseite ist unter Daten aus anderen Apps konsumieren dokumentiert.

Datenhoheit & der EU Data Act

IronFlock baut auf einem klaren Prinzip auf: Der Projekteigentümer ist der Dateneigentümer — nicht der App-Entwickler.

Alle von Apps erzeugten Daten — ob Telemetrie-Streams von Edge-Geräten, Event-Logs oder abgeleitete Analytics — werden in der Projektdatenbank gespeichert, die dem Projekteigentümer gehört. Der App-Entwickler schreibt die App, aber die Daten, die die App innerhalb eines Projekts erzeugt, sind ausschließlich Eigentum des Projekts, in dem sie läuft.

Dieses Modell entspricht direkt den Anforderungen des EU Data Act, der Nutzern vernetzter Produkte und zugehöriger Dienste die volle Kontrolle über die von ihren Geräten erzeugten Daten gibt. In IronFlock:

• Exklusive Kontrolle. Der Projekteigentümer hat vollständige administrative Kontrolle über die Projektdatenbank — Lesen, Exportieren, Löschen, Sichern aller enthaltenen Daten.
• Keine stillen Datenabflüsse. App-Entwickler haben keinen Zugriff auf Projektdaten, sofern sie nicht explizit eingeladen werden. Es gibt keine versteckte Datenpipeline aus Projekten zurück zu App-Entwicklern.
• Portabilität. Da alle Daten in einer Standard-TimescaleDB liegen, können sie mit SQL abgefragt, in offenen Formaten exportiert und jederzeit migriert werden — kein Vendor-Lock-in.
• Granulares Teilen. Der Projekteigentümer kann App-Entwickler, Integrationspartner oder andere Interessengruppen ins Projekt einladen und feingranulare Zugriffsrechte auf bestimmte Datenbereiche vergeben. So lassen sich Drittanbieter-Support, Fernwartung oder spezialisierte Analytics nutzen — zu Bedingungen, die der Projekteigentümer definiert und jederzeit widerrufen kann.

Kurz gesagt: Apps erzeugen Daten, doch der Projekteigentümer besitzt, kontrolliert und teilt sie. Dieses Eigentümermodell ist ein Kern-Designziel der IronFlock-Plattform — kein Nachgedanke.

Opt-out: Umgehung der IronFlock-Datenpipeline

Die IronFlock-Messaging-Schicht und die Projektdatenbank sind der empfohlene Weg — sie liefern Echtzeit-Routing, dauerhafte Speicherung, Dashboard-fertige Daten und integrierte Eigentumsgarantien ab Werk. IronFlock zwingt Apps jedoch nicht, diese Pipeline zu nutzen.

Apps auf IronFlock-verwalteten Geräten sind reguläre Container-Workloads und behalten volle Netzwerk- und Systemfreiheit. Wenn ein Projekteigentümer oder App-Entwickler einen anderen Daten-Stack bevorzugt, kann eine App:

• In externe Systeme pushen. Daten direkt an Drittanbieter-Broker (MQTT, Kafka, AMQP), Cloud-Ingestion-Endpunkte (AWS IoT, Azure IoT Hub, Google Cloud IoT) oder eigene REST-/gRPC-APIs senden.
• Alternative Speicher verwenden. In eine externe Datenbank schreiben (InfluxDB, MongoDB, S3, eigene TimescaleDB usw.) — anstelle oder zusätzlich zur IronFlock-Projektdatenbank.
• On-Premises-Systeme anbinden. Direkt mit bestehenden MES-, ERP-, Historian- oder SCADA-Systemen über das lokale Netzwerk integrieren, ohne die IronFlock-Cloud zu berühren.
• Kombinieren. Einen Datenauszug für Dashboards und KI-Analysen an IronFlock senden und die vollständigen Daten parallel woanders streamen.

Diese Flexibilität macht IronFlock gleichermaßen geeignet für Greenfield-Deployments, die die Plattform end-to-end nutzen, wie auch für Integrationen in bestehende Enterprise-Datenarchitekturen, bei denen das Datenziel feststeht.

Daten in IoT-Dashboards und SCADA-Boards nutzen

Daten visuell nutzbar zu machen, ist mühelos. Wenn Sie ein Widget in Ihrem IoT-Board oder SCADA-Board konfigurieren, können nahezu alle Eigenschaften (z. B. Titel, Werte, Farben) dynamisch an Live-Daten Ihrer Projektdatenbank gebunden werden.

Beim Bearbeiten eines Widgets im Board Studio finden Sie unter den Konfigurationsfeldern einen Datenbindungs-Schalter. Wählen Sie eine bestimmte Tabellenspalte aus, entsteht ein Echtzeit-Kanal für diese Eigenschaft. Sobald neue Telemetriedaten in der Datenbank eintreffen, aktualisieren sich die gebundenen Eigenschaften auf Ihrem Dashboard automatisch in Echtzeit — ohne manuelles Neuladen.

Hinweis: Für einen tiefen Einstieg ins Verbinden von Widget-Eigenschaften mit Ihrer Datenbank siehe den ausführlichen Abschnitt zur Datenbindung in der IoT-Dashboards-Dokumentation.