Was ist MTConnect? Der offene Standard für CNC-Daten

September 2008, Chicago. Auf dem Freigelände der International Manufacturing Technology Show (IMTS) vernetzten fünfundzwanzig Werkzeugmaschinenbauer Anlagen unterschiedlicher Marken in einem einzigen lokalen Netzwerk. Das Ziel war nicht, die proprietäre Sprache eines einzelnen Herstellers durchzusetzen, sondern ein gemeinsames Vokabular zu demonstrieren, über das Maschinen verschiedener Fabrikate dieselben betrieblichen Tatsachen ausdrücken können. Was damals vorgestellt wurde, war weder ein Kabel noch eine Steckkarte; es war ein semantisches Datenmodell.^[1]

Dieselbe betriebliche Reibung prägt Werkshallen bis heute. Eine FANUC-Steuerung, eine Heidenhain TNC und eine Mazak MAZATROL arbeiten nebeneinander; alle drei erfassen Achskoordinaten, Programmnamen und Alarmzustände. Doch wer diese Daten auf einem zentralen Dashboard zusammenführen will, sah sich traditionell mit individuellen Treibern, lückenhafter Signalzuordnung und enormem Pflegeaufwand konfrontiert. MTConnect löst dieses Problem: Ohne in die proprietäre Steuerungslogik einzugreifen, stellt es Betriebsdaten über ein offenes, standardisiertes Wörterbuch nach außen bereit.

MTConnect ist ein offener, lizenzgebührenfreier und konsequent rein lesender Datenstandard zur Erfassung von Prozess- und Telemetriedaten aus Werkzeugmaschinen. Er publiziert Daten als strukturiertes XML über HTTP; er schreibt keine Befehle in die Steuerung zurück. Dieser einzige Satz definiert sowohl seine technologische Leistungsfähigkeit als auch seine physikalische Sicherheitsgrenze.^[1][4]

MTConnect auf einen Blick

Was MTConnect nicht ist

Missverständnisse rühren häufig von drei überladenen Begriffen her: Feldbus, Treiber und Protokoll. MTConnect ist kein industrieller Feldbus; es synchronisiert keine Servoschleifen im Submillisekundenbereich über EtherCAT oder PROFINET. Es ist auch keine SPS-Programmiersprache und verändert nicht die Ablauflogik der Maschine. Ebenso wenig ersetzt es herstellereigene Entwickler-APIs wie FANUC FOCAS oder Heidenhain LSV2; diese APIs bieten tiefen, schreibfähigen Zugriff auf Steuerungsregister, während MTConnect ein nach außen gerichtetes, lesbares Datenmodell bereitstellt.^[4]

Diese Trennung bestimmt die gesamte IT-Architektur. Wenn eine Anwendung Werkzeugkorrekturwerte automatisiert zurückschreiben soll, ist MTConnect die falsche Schnittstelle. Wenn ein Leitsystem jedoch wissen muss: „Welche Maschine läuft, welches NC-Programm ist aktiv und welcher Alarm liegt an?“, ist MTConnect die exakt richtige Ebene. Herstellertools wie FANUC MT-LINK i bieten Überwachung via Ethernet und OPC UA; MTConnect ergänzt solche Werkzeuge, statt sie zu verdrängen. In ein und derselben Fabrik koexistieren beide Anforderungen völlig harmonisch: Hersteller-APIs für steuernde Eingriffe, MTConnect für das werksweite Monitoring.^[8]

Drei Dokumente, ein Wörterbuch: Devices, Streams, Assets

Während die Transportschicht von MTConnect bemerkenswert einfach gehalten ist, liegt die eigentliche Ingenieurleistung im semantischen Informationsmodell. Der Agent liefert drei zentrale Dokumentstrukturen:^[4]

• Devices: Beschreibt die strukturelle Komponentenhierarchie der Maschine. Achsen, Spindeln, Steuerungseinheiten, NC-Programme und Überwachungszustände werden hier abgebildet. Jedes Element besitzt eine eindeutige dataItemId, einen normierten type, eine Messkategorie (SAMPLE, EVENT, CONDITION) und Maßeinheiten.
• Streams: Enthält zeitgestempelte Messwerte und Zustandswechsel. Kontinuierliche Daten wie Koordinaten, Spindeldrehzahlen und Vorschübe fließen hier gemeinsam mit diskreten Ereignissen wie Betriebsarten und Alarmen.
• Assets: Modelliert mobile Objekte wie Schneidwerkzeuge, Paletten, Spannmittel und Werkstücke. Standzeitdaten oder Palettenbeladungen werden in separaten XML-Schemata geführt.

Ein Software-Client ruft zunächst /probe ab, um die Gerätestruktur zu erfassen; anschließend fragt er mit /current den aktuellen Zustand ab oder abonniert über /sample den fortlaufenden Datenstrom. Ohne das zugrundeliegende Modell ist ein Zahlenwert wertlos: Der Wert 12.345, der an einem Element namens Xabs hängt, bezeichnet die absolute X-Position in Millimetern; an anderer Stelle könnte er eine Kühlmitteltemperatur bedeuten. Die Schemadokumente und der Gerätemodell-Browser sind öffentlich zugänglich, sodass Integrationen vor der Inbetriebnahme verifiziert werden können.^[2][3][4]

<!-- Schematisch: Definition eines Datenelements in /probe -->
<DataItem id="Xabs" type="POSITION" subType="ACTUAL"
          category="SAMPLE" units="MILLIMETER" />

<!-- Schematisch: Messwertprobe in /current -->
<Position dataItemId="Xabs" timestamp="2026-11-14T09:15:22Z">
  12.345
</Position>

Dieser Aufbau unterscheidet MTConnect grundlegend von individuellen Treiberanpassungen. Ein herkömmlicher Treiber spricht die interne Maschinensprache; MTConnect übersetzt diese Sprache in ein offenes Weltmodell. Und genau hier beginnt die reale Praxis.

Erster Wendepunkt: Das Wörterbuch ist anspruchsvoller als die Leitung

Das Abrufen von XML über HTTP stellt moderne Programmierumgebungen vor keine Hürde; mit wenigen Codezeilen wird die Antwort von /current analysiert. Die eigentliche Herausforderung besteht im Auflösen semantischer Dialekte: Welches spezifische Datenelement entspricht welcher physikalischen Messgröße an der Maschine? Obwohl der Standard ein klares Vokabular definiert, nutzen Maschinenhersteller und Agent-Entwickler oft spezifische Benennungen.

Erfahrungen aus realen Werkshallen belegen dies deutlich. Bei Mazak-Maschinen werden im MTConnect-Strom der Programmname oft als pgm, die Satznummer als ln, die Werkzeugnummer als tid, der Stückzähler als pc, der Vorschub-Override als pfo und der Eilgang-Override als pfr ausgegeben. Bei DMG Mori-Anlagen finden sich häufig indizierte Bezeichner wie program1, toolnumber1 oder part_count1. Von Memex bereitgestellte Agents verwenden oft Kürzel wie cn5, cn4 oder cnt1. Zudem hinterlegen manche Hersteller den Standardbegriff im name-Attribut statt in der dataItemId.^[7]

Ein praxistauglicher Client darf sich daher nicht auf ein einzelnes Attribut verlassen. Er prüft hierarchisch: zuerst dataItemId, dann name und schließlich den semantischen type. In stabilen Erfassungssystemen existieren Zuordnungstabellen für Paare wie execution/exec, program/pgm, Tool_number/tid und PartCountAct/pc. Der Standard liefert das Nachschlagewerk; das Verstehen der Dialekte obliegt der Integrationssoftware.

Besondere Aufmerksamkeit verlangt auch das Statussignal: Wenn das Element avail den Wert UNAVAILABLE meldet, gilt die Maschine als abgeschaltet oder vom Netzwerk getrennt. Wird diese Statuslogik fehlerhaft ausgewertet, zeigt das Dashboard eine produzierende Maschine fälschlicherweise als stillstehend an. Verbindungsmeldungen müssen ebenso sorgfältig getestet werden wie Koordinatendaten.^[4]

Zweiter Wendepunkt: Nur-Lesen ist ein Sicherheitskonzept, kein Mangel

Die am häufigsten geäußerte Kritik an MTConnect betrifft das Fehlen einer Schreibfunktion. Dabei handelt es sich nicht um ein Versäumnis, sondern um eine bewusste architektonische Schutzgrenze. Hersteller-APIs wie FOCAS oder LSV2 gestatten das Schreiben von Maschinenparametern, Werkzeugkorrekturen, NC-Programmen und SPS-Merkerzuständen. Diese Befugnis ist für Automatisierungszellen unverzichtbar, stellt jedoch ein direktes Gefahrenpotenzial dar. Eine fehlerhaft übertragene Nullpunktverschiebung kann das Werkzeug mit 20.000 U/min in den Schraubstock rammen, Werkstücke zerstören und das Bedienpersonal gefährden.^[1][4]

MTConnect eliminiert dieses Risiko vollständig auf Architekturebene: Maschinendaten fließen ausschließlich nach außen. Es stellt alle für OEE, MES, Energieanalyse und Wartungsprognosen nötigen Daten bereit, ohne der Steuerung von außen manipulierbare Angriffspunkte zu bieten. Das bedeutet nicht, dass auf Netzwerksicherheit verzichtet werden kann; Netzwerksegmentierung, TLS-Verschlüsselung und Zugriffskontrollen bleiben unerlässlich. Der wesentliche Sicherheitsgewinn liegt darin, dass MTConnect keinerlei Gefahren durch versehentliche Schreibbefehle birgt.

Dritter Wendepunkt: Standardspezifikation vs. Agent-Release

In der Praxis wird oft fälschlicherweise angenommen: „Wenn der Agent Version 2.8 erreicht hat, entspricht der Standard 2.8.“ Der Agent ist jedoch das ausführende Softwareprogramm; der Standard ist das normative Spezifikationsdokument. Der C++-Referenz-Agent (cppagent) erreichte am 13. Oktober 2026 den Stand 2.8.0.4. Seine Dokumentation führt aus, welche Standardspezifikationen unterstützt werden: Versionen 2.5, 2.6 und 2.7. Release 2.5 brachte Paletten-/Spannmittelmodelle und WebSocket-Streaming; 2.6 ergänzte strukturierte REST-Fehlermeldungen und AssetAdded-Meldungen; 2.7 führte standardisierte Part-, Process- und Task-Assetstrukturen ein.^[4][5]

Diese Differenzierung beeinflusst Einkaufs- und Integrationsentscheidungen maßgeblich. Wer bei einem MES-Hersteller nach MTConnect-Unterstützung fragt, benötigt zwei klare Antworten: Welche Standardspezifikation wird verarbeitet, und welches Agent-Release kommt zum Einsatz? Die Open-Source-.NET-Bibliothek MTConnect.NET deckt Spezifikationen bis 2.7 ab, was verdeutlicht, dass ältere Agents und moderne Client-Software versionsmäßig aufeinander abgestimmt sein müssen. Auch das Pufferverhalten des Agents, Ringspeichergrößen und das Wiederverbindungsmanagement prägen die Praxis im Betrieb entscheidend.^[4][5][6]

Auf der Adapterebene existieren ebenfalls wichtige Wahlmöglichkeiten. SHDR (Simple Hierarchical Data Representation) ist ein zeilenbasiertes, einfaches Textprotokoll, das bei älteren CNC-Adaptern dominiert. Moderne Architekturen setzen zwischen Maschinenadapter und Agent zunehmend auf MQTT oder strukturiertes JSON. Diese Transportentscheidung ist zwar nicht Teil des Kernstandards, entscheidet jedoch über die Skalierbarkeit der Lösung.

Einsatzmatrix: Für wen eignet sich MTConnect?

Vier verbreitete Praxisirrtümer

• „Mit der MTConnect-Installation sind sofort alle Maschinendaten verfügbar.“ Falsch. Der Agent gibt nur jene Signale aus, die der jeweilige Hardware-Adapter bereitstellt. Ist ein Sensor im Adapter nicht angebunden, bleibt er im Datenstrom unsichtbar.
• „Agent und Adapter sind identische Programme.“ Falsch. Der Adapter liest die proprietäre Schnittstelle der Steuerung; der Agent überführt die Rohdaten in das MTConnect-Schema und verwaltet die Client-Verbindungen. Beide Komponenten zu verwechseln, ist der häufigste Architekturfehler.
• „Das Abfragen von /current bildet den gesamten Fertigungsverlauf ab.“ Falsch. /current liefert eine Momentaufnahme. Um kurze Alarme und Mikrostillstände lückenlos zu erfassen, ist die sequenzbasierte Abfrage via /sample zwingend erforderlich.
• „Die Elementnamen sind bei jeder Steuerung identisch.“ Falsch. Der Grundwortschatz ist standardisiert, die Dialekte der Hersteller variieren jedoch. Wer ohne Übersetzungstabelle arbeitet, riskiert unbemerkte Datenfehler.

Auch das Alarmhandling verlangt Sorgfalt. Alarme sind in MTConnect keine einfachen Wahrheitswerte (Booleans), sondern durchlaufen die formalen Zustände Warning, Fault und Normal. Wertet eine Software nur das Ereignis Fault aus, ignoriert jedoch den Übergang zu Normal, bleibt der Alarm im Leitsystem aktiv, obwohl die Störung an der Maschine längst behoben ist. Zustandsübergänge müssen stets im Zusammenspiel mit dem avail-Status validiert werden.^[4]

Sieben entscheidende Schritte zur Produktivsetzung

1. Netzwerk isolieren: Eine DMZ oder einen Reverse-Proxy zwischen Maschinennetz und Firmennetzwerk einrichten. Einen Agenten niemals ungeschützt ins Internet stellen.
2. Agent nah an der Steuerung platzieren: Den Agenten lokal auf der Maschine oder einem maschinennahen Edge-Gerät betreiben, um Paketverluste im Ringspeicher zu minimieren.
3. Adapter-Transport gezielt wählen: Für bestehende Steuerungen SHDR nutzen; für moderne Edge-Umgebungen MQTT oder JSON evaluieren.
4. Gerätemodell (/probe) versionieren: Das strukturelle XML-Modell der Maschine in der Versionsverwaltung sichern und bei Firmware-Updates der CNC gegenprüfen.
5. Dialekttabelle pflegen: Eindeutige Dokumentation von dataItemId, name, physikalischen Einheiten und betrieblicher Bedeutung über alle Fabrikate hinweg.
6. Uhren per NTP synchronisieren: Steuerungen, Edge-Agents und Auswerteserver auf denselben Zeitserver abgleichen; ohne konsistente Zeitstempel ist keine Stillstandsanalyse verlässlich.
7. Grenzfälle simulieren: Das Verhalten bei Stromausfall (avail=UNAVAILABLE), quittierten Alarmen und Wiederverbindungen vorab im Testaufbau prüfen.

Fazit: Gemeinsame Sprache, gemeinsame Verantwortung

Der technologische Wert von MTConnect bemisst sich nicht nach der schieren Anzahl übertragener Werte, sondern nach der Fähigkeit, heterogene Maschinen in einem einheitlichen Satz sprechen zu lassen. Eine gemeinsame Sprache verlangt jedoch klare Vereinbarungen: wer die Gerätemodelle pflegt, wer Dialekte übersetzt und welche Parameter niemals für externe Schreibzugriffe geöffnet werden dürfen.

Wo lagern die Fertigungsdaten in Ihrem Betrieb heute? Und kann Ihr Team klar unterscheiden, welche Prozessdaten werksweit offen beobachtet werden dürfen und welche Steuerungsfunktionen strikt vor Netzwerkzugriffen geschützt bleiben müssen?

Dieser Beitrag ist Teil unserer Serie zu CNC-Steuerungsprotokollen mit FOCAS, Heidenhain DNC/LSV2 und Mazak. Grundlagen zur seriellen Kommunikation finden Sie in unserem RS-232-Leitfaden; Details zur Protokollphysik bietet unser Fachartikel zu I2C, SPI und UART.