Datenfluss

:::info Kurzübersicht — Datenpfad Sensoren/SPS → MQTT/OPC-UA → Erfassungsworker → PostgreSQL/TimescaleDB → FastAPI → React-Oberfläche

Alle Daten verbleiben vor Ort. Keine Cloud-Abhängigkeit. Kein Internet erforderlich. :::

OpSee verbindet die physische Welt (Sensoren, SPS, IoT-Geräte) mit Echtzeit-Dashboards und Analysen. Diese Seite erklärt, wie Daten durch das System fließen — vom Shopfloor bis zu Ihrem Bildschirm.

Warum ist das wichtig?

Wenn Sie neu in der Fertigungssoftware sind, kann der Datenfluss komplex erscheinen. Hier ist eine einfache Art, darüber nachzudenken:

Denken Sie an OpSee wie an eine Wetterstation. Eine Wetterstation hat Sensoren (Thermometer, Regenmesser, Windfahne), die kontinuierlich Bedingungen messen. Diese Messungen werden gesammelt, in einer Datenbank gespeichert und auf einem Dashboard angezeigt, das Ihnen das aktuelle Wetter und historische Trends zeigt.

OpSee funktioniert genauso, aber für Ihre Fabrik:

• Sensoren an Maschinen messen Temperatur, Geschwindigkeit, Zustand (laufend/gestoppt) und Zählungen
• Worker (Softwareprozesse) sammeln und speichern diese Messungen
• Dashboards zeigen Echtzeit-Produktionskennzahlen und historische Analysen

Der Hauptunterschied besteht darin, dass OpSee auch Intelligenz hinzufügt: Es berechnet automatisch OEE, erkennt Ausfallereignisse und ermöglicht Bedienern, die Gründe für Stopps zu klassifizieren.

Das Gesamtbild

Schicht für Schicht

1. Shopfloor (Datenquellen)

Quelle	Protokoll	Beschreibung
SPS / SCADA	MQTT, OPC-UA	Industrielle Steuerungen veröffentlichen Maschinenzustände, Zähler und Alarme
IoT-Sensoren	MQTT	Temperatur-, Druck- und Vibrationssensoren über IoT-Gateways
Node-RED	MQTT	Visuelle Flussprogrammierung zum Transformieren, Weiterleiten und Anreichern von Daten, bevor sie OpSee erreichen
Manuelle Eingabe	HTTP (Oberfläche)	Bediener erfassen Stillstandsgründe, Qualitätsmängel und Produktionszählungen direkt in OpSee

2. Nachrichten-Broker (Transport)

MQTT (Mosquitto) ist der primäre Nachrichtentransport. Es verwendet ein Publish/Subscribe-Modell:

• Publisher — SPS, Sensoren und Node-RED-Flows veröffentlichen Daten zu MQTT-Topics
• Abonnenten — OpSees Erfassungsworker abonnieren relevante Topics
• Topics folgen einer strukturierten Namenskonvention, z. B. plant/line1/machine3/state

OPC-UA wird als Alternative für Industrieumgebungen unterstützt, die es nativ verwenden. OpSees OPC-UA-Worker verbindet sich direkt mit OPC-UA-Servern.

3. Erfassungsschicht (Verarbeitung)

Zwei parallele Erfassungspfade stellen sicher, dass Daten die Datenbank erreichen:

Worker	Aufgabe
MQTT-Collector-Worker	Abonniert MQTT-Broker, verarbeitet Payloads, ordnet sie Anlagen und Tags zu, schreibt in die Datenbank
OPC-UA-Collector-Worker	Abonniert OPC-UA-Server (Data-Change-Benachrichtigungen), ordnet Werte Anlagen und Tags zu, schreibt in die Datenbank

Worker werden über die OpSee-API verwaltet — Sie können deren Status überwachen, den Debug-Modus umschalten und Abfrageintervalle über das Admin-Panel anpassen.

:::info Entdeckungsmodus Der MQTT-Discovery-Worker scannt automatisch MQTT-Topics, um neue Datenquellen zu finden. Dies hilft bei der Ersteinrichtung, wenn Sie Sensoren Anlagen zuordnen. :::

4. Speicherung (Datenbank)

PostgreSQL + TimescaleDB ist die einzige Wahrheitsquelle:

• Stammdaten (Tabellen mit Präfix m_) — Anlagen, Materialien, Personal, Rezepte, OEE-Konfiguration
• Ist-Daten (Tabellen mit Präfix a_) — Produktionsereignisse, Verfügbarkeitsdatensätze, Qualitätsprotokolle, Audit-Trail
• Zeitreihen — TimescaleDB-Hypertabellen für hochfrequente Sensordaten mit automatischer Komprimierung und Aufbewahrung

Alle Daten werden lokal gespeichert — OpSee läuft vollständig vor Ort ohne Cloud-Abhängigkeit.

5. Anwendungsschicht (Präsentation)

Komponente	Zweck
FastAPI-Backend	REST-API, die die Datenbank abfragt, OEE-Kennzahlen berechnet, Zugriffssteuerung durchsetzt und Daten an Clients liefert
React-Frontend	Single-Page-Anwendung mit Echtzeit-Dashboards, Datengrids, Formularen und dem Cockpit-Widget-System
Grafana	Erweiterte Zeitreihenvisualisierung und Alarmierung für Sensordatentrends

Datenfluß-Beispiele

Beispiel 1: Maschinenzustandsänderung

Beispiel 2: Bediener erfasst Stillstandsgrund

Offline-First-Architektur

OpSee ist für Fabrikumgebungen konzipiert, in denen die Internetverbindung unzuverlässig oder nicht vorhanden ist:

• Alle Dienste laufen lokal über Docker-Container
• Keine externen API-Aufrufe oder Cloud-Abhängigkeiten
• Daten verbleiben vor Ort
• Das React-Frontend ist vollständig gebündelt — keine CDN-Ressourcen
• MQTT und OPC-UA funktionieren im lokalen Netzwerk

tipp

Dadurch ist OpSee für abgeschottete Umgebungen, klassifizierte Einrichtungen und entlegene Fertigungsstandorte geeignet.

Nächste Schritte

• Architekturübersicht — Detaillierte technische Architektur aller Dienste
• OEE-Grundlagen — Wie OEE aus den erfassten Daten berechnet wird
• Anlagenmodell — Wie Sensoren Anlagen zugeordnet werden