Maschinendatenerfassung-Software: was 2026 kaufen (und was nicht)
Maschinendatenerfassung-Software ist die Schicht zwischen einer Produktionslinie und jedem System, das mit dem, was die Linie tut, etwas Sinnvolles anfangen will. Sie liest Signale aus SPS, Sensoren, Bildverarbeitungssystemen, MES und zunehmend aus Kameras, die auf die Maschine zeigen, und verwandelt diese Signale in einen Strom, den eine Datenbank, ein Dashboard oder ein KI-Modell konsumieren kann.
Die Kategorie ist in fünf Jahren von ein, zwei dominanten Anbietern auf rund zwanzig gewachsen. Die Hälfte davon löst ein Problem, das es 2020 noch nicht gab. Die andere Hälfte löst ein Problem, das die großen MES-Anbieter früher gelöst haben und heute nicht mehr lösen wollen. Dieser Artikel richtet sich an die Operations- oder IT-Verantwortliche, die Tools auf eine Shortlist setzt und eine klare Karte will.
Was Maschinendatenerfassung-Software tatsächlich macht
Im Kern drei Dinge. Sie verbindet sich mit der Datenquelle (SPS, Sensor, Kamera, MES, ERP, handschriftliches Protokoll). Sie normalisiert die Daten in ein konsistentes Format mit Zeitstempeln und Einheiten. Sie übergibt die Daten an das System, das sie konsumiert (ein Historian, ein Dashboard, eine Cloud-Datenbank, ein KI-Modell, die Excel-Tabelle einer Prozessingenieurin).
Die Unterschiede zwischen den Anbietern liegen fast vollständig im ersten und im dritten Schritt. Die Mitte ist Commodity. Anbieter konkurrieren darüber, wie viele Protokolle sie nativ sprechen (Siemens S7, Allen-Bradley, Modbus, OPC UA, MQTT, EtherNet/IP, Profinet plus den langen Schwanz markenspezifischer Protokolle) und wie viele Consumer sie integrieren (SQL, Time-Series-Datenbanken, Snowflake, BigQuery, Azure Data Explorer, Power BI, Grafana, eigene REST-Endpunkte).
Für ein kleines oder mittelgroßes Werk zählt die Verbindungsschicht mehr als die Consumer-Schicht. Für ein großes Werk mit bestehendem Analytics-Stack ist es umgekehrt.
Die fünf Tool-Kategorien in 2026
Fünf Töpfe decken den Markt 2026 weitgehend ab.
1. Klassische SCADA-nahe Middleware
Tools, die aus Historian- und SCADA-Workflows gewachsen sind: AVEVA PI, Inductive Automation Ignition, Wonderware/AVEVA System Platform, GE Proficy. Stark bei hochvolumigen SPS-Daten, schwach bei modernen Cloud-Integrationen und bei Kameradaten. Teuer (Lizenzierung pro Tag oder Verbindung summiert sich schnell). Zuverlässig. Der Default in Öl und Gas, in der großen Chemie und in der großen diskreten Fertigung.
Wähle, wenn: du eine lang gewachsene SPS- und Historian-Landschaft hast, deine Werks-IT sie souverän betreibt und du nicht in Eile kamerabasierte Überwachung oder Cloud-Analytics ergänzen willst.
2. Moderne Open-Source-basierte Stacks
Node-RED + InfluxDB + Grafana, oft mit Mosquitto als MQTT-Broker. United Manufacturing Hub für ein etwas meinungsstärkeres Open-Source-Bundle. HiveMQ für ernsthaftes MQTT. Die Total Cost of Ownership ist deine Engineering-Zeit, keine Lizenzgebühr. Die Decke ist hoch, der Boden niedrig (du brauchst jemanden, der das betreiben kann).
Wähle, wenn: du ein internes Team hast, das mit Self-Hosting souverän umgeht, du Anbieterbindung vermeiden willst und es dir lieber ist, in Ingenieurstunden statt in Lizenz-Dollars zu zahlen.
3. Cloud-native kommerzielle Plattformen
Tulip, Litmus Edge, HighByte, Cognite, Element, Cumulocity, AVEVA Data Hub. Der Pitch ist über die meisten hinweg derselbe: niedrigere TCO als klassische SCADA-nahe Middleware, schnellere Zeit zum ersten Dashboard, native Cloud-Auslieferung, akzeptable IT-Story für die Beschaffung. Die Preise gehen pro Gerät oder pro Datenstrom und summieren sich schneller, als die Anbieter dir sagen werden. UX und KI-Integrationen variieren stark zwischen den Anbietern.
Wähle, wenn: du ein modernes Tool willst, nicht selbst hosten willst, ein Budget für laufende Pro-Gerät-Gebühren hast und in zwölf Monaten eine klare Menge an Datenquellen anbinden willst.
4. Kamera- und KI-zuerst-Systeme
Eine neuere Kategorie. Tools, die die Kamera als erstklassige Datenquelle behandeln, nicht als Nachgedanken. Die Kamera füttert Vision-Modelle, die Teile zählen, Defekte klassifizieren und Prozessanomalien erkennen, und die entstehenden Events werden über dieselbe Pipeline ausgespielt wie SPS-Daten. Enao Vision sitzt hier. Weitere Vertreter sind Augmentir, MakinaRocks und mehrere spezialisierte Vision-MES-Plug-ins. Für einen tieferen Blick siehe kamerabasierte Produktionsüberwachung.
Wähle, wenn: dein Flaschenhals Sichtbarkeit darauf ist, was die Linie tatsächlich tut (nicht nur was die SPS glaubt) und du ein Tool willst, das Kameradaten und SPS-Daten gleichwertig behandelt.
5. Eigenbau-Integrationen
Eine Menge Werke laufen auf Python-Skripten, die einen OPC-UA-Client ansprechen, CSVs auf einen Netzwerk-Share kippen und ein paar Power-BI-Reports obendrauf legen. Das ist keine Tool-Kategorie, sondern die Abwesenheit einer, aber es verdient genannt zu werden, weil es im kleinen Maßstab funktioniert. Es hört auf zu funktionieren, wenn das Skript um 2 Uhr morgens kaputtgeht und niemand weiß, wie er es repariert.
Wähle, wenn: du eine oder zwei Linien hast, eine Ingenieurin, die die Skripte pflegt, und kein Budget. Wechsle zu einer der Kategorien 1 bis 4, sobald du entweder wachsende Komplexität hast oder eine zweite Person, die das System pflegen muss.
Wo jede Kategorie an ihre Grenzen stößt
Klassische SCADA-nahe Middleware stößt bei Kameradaten und Cloud-Auslieferung an Grenzen. Ein Bildverarbeitungssystem an einen PI-Server zu hängen, fühlt sich nach Bastelei an. Daten in ein Cloud-Data-Warehouse zu ziehen, fügt Lizenz- und Engineering-Kosten hinzu, die die meisten Teams unterschätzen.
Moderne Open-Source-Stacks stoßen an Menschen, nicht an Technik. Sie laufen wunderbar, wenn eine bestimmte Ingenieurin im Gebäude ist, und hören auf zu laufen, wenn diese Ingenieurin geht. Die Kosten der zweiten Ingenieurin, die den Stack lernt, übersteigen fast immer das, was ein Jahr kommerzielle Lizenzierung gekostet hätte.
Cloud-native kommerzielle Plattformen stoßen an Preistransparenz. Der Listenpreis ist selten der echte Preis, und der echte Preis wächst mit der Nutzung auf eine Art, die im Proof of Concept nicht offensichtlich ist. Sie stoßen auch an Edge Cases: das Long-Tail-SPS-Protokoll, das der Anbieter noch nicht unterstützt, die lokale IT-Richtlinie, die Cloud-Egress verbietet, die Linie, die auf einer Steuerung von 1998 ohne Ethernet-Port läuft.
Kamera- und KI-zuerst-Systeme stoßen an Grenzen, wenn die bestehenden SPS-Daten gut genug sind und die Kamera Rauschen ohne Wert hinzufügt. Sie stoßen auch an Grenzen, wenn Beleuchtung und Montage an der Linie falsch sind (dasselbe Problem wie bei jedem Bildverarbeitungssystem).
Eigenbau stößt in der ersten Urlaubswoche derjenigen an Grenzen, die ihn geschrieben hat.
So wählst du für ein bestimmtes Werk
Drei Fragen in dieser Reihenfolge. Welche Datenquellen brauchst du heute, welche in achtzehn Monaten? Wo sollen die Daten landen (ein Historian, ein Cloud-Warehouse, ein BI-Tool, ein KI-Modell)? Wer pflegt das System, und wie hoch ist seine Toleranz für selbstgehostete Komplexität?
Ein Werk mit zwanzig SPS-angebundenen Maschinen, einem bestehenden PI-Historian und einem kleinen IT-Team sollte vermutlich erweitern, was es hat. Ein Werk mit fünf Linien, ohne Historian, mit dem Wunsch nach Cloud-Analytics und mit Bereitschaft, pro Gerät zu zahlen, sollte sich die cloud-native kommerzielle Kategorie ansehen. Ein Werk, dessen größte Sichtbarkeitslücke darin liegt, was auf der Linie jenseits dessen passiert, was die SPS meldet, sollte mit Kamera- und KI-zuerst-Systemen starten. Ein Werk mit einer Ingenieurin und einer Linie ist mit Eigenbau in Ordnung, bis die Ingenieurin in den Urlaub geht.
Der Fehler ist, nach Markenbekanntheit auszuwählen statt nach der Antwort auf diese drei Fragen. Die richtige Antwort ist selten dieselbe wie die für das Nachbarwerk.
Kosten in 2026
Grobe Größenordnung für ein mittelgroßes Werk (10 bis 30 angebundene Maschinen).
Klassische SCADA-nahe Middleware: 100.000 bis 400.000 Euro Anfangsinvestition plus 15 bis 25 Prozent Wartung pro Jahr.
Moderne Open-Source: 0 Euro Lizenz plus 1 bis 2 Vollzeit-Ingenieure (also 100.000 bis 200.000 Euro pro Jahr fully loaded).
Cloud-native kommerziell: 30.000 bis 150.000 Euro pro Jahr Abonnement, je nach Pro-Gerät- oder Pro-Datenstrom-Stufe.
Kamera- und KI-zuerst: 5.000 bis 20.000 Euro pro Linie pro Jahr Abonnement, plus einmalige Setup-Kosten im Bereich 1.000 bis 5.000 Euro pro Linie für Hardware, um die Kamera zum Laufen zu bringen.
Eigenbau: die Kosten für die Zeit einer Ingenieurin und das Risiko des katastrophalen Ausfalls, wenn sie geht.
Diese Spannen sind weit, weil die tatsächlichen Zahlen von Verhandlung, Volumen und Rabatten am Quartalsende abhängen. Behandle sie als Orientierung, nicht als Angebot.
Ein Feld-Primer: was tatsächlich in einem Datenerfassungssystem steckt
Ein arbeitsfähiges Datenerfassungssystem ist 2026 ein Stack, kein einzelnes Produkt. Die Teile zu benennen hilft, wenn du dich einem Anbieter gegenübersetzt und die Demo die Hälfte davon überspielt.
Auf der Sensor-Ebene sind die Inputs typischerweise eine Mischung aus Thermoelementen und RTDs für die Temperatur, Druck-Transmittern, Vibrations-Transmittern, Durchfluss-Transmittern und Strom-und-Spannungs-Transmittern für die Leistungsanalyse. Jedes Sensorsignal wird konditioniert (Signalkonditionierung umfasst Verstärkung, Isolation und Filterung) und von Analog-Digital-Wandlern von analog in digital konvertiert. Der konvertierte Strom trägt dann eine Seriennummer der Quelle, einen Zeitstempel und die physikalischen Einheiten und wird an das übergeben, was ihn konsumiert.
Die DAQ-Hardware, die diese Konvertierung macht, kommt in drei groben Formen. Standalone-Datenlogger und -Rekorder, die Messwerte im internen Speicher ablegen, damit sie später ausgelesen werden (der einfachste Data-Logging-Workflow, immer noch verbreitet bei abgelegenen Pumpen, Generatoren und HVAC-Anlagen). Modulare DAQ-Hardware auf einem Ethernet- oder USB-Backbone, die zu einem Host streamt (die dominante Form in Testlaboren und auf F&E-Bänken). Und SPS-Frontends, die einen kleinen DAQ-Stack mit Steuerungslogik auf demselben Gerät vereinen (die dominante Form auf Produktionslinien).
Über der Hardware sitzt die DAQ-Software. Sie erledigt drei Aufgaben, die mit dem überlappen, was ein Maschinendatenerfassungs-Tool auf Werksebene macht. Sie konfiguriert die Kanäle (Abtastrate, Bereich, Filterung). Sie zeichnet die Prozessdaten auf und legt sie ab (oft auf einem Linux-Host, der auch den Historian fährt). Und sie spielt die Messwerte über Echtzeit-Grafiken, Dashboards und Alarme an die Operatoren aus. Die Anwenderschicht ist in einer Bandbreite von Programmiersprachen gebaut: C und C# für die Alt-Stacks, Python und JavaScript für die modernen Web-Dashboards, plus den langen Schwanz von Anbieter-Skriptumgebungen (LabVIEW, Codesys Strukturierter Text, Beckhoff TwinCAT).
Der Grund, warum dieser Primer für die Käuferin auf Werksebene zählt: dieselben Worte bedeuten in verschiedenen Maßstäben Verschiedenes. Eine Testingenieurin in einem Batterie-F&E-Labor, die „DAQ“ sagt, meint meist ein National-Instruments-PXI-Chassis mit einem Stapel analoger Eingangsmodule und LabVIEW obendrauf. Eine Operations-Verantwortliche in einem Verpackungswerk, die „Maschinendatenerfassung“ sagt, meint meist eine Middleware, die Daten aus zwanzig SPS zieht und in ein Dashboard und ein KI-Modell speist. Beide haben recht, beide verwenden dieselben Worte, und die Anbieter, die in beide Segmente verkaufen, sprechen mit Absicht in zweideutigen Begriffen. Wenn eine Vertrieblerin dir DAQ entgegenwirft, frage, ob sie den Sensor-zu-Wandler-Stack oder die SPS-zu-Dashboard-Schicht meint. Die Antwort entscheidet, ob das Tool passt.
Qualitätssicherungs-Teams nutzen DAQ-Daten am aggressivsten aller Funktionen. Die Daten sind die Belege in jeder CAPA, jedem Lieferanten-Audit, jeder Kundenreklamation, die Rückverfolgbarkeit braucht. Ein Werk, das Qualitätssicherung mit handgeschriebenen Logs fährt, ist in einem anderen Jahrzehnt als ein Werk, das sie auf dem Datenerfassungssystem fährt. Der Wechsel von einem zum anderen ist das, was die meiste dieser Software tatsächlich verkauft, auch wenn sie als Produktivität oder Sichtbarkeit verkauft wird.
FAQ
Ist MQTT dasselbe wie ein Maschinendatenerfassungs-Tool? Nein. MQTT ist ein Transportprotokoll. Ein Maschinendatenerfassungs-Tool nutzt typischerweise MQTT (oder OPC UA oder proprietäre Protokolle) als eine seiner Transportschichten. Tools und Protokolle sind unterschiedliche Dinge.
Brauche ich einen Historian und ein Maschinendatenerfassungs-Tool? In einem kleinen Werk nein. In einem großen Werk mit hochvolumigen SPS-Daten ja. Der Historian ist auf Time-Series-Speicherung und -Abfrage in hoher Kadenz optimiert. Das Erfassungs-Tool ist darauf optimiert, die Daten dorthin und zu anderen Consumern zu bekommen.
Was ist OPC UA, und brauche ich es? OPC UA ist der moderne offene Standard für Maschine-zu-Maschine-Datenaustausch. Die meisten Erfassungs-Tools sprechen es. Du brauchst es, wenn deine Maschinen es unterstützen (die meisten modernen SPS tun das). Für ältere Maschinen fällst du auf die spezifischen Markenprotokolle zurück.
Wie passt das mit unserem MES oder ERP zusammen? Das Erfassungs-Tool speist das MES mit Echtzeit-Maschinendaten. Das MES speist das ERP mit aggregierten Produktionsdaten. Das Erfassungs-Tool sitzt vor beiden.
Starte dort, wo die Sichtbarkeitslücke ist
Das richtige Tool hängt von der Lücke ab. Wenn die Lücke Dashboards aus SPS-Daten sind, geh cloud-native kommerziell oder Open Source. Wenn die Lücke Enterprise-Reporting aus einer großen Maschinenflotte ist, bleib beim klassischen Stack und erweitere ihn. Wenn die Lücke darin liegt, zu wissen, was die Linie tatsächlich tut, jenseits dessen, was die SPS meldet, starte mit der Kamera- und KI-zuerst-Kategorie und kümmere dich um den Rest später.
Für einen tieferen Blick darauf, was kamerabasiertes Monitoring dir bringt, siehe kamerabasierte Produktionsüberwachung. Für die Einordnung in ein breiteres Sichtbarkeitsprogramm siehe Produktionsmonitoring ohne SPS.
Jetzt starten
Lege dein kostenloses Konto an und vergleiche Stacks an deiner eigenen Linie: Konto erstellen.
Der Community beitreten
Tausch dich mit Peers aus anderen Werken aus, die mit verschiedenen Stacks arbeiten: Der Enao-Community beitreten.
