Key takeaways
- Industrial protocols are the languages edge AI computers use to read sensors, cameras, PLCs, and drives. Pick the wrong one and the smartest inference model in the world never sees clean data.
- The connectivity stack has layers: fieldbus and serial at the bottom, industrial Ethernet in the middle, and IT-facing protocols like OPC-UA and MQTT at the top. An edge AI box usually has to speak several at once.
- Determinism matters more than raw bandwidth for control. Real-time Ethernet (EtherCAT, PROFINET) and time synchronization (TSN, PTP) exist because a late packet in a motion loop is a failed packet.
- The IT/OT boundary is where most edge AI projects stall. OPC-UA and MQTT are the two protocols that carry factory-floor data up to dashboards and models without a rat's nest of custom converters.
- Protocol support is a hardware decision. Serial port count, isolated DIO, PoE budget, dual LAN, and a slot for a 5G or Wi-Fi 6 module all get locked in when you choose the computer, so specify them against the protocols the site actually runs.
What are industrial protocols, and why do they matter for edge AI?
An industrial protocol is the agreed format two machines use to exchange data on a factory floor, a vehicle, or a substation. A PLC controlling a conveyor, a temperature sensor in a tank, a servo drive on a robot arm, and a camera on an inspection line each talk in their own dialect. An edge AI computer sits in the middle of that conversation. It has to collect the data, run inference on it, and often send a decision back, all in the time budget the process allows.
This is the part of an edge AI deployment that quietly decides whether the project ships. Teams spend months tuning a model and then discover the computer cannot read the drive at the rate the control loop needs, or that the plant's historian speaks a protocol the box does not support. The model was never the bottleneck. The plumbing was.
Getting the connectivity right starts before you pick a model or even a computer. It starts with a map of what the edge device has to talk to, how fast, and how reliably. Once you have that, the hardware and protocol choices follow. If you are still choosing the platform itself, the companion guide on how to choose an industrial edge AI computer covers compute, thermals, and I/O together. This reference goes deep on the connectivity half of that decision.
Two ideas run through everything below. First, industrial networks care about determinism, not just speed. A protocol that delivers data on a predictable schedule beats a faster one that delivers it whenever it feels like it. Second, there is no single protocol that does everything. A real edge AI deployment stitches together three or four, each doing the job it is good at.
The connectivity stack: from field device to cloud
It helps to picture industrial connectivity as a stack, because each layer has different priorities and a different set of protocols.
At the bottom is the field level. This is where sensors, actuators, drives, and I/O modules live. Data here is small, frequent, and time-sensitive. A drive position update that arrives 2 milliseconds late can ruin a motion profile. Protocols at this level are built for determinism above all else.
In the middle is the control and cell level. PLCs, machine controllers, and now edge AI computers coordinate groups of devices. Industrial Ethernet dominates here because it carries more data than legacy fieldbus while keeping timing tight enough for control.
At the top is the operations and IT level. Historians, SCADA, MES, dashboards, and cloud platforms consume aggregated, contextualized data. Timing loosens, but structure, security, and interoperability become the priorities. This is where OPC-UA and MQTT do their work.
An edge AI computer is unusual because it often touches all three layers. It reads raw signals at the field level, runs inference at the cell level, and publishes results to the IT level. That is why the I/O spec of an edge AI box reads like a small networking switch: multiple LAN ports, serial ports, digital I/O, and expansion for wireless. Designing that data path end to end is its own discipline, and the walkthrough on building an edge-to-cloud data pipeline shows how the layers connect in a converged network.
Fieldbus and serial protocols: the legacy that will not die
Plenty of installed equipment still speaks serial, and it will for years. Modbus RTU, running over RS-485, is the most common. It is slow by modern standards, but it is simple, cheap, and everywhere: power meters, VFDs, temperature controllers, and older PLCs. An edge AI computer aimed at brownfield sites needs real serial ports, ideally isolated ones, because RS-485 runs long distances through electrically noisy environments.
In vehicles and mobile machinery, the equivalent workhorse is the CAN bus, and its faster successor CAN FD. Engine control units, battery management systems, and body electronics all publish on CAN. An edge AI computer doing fleet analytics or in-cab perception has to tap that bus to correlate what the cameras see with what the vehicle is doing. This is why rugged in-vehicle computers ship with onboard CAN interfaces, and it is a big part of why fleet deployments favor a compact fanless box like the POC-700 with native vehicle I/O. The integration pattern is spelled out in the guide on connecting a cellular IoT gateway to a POC-700.
The takeaway for hardware selection is blunt. If your deployment touches serial or CAN devices, that requirement has to be on the datasheet before you buy. You cannot add a truly isolated RS-485 port to a box that shipped without one, and a USB dongle is not the same thing in a plant full of electrical noise.
Industrial Ethernet: the middle of the stack
Most new industrial connectivity is some flavor of Ethernet, but industrial Ethernet is not just office Ethernet with a rugged connector. Several protocols share the same cabling and physical layer while adding timing guarantees that standard TCP/IP does not provide.
Modbus TCP is the gentlest step up from serial. It wraps the familiar Modbus register model in Ethernet, so it is easy to adopt and widely supported, but it inherits Modbus's polling model and offers no real-time guarantee. It is fine for reading meters and slow process variables, and a poor fit for tight motion control. The trade-offs against its messaging cousin are laid out in the comparison of MQTT vs Modbus TCP.
PROFINET and EtherNet/IP are the two dominant real-time industrial Ethernet families, roughly split along vendor and regional lines. Both add scheduling on top of standard Ethernet so that time-critical traffic gets priority over best-effort traffic on the same wire. For an edge AI computer reading a PROFINET line, the detail that matters is whether it participates as a real device on the network or just sniffs data. The mechanics are covered in the explainer on PROFINET real-time industrial Ethernet.
EtherCAT sits at the demanding end. It uses a processing-on-the-fly technique that lets a single frame service many nodes in one pass, which drives cycle times down to the tens of microseconds. That makes it the choice for high-axis-count motion and fast, synchronized I/O. If your edge AI application is closing a control loop rather than just observing one, EtherCAT is often the reason the timing works, as the guide on what EtherCAT is explains.
The practical point across all of these: an edge AI computer that has to join a real-time Ethernet network usually needs a dedicated network interface for it, kept separate from the general-purpose LAN that carries camera streams and cloud traffic. Mixing time-critical control traffic and bursty video on one port is how you get missed deadlines.
Determinism and time: TSN and PTP
Two technologies deserve their own section because they are what make modern Ethernet trustworthy for control and for multi-sensor AI.
Time-Sensitive Networking, or TSN, is a set of IEEE standards that bring deterministic scheduling to standard Ethernet. Instead of a vendor-specific real-time layer, TSN reserves bandwidth and schedules time-critical frames so they arrive within a bounded window, while ordinary traffic shares the same network. For edge AI, TSN is what lets a single converged network carry motion control, sensor data, and camera streams without the control traffic getting stepped on. The plain-English version is in the guide on what TSN is.
Precision Time Protocol, IEEE 1588, solves a related but distinct problem: making many devices agree on the same clock to sub-microsecond accuracy. This matters more than people expect for AI. If you are fusing data from several cameras or several sensors, the model needs to know which readings happened at the same instant. Without a shared clock, you are correlating frames that are milliseconds apart and calling it fusion. PTP gives every device a common timestamp, which is why it shows up in substation automation, in multi-camera vision, and in any sensor-fusion workload. The details are in the explainer on PTP time synchronization.
TSN and PTP work together. PTP distributes the time; TSN uses that shared time to schedule traffic. For an edge AI computer, hardware timestamping support on the network interface is the feature to look for, because software timestamps are too jittery for either job to work well.
The IT/OT bridge: OPC-UA and MQTT
Everything above moves data around the factory floor. Getting that data up to dashboards, historians, and cloud models is a different problem, and it is where most edge AI projects hit friction. The operations technology (OT) world and the information technology (IT) world grew up with different assumptions about security, addressing, and data structure. Two protocols have become the accepted bridge.
OPC-UA is the structured, self-describing option. It does not just move a number; it moves a number with its meaning, its units, its data type, and its relationships to other data. That semantic model is why OPC-UA has become the backbone of Industry 4.0 interoperability: a dashboard or a model can discover what a device offers without a human hand-mapping every register. For an edge AI computer, OPC-UA is often how it both ingests contextualized plant data and publishes its own inference results back in a form the rest of the plant understands. The case for it is in the guide on what OPC-UA is.
MQTT comes at the problem from the messaging side. It is a lightweight publish-subscribe protocol built for constrained networks and intermittent links, which is exactly what you get with remote sites and cellular backhaul. Devices publish to topics, and any authorized consumer subscribes. That decoupling makes MQTT ideal for pushing edge AI results to the cloud without every device needing to know who is listening. A worked example lives in the guide on building a remote monitoring stack with MQTT.
In practice the two are complementary. OPC-UA is strong inside the plant where structure and discovery matter; MQTT is strong across the wide-area link where efficiency and loose coupling matter. Many edge AI deployments run OPC-UA on the OT side and MQTT on the cloud side, with the edge computer translating between them. Done well, this replaces a pile of point-to-point protocol converters with one intelligent node, an approach detailed in the piece on eliminating protocol converters with a native Modbus-to-MQTT gateway. A box that can host both stacks and a container runtime, such as the Nuvo-11000 series with its multiple LAN ports, is what makes that consolidation possible.
Physical connectivity: power, wired, and wireless
Protocols ride on physical connections, and the physical layer has its own decisions.
Power over Ethernet earns a mention because so many edge AI inputs are cameras. PoE and the higher-power PoE++ deliver both data and power over one cable, which cuts installation cost and simplifies IP camera deployments. The catch is the power budget: a computer with PoE ports has a finite watt budget to share across them, and high-power PTZ or heated outdoor cameras can exhaust it fast. Sizing that budget correctly is covered in the guide on PoE and PoE++ power budgets for edge AI cameras. If you are running several cameras, look for a computer with a PoE-equipped model, such as the PoE variants in the Nuvo-11000 family, rather than adding external injectors.
For sites without structured cabling, wireless carries the backhaul. The three contenders are private 5G, private LTE, and Wi-Fi 6, and they suit different jobs. Wi-Fi 6 is cheap and fast for dense indoor coverage. Private LTE and 5G give wide-area range, better mobility handoff, and deterministic behavior that Wi-Fi struggles to match outdoors. The trade-offs are compared in detail in the guide on 5G vs private LTE vs Wi-Fi 6. The hardware requirement is a spare M.2 or mini-PCIe slot and a SIM holder, which is why a sealed outdoor box like the POC-766AWP ships with wireless expansion built in.
One more physical-layer reminder that connects to the wider standards picture: outdoor and vehicle connectivity has to survive vibration, surge, and temperature, not just carry packets. The connector ratings and isolation that keep a link alive in the field are part of the ruggedness story covered in the industrial ruggedness and compliance standards reference.
How to choose protocols for an edge AI deployment
Work from the deployment outward, not from a protocol you already like. Four questions settle most of it.
First, what does the edge computer have to read, and how fast? List every device and its native protocol. If the list includes serial meters and a PROFINET line and a bank of IP cameras, the computer needs serial ports, a real-time-capable network interface, and PoE, all at once.
Second, is there a control loop or just observation? Observation tolerates polling protocols like Modbus TCP. Closing a loop, especially motion, pushes you toward EtherCAT or a real-time Ethernet family with TSN.
Third, does the workload fuse multiple sensors? If yes, shared time is not optional, and PTP with hardware timestamping belongs on the spec.
Fourth, how does data leave the site? A reliable plant LAN suggests OPC-UA. A remote site on cellular suggests MQTT. Many sites need both, with the edge computer bridging them.
The table below maps common needs to the protocol that fits.
| Deployment need | Layer | Protocol to reach for | Why |
|---|---|---|---|
| Read legacy meters and drives | Field | Modbus RTU / Modbus TCP | Simple, universal, polling is acceptable |
| In-vehicle and mobile data | Field | CAN bus / CAN FD | Native to ECUs and battery systems |
| High-speed synchronized motion | Field / cell | EtherCAT | Microsecond cycle times, one frame serves many nodes |
| Real-time cell networking | Cell | PROFINET / EtherNet/IP | Prioritized traffic on standard Ethernet |
| Multi-sensor or multi-camera fusion | Cell | PTP (IEEE 1588) | Sub-microsecond shared clock for correct correlation |
| Structured plant-to-IT data | Operations | OPC-UA | Self-describing, discoverable, secure |
| Remote or cloud backhaul | Operations | MQTT | Lightweight publish-subscribe over unreliable links |
| Powered IP cameras | Physical | PoE / PoE++ | Data and power on one cable |
| No wired backhaul available | Physical | 5G / private LTE / Wi-Fi 6 | Wide-area or dense wireless coverage |
What this means for edge AI hardware
Every protocol above turns into a hardware requirement, and hardware requirements are hard to change after purchase. When you evaluate an edge AI computer for a connected deployment, read the I/O section of the datasheet against the protocol map you just built.
Serial and CAN support has to be native and isolated for field-level work. Multiple physically separate LAN ports let you keep real-time control traffic off the same wire as camera and cloud traffic; a computer like the Nuvo-11000 series is built around that multi-LAN, expandable layout. GPU-class vision boxes such as the Nuvo-10108GC pair that connectivity with the compute needed to run inference on the streams those ports carry. For power-efficient, Arm-based inference at connected remote sites, the NRU-220 platform covers the low-power end. And where cameras and wireless both matter outdoors, a sealed unit like the POC-766AWP brings PoE and wireless expansion in one weatherproof package.
Two features are easy to overlook and expensive to miss. Hardware timestamping on the network interface is what makes PTP and TSN actually work; without it, timing is jittery. Expansion slots (M.2, mini-PCIe, PCIe) are what let a deployment add a 5G module or a capture card in year two without replacing the computer. Leaving that headroom is cheap insurance, the same lesson that runs through the broader platform selection guide.
Selection matrix: matching connectivity to the computer
Use this as a shortlist, then confirm the exact port count and ratings on the datasheet for the specific model.
| If the deployment is… | Connectivity priority | Look at |
|---|---|---|
| Brownfield plant with mixed serial and Ethernet | Isolated serial, multi-LAN, OPC-UA host | Nuvo-11000 series |
| Multi-camera vision with heavy inference | PoE, high-bandwidth LAN, GPU | Nuvo-10108GC |
| Remote outdoor site, cameras plus wireless | PoE, 5G/LTE expansion, sealed enclosure | POC-766AWP |
| In-vehicle or fleet analytics | CAN bus, cellular backhaul, wide-range power | POC-700 |
| Power-efficient connected inference | Arm GPU, compact, low power | NRU-220 |
Related Products
Standards and protocols referenced in this guide
- Modbus: Serial (RTU) and TCP register-based protocol. Managed by the Modbus Organization.
- CAN / CAN FD: Controller Area Network for in-vehicle and machinery communication. ISO 11898.
- PROFINET: Real-time industrial Ethernet. PROFIBUS & PROFINET International (PI), IEC 61158/61784.
- EtherNet/IP: Real-time industrial Ethernet. ODVA, IEC 61158.
- EtherCAT: High-speed real-time Ethernet. EtherCAT Technology Group, IEC 61158.
- TSN: Time-Sensitive Networking. IEEE 802.1 TSN task group.
- PTP: Precision Time Protocol. IEEE 1588.
- OPC-UA: Unified Architecture for industrial interoperability. OPC Foundation, IEC 62541.
- MQTT: Message Queuing Telemetry Transport. OASIS and ISO/IEC 20922.
- PoE / PoE++: Power over Ethernet. IEEE 802.3af/at/bt.
Connectivity is the half of an edge AI deployment that decides whether the compute ever gets clean data to work with. Map the protocols first, then choose the hardware that speaks them. Follow Neteon on LinkedIn for more deep dives, or reach us at [email protected] or www.neteon.net to talk through the connectivity design for a specific edge AI deployment.
FAQs
What is the difference between a fieldbus and industrial Ethernet?
A fieldbus is an older serial network like Modbus RTU or CAN that carries small, deterministic messages over simple wiring, usually at low speed. Industrial Ethernet carries far more data on standard Ethernet cabling and adds timing mechanisms so critical traffic stays deterministic. Most new deployments use industrial Ethernet, but a lot of installed equipment still speaks fieldbus, so edge computers often need both.
Do I need OPC-UA or MQTT for an edge AI deployment?
Often both. OPC-UA is the better fit inside the plant, where its self-describing, structured data model lets systems discover and interpret each other without manual mapping. MQTT is the better fit for sending data over unreliable or remote links to the cloud, thanks to its lightweight publish-subscribe design. A common pattern is OPC-UA on the OT side and MQTT for cloud backhaul, with the edge computer translating between them.
Why does time synchronization matter for edge AI?
Sensor fusion and multi-camera vision only work if the system knows which readings happened at the same instant. Precision Time Protocol (IEEE 1588) gives every device a shared clock accurate to under a microsecond, so data from different sources can be correlated correctly. Without it, a model is comparing readings that are milliseconds apart, which corrupts fusion results.
Can one edge AI computer handle multiple protocols at once?
Yes, and most real deployments require it. An edge computer commonly reads serial or CAN devices, joins a real-time Ethernet network, drives PoE cameras, and publishes results over MQTT, all at the same time. The requirement is hardware: enough isolated serial ports, multiple separate LAN interfaces, a PoE budget, and expansion slots for wireless. Confirm those on the datasheet before buying.
What connectivity features are hardest to add after purchase?
Native isolated serial and CAN ports, hardware timestamping for PTP and TSN, and the number of physically separate LAN ports. These are set by the computer's design and cannot be bolted on later in any reliable way. Wireless can usually be added if the box has a spare M.2 or mini-PCIe slot and a SIM holder, which is why expansion headroom is worth specifying up front.
