Edge connectivity in manufacturing is the layer of hardware and software that sits at or near your machines, reads signals from PLCs and sensors, translates industrial protocols into a common language, buffers data locally when the network drops, and forwards clean, contextualized data to the systems your operations team uses. It is the plumbing between the plant floor and everything above it.
The word "edge" just means close to the machine, at the edge of the network rather than in a data center or the cloud. Most plants that struggle to get value from machine data do not have a data problem. They have a connectivity problem: the data exists inside the PLC, but nothing is reading it, translating it, and moving it somewhere useful. This guide covers what the edge layer actually does, what hardware is involved, and how to roll it out without ripping anything out.
What Is Edge Connectivity?
Edge connectivity is everything involved in getting a signal out of a machine and into a system that people use, handled locally at the plant rather than remotely. That usually means an industrial gateway device on the plant network that polls PLCs and sensors, plus the software on that device that translates protocols, filters values, and publishes data upward.
It helps to see where the edge sits in the stack. A PLC controls the machine and holds its state in memory as tags. The edge layer reads those tags. Above the edge, an operations platform, an MES, or a cloud historian consumes the data and turns it into dashboards, alerts, and records. The edge is the translator and courier in the middle. This is the same territory as edge computing in manufacturing, but connectivity is the narrower, more practical slice: not running heavy analytics at the machine, just reliably collecting and moving the signals that matter.
What Does an Edge Gateway Actually Do?
An edge gateway does four jobs: protocol translation, polling, buffering, and filtering. Each one solves a real problem that shows up the moment you try to connect a mixed-age fleet.
Protocol translation. A 1998 PLC might speak an old serial or proprietary protocol. A 2016 PLC speaks EtherNet/IP or Profinet. A modern machine may expose OPC UA. The gateway speaks all of them on the floor side and publishes one consistent format on the other side, commonly MQTT or OPC UA. Without this, every system above the floor would need its own driver for every machine.
Polling and change detection. Most PLCs do not push data; something has to ask. The gateway polls tags on a cycle, often every 100 milliseconds to a few seconds depending on the signal, and detects when a value changes. Run state flipping from RUN to STOPPED is an event worth publishing. The same value repeated ten thousand times is not.
Store-and-forward buffering. Plant networks drop. Switches reboot, cables get crushed, Wi-Fi dies in the metal canyon between two lines. A good gateway buffers data locally during an outage and forwards it, with original timestamps, when the connection returns. Your downtime history stays complete even when the network was not.
Filtering and deadbanding. An analog value like motor current jitters constantly. A deadband rule ("only publish if the value moves more than 0.5 A") turns a firehose into a stream of meaningful changes. This is why a well-configured edge layer sends kilobytes per minute, not gigabytes per day.
The gateway is also a natural security boundary. The floor network stays isolated; only the gateway talks upward, usually through an outbound-only connection, so nothing on the internet can reach a PLC directly. That pattern is covered in more depth in connecting PLC data to the cloud.
Why Not Send Machine Data Straight to the Cloud?
Because the cloud cannot speak Modbus, and your network is less reliable than you think. Direct-to-cloud sounds simpler until you meet the details: legacy protocols need translating somewhere, and if that somewhere is not local, every network hiccup becomes a hole in your data. A gap in the data during a line stoppage is worse than no data at all, because it looks like the machine was fine.
Latency matters too, for a narrow set of uses. If a fault on machine 3 should light an andon or open an operator prompt within a second or two, that logic should not depend on a round trip to a data center. Keep the fast loop local; send the history upward.
What Hardware Do You Need at the Edge?
Less than most vendors imply. For machines with a PLC, you typically need one industrial gateway per line or per area, a small DIN-rail or fanless box that connects to the existing machine network. You are reading tags the PLC already has; no changes to the control program are required for basic signals. For machines with no PLC or no usable one, add-on sensors do the job: a current clamp on the motor circuit to infer run state, a photo eye or proximity sensor to count parts, a vibration or temperature sensor where condition matters. That retrofit path is covered in how to connect legacy machines and connecting sensors to operations.
Budget-wise, edge hardware is the cheap part of the project. Industrial gateways and add-on sensor kits typically run in the hundreds of dollars to low thousands per machine or line, not the five- and six-figure sums people associate with "machine integration." The real cost is in the mapping and context work: deciding which signals matter, naming them sensibly, and connecting them to how the plant actually runs. Get a feel for the payback side with the calculators on our ROI calculators and tools page.
How Do You Roll Out Edge Connectivity?
Start small, prove value, expand. A practical sequence looks like this:
- Pick one line that matters. Choose a line where downtime or slow running visibly costs money, and where the supervisor wants the data. Do not start with the hardest machine in the plant.
- Inventory what each machine can give you. For each machine: PLC make, model, protocol, and whether an Ethernet port is reachable. No PLC access? Note it as a sensor-retrofit candidate.
- Choose a short signal list. Run state, fault code, part count, and rate cover most decisions. Resist the urge to collect everything; see machine signals that matter for why four good signals beat ten thousand raw tags.
- Install the gateway and map the tags. Wire the gateway into the machine network, point it at each PLC, and map raw tag addresses to named, contextualized signals. Naming conventions are worth doing properly; our PLC tag mapping guide covers them.
- Configure buffering and deadbands. Set store-and-forward on, set deadbands on analog values, and confirm timestamps come from the edge, not the server.
- Connect the data to people, then expand. Put the signals on a live display, wire downtime events to operator prompts, and run for two weeks. Fix what is noisy, then copy the pattern to the next line.
How Does Edge Data Become Something Operators Actually Use?
Raw connectivity is necessary but not sufficient. A stream of tag values is only useful once it is joined with context: which product was running, which shift, what the operator saw, why the line stopped. That join happens above the edge, in the operations layer, where a machine-detected stoppage can automatically open a reason-code prompt for the operator and land in the production record alongside the paperwork. That pattern, the machine event and the human record meeting in one place, is what turns connectivity into a system people trust, and it is the approach we take at Harmony AI; you can see the shape of it in our connected systems and machines features.
None of this requires replacing equipment or control systems. The edge layer reads what is already there. Harmony AI's deployments are white-glove: our engineers come on-site, walk the lines, identify what each machine can give up, and install and map the edge layer with your team, so the plant gets live data without the plant becoming an integration project. No rip-and-replace.
Which Standards Matter for Edge Connectivity?
Three are worth knowing by name. OPC UA, maintained by the OPC Foundation and standardized as IEC 62541, is a platform-independent architecture for exchanging machine data, running on everything from embedded controllers to cloud servers. MQTT, standardized as ISO/IEC 20922, is the lightweight publish/subscribe protocol most edge gateways use to move data upward efficiently. And ISA-95, from the International Society of Automation, defines the equipment hierarchy (enterprise, site, area, work center, work unit) that gives edge data its address, so a signal is not just "tag 47" but "Plant 2, Packaging, Line 3, Filler, run state." You do not need to read the standards to benefit from them, but tools that follow them will save you rework later; the naming side is covered in our tag mapping guide.
Where Should You Go From Here?
Edge connectivity is the least glamorous part of a connected plant and the most decisive. Get the layer right, one line at a time, and everything above it, dashboards, downtime intelligence, scheduling, gets dramatically easier. Start with the shortest useful signal list, name things properly, buffer everything, and connect the data to the people who run the line. If you want the broader map first, start with the machine connectivity guide, then come back to the plumbing.