Smart factory KPIs only help when they are computed from trustworthy data and seen while there is still time to act. This guide defines 15 KPIs that most manufacturers can track in real time, gives the formula for each, and lists exactly which machine events you need to publish so the numbers can be calculated live from an MQTT data stream.
What Makes a KPI "Smart"
A traditional KPI is calculated at the end of the week from manual reports. A smart factory KPI differs in three ways:
- It is computed from machine data, not from memory or spreadsheets.
- It updates continuously, so a shift supervisor can react within the shift.
- It can be drilled down from plant to line to machine to reason, because the raw events carry that context.
All three depend on the same foundation: a small set of well-defined events published by every machine. Get those right, and most KPIs below are simple arithmetic.
The Raw Data Behind Smart Factory KPIs
Almost every KPI in this list is built from six event types. Publish them consistently under an ISA-95 topic hierarchy and you can derive the rest.
| Event | Example topic | Payload essentials |
|---|---|---|
| Machine state | .../line1/cnc4/state |
state, reason code, timestamp (retained) |
| Count | .../line1/cnc4/count |
good, scrap, rework, order ID, timestamp |
| Ideal cycle time | .../line1/cnc4/order/current |
order ID, material, ideal cycle seconds (retained) |
| Quality result | .../line1/qc1/result |
serial or lot, pass/fail, defect code |
| Energy | .../line1/cnc4/energy |
kWh meter reading, timestamp |
| Planned schedule | .../line1/schedule |
planned production time, breaks (retained) |
The ISA-95 MQTT topics article explains how to build the path in front of these leaf topics.
15 Smart Factory KPIs
Equipment Effectiveness
| # | KPI | Formula | Data needed |
|---|---|---|---|
| 1 | Availability | Run time / planned production time | State events, schedule |
| 2 | Performance | (Ideal cycle time x total count) / run time | Counts, ideal cycle time, state |
| 3 | Quality rate | Good count / total count | Counts with good and scrap |
| 4 | OEE | Availability x Performance x Quality | All of the above |
| 5 | TEEP | OEE x (planned production time / all time) | OEE, calendar time |
OEE is the umbrella metric for equipment effectiveness. The step-by-step calculation, including the pitfalls of choosing the ideal cycle time, is in how to calculate OEE, and the difference between OEE and TEEP is discussed in OEE vs TEEP vs OOE.
Reliability and Maintenance
| # | KPI | Formula | Data needed |
|---|---|---|---|
| 6 | MTBF | Total run time / number of failures | State events with failure reason |
| 7 | MTTR | Total repair time / number of repairs | Down and back-to-run timestamps |
| 8 | Unplanned downtime share | Unplanned down time / planned production time | State events with reason category |
| 9 | Planned maintenance compliance | Completed planned tasks / scheduled tasks | Maintenance events from CMMS |
MTBF and MTTR depend on clean state transitions and on distinguishing failures from planned stops. MTBF and MTTR calculation covers the edge cases, such as how to count a failure that spans a shift change.
Quality
| # | KPI | Formula | Data needed |
|---|---|---|---|
| 10 | First pass yield (FPY) | Units passing first time / units entering | Quality results per unit or lot |
| 11 | Scrap rate | Scrap count / total count | Counts |
| 12 | Defects per million (DPMO) | Defects / (units x opportunities) x 1,000,000 | Defect codes, opportunities per unit |
FPY differs from the OEE quality rate when rework exists: a reworked part counts as good in the end but not as a first-pass success. Publishing rework as its own count keeps both numbers honest.
Flow and Cost
| # | KPI | Formula | Data needed |
|---|---|---|---|
| 13 | Throughput | Good units / hour | Counts |
| 14 | Average cycle time | Run time / total count | State, counts |
| 15 | Energy per unit | kWh consumed / good units | Energy meter, counts |
Energy per unit is one of the most useful KPIs to add in a smart factory because it links production and utilities. It needs a meter per machine or line and timestamps that align with counts; see factory energy monitoring for metering options.
Computing a KPI Live from MQTT Events
To show how little code a real-time KPI needs, the following Python script subscribes to state and count events for one machine and prints availability, quality rate and throughput every ten seconds. It uses paho-mqtt 2.x and the public MQTT test broker; replace the prefix with your own random ID.
import json
import time
import uuid
import paho.mqtt.client as mqtt
BASE = "connectmq/demo/kpi-6a0c/line1/cnc4"
start = time.time()
run_seconds = 0.0
state, state_since = "UNKNOWN", start
good = scrap = 0
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe([(f"{BASE}/state", 1), (f"{BASE}/count", 1)])
def on_message(client, userdata, msg):
global state, state_since, run_seconds, good, scrap
data = json.loads(msg.payload)
now = time.time()
if msg.topic.endswith("/state"):
if state == "RUNNING":
run_seconds += now - state_since
state, state_since = data["state"], now
else:
good += data.get("good", 0)
scrap += data.get("scrap", 0)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"kpi-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()
while True:
time.sleep(10)
now = time.time()
running = run_seconds + (now - state_since if state == "RUNNING" else 0)
elapsed = now - start
total = good + scrap
availability = running / elapsed if elapsed else 0
quality = good / total if total else 0
throughput = good / (elapsed / 3600) if elapsed else 0
print(f"state={state} availability={availability:.1%} "
f"quality={quality:.1%} throughput={throughput:.0f}/h")
Feed it test events from the command line:
mosquitto_pub -h broker.connectmq.com -p 1883 -i kpi-pub-6a0c -t "connectmq/demo/kpi-6a0c/line1/cnc4/state" -m '{"state":"RUNNING"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i kpi-pub-6a0c -t "connectmq/demo/kpi-6a0c/line1/cnc4/count" -m '{"good":5,"scrap":1}'
In production you would use the planned schedule instead of elapsed time, persist the state, and write results to a time-series database for trends. The structure stays the same. A complete pipeline with dashboards is described in real-time OEE monitoring.
Showing the Right Smart Factory KPIs to the Right People
The same events produce different views for different audiences, and matching the view to the audience matters more than the number of KPIs:
| Audience | KPIs | Refresh | Where |
|---|---|---|---|
| Operators | Current state, throughput vs target, scrap this hour | Seconds | Screen at the line |
| Shift supervisors | OEE per machine, top downtime reasons, open calls | Minutes | Tablet or office screen |
| Maintenance | MTBF, MTTR, unplanned downtime share | Daily | Maintenance dashboard |
| Plant management | OEE trend, FPY, energy per unit, throughput | Weekly | Report or management dashboard |
Line screens connect to the broker over secure WebSocket and update live; management views query a time-series database fed by the same events. Because ConnectMQ delivers each event to every subscriber, adding a new view never requires changing the machines or the gateways.
Common KPI Mistakes
- Tracking too many KPIs. Pick three to five per audience. Operators need state, throughput and current OEE; managers need trends and losses.
- Mixing definitions between sites. Write down what counts as planned time, a failure and a good part before comparing plants.
- Using a "theoretical" ideal cycle time nobody can reach. Performance then looks permanently poor and people stop trusting the number.
- Ignoring data gaps. A gateway that was offline should show "no data", not "machine stopped". A last will message on a status topic makes the difference visible.
- Showing KPIs without reasons. A low availability figure invites the question why. Collect reason codes alongside states.
A Reliable Data Backbone for Your KPIs
Every KPI above inherits the reliability of the pipeline under it. ConnectMQ runs that pipeline as a managed MQTT broker: MQTT 3.1.1 and 5.0, TLS and secure WebSocket for browser dashboards, retained messages for current state, and a portal with a live topic explorer, dashboard and threshold alert rules for quick checks. Your KPI services, Node-RED flows or Grafana pipelines connect as normal MQTT clients. For the overall roadmap, see the smart manufacturing guide.
Track Your Smart Factory KPIs on ConnectMQ
Create a free Serverless broker at app.connectmq.com with no credit card, publish state and count events from one machine and have live availability and throughput figures in minutes.
Frequently Asked Questions
Which smart factory KPI should I start with?
Start with availability and the downtime reasons behind it, because state data is the easiest to collect and the losses are usually the largest. Add performance and quality to reach full OEE.
How real-time do manufacturing KPIs need to be?
Operators benefit from updates every few seconds to a minute so they can react within the shift. Management trends can be aggregated hourly or per shift from the same events.
What is the difference between FPY and the OEE quality rate?
The OEE quality rate counts all good units, including reworked ones. First pass yield only counts units that were good the first time, so it exposes hidden rework.
Do I need an MES to calculate these KPIs?
No. Most of them can be calculated directly from machine state, count and energy events published over MQTT. An MES adds order context and workflows on top.



