Live data flowing within 30 days of hardware installation. No IT department required. See exactly what it looks like for your machines.
Calculate Your Downtime CostPractical guides, benchmarks, and shop floor strategies — no fluff, no spam, unsubscribe anytime.
TPG Capital acquired Kepware. Prices are going up. The Unified Namespace replaces per-driver licensing with open-standard MQTT, eliminates the single point of failure, and runs on Linux edge compute instead of Windows servers. Here is the migration path.
Point-to-point integrations do not scale. The Unified Namespace replaces spaghetti with a single event-driven hub — MQTT, Sparkplug B, and ISA-95 hierarchy. How it works, how it compares to historians and MES, and why small shops benefit too.
A tool crash costs $200 in tooling and $15,000 in spindle damage. Tool wear monitoring catches the degradation days before the break. Vibration signatures, spindle load patterns, failure mode reference table, and how to get started.
Every CNC machine on your floor speaks a different language. Haas talks Haas. Mazak talks Mazak. Fanuc talks Fanuc. If you want to monitor all of them from one dashboard, you need a common language. That language is Sparkplug B.
Sparkplug B is not a product. It is an open specification built on top of MQTT — the same messaging protocol used by Tesla, Facebook, and Amazon for IoT. It was designed specifically for industrial environments by people who have spent decades connecting factory equipment. And it solves problems that raw MQTT cannot.
Walk into any CNC shop with 10 machines and you will find at least 3 different control platforms. A Haas NGC, a Fanuc 0i-TF, a Siemens 840D. Each has its own way of exposing data — different registers, different formats, different connection methods.
Traditional approaches to monitoring these machines require a custom integration for each control type. A Fanuc FOCAS library for the Fanuc machines. MTConnect for the ones that support it. A proprietary OPC server for the Siemens. Each integration costs $5,000-$15,000 and takes weeks to implement. Add a new machine brand and you start over.
This is why most shops with fewer than 50 machines do not have machine monitoring. The integration cost exceeds the perceived value. And that perception is wrong — but the cost problem is real.
MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol. Instead of devices talking directly to each other (point-to-point), they all talk to a central broker. Publishers send data to named topics. Subscribers listen to the topics they care about.
Think of it like a radio system. Each machine publishes on its own channel. The dashboard subscribes to all channels. The broker handles the routing. No machine needs to know where the data ends up — it just publishes.
MQTT is small, fast, and reliable. It works on low-bandwidth connections (cellular, satellite). It handles intermittent connectivity gracefully — messages are queued when the connection drops and delivered when it reconnects. For industrial environments where network reliability is never guaranteed, this matters.
But raw MQTT has limitations. It does not define how topics should be structured, how devices should announce themselves, or what the data format should be. Every company that uses MQTT invents their own conventions. That is where Sparkplug B comes in.
When a device connects to the network, Sparkplug B requires it to publish a “birth certificate” (DBIRTH message). This message describes the device: what metrics it reports, what data types they are, what units they use. When the device disconnects — whether gracefully or due to a power failure — the broker publishes a “death certificate” (DDEATH message).
This means you always know exactly which devices are online, which are offline, and when the change happened. No polling. No heartbeat timeouts. No guessing. When a sensor drops off your CNC machine at 2 AM, you get a notification, not a gap in the data you discover Monday morning.
Most machine data does not change every second. A spindle running at 8,000 RPM reports 8,000 RPM continuously. Sending that same value every second wastes bandwidth, storage, and processing.
Sparkplug B uses Report by Exception (RBE): data is only published when it changes. If the spindle speed is stable at 8,000 RPM, no message is sent. When it changes to 10,000 RPM, one message fires. This reduces data volume by 60-90% in typical CNC monitoring scenarios while keeping the dashboard perfectly up to date.
Sparkplug B defines a mandatory topic namespace based on the ISA-95 hierarchy — the industrial standard for modeling manufacturing operations:
In a CNC shop, this translates to:
Every piece of data is automatically tagged with where it came from: which enterprise, which site, which area, which edge node, which device. No manual tagging. No CSV mapping files. The topic structure encodes the context.
Sparkplug B uses Protocol Buffers (protobuf) for data encoding, not JSON. This makes messages compact and strictly typed. A spindle speed value is declared as a 32-bit float, not a string that might or might not parse as a number. This prevents the data-type mismatches that plague JSON-based systems at scale.
Each metric can carry metadata: engineering units, data type, description, and aliases for efficient repeat transmission. When a machine publishes its birth certificate, the consuming application knows not just the value but what it means — without any external configuration.
Here is what a Sparkplug B data stream from a CNC machine actually looks like in practice:
| Metric Name | Data Type | Example Value | Source |
|---|---|---|---|
| spindle_speed | Float | 8450.0 | Controller / power monitoring |
| feed_rate | Float | 120.5 | Controller / derived from axis motion |
| vibration_velocity | Float | 1.82 | Vibration sensor (mm/s RMS) |
| spindle_load | Float | 42.0 | Controller (% of max) |
| utilization | Boolean | true | Derived (spindle running = utilized) |
| tool_number | Int32 | 7 | Controller |
| part_count | Int64 | 1247 | Controller / manual entry |
The auto-discovery aspect is where this gets powerful. When a new machine is connected to the network and its edge node publishes a DBIRTH, the system automatically registers the machine, creates its dashboard tile, and starts collecting data. No database entries. No configuration files. Plug in the sensor, and the machine appears.
This is the question that comes up in every technical conversation about industrial IoT. The answer is straightforward: they solve different problems and are complementary, not competing.
| Capability | Sparkplug B | OPC-UA |
|---|---|---|
| Primary use | Sensor data, monitoring, edge-to-cloud | Controller access, bidirectional control |
| Architecture | Publish/subscribe via broker | Client/server, direct connection |
| Bandwidth | Very low (protobuf + RBE) | Moderate to high |
| Connectivity | Handles intermittent (store & forward) | Requires stable connection |
| Device discovery | Automatic (birth certificates) | Browse server address space |
| Write to device | Limited (NCMD/DCMD commands) | Full read/write to controller |
| Best for | Retrofitting existing machines with external sensors | New machines with OPC-UA built into the controller |
For a CNC shop that wants to start monitoring machines that do not have OPC-UA built in (which is most machines older than 5 years), Sparkplug B with external sensors is the path of least resistance. No controller modification, no PLC programming, no IT integration.
If you later add machines with OPC-UA controllers, the edge compute node can bridge OPC-UA data into the same Sparkplug B topic namespace. One dashboard, one data model, regardless of how the data gets off the machine.
If you are running 5-50 CNC machines, the protocol your monitoring system uses determines three things:
Sparkplug B is not experimental. It is an Eclipse Foundation open standard (version 3.0 released 2022, compatible with MQTT 5.0) with production deployments across manufacturing, oil and gas, energy, and water treatment.
When your monitoring data speaks Sparkplug B, it is natively compatible with the ecosystem these companies are building. Your data is not stranded — it is on the same bus as the rest of the industry.
See Sparkplug B data live
Our lab runs 3 CNC machines publishing Sparkplug B data in real time. Watch birth certificates arrive, see metrics update on change, and explore the topic namespace.
Watch live Sparkplug B data from 3 CNC machines →Sparkplug B is not something you need to understand in depth to benefit from. It runs under the hood of your monitoring system the same way TCP/IP runs under your web browser. What matters is what it enables: automatic device discovery, efficient data transmission, vendor-neutral architecture, and compatibility with the direction the entire manufacturing automation industry is heading.
When someone tries to sell you a proprietary monitoring system with a proprietary protocol and a proprietary data format, ask one question: “Can I take my data with me if I leave?” With Sparkplug B, the answer is always yes.
Open standards. Open data. Your machines, your data, your choice.
