Connected Worker mit MQTT über WebSocket

Ein Connected Worker ist ein Bediener, Techniker oder Schichtleiter, dessen Geräte genau dann die richtigen Informationen erhalten, wenn es darauf ankommt: die nächste Arbeitsanweisung, einen Maschinenalarm, eine Qualitätssperre oder eine Bitte um Unterstützung. Dieser Artikel behandelt die Connected-Worker-Anwendungsfälle, die in der Fertigung Nutzen stiften, die Strukturierung der zugrunde liegenden MQTT-Topics und einen funktionierenden Browser-Client, der Aufgaben empfängt und Quittierungen über sicheres WebSocket sendet.

Was eine Connected-Worker-Lösung tatsächlich leistet

Die meisten Werker in der Fertigung erfahren von Problemen noch immer, indem sie daran vorbeilaufen. Eine Maschine wartet auf Material, bis es jemand bemerkt, ein Instandhaltungstechniker wird per Funk gerufen, und Arbeitsanweisungen liegen in einem Ordner am Arbeitsplatz. Connected-Worker-Lösungen schließen diese Lücke, indem sie Live-Daten aus dem Werk zu den Menschen bringen statt die Menschen zu den Daten.

Typische Funktionen:

Digitale Arbeitsanweisungen, die sich automatisch mit dem aktiven Auftrag oder der Variante ändern.
Gezielte Alarme: Ein Maschinenstopp geht an die Uhr des zuständigen Technikers, nicht an alle.
Hilfeanforderungen und Eskalation: Ein Bediener tippt auf „Material benötigt“, und die Anforderung eskaliert, wenn niemand sie innerhalb weniger Minuten annimmt.
Checklisten und Freigaben: Anfahrprüfungen, Qualitätsprüfungen und Umrüstungen werden mit Person und Zeitpunkt erfasst.
Rückmeldung in beide Richtungen: Werker ergänzen Ursachencodes, Fotoverweise oder Kommentare, die in die Daten zurückfließen.

Das Schlüsselwort ist Echtzeit. Eine Aufgabenliste, die sich alle paar Minuten aktualisiert, reicht nicht, wenn eine Linie steht; Ereignisse müssen innerhalb von Sekunden ankommen.

Connected-Worker-Anwendungsfälle in der Fertigung

Anwendungsfall	Ereignisquelle	Empfänger	Erfasste Reaktion
Ruf bei Maschinenstopp	Zustandswechsel in der SPS	Linientechniker	Angenommen, vor Ort, behoben
Materialnachschub	Bedienertaster oder Füllstandssensor	Logistik	Angenommen, geliefert
Qualitätssperre	Fehlermuster an einer Prüfstation	Qualitätsingenieur, Linienleitung	Sperre bestätigt, freigegeben
Umrüstanweisungen	Auftragswechsel im MES	Bediener am Arbeitsplatz	Jeder Schritt bestätigt
Sicherheits- oder Umweltalarm	Gassensor, Temperaturgrenzwert	Alle in einem Bereich	Quittiert
Schichtübergabe	App der Schichtleitung	Schichtleitung der nächsten Schicht	Lesebestätigung

Viele davon überschneiden sich mit einem digitalen Andon-System; der Unterschied besteht darin, dass ein Connected-Worker-Setup Ereignisse an einzelne Geräte leitet und die Reaktion jeder Person festhält.

Warum MQTT zu Connected-Worker-Apps passt

Geräte in der Fertigung sind mobil, batteriebetrieben und häufig in lückenhaftem WLAN unterwegs. Das Design von MQTT passt zu dieser Umgebung:

Push statt Polling. Geräte halten eine einzige schlanke Verbindung und erhalten Ereignisse sofort, was im Vergleich zum Abfragen einer API Akku und Netzwerk schont.
Funktioniert im Browser. Über MQTT über WebSocket kann eine einfache Web-App auf einem Tablet abonnieren, ohne dass etwas installiert werden muss.
Retained Messages geben einem Gerät den aktuellen Zustand (aktiver Auftrag, offene Rufe) in dem Moment, in dem es sich neu verbindet.
Persistente Sessions mit Session Expiry sorgen dafür, dass ein Gerät, das durch ein Funkloch läuft, die zwischenzeitlich gepufferten QoS-1-Nachrichten erhält.
MQTT-5-Request/Response mit Response Topics und Correlation Data bildet „Aufgabe gesendet, Aufgabe angenommen“ ganz natürlich ab.

Topic-Design

Organisieren Sie Topics für Broadcast-Ereignisse nach Werksbereich und für gezielte Aufgaben nach Rolle oder Person. Die Bereichs-Topics folgen dabei der ISA-95-Hierarchie (Unternehmen → Werk → Bereich → Linie) und fügen sich so in einen Unified Namespace (UNS) ein, in dem Werkerrufe neben Maschinen- und Auftragsdaten stehen:

acme/plant1/assembly/line2/calls/open/<callId>     retained, cleared when resolved
acme/plant1/assembly/line2/instructions/station4   retained, current instruction
acme/plant1/workers/role/maintenance/tasks         tasks for anyone in a role
acme/plant1/workers/user/u1042/tasks               tasks for one person
acme/plant1/workers/responses                      accept, arrive, resolve events

Das Tablet eines Technikers abonniert seine Rolle, sein eigenes Benutzer-Topic und die offenen Rufe seines Bereichs. Ein retained Ruf wird gelöscht, indem eine leere retained Message auf dasselbe Topic veröffentlicht wird, wodurch er auf allen Geräten gleichzeitig verschwindet.

Ein Browser-Client über sicheres WebSocket

Das folgende Beispiel ist ein minimaler Connected-Worker-Client mit MQTT.js v5. Er verbindet sich über sicheres WebSocket auf Port 8084, abonniert offene Rufe und persönliche Aufgaben und veröffentlicht eine Annahme mit der ID des Werkers. Er läuft nach npm install mqtt in jedem modernen Browser-Bundle (Vite, webpack).

import mqtt from "mqtt";

const prefix = "connectmq/demo/cw-4f19";          // eigene Zufalls-ID verwenden
const workerId = "u1042";
const clientId = `cw-${workerId}-${Math.random().toString(16).slice(2, 8)}`;

const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId,
  protocolVersion: 5,
  clean: false,
  properties: { sessionExpiryInterval: 1800 },   // gepufferte QoS-1-Nachrichten 30 Minuten aufbewahren
  reconnectPeriod: 2000,
});

const openCalls = new Map();

client.on("connect", () => {
  client.subscribe(
    [`${prefix}/line2/calls/open/+`, `${prefix}/workers/user/${workerId}/tasks`],
    { qos: 1 }
  );
});

client.on("message", (topic, payload) => {
  if (topic.includes("/calls/open/")) {
    const callId = topic.split("/").pop();
    if (payload.length === 0) {
      openCalls.delete(callId);                     // Ruf behoben, retained Message gelöscht
    } else {
      openCalls.set(callId, JSON.parse(payload.toString()));
    }
    render();
  } else {
    const task = JSON.parse(payload.toString());
    navigator.vibrate?.(300);
    console.log("New task:", task);
  }
});

export function acceptCall(callId) {
  client.publish(
    `${prefix}/workers/responses`,
    JSON.stringify({ callId, workerId, action: "ACCEPTED", ts: Date.now() }),
    { qos: 1 }
  );
}

function render() {
  console.table([...openCalls.entries()].map(([id, c]) => ({ id, ...c })));
}

Lösen Sie einen Testruf über die Kommandozeile aus und beobachten Sie, wie er auf dem Gerät erscheint; löschen Sie ihn anschließend mit einer leeren retained Message:

mosquitto_pub -h broker.connectmq.com -p 1883 -i cw-plc-4f19 -r -q 1 \
  -t "connectmq/demo/cw-4f19/line2/calls/open/C-001" \
  -m '{"type":"MACHINE_STOP","station":"press2","reason":"jam"}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i cw-plc-4f19 -r -q 1 -n \
  -t "connectmq/demo/cw-4f19/line2/calls/open/C-001"

Der öffentliche MQTT-Broker unterstützt QoS 0 bis 2 und eine Session Expiry von bis zu 30 Minuten, was genügt, um das Reconnect-Verhalten auszuprobieren. Denken Sie daran, dass sein öffentlicher Bereich für jeden lesbar ist; senden Sie dort also niemals echte Namen oder Werksdaten.

Checkliste für den Rollout von Connected-Worker-Projekten

Beginnen Sie mit einem schmerzhaften Prozess, meist Rufe bei Maschinenstopp oder Materialrufe, und messen Sie die Reaktionszeit vorher und nachher.
Binden Sie Bediener früh ein. Ist ein Alarm für sie nur Rauschen, wird er ignoriert oder stummgeschaltet.
Leiten Sie nach Rolle und Bereich, nicht an alle. Broadcasts erzeugen schnell Alarmmüdigkeit.
Planen Sie die Eskalation: Nimmt niemand einen Ruf innerhalb einer definierten Zeit an, geht er an die nächste Ebene.
Lassen Sie Geräte sich still erholen. Nutzen Sie retained Zustände und persistente Sessions, damit ein Reconnect keine Benutzeraktion erfordert.
Verwenden Sie eindeutige Zugangsdaten pro Gerät oder App-Instanz, ausschließlich über TLS oder sicheres WebSocket.
Erfassen Sie die Reaktionen in einer Datenbank für Reaktionszeitanalysen und kontinuierliche Verbesserung.
Planen Sie gemeinsam genutzte Geräte ein: Eine Schichtanmeldung entscheidet, welches Benutzer-Topic ein Stationstablet abonniert.

Messen, ob es funktioniert

Ein Connected-Worker-Projekt sollte seinen Nutzen mit Kennzahlen belegen, die dem Werk ohnehin wichtig sind. Da jeder Ruf und jede Reaktion ein MQTT-Ereignis ist, können Sie ohne zusätzlichen Aufwand messen:

Zeit bis zur Annahme: vom Auslösen des Rufs bis zur Annahme durch eine Person.
Zeit bis zum Eintreffen: von der Annahme bis zur Bestätigung des Technikers, dass er am Arbeitsplatz ist.
Zeit bis zur Behebung: vom Ruf bis die Linie wieder läuft, was direkt mit dem Stillstand zusammenhängt.
Eskalationsquote: wie oft Rufe auf der ersten Ebene unbeantwortet bleiben, ein Zeichen für Unterbesetzung oder schlechtes Routing.
Rufe pro Schicht und Arbeitsplatz: Ein wiederkehrender Ruf am selben Arbeitsplatz ist ein Problem, das behoben werden muss, nicht nur eines, auf das reagiert wird.

Besprechen Sie diese Kennzahlen während des Pilotprojekts jede Woche mit dem Team. Ziel ist nicht schnelleres Feuerlöschen, sondern weniger Brände; speisen Sie wiederkehrende Ursachen daher in Ihren Verbesserungsprozess ein.

Connected-Worker-Apps mit ConnectMQ skalieren

Jedes Tablet, jede Uhr und jedes Liniendisplay hält eine eigene Verbindung, sodass die Zahl der Verbindungen schnell wächst. ConnectMQ ist ein vollständig verwalteter MQTT-Broker, der sicheres WebSocket auf Port 8084 mit einem Let's-Encrypt-Zertifikat bereitstellt, sodass sich Browser-Apps ohne Zertifikats-Workarounds verbinden. Der kostenlose Serverless-Plan deckt ein Pilotprojekt mit bis zu 25 Verbindungen ab, der Plan Serverless (Paid) skaliert auf 1.000 Verbindungen mit QoS 2 und Shared Subscriptions, und Dedicated-Cluster isolieren größere Installationen. Eskalationslogik und Protokollierung der Reaktionen laufen in Ihren eigenen Diensten, etwa einem Node-RED-Flow oder einem kleinen Node.js-Worker, die sich als gewöhnliche Clients verbinden.

Den vollständigen Werkskontext liefert der Smart-Manufacturing-Leitfaden, und die Übersicht zum Cloud-MQTT-Broker erklärt, wie ein gehosteter Broker Werk und mobile Geräte sicher verbindet.

Vernetzen Sie Ihre Werker mit ConnectMQ

Erstellen Sie unter app.connectmq.com kostenlos und ohne Kreditkarte einen Serverless-Broker, übernehmen Sie den generierten Benutzernamen, das Passwort und die Client-ID in den obigen Browser-Client und senden Sie noch heute Ihren ersten Live-Ruf an ein Tablet.

Häufig gestellte Fragen

Welche Geräte eignen sich als Connected-Worker-Geräte?

Tablets, Smartphones, Smartwatches, robuste Handhelds und große Liniendisplays funktionieren alle. Alles mit einem modernen Browser kann MQTT über sicheres WebSocket nutzen; native Apps können direkt eine MQTT-Bibliothek verwenden.

Wie erhalten Werker Nachrichten, die sie offline verpasst haben?

Nutzen Sie eine persistente Session mit Session Expiry Interval und QoS-1-Abonnements, damit der Broker Nachrichten puffert, während das Gerät getrennt ist. Retained Messages liefern beim Reconnect den aktuellen Zustand.

Sollte jedes Gerät eigene Zugangsdaten haben?

Ja. Eindeutige Zugangsdaten und Client-IDs pro Gerät oder App-Instanz ermöglichen es, ein verlorenes Tablet zu sperren, ohne andere zu beeinträchtigen, und nachzuvollziehen, wer welche Reaktion gesendet hat.

Ist eine Connected-Worker-Plattform dasselbe wie ein Andon-System?

Sie überschneiden sich. Andon macht Probleme an der Linie sichtbar; eine Connected-Worker-Lösung leitet zusätzlich Aufgaben an bestimmte Personen weiter und erfasst deren Reaktionen.

Connected-Worker-Lösungen mit MQTT: Arbeitsanweisungen und Alarme in Echtzeit