How to Run an IIoT Proof of Concept in 30 Days

An IIoT proof of concept should answer one business question with real plant data in a short, fixed time, and 30 days is enough if you keep the scope tight. In this guide you will get a week-by-week plan, the success metrics to agree on before you start, a lightweight stack of one gateway, a managed MQTT broker and a dashboard, and a working simulator so you can build the data pipeline before the hardware even arrives.

Why Most IIoT Pilots Stall

Industrial IoT pilots rarely fail because the technology does not work. They stall because the scope grows to "connect the whole line," because nobody agreed what success looks like, or because the pilot depends on infrastructure that takes months to approve. The result is the infamous pilot purgatory: a demo that impresses once and is never used again.

A good proof of concept is the opposite. It is small enough to finish, important enough that someone on the floor wants the result, and built on components that can scale without a rewrite if it succeeds.

Step 1: Choose a Narrow, Valuable Scope

Pick one question that a specific person needs answered. Good examples:

• "Why does the bottleneck CNC in cell 3 stop, and for how long?"
• "Is the compressor running when the plant is idle at night?"
• "How often does furnace 2 exceed its temperature band?"

Then limit the scope deliberately:

1. One to three machines, ideally the same type.
2. Three to ten signals, such as state, part count, current and one alarm.
3. Read-only. No writing to PLCs in the proof of concept.
4. One dashboard, used by named people.

If your target machine has no network interface, plan for add-on sensors instead. Our guide to retrofitting legacy machines for IoT covers current clamps and part counters.

Step 2: Agree on Success Metrics Before Day 1

Write the metrics down and get the plant manager to sign them. Mix technical and business measures.

The targets above are examples. Set your own, but make them measurable. "Show the value of IIoT" is not a metric. Many teams also capture expected payback for the business case; our article on IIoT ROI explains how to frame it honestly.

Step 3: Pick a Lightweight Stack

Resist building a platform. A proof of concept needs four things:

1. A data source. The machine's PLC through a protocol gateway, or add-on sensors through a microcontroller.
2. An edge gateway. A small industrial PC or Raspberry Pi running Node-RED, a Python script or a commercial gateway that reads the source and publishes MQTT.
3. A broker. A managed MQTT broker so nobody spends week one installing and securing a server.
4. A dashboard. Node-RED Dashboard, Grafana fed by a small subscriber, or the broker's own dashboard for the very first days.

This is the same layered model described in our IIoT architecture reference, just with one component per layer. Because every layer talks MQTT, each piece can be swapped later without touching the others.

The 30-Day IIoT Proof of Concept Plan

For the network work in week 1, the IIoT connectivity checklist gives you the exact rules and test commands.

Build the Pipeline Before the Hardware Arrives

Hardware and firewall approvals often take a week or more. Do not wait. Build the full pipeline against a simulator on day one, using the public MQTT test broker, so that when the real gateway goes live it simply replaces the simulator.

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]
        # Random state changes: mostly running, sometimes idle or stopped
        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)

Watch the stream from another terminal with the topic the script prints:

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

The simulator uses the same topic structure and payload format the real gateway will use: retained state and part count, non-retained current readings, an ISO timestamp in every message. Build your dashboard against it. When the gateway is ready, switch the dashboard and gateway to your private broker with TLS and the credentials from the portal. The public broker is for development only, because anyone can read it.

Who Does What During the 30 Days

A proof of concept needs a small team with clear roles, not a steering committee. Three or four people are usually enough:

• The sponsor, often the plant or production manager, owns the business question and makes the go or no-go decision on day 30.
• The controls engineer owns everything at the machine: which tags or sensors to read, read-only access, and validating values against the HMI.
• The IT or data person owns the network path, the broker credentials and the dashboard.
• The end user, typically a shift supervisor or maintenance lead, tests the dashboard every day from week 3 and says honestly whether it helps.

Hold a fifteen-minute check-in twice a week. Anything blocked for more than two days goes straight to the sponsor, because a 30-day plan has no slack for waiting on approvals.

Common Proof of Concept Pitfalls

• Picking the hardest machine first. Start with a machine that has an accessible interface and a cooperative owner.
• No operator involvement. If operators were not involved in the dashboard, they will not use it, and adoption is a success metric.
• Collecting everything. Two thousand tags make the pilot slower and the insight harder to find. Start with the signals that answer your question.
• Skipping the boring metrics. Data completeness and latency are what the IT and OT teams will ask about before scaling. Measure them.
• Building throwaway infrastructure. A broker on someone's laptop has to be rebuilt to scale. Use something that can carry the production rollout.

From Proof of Concept to Rollout

If the pilot succeeds, the next question is how fast you can add machines. With a clean topic hierarchy and a broker that scales by plan, adding the tenth machine looks the same as adding the second. ConnectMQ lets you start on the free Serverless plan (up to 25 connections, QoS up to 1, 256 KB messages), which comfortably covers a 30-day pilot, and move to paid Serverless with QoS 2 and shared subscriptions or a Dedicated cluster as the rollout grows, without changing topics or client code. The portal's live topic explorer, ISA-95 devices view and threshold alert rules support weeks 2 and 3 directly. For the full journey beyond the pilot, read the Industrial IoT with MQTT guide.

Start Your 30-Day Pilot on ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required. Run the simulator against your own ConnectMQ broker on day one, build the dashboard while hardware is on order, and arrive at day 30 with real numbers.

Frequently Asked Questions

How long should an IIoT proof of concept take?

Around 30 days is realistic for one to three machines with a narrow question. Longer pilots tend to grow in scope without producing a decision.

What does an IIoT proof of concept cost?

Mostly people's time plus a gateway and possibly sensors. A free managed broker tier and open-source tools such as Node-RED keep the software cost low.

How many machines should a pilot include?

One to three, ideally of the same type. That is enough to prove the data path and the value without turning the pilot into a rollout.

What happens after a successful proof of concept?

Use the documented effort per machine and the measured metrics to plan a phased rollout. Keep the same topic hierarchy and broker so the pilot becomes the first phase rather than a throwaway.