TLDR
An edge-to-cloud pipeline moves field data through four stages: acquisition at the sensor, inference at the edge, transport over a gateway, and visualization in a dashboard. This guide maps each stage to real hardware, shows where inference should run locally, and lists the checks that catch a broken pipeline before it reaches production. The compute layer here is the Nuvo-10108GC, paired with an Advantech sensor module and a cellular gateway.
Overview
Most industrial data dies on the factory floor. A sensor reads a value, a PLC logs it, and nobody looks again until something breaks. An edge-to-cloud pipeline changes that by deciding, at each hop, what to compute locally and what to ship upstream.
The design splits into two halves. The OT side handles acquisition and real-time inference. The IT side handles transport, storage, and dashboards. The handoff between them is the hard part, and it is mostly a networking problem. We walked through that network side in our guide to converged IT/OT networks, and the protocol tradeoffs in MQTT vs Modbus TCP. This guide stitches those pieces into one working path.
Reference architecture
Four layers, each with one job and a clean handoff to the next.
| Layer | Function | Hardware | Output |
|---|---|---|---|
| Acquisition | Read analog and digital sensors | Advantech ADAM-4015 | Raw tags over Modbus |
| Edge inference | Run models, filter noise | Nuvo-10108GC | Events and features |
| Transport | Buffer and uplink | PLANET IOG700 gateway | MQTT over cellular |
| Visualization | Store, query, chart | Cloud broker and dashboard | Trends and alerts |
The column that matters is Output. Each layer hands the next one less data and more meaning. A vibration sensor might produce 10,000 samples a second. The edge layer turns that into a single "bearing wear 12%" message an hour.
Component selection
The Nuvo-10108GC sits at the center because it carries an RTX-class GPU for inference and enough I/O to talk to both the sensor layer and the gateway without a separate aggregator. For lighter perception work, the NRU-220 on Jetson Orin draws less power and fills the same slot in the pipeline. When you need room for extra capture cards, the Nuvo-10000 gives you the PCIe expansion.
On the connectivity side, the ADAM-4015 reads six channels of RTD input at the sensor edge, and the PLANET IOG700 cellular gateway buffers messages and uplinks them over 4G where wired backhaul is not an option.
Implementation steps
Wire the sensor module to the Nuvo-10108GC over RS-485 and confirm you are reading raw tags. Load your model and run inference on a sample stream, checking that the box emits events instead of forwarding every reading. Configure the gateway as an MQTT publisher, set a sane keepalive, and point it at your cloud broker. Build the dashboard subscription last, and confirm a sensor change shows up downstream inside your latency budget.
Order matters here. Each step depends on the one before it, so validate locally before adding the next hop. Most pipeline failures trace back to a layer that nobody tested in isolation.
Validation
Pull the network cable and confirm the gateway buffers instead of dropping data. Force a sensor fault and check that the alert reaches the dashboard. Measure end-to-end latency under load, not at idle. Confirm the edge box keeps inferring while the uplink is down, since local autonomy is the whole reason to run a GPU in the field. For models that update over the air, our AI model lifecycle guide covers the deploy and monitor loop.
Related Products
Conclusion
A pipeline is only as good as its weakest handoff. Build it one layer at a time, test each in isolation, and the dashboard at the end will reflect what is actually happening in the field. Start with the Nuvo-10108GC for the inference layer and add the sensor and gateway pieces around it.
Follow Neteon on LinkedIn for more build guides, or reach us at [email protected] or www.neteon.net to scope an edge-to-cloud pilot.
FAQs
What is an edge-to-cloud data pipeline?
It is the path field data takes from a sensor to a dashboard, passing through acquisition, edge inference, transport, and visualization. Each layer reduces raw data volume and adds meaning before handing off to the next.
Why run inference at the edge instead of in the cloud?
Local inference cuts latency, reduces bandwidth, and keeps the system working when the uplink drops. A box like the Nuvo-10108GC turns thousands of raw samples into a handful of meaningful events before anything leaves the site.
Which protocol should I use for the cloud uplink?
MQTT is the common choice for edge-to-cloud transport because it is lightweight and handles intermittent connectivity well. Modbus often stays on the sensor side. The MQTT vs Modbus TCP guide covers the tradeoffs.
What happens to data if the network connection fails?
A gateway such as the PLANET IOG700 buffers messages locally and uplinks them once connectivity returns, so a dropped link delays data rather than losing it.
How do I validate the pipeline before production?
Test each layer in isolation, pull the network cable to confirm buffering, force a sensor fault to confirm alerts arrive, and measure end-to-end latency under load rather than at idle.
