Architektur

IronFlock ist ein verteiltes System mit zwei Schichten: autonome Edge-Geräte, die Anwendungen am Einsatzort ausführen, und zentrale Services, die flottenweite Datenspeicherung, Dashboarding, KI und Koordination bereitstellen. Ein Echtzeit-Message-Broker verbindet alles.

Dies ist weder eine reine Edge-Plattform noch eine reine Cloud-Plattform. Es ist beides — und die Architektur ist so konzipiert, dass jede Schicht das tut, was sie am besten kann.

Wie das System zusammenwirkt

┌─────────────────────────────────────────────────────────┐  ┌──────────┐
│                    Zentrale Services                    │  │Virtuelles│
│                                                         │  │  Gerät   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐   │  │┌────────┐│
│  │ FleetDB  │  │ Backend  │  │    KI    │  │  Web   │   │  ││ Custom ││
│  │ Cluster  │  │ Service  │  │ Service  │  │  UI    │   │  ││ Service││
│  │(Timescale│  │          │  │          │  │        │   │  │└────────┘│
│  │   DB)    │  │          │  │          │  │        │   │  │  Agent   │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └───┬────┘   │  └────┬─────┘
│       │             │             │            │        │       │
│       └─────────────┴──────┬──────┴────────────┘        │       │
│                            │                            │       │
│                    ┌───────┴───────┐                    │       │
│                    │  WAMP Message ├────────────────────────────┘
│                    │    Broker     │                    │
│                    └───────┬───────┘                    │
│                            │                            │
└────────────────────────────┼────────────────────────────┘
                             │
              ┌──────────────┼─────────────┐
              │              │             │
      ┌───────┴──┐   ┌───────┴──┐   ┌──────┴───┐
      │  Edge    │   │  Edge    │   │  Edge    │
      │ Gerät 1  │   │ Gerät 2  │   │ Gerät 3  │
      │┌────────┐│   │┌────────┐│   │┌────────┐│
      ││  Apps  ││   ││  Apps  ││   ││  Apps  ││
      ││(Docker)││   ││(Docker)││   ││(Docker)││
      │└────────┘│   │└────────┘│   │└────────┘│
      │  Agent   │   │  Agent   │   │  Agent   │
      └──────────┘   └──────────┘   └──────────┘

Die drei Schichten

1. Edge-Geräte — Autonome Anwendungsrechner

Edge-Geräte sind die zentralen Ausführungsknoten in IronFlock. Jedes Gerät betreibt einen leichtgewichtigen Agenten und eine oder mehrere containerisierte Anwendungen (Docker). Geräte sind autonom: Sie arbeiten auch bei Trennung von den zentralen Services weiter und verbinden sich automatisch wieder, wenn das Netzwerk wiederhergestellt ist.

Edge-Geräte können jede Linux-fähige Hardware sein — Raspberry Pi, Industrie-PCs, NVIDIA Jetson, x86-Gateways oder benutzerdefinierte ARM-Boards.

Was auf Edge-Geräten läuft:

• Der IronFlock-Agent — verwaltet den Gerätelebenszyklus, behandelt OTA-Updates, führt Container aus und hält die Verbindung zum Message Broker aufrecht
• Ihre Anwendungen — bereitgestellt als Docker-Container in jeder Programmiersprache. Diese Apps erfassen Daten von SPSen und Sensoren, führen Steuerungslogik aus, stellen lokale HMIs bereit, führen KI-Modelle aus oder erledigen alles andere, was eine Linux-Anwendung kann

Edge-Geräte initiieren standardmäßig alle Verbindungen nach außen — es müssen keine eingehenden Ports geöffnet werden. Geräte-Ports können jedoch bei Bedarf gezielt geöffnet werden, beispielsweise um ein lokales HMI oder einen API-Endpunkt freizugeben. Siehe Edge-Geräte & Agent für Details.

2. Zentrale Services — Flottenweite Daten, UI und Intelligenz

Die zentrale Schicht bietet Fähigkeiten, die eine flottenweite Sicht oder persistente Infrastruktur erfordern. Jeder zentrale Service ist unabhängig skalierbar — Services können horizontal skaliert werden, um wachsende Flotten zu bewältigen, ohne sich gegenseitig zu beeinflussen:

• FleetDB — Ein Cluster von PostgreSQL/TimescaleDB-Datenbanken, der alle von Geräten erfassten Telemetriedaten speichert. Jedes Projekt erhält eine eigene isolierte Datenbankinstanz mit dedizierten Tabellen und Zugangsdaten. Die Cluster-Architektur ermöglicht horizontale Skalierung über Projekte hinweg. FleetDB übernimmt Zeitreihenspeicherung, geplante Aggregationen und dient als Daten-Backend für Dashboards und KI-Abfragen.
• Backend Service — Verwaltet Geräte, Projekte, Apps, Benutzerkonten, Releases und alle flottenweiten Operationen. Stellt die Web-API bereit und behandelt die Geschäftslogikschicht. Skaliert horizontal für steigende API-Last und Geräteregistrierungen.
• FleetDB Service — Verarbeitet eingehende Datenströme von Geräten, behandelt Datentransformationen, liefert Echtzeit-Dashboard-Daten an das Frontend und verwaltet die Alarmbewertung. Skaliert unabhängig entsprechend dem Datenaufkommen.
• KI-Service — Orchestriert KI-Agent-Gespräche, fügt spezialisierte Agenten dynamisch hinzu und entfernt sie, wenn sich das Gespräch entwickelt. Leitet natürlichsprachliche Anfragen weiter, ruft geräteseitige Funktionen über den Message Broker auf und generiert Charts und Analysen in Echtzeit. Skaliert zur Unterstützung paralleler KI-Gespräche über Projekte hinweg.
• Web UI — Die browserbasierte Steuerungskonsole, in der Bediener ihre Flotte verwalten, Dashboards anzeigen, Alarme konfigurieren, Apps entwickeln und mit dem KI-Assistenten interagieren.
• Container Registry — Speichert Docker-Images für alle Apps und ermöglicht OTA-Bereitstellung auf jedes Gerät der Flotte. Skaliert Speicher und Durchsatz unabhängig, wenn Ihr App-Katalog wächst.

Zentrale Services können in der IronFlock Cloud (von IronFlock verwaltet) oder auf Ihrer eigenen Infrastruktur für On-Premises-Bereitstellungen betrieben werden. Siehe Zentrale Services für Details.

3. Virtuelle Geräte — Benutzerdefinierte zentrale Rechenknoten

Zusätzlich zu physischen Edge-Geräten können Sie in IronFlock virtuelle Geräte bereitstellen — in der Cloud gehostete Rechenknoten, die Ihrem Projekt neben Ihrer physischen Flotte beitreten. Ein virtuelles Gerät betreibt denselben IronFlock-Agenten wie ein physisches Gerät, nimmt am gleichen Nachrichten-Routing teil und kann jede containerisierte Anwendung ausführen.

Häufige Verwendungen für virtuelle Geräte:

• Betrieb von zentralen Flottendiensten wie Grafana, Node-RED, Netdata oder Jupyter, die eine flottenweite Perspektive benötigen
• Hosting von Datenverarbeitungs-Pipelines, die Daten von mehreren physischen Geräten aggregieren
• Ausführung von KI-Inferenzdiensten, die zu rechenintensiv für Edge-Hardware sind
• Einsatz als Protokollbrücken, die externe Systeme (SAP, ERP, Cloud-APIs) mit Ihrem IronFlock-Projekt verbinden

Virtuelle Geräte sind kein separates Feature — sie sind vollwertige Teilnehmer in Ihrem Projekt. Sie erscheinen in der Geräteliste, erhalten OTA-Updates und ihre Apps kommunizieren mit Edge-Geräte-Apps über denselben Message Broker.

Siehe Virtuelle Geräte für Details.

Der Message Broker — Das Bindeglied

Alle Komponenten in IronFlock kommunizieren über einen zentralen WAMP (Web Application Messaging Protocol) Message Broker. Der Broker bietet:

• Echtzeit-Pub/Sub-Messaging — Geräte veröffentlichen Telemetriedaten, Dashboards abonnieren Live-Daten, Apps kommunizieren bidirektional
• RPC (Remote Procedure Calls) — Der KI-Service ruft geräteseitige Funktionen auf, das Backend löst Container-Operationen auf Geräten aus, Bediener senden Befehle
• Projektisolierung — Jede Projekt-App-Kombination erhält ihren eigenen kryptographisch isolierten Messaging-Bereich. Geräte in einem Projekt können keine Nachrichten eines anderen sehen
• Authentifizierung — Jede Verbindung zum Broker erfordert gültige Zugangsdaten

Der Message Broker ist es, der IronFlock zu einem verteilten System statt einer Sammlung unverbundener Teile macht. Ein KI-Agent in der zentralen Cloud kann eine Funktion auf einem physischen Gerät in einer Fabrikhalle aufrufen — und das Ergebnis in Echtzeit zurückerhalten — weil beide mit demselben Broker verbunden sind.

Siehe Message Broker (WAMP) für Details.

Skalierbarkeit & Updates ohne Ausfallzeit

Jede Komponente der IronFlock-Architektur ist für horizontale Skalierbarkeit ausgelegt. Backend, FleetDB, KI-Service, Message Broker und Container Registry können jeweils unabhängig voneinander skaliert werden, um wachsende Flotten, steigende Datenvolumen und mehr gleichzeitige Nutzer zu bewältigen — ohne andere Teile des Systems zu beeinträchtigen.

Alle Systemkomponenten unterstützen jetzt Updates mit nahezu null Ausfallzeit — sie können auf neue Versionen aktualisiert werden, praktisch ohne aktive Verbindungen oder Datenflüsse zu unterbrechen. Der geclusterte Message Broker war die letzte Komponente, die diesen Schritt vollzogen hat, sodass die gesamte Plattform jetzt mit nahezu null Ausfallzeit aktualisierbar ist.

Architektur vs. Traditionelle SCADA

Traditionelle SCADA-Plattformen (Ignition, WinCC, Wonderware) folgen einem Gateway-zentrierten Modell: Ein zentraler Server erledigt alles — Tag-Erfassung, Historienspeicherung, Bildschirmdarstellung, Alarmverarbeitung und Scripting. Der „Edge” sind nur SPSen, die Daten an diesen zentralen Server liefern.

IronFlock kehrt dies um. Die Edge-Geräte sind autonome Anwendungsrechner mit voller Rechenleistung. Die zentralen Services übernehmen, was eine flottenweite Sicht erfordert: persistente Datenspeicherung, Dashboarding, KI-Orchestrierung und Flottenmanagement. Keine Schicht ist der anderen untergeordnet — sie sind komplementär.

Bereitstellungsoptionen

Die zentralen Services von IronFlock können in drei Konfigurationen betrieben werden:

Siehe Bereitstellungsoptionen für einen vollständigen Vergleich der drei Modelle.