Smart Manufacturing Guide: From Connected Machines to Data-Driven Plants

This smart manufacturing guide shows how to turn isolated machines into a plant that measures itself in real time. You will learn which use cases pay off first, how data should flow from a PLC to a dashboard, how to name it so it stays usable, and how to build a working pipeline with MQTT in an afternoon.

What Smart Manufacturing Actually Means

Smart manufacturing is not a product you buy. It is the practice of collecting data from machines, processes and people continuously, making that data available to anyone who needs it, and using it to make better decisions faster than a weekly spreadsheet allows.

Most plants already generate the data. PLCs know whether a spindle is turning, energy meters know how many kilowatt-hours a compressor used, and quality stations know which parts failed inspection. The problem is that this information is locked inside individual machines, proprietary HMIs and point-to-point integrations that nobody wants to touch. A smart plant breaks those silos with three ingredients:

1. Connectivity: every relevant signal leaves the machine in a standard, open format.
2. A shared data backbone: one place where producers publish and consumers subscribe, instead of dozens of custom links.
3. Context: data that carries its meaning with it, so "temperature 71.2" becomes "line 2, CNC 4, spindle bearing temperature in Celsius".

The rest of this guide covers each ingredient and how they combine into concrete projects. If you want the broader industry framing first, the Industry 4.0 guide explains where smart manufacturing fits among the wider set of technologies.

High-Value Smart Manufacturing Use Cases

The best first project is the one that answers a question your production manager already asks every morning. The table below lists the use cases that most often justify the effort, what data each needs and where to go deeper.

Notice that the first two rows need very little data. A single digital signal that says "running or not" plus a part counter is enough to calculate availability and throughput. That is why downtime tracking is the classic starting point: cheap to instrument, immediately useful, and it builds the plumbing every later project reuses.

The Plant Data Flow: From Machine to Decision

Every smart manufacturing architecture, however it is branded, follows the same four layers. Understanding them prevents the most expensive mistake in plant digitalization: building one-off integrations that cannot be extended.

Layer 1: Data sources

These are PLCs, CNC controllers, robots, smart sensors, energy meters, barcode scanners and operator terminals. They speak a mix of protocols: Modbus TCP or RTU, OPC UA, EtherNet/IP, Profinet, vendor-specific CNC interfaces, or simply digital I/O. For older machines without any interface, a small retrofit sensor such as a current clamp or a stack-light tap is often the fastest way to get a running signal. The shop floor data collection article compares these options in detail.

Layer 2: Edge gateways

An edge gateway sits close to the machines, reads the native protocols and translates readings into MQTT messages. It can be an industrial PC running Node-RED, a Raspberry Pi with a Python script, an ESP32 for simple sensors, or a commercial protocol converter. The gateway is also where you buffer data when the network drops, add timestamps and convert raw register values into engineering units.

Layer 3: The MQTT data backbone

All gateways publish to a central MQTT broker, and all applications subscribe to it. This publish/subscribe pattern is the key architectural decision. A new dashboard, a historian or a maintenance model can be added later by subscribing to existing topics, without touching a single PLC. The machines do not need to know who consumes their data.

MQTT works well here because it is lightweight, tolerates unreliable networks, supports quality-of-service levels and has client libraries for practically every language and platform. Running the broker yourself means patching, monitoring and securing a critical piece of infrastructure; a fully managed MQTT service removes that operational burden so the plant team can focus on the data.

Layer 4: Consumers

Consumers are the tools that turn messages into decisions: dashboards on the shop floor, a time-series database such as InfluxDB fed by Telegraf, an MES, alerting logic, maintenance models, or a 3D view of the line. Each one is just another MQTT client. For how this layer connects to production planning systems, see MES and MQTT integration.

Designing a Topic Namespace That Scales

A topic namespace is the address book of your plant. Get it right early and every new consumer can find data without asking anyone. Get it wrong and you end up with topics like data/plc7/reg40012 that only one engineer understands.

The widely adopted approach is to follow the ISA-95 equipment hierarchy, which is also the backbone of the Unified Namespace pattern:

<enterprise>/<site>/<area>/<line>/<cell>/<category>

acme/izmir/machining/line2/cnc4/state
acme/izmir/machining/line2/cnc4/telemetry
acme/izmir/machining/line2/cnc4/counters
acme/izmir/utilities/compressors/comp1/energy

A few rules keep the namespace clean:

• Use lowercase, no spaces and no leading slash.
• Keep the hierarchy physical (where something is), and put the kind of data in the last level.
• Publish current state as retained messages so a new subscriber immediately sees the latest value.
• Put units and timestamps in the JSON payload, not in the topic.
• Never put secrets, personal data or serial numbers you consider sensitive in topic names.

ConnectMQ detects ISA-95 and Unified Namespace topics automatically and shows connected devices grouped by enterprise, site, area, line and cell in its portal. If some of your equipment already speaks Sparkplug B, ConnectMQ decodes the Protobuf payloads and republishes them into readable ISA-95 topics, so a message on spBv1.0/factory1/DDATA/line1/cnc1 becomes available on connectmq/factory1/production/line1/cnc1/telemetry. The Sparkplug B and Unified Namespace article explains the trade-offs between both conventions.

A Step-by-Step Smart Manufacturing Roadmap

This roadmap is deliberately incremental. Each step delivers something useful on its own, and none of them requires a plant-wide shutdown or a multi-year budget.

1. Pick one line and one question. For example: "Why did line 2 produce 15 percent less than planned last week?" A narrow question keeps the scope honest.
2. Inventory the signals. List what each machine on that line can already provide and what needs a retrofit sensor. Usually a running signal, a part counter and an alarm code are enough to start.
3. Define the topic namespace. Write down the ISA-95 path for every asset on the line and the payload format. Agree on it before any code is written.
4. Prototype on a test broker. Use a public MQTT test broker to validate payloads and dashboards with simulated or non-sensitive data.
5. Deploy edge gateways. Install gateways that read the machines and publish to the namespace. Add local buffering for network outages.
6. Move to a private broker with credentials and TLS. Production data belongs on an authenticated, encrypted connection.
7. Build the first consumer. A line status board or a downtime report. Show it to operators and supervisors and collect feedback.
8. Add context. Let operators assign downtime reasons from a tablet, as described in downtime reason codes. Data without reasons tells you that you lost time, not why.
9. Measure and expand. Track the KPI you chose in step 1 for a few weeks. When it moves, replicate the pattern to the next line and add a second use case such as energy or condition monitoring.

Small and mid-sized manufacturers can follow exactly the same sequence with a smaller footprint; the smart manufacturing for SMBs article shows how to do it with off-the-shelf hardware.

Hands-On: Stream a Simulated Machine with Python

The fastest way to understand the data flow is to build it. The script below simulates a CNC machine that publishes its state and telemetry to the free public area of broker.connectmq.com. It uses paho-mqtt 2.x, a retained status topic and a Last Will message, which are the same building blocks a real gateway uses.

Install the library first:

pip install "paho-mqtt>=2.0"

Then save this as cnc_simulator.py:

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/site1/line1/cnc1"

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=f"cnc1-sim-{RUN_ID}",
)
# If the simulator dies, the broker publishes "offline" for us.
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)


def on_connect(client, userdata, flags, reason_code, properties):
    print(f"Connected: {reason_code}. Subscribe with:")
    print(f'  mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-{RUN_ID} -t "{BASE}/#" -v')
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)


client.on_connect = on_connect
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

state = "RUNNING"
parts = 0
try:
    while True:
        # Occasionally change machine state to create downtime events.
        if random.random() < 0.1:
            new_state = random.choice(["RUNNING", "RUNNING", "IDLE", "STOPPED"])
            if new_state != state:
                state = new_state
                payload = {"state": state, "ts": int(time.time() * 1000)}
                client.publish(f"{BASE}/state", json.dumps(payload), qos=1, retain=True)

        if state == "RUNNING":
            parts += 1

        telemetry = {
            "ts": int(time.time() * 1000),
            "spindleTempC": round(random.uniform(38.0, 46.0), 2),
            "spindleRpm": 8000 if state == "RUNNING" else 0,
            "partCount": parts,
        }
        client.publish(f"{BASE}/telemetry", json.dumps(telemetry), qos=0)
        time.sleep(2)
except KeyboardInterrupt:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True)
    client.loop_stop()
    client.disconnect()

Run it with python cnc_simulator.py and copy the mosquitto_sub command it prints into a second terminal. You will see retained status and state messages arrive immediately, followed by telemetry every two seconds. Stop the script with Ctrl+C and the status flips to offline; kill it hard instead and the broker publishes the Last Will after the keepalive expires.

Two details matter on the public broker. Topic depth is limited to eight levels, so the demo uses a shortened hierarchy under the unique connectmq/demo/<id> prefix. And everything in the public area is readable by anyone, so only simulated or non-sensitive values belong there.

Turning Messages into Your First KPI

Raw messages become valuable when they answer a question. The subscriber below listens to the state topic and calculates availability, the first factor of OEE, from the time spent in each state. Pass the run ID printed by the simulator as an argument.

import json
import sys
import time
import uuid

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]
STATE_TOPIC = f"connectmq/demo/{RUN_ID}/site1/line1/cnc1/state"

durations = {"RUNNING": 0.0, "IDLE": 0.0, "STOPPED": 0.0}
current = {"state": None, "since": None}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(STATE_TOPIC, qos=1)


def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    now = data["ts"] / 1000
    if current["state"] is not None:
        durations[current["state"]] += now - current["since"]
    current["state"], current["since"] = data["state"], now
    planned = sum(durations.values())
    if planned > 0:
        availability = durations["RUNNING"] / planned * 100
        print(f"state={data['state']:<8} availability={availability:5.1f}% {durations}")


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"oee-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

This is intentionally simple: it treats all observed time as planned production time and ignores shifts and planned breaks. A production version stores state changes in a database and calculates availability, performance and quality per shift. The smart factory KPIs article covers which metrics to add next and how to avoid vanity numbers.

Reliability, Security and Scale on the Shop Floor

A prototype that works on a laptop is not yet a plant system. Before you rely on the data for decisions, address these points.

Quality of service. Use QoS 1 for state changes, counters and alarms, which must not be lost, and QoS 0 for high-frequency telemetry where the next sample replaces a missed one. The MQTT QoS levels explained article goes through the delivery guarantees in detail.

Edge buffering. Network outages happen. Gateways should queue messages locally and publish them with their original timestamps after reconnecting, so the time series has no holes.

Security. Production traffic should use TLS on port 8883 with per-gateway credentials. Never share one username across every device, and never expose plant networks directly to the internet; gateways make outbound connections only. The MQTT security best practices checklist is a good review before go-live.

Broker capacity. Count your clients and message sizes up front. A pilot line might need a dozen connections; a whole plant with per-machine gateways, dashboards and services can need hundreds. With ConnectMQ, the free Serverless plan covers up to 25 connections with QoS up to 1, the paid Serverless plan raises this to 1,000 connections with QoS 2, 1 MB messages and shared subscriptions, and Dedicated or BYOC plans give you an isolated cluster or a deployment in your own cloud account.

Monitoring the backbone. Watch connection states as closely as machine states. A gateway that silently disconnects looks exactly like a machine that stopped. Retained status topics with a Last Will, combined with threshold alerts in your broker portal, make these failures visible.

Common Smart Manufacturing Pitfalls

Most stalled projects fail for organizational reasons rather than technical ones. Watch out for these patterns:

• Starting with a platform instead of a problem. Buying a large suite before you know which decisions you want to improve leads to dashboards nobody opens.
• Point-to-point integrations. Connecting the MES directly to each PLC works for one machine and becomes unmaintainable at twenty. Route everything through the broker.
• Missing context. Downtime without reason codes, energy without production volume, and quality data without batch IDs are hard to act on.
• Ignoring operators. The people on the line know why the machine stopped. Give them an easy way to record it, and show them the results.
• No owner for the namespace. Someone must approve new topics and payload formats, or the structure decays within months.
• Treating the cloud as all or nothing. Real-time control loops stay on the PLC. The broker carries monitoring, analytics and coordination traffic, not safety functions.

Where to Go Next

Once the first line is connected, the same backbone supports more advanced work: maintenance models that read vibration data, 3D views of the line, and plant-wide energy baselines. For the industrial architecture behind all of this, the industrial IoT with MQTT guide is the natural companion to this smart manufacturing guide.

Connect Your Plant with ConnectMQ

You can build the entire pipeline from this guide without running any broker infrastructure. Sign up at app.connectmq.com on the free Serverless plan, no credit card required, create a broker and copy the generated username, password and client ID into your gateways. Point them at port 8883 with TLS, and use the portal's live topic explorer, ISA-95 devices view and threshold alert rules to watch your first line come online. When you are ready to grow beyond the pilot, a cloud MQTT broker plan scales with you from one line to the whole plant.

Frequently Asked Questions

What is the best first smart manufacturing project?

Machine status and downtime tracking on a single line is the most common and reliable starting point. It needs only a running signal and a part counter, delivers visible results quickly and builds the data plumbing that later projects reuse.

Do I need to replace my old machines to start smart manufacturing?

No. Older machines can be retrofitted with external sensors such as current clamps, stack-light taps or vibration sensors connected to an edge gateway that publishes over MQTT. Replacement is only worth considering when the machine itself is the bottleneck.

Why use MQTT instead of connecting systems directly?

MQTT decouples producers from consumers. Machines publish once to the broker, and any number of dashboards, databases or models can subscribe without new integrations on the shop floor, which keeps the architecture maintainable as it grows.

Can I use the public broker for production data?

No. The public area of broker.connectmq.com is readable by everyone and is meant for testing with simulated or non-sensitive data. Production data should go to a private broker with credentials and TLS.

How does ISA-95 relate to the Unified Namespace?

ISA-95 defines the enterprise, site, area, line and cell hierarchy. The Unified Namespace uses that hierarchy as the topic structure of a central MQTT broker, so every piece of plant data has a predictable, self-describing address.