10 Edge Computing Use Cases That Need an Industrial Gateway, Not Just Cloud
When an industrial site needs more than data transport, a Robustel edge computing gateway can add local protocol integration, buffering, filtering, or application execution between field equipment and the cloud. The real question is not whether edge is better than cloud, but whether a site constraint makes cloud-only operation impractical.
A factory with legacy PLCs, a remote pumping station with intermittent cellular coverage, and a roadside cabinet handling several cameras may all use edge computing for different reasons. The gateway should solve a defined field problem while the cloud continues doing the work that makes more sense centrally.
Start with the Constraint, Not the Industry
“Edge computing use case” can easily become a list of industries: manufacturing, energy, transport, utilities, smart cities. That classification is useful, but it does not explain why an industrial gateway is actually required.
A Robustel edge computing gateway becomes relevant when something at the site needs to happen before, during, or independently of the cloud connection. That may be protocol conversion, data preparation, temporary storage, secure remote access, or a local application.
A cloud-only design may remain perfectly adequate when devices already produce usable IP data, traffic volumes are small, WAN connectivity is stable, and no local processing or recovery behaviour is required.
The following ten use cases begin with the field constraint instead.
Why add edge processing when the cloud is already available? Watch “Why Do We Need Edge Computing If We Have the Cloud?” for a quick overview of where local processing complements cloud platforms before exploring the ten field constraints below.
Legacy Data and Excessive Raw Traffic
1. Legacy PLC Data Must Reach Modern Applications
Consider a brownfield production line where the PLC is still operating reliably, but power meters and drives communicate over RS485. Replacing functioning equipment simply to obtain Ethernet or cloud-native connectivity may add cost and commissioning risk.
A Robustel EG5100 edge computing gateway can sit between serial equipment and upstream systems, supporting local protocol handling and suitable applications without changing the PLC’s control responsibility. Its RobustOS Pro environment supports Debian packages and Docker-based applications for focused protocol bridging and preprocessing.
The gateway should not be treated as a replacement for the PLC. Machine sequencing, interlocks, and deterministic control remain in the appropriate automation layer.
2. Raw Sensor Data Is Too Repetitive to Send Continuously
A compressor may report pressure, temperature, current, and running state every second. If most values remain stable, transmitting every sample over cellular simply because it exists can increase traffic, broker load, and cloud storage without improving operational visibility.
A suitable application on a Robustel edge computing gateway can filter unchanged values, aggregate selected measurements, or publish events when meaningful changes occur.
The processing rule must preserve evidence needed for diagnostics. Reducing traffic is useful only when alarms, abnormal transitions, timestamps, and relevant historical data remain available.
3. Different Devices Need One Consistent Data Model
A plant may contain one PLC reporting integers, a meter requiring scaling, and another controller using different names and timestamps for similar measurements.
Sending those raw representations directly upstream shifts every mapping problem into the cloud application.
With RobustOS Pro, a compatible edge application can normalise selected device data before publishing it. That may include units, scaling, timestamps, asset identifiers, quality states, and mapping versions. Robustel’s edge gateway platform is designed to support local applications and protocol integration, but the project still owns the accuracy and lifecycle of those mappings.
Continuity and Local Response During WAN Problems
4. Data Collection Must Continue During a WAN Outage
A remote wastewater station may continue producing flow, pressure, and pump-status data while its cellular connection is unavailable for twenty minutes.
If the architecture depends entirely on continuous cloud access, that interruption can create a gap in the operational record.
A Robustel edge computing gateway can host an application that buffers selected records locally and forwards them when connectivity returns. The design still needs retention limits, timestamps, queue behaviour, replay order, and storage-full handling.
Buffering cannot recreate measurements that were never collected because the PLC, sensor, or local application itself had failed.
5. An Operational Event Is Needed Faster Than a Cloud Workflow
At an unmanned pump station, a pressure value alone may not justify an alert. Low pressure while the pump remains active for several minutes is much more useful.
A local application running on a Robustel gateway can combine approved inputs and generate an event close to the equipment rather than waiting for several independent data streams to reach a remote platform.
This does not justify moving safety logic onto the gateway. Emergency shutdowns, certified protection, deterministic control, and safety interlocks should remain in the appropriate PLC or safety controller.
6. The Site Must Keep Working While the Cloud Is Unavailable
Cloud dashboards, central analytics, and reporting may be unavailable during a WAN interruption, but local equipment may still need to collect data or run approved non-safety applications.
This is where the division of responsibility matters.
A Robustel edge computing gateway can maintain selected local functions while upstream services are temporarily unreachable. The cloud can continue owning long-term storage, cross-site analytics, enterprise workflows, and fleet-wide reporting after connectivity returns.
“Offline operation” should therefore be defined function by function rather than used as a blanket promise.
Remote Sites and Complex Local Networks
7. Remote Engineers Need Controlled Access to Local Equipment
A technician may need to diagnose a PLC or controller hundreds of kilometres away. Exposing that device directly to the public internet for convenience creates an unnecessary security risk.
A Robustel edge computing gateway can provide routing, firewall, VPN, and centrally managed remote-access capabilities around the local equipment. Supported Robustel gateways also integrate with RCMS for monitoring, configuration, updates, and remote fleet operations.
Remote access still requires an approved security architecture. Credentials, reachable network segments, firewall policies, account ownership, and access revocation remain project responsibilities.
Robustel’s Application example: remote support for connected CNC machines
Robustel’s connected-CNC application example shows this requirement in a machine-service environment. A Robustel Edge Computing Gateway connects to the CNC control system through RS-232 or RS-485 and provides a managed cellular or Ethernet path for remote monitoring and support. RCMS gives service teams visibility into machine and network status before deciding whether an engineer needs to travel to site. The gateway adds a communications and diagnostic layer without taking over the CNC machine’s core control logic.
Explore the Connected CNC Machines application example
8. Several Cameras, Controllers, and Sensors Share One Site
A roadside cabinet may contain IP cameras, an intersection controller, environmental sensors, and local networking equipment. The challenge is no longer connecting one device—it is managing several local endpoints and deciding which data should leave the site.
The Robustel EG5200 edge computing gateway provides five Gigabit Ethernet ports, serial connectivity, HDMI, USB expansion, local application support, and cellular backhaul, making it relevant to multi-device and camera-heavy site architectures.
Port count alone does not determine capacity. Camera bitrate, application workload, local processing, storage, network segmentation, and WAN demand still need to be measured.
Application example: divide a multi-device site by workload
Robustel’s smart-parking application example shows why a complex edge site does not need one device to perform every task. Cameras use dedicated connectivity, meters and gates follow another network path, while the Robustel EG5120 edge computing gateway hosts compatible partner ANPR inference or preprocessing applications. Selected results can be filtered and timestamped locally before compact data is sent upstream, reducing the need to transmit every raw input to the central platform.
The architecture also shows the link between multi-device aggregation and edge processing: first define which devices belong at the site, then decide which workloads actually benefit from running locally.
Explore the Smart Parking application example
Local Applications and Edge AI
9. A Custom Application Must Run Near the Equipment
An OEM may already have a Linux application that parses a proprietary device protocol, applies customer-specific logic, and sends structured data to an existing platform.
Moving that software entirely into the cloud may be impractical if it depends on direct access to local serial or Ethernet equipment.
RobustOS Pro provides a Debian-based environment on supported Robustel edge gateways and supports Docker containers and Debian packages. This allows suitable third-party or custom applications to run near the equipment.
Compatibility is not automatic. CPU architecture, dependencies, drivers, storage, permissions, libraries, update behaviour, and recovery must all be validated before deployment.
10. AI Inference Must Run Close to a High-Volume Data Source
A machine-vision or condition-monitoring application may generate far more raw data than the project wants to send continuously to the cloud. In that case, running a validated inference model locally and publishing selected results may reduce upstream traffic and shorten the path from input to event.
The Robustel EG5120 edge computing gateway includes a 2.3 TOPS NPU alongside its local Linux application environment, giving suitable projects a platform for compatible inference workloads.
That specification does not guarantee compatibility with every model. Runtime support, model architecture, memory use, input resolution, inference frequency, and accuracy require testing. Model training normally belongs elsewhere.
When Cloud Alone May Still Be Enough
Not every industrial IoT project needs an edge computing gateway.
Consider a weather station that already produces a small, structured IP message every ten minutes. The connection is reliable, no legacy protocol must be converted, no local event decision is required, and the cloud platform can tolerate temporary data interruption.
Adding local containers, databases, or AI processing would create additional software and maintenance responsibilities without solving a meaningful problem.
The same principle applies across the Robustel edge computing gateway portfolio: the product should match the constraint rather than maximise specifications.
| Project need | Example Robustel direction |
| Focused serial integration, protocol bridging, buffering | Robustel EG5100 edge computing gateway |
| Broader local applications, storage, mixed-device processing, compatible inference | Robustel EG5120 edge computing gateway |
| Multi-device Ethernet aggregation, cameras, display and peripherals | Robustel EG5200 edge computing gateway |
EG5100 is positioned for focused protocol bridging and preprocessing; EG5120 adds more compute, storage and an NPU; EG5200 expands the local network and peripheral topology with five Gigabit Ethernet ports, HDMI and USB connectivity.
This is a direction for evaluation, not an automatic product assignment.
Validate the Edge Function Before Scaling
An edge function should solve a measurable problem before it is standardised across hundreds of sites.
Test the real devices, register maps, data volume, WAN behaviour, application dependencies, storage growth, reboot recovery, and remote-management process. A successful proof of concept with one PLC or camera does not establish production capacity.
Robustel RCMS can support monitoring, configuration, firmware management, diagnostics, and application operations across supported gateway fleets. It helps manage the gateway estate, but it does not validate customer processing logic, AI accuracy, protocol mappings, or local application recovery on behalf of the project.
The best edge architecture is therefore not the one with the most functions running locally. It is the one where every local function has a clear reason to exist.
FAQ
Q1. What are the most common edge computing use cases in industrial IoT?
Common use cases include legacy protocol integration, local data normalisation, filtering, aggregation, buffering during WAN loss, event generation, secure remote access, multi-device site aggregation, custom Linux applications, and compatible AI inference. The common factor is not the industry. Edge becomes useful when a specific field constraint cannot be handled efficiently by simple device-to-cloud connectivity alone.
Q2. When does an industrial project need an edge gateway instead of only cloud computing?
An edge gateway becomes relevant when data must be processed, transformed, retained, or acted on locally before reaching the cloud. Typical triggers include intermittent WAN connectivity, legacy serial equipment, excessive raw traffic, multiple local protocols, or applications that must run near the device. If data is already cloud-ready and the WAN is reliable, a simpler architecture may be sufficient.
Q3. Can an edge computing gateway keep an industrial site operating without cloud connectivity?
It can keep selected local functions running when they have been explicitly designed for that condition. A gateway may continue collecting, buffering, filtering, or processing data during a WAN outage. It does not mean every application remains available. Cloud dashboards, central analytics, and remote commands may still be offline, while PLC control and safety functions should remain independent of the gateway.
Q4. Does an edge gateway reduce the amount of industrial data sent to the cloud?
It can, when a suitable local application filters repetition, aggregates measurements, extracts events, or processes high-volume inputs before transmission. The reduction should be measured rather than assumed. Important alarms, diagnostic evidence, timestamps, and quality information must remain available. Sending less data is not beneficial if the processing rule removes information required for troubleshooting, compliance, or later analysis.
Q5. Which Robustel edge computing gateway fits different industrial edge use cases?
Robustel EG5100 edge computing gateway fits focused protocol bridging, serial integration, buffering, and lightweight preprocessing. Robustel EG5120 edge computing gateway provides more application resources and compatible AI-inference capability. Robustel EG5200 edge computing gateway is better suited to multi-device sites needing more Ethernet ports and peripherals. Final selection should follow measured interfaces, applications, traffic, storage, and recovery requirements.
結論
When a site needs protocol integration, local data preparation, buffering, secure access, application hosting, or compatible inference, a Robustel edge computing gateway can provide the missing layer between industrial equipment and the cloud. The value comes from solving a specific field constraint—not from moving as many cloud functions as possible onto local hardware.
The ten use cases share the same decision principle. First identify what breaks or becomes inefficient in a cloud-only architecture. Then select the smallest local function that removes that constraint while keeping PLC control, enterprise workflows, long-term analytics, and other responsibilities in the systems best suited to them.
Related Reading on Edge Computing in Industrial IoT:
著者について
Robert Liao | Technical Support Engineer
Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.