IIoT: What “Connecting Your Machines” Actually Means in Practice
1. What This Resource Covers & Why It Matters
Studies show that 72% of factory tasks are still performed manually. Most manufacturers operate what practitioners call islands of automation: individual machines that run well in isolation but share no data with each other, with management, or with any upstream or downstream system. A CNC machine finishes a part. Nobody knows the cycle time, the spindle load, or whether the machine was actually cutting or sitting idle waiting for an operator. The data exists inside the controller. Nobody can see it.
The Industrial Internet of Things, or IIoT, is the category of hardware and software that extracts that data from machines and makes it visible in real time. The concept sounds simple. In practice, the path from concept to working data depends heavily on how old the machine is, what controller it runs, and what the shop actually wants to do with the information once it has it.
This article covers the practical mechanics of connecting machines to an IIoT system, with specific attention to the question almost no vendor content answers: what do you actually do with a 2008 CNC machine that has no network port?
2. Typical Equipment in This System
| Equipment | Role or Typical Capability |
|---|---|
| IIoT edge gateway | Hardware device installed in the machine’s electrical cabinet; collects data from the controller and transmits it to a network or cloud platform; handles protocol translation for legacy machines |
| Current transformer (CT) sensor | Clamps around power supply wires without cutting them; measures electrical current draw to infer machine state: running, idle, or stopped; works on any machine regardless of controller age |
| MTConnect adapter | Software or hardware layer that translates a CNC controller’s native data into MTConnect’s standardized XML format; required for machines whose controllers do not natively support MTConnect |
| OPC-UA server | Software layer installed on or near a modern controller that exposes machine data in the OPC-UA standard format; allows read and write access to controller variables |
| MQTT broker | Lightweight messaging protocol layer that routes data from machines to cloud or on-premise platforms; commonly used between edge gateways and analytics systems |
| Machine monitoring software / dashboard | Platform that receives, stores, and visualizes data from connected machines; calculates OEE, downtime categories, and production counts |
| Network switch / industrial router | Provides wired or wireless network access to machine areas; industrial-rated hardware handles temperature, vibration, and EMI conditions on the shop floor |
3. How It Works: Real-World Breakdown
The Three Tiers of Machine Connectivity
IIoT connectivity falls into three tiers based on what the machine can provide. Understanding which tier a given machine sits in determines the hardware approach, the data richness available, and the installation complexity.
Tier 1: Modern machines with native connectivity. Controllers from roughly 2015 onward from FANUC, Okuma, Mazak, Siemens, and Haas increasingly support MTConnect or OPC-UA natively. Connecting these machines requires installing an adapter or enabling a built-in protocol, then pointing the monitoring software at the machine’s IP address. Data available typically includes spindle speed, feed rate, program name, alarm codes, axis positions, and machine state. For shops with newer equipment, this path is the fastest and lowest cost.
Tier 2: Older machines with serial or proprietary interfaces. A 2008 Mazak or FANUC controller likely has a serial port, a proprietary DNC interface, or a fieldbus connection such as DeviceNet. These machines can still provide rich data. However, connecting them requires a hardware gateway that translates the machine’s native protocol into something a modern network can handle. Companies like Beckhoff, Kepware, and Shop Floor Automations specialize in exactly this translation layer. Beckhoff’s EK9160 IoT Coupler, for example, reads from legacy controllers and transmits via OPC-UA or MQTT without requiring any PLC reprogramming.
Tier 3: Very old machines with no digital communication. A 1998 vertical machining center with a Fanuc Series 0 control or a relay-logic-based machine has no protocol to speak and no port to speak through. In practice, this is where current transformer sensors provide the pragmatic answer.
The Current Transformer Approach: Getting Data From Any Machine
A current transformer sensor clamps around the power supply wires feeding the machine’s spindle motor or main disconnect. No cutting, no wiring changes, no controller access required. The sensor measures electrical current draw at high frequency and transmits that reading to an edge gateway via a short wire or wireless transmitter.
The data available through a CT sensor is limited but immediately useful. Current draw correlates directly with machine state. A spindle under cutting load draws significantly more current than an idle spindle. A machine in e-stop or with the power on but not cutting draws near zero. From these current signatures, the monitoring platform infers whether the machine is cutting, idle, or stopped, and calculates uptime, downtime, and utilization rates.
This approach works on any machine that uses electricity. A CT sensor on a 30-year-old lathe, a press brake, a grinding machine, or a welding positioner produces the same basic visibility: when is the machine running, and when is it not. For shops whose primary question is “where is my hidden capacity,” that answer is worth significant money before any richer data integration is attempted.
[IMAGE: Current transformer sensor clamped around power supply cables entering a legacy CNC electrical cabinet, with labeled wiring to a small edge gateway mounted on a DIN rail]
MTConnect vs. OPC-UA: The Protocol Question
Both of these are the two dominant standards for machine data in manufacturing, and they serve different purposes. MTConnect was designed specifically for CNC machines and shop floor equipment. The protocol defines a standard vocabulary for manufacturing data: spindle speed is spindle speed, regardless of whether the machine is a Mazak or a Haas. MTConnect reads data from the machine and publishes it as XML over HTTP, which any monitoring software can consume without custom development.
OPC-UA is bidirectional. It allows reading data from a machine and writing commands back to it. Beyond that, OPC-UA is plant-wide rather than machine-specific, making it the standard for connecting machines to PLCs, to MES systems, and to ERP layers. Modern machines from Siemens, Beckhoff, and many robot controllers natively support OPC-UA. The practical difference for a shop manager is simple: use MTConnect if you want to monitor CNC machines and the vendor supports it; use OPC-UA if you want to connect machines to broader plant-wide systems or need to write data back to the controller.
For machines that support neither, a hardware gateway running translation software handles the conversion. MachineMetrics, Excellerant, and Scytec DataXchange all ship edge devices pre-loaded with dozens of software adapters that automatically unlock and standardize data from specific controller models without requiring PLC programming or NC program modifications.
4. Integration & Deployment Reality
Network infrastructure is the first physical requirement most shops underestimate. Getting data out of a machine requires that machine to have a network connection. Older machine areas often have no Ethernet drops nearby. Running conduit and cable to each machine adds installation time and cost. Industrial WiFi access points rated for shop floor environments provide an alternative, but require careful placement to avoid interference from CNC spindle drives and high-current equipment. Plan the network before ordering any sensors or gateways.
IT and OT boundary. Shop floor machines running on isolated networks for security reasons require a defined path for data to cross from the operational technology network to the IT network or cloud. Industrial routers or DMZ configurations handle this boundary. Involve the IT team early. A monitoring project that installs hardware before addressing network security policy creates problems that delay go-live significantly.
Data destination. Deciding where data lives before installation determines which platform handles it. Cloud-hosted platforms like MachineMetrics and Guidewheel minimize on-premise infrastructure but require reliable internet connectivity and introduce data retention and privacy considerations. On-premise platforms keep data inside the facility but require a server, backup procedures, and ongoing maintenance. Hybrid edge-plus-cloud architectures run analytics locally on the gateway and sync summaries to the cloud, reducing bandwidth requirements while maintaining real-time local visibility.
Cybersecurity. Connecting machines to a network introduces attack surface that did not previously exist. Establish firewall rules that prevent inbound connections to machine controllers from outside the facility network. Segment the machine network from the corporate network. Use VPN for any remote access to machine data. These are not advanced security measures. They are the baseline that any connected shop floor requires.
5. Common Failure Modes & Constraints
| Failure | Root Cause | Signal / Symptom |
|---|---|---|
| Gateway loses connection to machine | Network switch in machine area loses power or fails; IP address conflict on network | Data gap in monitoring dashboard; machine shows as offline despite running |
| CT sensor reads false idle state | Sensor clamped on wrong wire or measuring three-phase incorrectly; machine running light cuts with low current | Machine shows idle in dashboard while operator observes active cutting |
| MTConnect adapter stops publishing data | Controller firmware update changes data point names or addresses; adapter configuration no longer matches controller | Dashboard shows stale data; no alarms generated because connection still exists |
| Data collected but never acted upon | No defined process for reviewing dashboard data; no owner assigned to respond to downtime alerts | OEE data accumulates without driving improvement; project loses internal support |
| Network interference from CNC drives | WiFi access point positioned too close to servo drives or spindle inverters | Intermittent connection drops; data gaps correlate with high-power cutting operations |
The most common failure in IIoT projects is not technical. It is organizational. A shop that installs monitoring hardware and generates dashboards nobody reviews has spent capital without producing return. Assign a specific person to review the downtime data per shift, define what actions specific downtime categories trigger, and hold a weekly review of the previous week’s OEE by machine. The hardware is the easy part. The process change that uses the data is where the return actually comes from.
6. When It’s a Good Fit vs. a Bad Fit
Good fit when:
IIoT monitoring delivers the clearest return when a shop believes it has capacity available but cannot identify where it is going. If machines appear busy but output is lower than expected, monitoring reveals whether the loss is downtime, slow cycles, or quality. Beyond diagnosis, IIoT is a strong fit for shops being asked by customers for production traceability data, cycle time documentation, or quality records that manual logging cannot reliably produce. Defense, medical device, and automotive customers increasingly require this data as a condition of doing business.
High risk when:
The investment carries risk when the shop has not defined what questions it wants the data to answer before ordering hardware. A shop that installs gateways on 20 machines because the concept sounds compelling, without identifying which machines are the actual bottlenecks, collects enormous volumes of data it cannot act on. Start with the two or three machines where the output gap is most visible and most expensive. Expand after the first installation demonstrates what the data reveals and how the team responds.
Usually the wrong tool when:
IIoT is the wrong immediate investment when the binding constraint is something the data cannot address: material shortages, sales volume limitations, or process engineering problems that measurement alone will not fix. A machine that is idle because parts are not arriving from a supplier does not need a connectivity upgrade. It needs a supply chain intervention. Measure what matters and be honest about whether machine data is the variable that drives the outcome you need.
7. Key Questions Before Committing
- Which two or three machines represent the largest gap between expected and actual output, and has the cause of that gap been confirmed as machine-side downtime rather than upstream or downstream process variation?
- What controller model and year does each target machine carry, and has a connectivity path been identified specifically for that controller, whether native MTConnect, gateway-based protocol translation, or CT sensor?
- Where will the machine network connect to the broader facility network, and has the IT team reviewed and approved the network architecture, firewall configuration, and data routing plan before hardware is ordered?
- Who owns the data after installation, specifically who reviews the downtime dashboard per shift, what actions specific downtime categories require, and who is accountable for the OEE trend over 90 days?
- What is the data destination, specifically cloud-hosted, on-premise, or hybrid, and does that destination match the facility’s internet reliability, data privacy requirements, and ongoing IT maintenance capacity?
8. How axis Recommends Using This Information
Axis recommends that shops approaching IIoT for the first time start with a single machine, not a facility-wide rollout. Choose the machine where downtime cost is most visible and most painful. Install the simplest monitoring approach that answers the question that matters most for that machine. If the machine is old enough that only a CT sensor is practical, start there. If it has a supported controller, connect it via MTConnect. Run the pilot for 60 days, review the data weekly, and document what the data reveals that was not previously visible. That documentation is the business case for the next phase.
On equipment selection, match the connectivity method to what the machine can actually provide rather than to what the platform promises. A CT sensor on a 1998 lathe is not a compromise. It is the right tool for a machine that offers no digital interface. The shop that understands machine uptime from CT sensors on 10 legacy machines has more actionable information than the shop that attempted full MTConnect integration on two machines and stalled on controller compatibility.
Axis also recommends treating network infrastructure as part of the project scope rather than as a precondition that will be handled separately. IIoT projects that arrive at installation and discover no network access near the machines, no IT approval for the connectivity architecture, or no defined path from the machine network to the monitoring platform stall at the most expensive moment. Scope the network with the connectivity hardware, get IT approval before purchase orders are signed, and include network installation in the project budget and timeline from the start.