So gelingt ein IIoT Proof of Concept in 30 Tagen

Ein IIoT Proof of Concept sollte eine einzige geschäftliche Frage mit echten Werksdaten in kurzer, fest definierter Zeit beantworten, und 30 Tage reichen dafür, wenn Sie den Umfang eng halten. In diesem Leitfaden erhalten Sie einen Plan Woche für Woche, die Erfolgskennzahlen, auf die Sie sich vor dem Start einigen sollten, einen schlanken Stack aus einem Gateway, einem verwalteten MQTT-Broker und einem Dashboard sowie einen funktionierenden Simulator, mit dem Sie die Datenpipeline aufbauen, noch bevor die Hardware eintrifft.

Warum die meisten IIoT-Piloten ins Stocken geraten

Industrial-IoT-Piloten scheitern selten daran, dass die Technik nicht funktioniert. Sie geraten ins Stocken, weil der Umfang auf „die ganze Linie anbinden" anwächst, weil sich niemand darauf geeinigt hat, wie Erfolg aussieht, oder weil der Pilot von Infrastruktur abhängt, deren Genehmigung Monate dauert. Das Ergebnis ist das berüchtigte Pilot-Fegefeuer: eine Demo, die einmal beeindruckt und dann nie wieder genutzt wird.

Ein guter Proof of Concept ist das Gegenteil. Er ist klein genug, um abgeschlossen zu werden, wichtig genug, dass jemand in der Fertigung das Ergebnis haben will, und auf Komponenten aufgebaut, die im Erfolgsfall ohne Neuentwicklung skalieren.

Schritt 1: Einen engen, wertvollen Umfang wählen

Wählen Sie eine Frage, auf die eine bestimmte Person eine Antwort braucht. Gute Beispiele aus dem Mittelstand:

• „Warum steht die Engpass-CNC in Zelle 3 still, und wie lange?"
• „Läuft der Kompressor nachts, wenn das Werk stillsteht?"
• „Wie oft überschreitet Ofen 2 sein Temperaturband?"

Begrenzen Sie dann den Umfang bewusst:

1. Eine bis drei Maschinen, idealerweise vom selben Typ.
2. Drei bis zehn Signale, etwa Zustand, Stückzahl, Strom und ein Alarm.
3. Nur lesend. Im Proof of Concept wird nicht in SPSen geschrieben.
4. Ein Dashboard, genutzt von namentlich benannten Personen.

Hat Ihre Zielmaschine keine Netzwerkschnittstelle, planen Sie stattdessen Nachrüstsensoren ein. Unser Leitfaden zum Nachrüsten älterer Maschinen für IoT behandelt Stromzangen und Stückzähler.

Schritt 2: Erfolgskennzahlen vor Tag 1 festlegen

Schreiben Sie die Kennzahlen auf und lassen Sie sie vom Werksleiter abzeichnen. Kombinieren Sie technische und geschäftliche Messgrößen.

Die obigen Ziele sind Beispiele. Legen Sie Ihre eigenen fest, aber machen Sie sie messbar. „Den Wert von IIoT zeigen" ist keine Kennzahl. Viele Teams erfassen für den Business Case zusätzlich die erwartete Amortisation; unser Artikel zum IIoT-ROI erklärt, wie Sie ihn ehrlich darstellen.

Schritt 3: Einen schlanken Stack wählen

Widerstehen Sie der Versuchung, eine Plattform zu bauen. Ein Proof of Concept braucht vier Dinge:

1. Eine Datenquelle. Die SPS der Maschine über ein Protokoll-Gateway oder Nachrüstsensoren über einen Mikrocontroller.
2. Ein Edge-Gateway. Ein kleiner Industrie-PC oder Raspberry Pi mit Node-RED, einem Python-Skript oder ein kommerzielles Gateway, das die Quelle liest und per MQTT veröffentlicht.
3. Einen Broker. Einen verwalteten MQTT-Broker, damit niemand die erste Woche damit verbringt, einen Server zu installieren und abzusichern.
4. Ein Dashboard. Node-RED Dashboard, Grafana mit einem kleinen Subscriber als Datenquelle oder für die allerersten Tage das broker-eigene Dashboard.

Das ist dasselbe Schichtenmodell, das in unserer Referenz zur IIoT-Architektur beschrieben ist, nur mit einer Komponente pro Schicht. Weil jede Schicht MQTT spricht, lässt sich jedes Teil später austauschen, ohne die anderen anzufassen.

Legen Sie die Topic-Namen schon im Pilot so fest, dass sie später den Unified Namespace (UNS) bilden können: Die ISA-95-Hierarchie aus Unternehmen, Standort, Bereich, Linie und Zelle wird zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Dann wird aus dem Pilot der erste Ast des UNS statt eines Insel-Datensilos; Details dazu im Beitrag Sparkplug B und der Unified Namespace.

Der 30-Tage-Plan für den IIoT Proof of Concept

Für die Netzwerkarbeit in Woche 1 liefert die IIoT-Konnektivitäts-Checkliste die genauen Regeln und Testbefehle.

Die Pipeline bauen, bevor die Hardware eintrifft

Hardware und Firewall-Freigaben dauern oft eine Woche oder länger. Warten Sie nicht. Bauen Sie am ersten Tag die vollständige Pipeline gegen einen Simulator auf dem öffentlichen MQTT-Broker, sodass das echte Gateway bei Inbetriebnahme den Simulator einfach ersetzt.

import json
import random
import time
import uuid
from datetime import datetime, timezone
import paho.mqtt.client as mqtt

POC_ID = uuid.uuid4().hex[:6]
BASE = f"connectmq/demo/{POC_ID}/plant1/cell3"
MACHINES = ["cnc01", "cnc02"]

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"poc-sim-{POC_ID}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
print(f"Subscribe to: {BASE}/#")

state = {m: {"state": "RUNNING", "parts": 0} for m in MACHINES}

while True:
    now = datetime.now(timezone.utc).isoformat(timespec="seconds")
    for m in MACHINES:
        s = state[m]
        # Zufällige Zustandswechsel: meist laufend, manchmal im Leerlauf oder gestoppt
        r = random.random()
        new_state = "RUNNING" if r < 0.85 else ("IDLE" if r < 0.95 else "STOPPED")
        if new_state != s["state"]:
            s["state"] = new_state
            client.publish(f"{BASE}/{m}/state",
                           json.dumps({"value": new_state, "ts": now}),
                           qos=1, retain=True)
        if s["state"] == "RUNNING":
            s["parts"] += 1
            client.publish(f"{BASE}/{m}/parts",
                           json.dumps({"value": s["parts"], "ts": now}),
                           qos=1, retain=True)
        amps = round(random.uniform(8, 12) if s["state"] == "RUNNING" else random.uniform(0.5, 2), 2)
        client.publish(f"{BASE}/{m}/current",
                       json.dumps({"value": amps, "unit": "A", "ts": now}), qos=0)
    time.sleep(5)

Beobachten Sie den Datenstrom in einem zweiten Terminal mit dem Topic, das das Skript ausgibt:

mosquitto_sub -h broker.connectmq.com -p 1883 -i poc-watch-$RANDOM \
  -t 'connectmq/demo/<POC_ID>/plant1/cell3/#' -v

Der Simulator verwendet dieselbe Topic-Struktur und dasselbe Payload-Format wie später das echte Gateway: Retained-Zustand und Stückzahl, nicht retained Stromwerte und einen ISO-Zeitstempel in jeder Nachricht. Bauen Sie Ihr Dashboard dagegen. Sobald das Gateway bereit ist, stellen Sie Dashboard und Gateway auf Ihren privaten Broker mit TLS und den Zugangsdaten aus dem Portal um. Der öffentliche MQTT-Broker ist nur für Tests und Prototypen gedacht, nicht für Produktionsdaten, denn jeder kann ihn lesen.

Wer macht was in den 30 Tagen

Ein Proof of Concept braucht ein kleines Team mit klaren Rollen, keinen Lenkungsausschuss. Drei oder vier Personen reichen meist:

• Der Sponsor, oft der Werks- oder Produktionsleiter, verantwortet die geschäftliche Frage und trifft an Tag 30 die Go- oder No-Go-Entscheidung.
• Der Automatisierungstechniker verantwortet alles an der Maschine: welche Tags oder Sensoren gelesen werden, den Nur-Lese-Zugriff und den Abgleich der Werte mit dem HMI.
• Die IT- oder Datenperson verantwortet den Netzwerkpfad, die Broker-Zugangsdaten und das Dashboard.
• Der Endanwender, typischerweise ein Schichtleiter oder Instandhaltungsleiter, testet das Dashboard ab Woche 3 täglich und sagt ehrlich, ob es hilft.

Halten Sie zweimal pro Woche ein fünfzehnminütiges Abstimmungstreffen ab. Alles, was länger als zwei Tage blockiert ist, geht direkt an den Sponsor, denn ein 30-Tage-Plan hat keinen Puffer für das Warten auf Freigaben.

Typische Fallstricke beim Proof of Concept

• Mit der schwierigsten Maschine beginnen. Starten Sie mit einer Maschine, die eine zugängliche Schnittstelle und einen kooperativen Verantwortlichen hat.
• Keine Einbindung der Bediener. Wurden die Bediener nicht am Dashboard beteiligt, werden sie es nicht nutzen, und Akzeptanz ist eine Erfolgskennzahl.
• Alles erfassen. Zweitausend Tags machen den Pilot langsamer und die Erkenntnis schwerer auffindbar. Beginnen Sie mit den Signalen, die Ihre Frage beantworten.
• Die langweiligen Kennzahlen überspringen. Datenvollständigkeit und Latenz sind genau das, wonach IT- und OT-Teams vor dem Skalieren fragen werden. Messen Sie sie.
• Wegwerf-Infrastruktur bauen. Ein Broker auf dem Laptop eines Kollegen muss für die Skalierung neu aufgebaut werden. Nutzen Sie etwas, das auch den Produktions-Rollout tragen kann.

Vom Proof of Concept zum Rollout

Ist der Pilot erfolgreich, lautet die nächste Frage, wie schnell Sie weitere Maschinen hinzufügen können. Mit einer sauberen, an ISA-95 ausgerichteten UNS-Topic-Hierarchie und einem Broker, der über den Plan skaliert, sieht das Hinzufügen der zehnten Maschine genauso aus wie das der zweiten. Mit ConnectMQ starten Sie im kostenlosen Serverless-Plan (bis zu 25 Verbindungen, QoS bis 1, Nachrichten bis 256 KB), der einen 30-Tage-Pilot problemlos abdeckt, und wechseln mit wachsendem Rollout zu kostenpflichtigem Serverless mit QoS 2 und Shared Subscriptions oder zu einem Dedicated-Cluster, ohne Topics oder Client-Code zu ändern. Der Live-Topic-Explorer im Portal, die ISA-95-Geräteansicht und die Regeln für Schwellwert-Alarme unterstützen die Wochen 2 und 3 direkt. Für den gesamten Weg über den Pilot hinaus lesen Sie den Leitfaden zu Industrial IoT mit MQTT.

Starten Sie Ihren 30-Tage-Pilot mit ConnectMQ

Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ganz ohne Kreditkarte. Lassen Sie den Simulator am ersten Tag gegen Ihren eigenen ConnectMQ-Broker laufen, bauen Sie das Dashboard, während die Hardware bestellt ist, und kommen Sie an Tag 30 mit echten Zahlen an.

Häufig gestellte Fragen

Wie lange sollte ein IIoT Proof of Concept dauern?

Rund 30 Tage sind für eine bis drei Maschinen mit einer eng gefassten Frage realistisch. Längere Piloten wachsen tendenziell im Umfang, ohne zu einer Entscheidung zu führen.

Was kostet ein IIoT Proof of Concept?

Vor allem Arbeitszeit, dazu ein Gateway und eventuell Sensoren. Ein verwalteter MQTT-Broker im kostenlosen Tarif und Open-Source-Werkzeuge wie Node-RED halten die Softwarekosten niedrig.

Wie viele Maschinen sollte ein Pilot umfassen?

Eine bis drei, idealerweise vom selben Typ. Das genügt, um Datenpfad und Nutzen nachzuweisen, ohne den Pilot in einen Rollout zu verwandeln.

Was passiert nach einem erfolgreichen Proof of Concept?

Nutzen Sie den dokumentierten Aufwand pro Maschine und die gemessenen Kennzahlen, um einen schrittweisen Rollout zu planen. Behalten Sie dieselbe Topic-Hierarchie im UNS und denselben Broker bei, damit der Pilot zur ersten Phase wird statt zum Wegwerfprodukt.