Cloud and Edge Computing: Workload Placement Decision Matrix for Industrial Sites
The Robustel EG3120e Industrial Edge Computing Gateway fits brownfield sites where several local industrial connections need to feed edge applications and selected cloud services. The architecture should not force every workload to one side. Place each function according to response time, WAN dependency, data volume, shared context and operational ownership.
Place Workloads from Failure Behaviour and Control Boundaries
If a function must continue during a WAN outage, some approved local component must own it. If it needs fleet-wide history or large shared datasets, the cloud or central platform often remains the natural location. Many systems divide a workflow: collect and filter locally, then analyze and report centrally.
Work through the outage as an operating sequence, not a yes/no connectivity question. A site may continue collecting while its central dashboard becomes stale; a local alarm may still appear while cross-site escalation is unavailable. Naming those differences before assigning the workload exposes what the edge must store, what users will see and which actions must wait for reconnection.
| Workload | Edge fit | Cloud/central fit | Key test |
|---|---|---|---|
| Protocol acquisition | Strong when equipment is local | Limited without site connectivity | Device loss and reconnect |
| Filtering/context | Reduces upstream volume | Applies common fleet model | Compare local and central outputs |
| Short outage buffer | Keeps collection decoupled | Long-term retention | Fill, recover and replay |
| Local alarm/workflow | Useful for bounded response | Escalation and cross-site coordination | WAN-loss behaviour |
| Historical analytics | Limited local window | Strong shared compute/history | Data completeness |
| Model training | Usually unsuitable gateway workload | Strong centralized resources | Version deployment back to edge |
Keep Control and Safety Boundaries Explicit
An edge gateway can run rules and workflows, but that does not make it a safety PLC. Deterministic machine control, interlocking and functional safety remain within the approved control architecture unless the whole system is engineered accordingly.
The edge layer can collect supported data, add context, trigger non-safety operational actions and maintain selected local visibility. The cloud can aggregate across sites without taking over functions that cannot tolerate WAN delay or loss.
Assign One Owner to Every Boundary
Hybrid architectures fail most often at the hand-offs. The controls team may assume the gateway will normalize a tag, the edge team may expect the cloud to retain it, and the cloud team may assume the source can replay missing records. A placement decision therefore needs an ownership map as well as a workload map.
For each data flow, name who owns device connectivity, protocol interpretation, timestamping, quality flags, local retention, replay, central ingestion and user notification. Also define the authoritative copy of configuration. Without that decision, a well-connected system can still produce two conflicting versions of the same asset or alarm rule.
This exercise often reveals that placement is not binary. A local edge process may create a bounded operational event, while the central service stores the history and coordinates escalation across sites. The division is sound only when both sides agree on identifiers, time, retry behaviour and what a missing acknowledgement means.
How Robustel EG3120e and E2C Factory Connect Brownfield Data
Robustel EG3120e provides a quad-core Cortex-A53 at 2.0 GHz, 2 GB RAM, cellular/eSIM connectivity and a serial-rich interface set including four RS-485 ports. This makes it a practical candidate where several legacy devices need local integration and a managed upstream path.
On Robustel EG3120e edge computing gateway, Robustel E2C Factory adds supported industrial data collection, local processing, data management, alarms, workflows, visualization and northbound connections to the gateway’s serial and cellular role. This can replace a collection of isolated data bridges with a clearer local operating layer, while PLC control and central enterprise services keep their defined responsibilities.
The Smart Parking Application Example illustrates distributed local preprocessing and central service roles around several equipment types. It is architecture evidence rather than a customer deployment.
The Public Safety CCTV Application Example shows a smaller remote edge responsibility where connectivity and lightweight local software can be sufficient.
Match Hardware to the Local Share
| Local responsibility | Robustel direction | Why |
|---|---|---|
| Focused serial collection | EG5101 | Lightweight platform |
| Mixed lightweight I/O | EG5100 | Additional local interfaces |
| Several legacy serial networks | EG3120e | Four RS-485 and cellular/eSIM |
| Compact higher compute/storage | EG5120 | 64 GB eMMC and NPU |
| Several IP devices/peripherals | EG5200 | Five GbE, HDMI, USB and relay |
The model choice follows only the workload assigned to the site. Moving analytics to the cloud does not remove protocol or buffering requirements at the edge; moving more functions local increases software lifecycle responsibility.
Test the Disconnected State and Preserve Data Meaning
Commission with representative data and establish a normal baseline before removing the WAN. Record the last item confirmed by the central system, then observe local collection, workflows, storage growth, user visibility and alert handling. On restoration, compare the gateway’s collected sequence with what the receiving system accepts; this makes gaps, duplicates and delayed acknowledgements visible instead of reducing the result to “data came back.”
Buffering is more than saving values to disk. Records need source timestamps, stable asset identifiers and enough context to remain meaningful after a delayed upload. The receiving system must know whether a late record is new history, a duplicate or a correction. Clock drift and time-zone handling should be tested explicitly.
Estimate the outage window from available storage, record size and event rate, then test with bursts rather than averages alone. Define what happens when the buffer reaches its limit: dropping the oldest record, stopping collection or raising a local alarm have different operational consequences. These are project design choices, not capabilities that should be assumed from the presence of local storage.
Finally, stop one local application while connectivity remains available. Confirm whether routing and remote access continue as designed and whether operators can distinguish an application fault from a gateway or WAN fault. That distinction determines who responds and whether a remote recovery attempt is appropriate.
The EG5000 Series Quick Pitch video provides a concise family overview. The decision matrix and failure tests determine actual placement.
Foire aux questions
Q1. What is the difference between cloud and edge computing?
Edge computing runs selected functions close to machines and data sources, while cloud computing provides shared resources and cross-site services from central infrastructure. Most industrial systems benefit from both: the design question is which responsibilities must remain local and which gain value from central coordination.
Q2. Will edge computing replace cloud computing?
Usually not. Edge is useful for local response, filtering and operation during defined connectivity interruptions; cloud platforms remain useful for fleet-wide analysis, shared applications and long-term aggregation. A sound architecture gives each layer a clear job rather than forcing everything into one location.
Q3. What are some examples of cloud and edge computing?
An edge gateway might collect machine data, apply a local rule and buffer records during a WAN outage. A cloud service might compare performance across sites, retain longer history and distribute approved configurations back to the fleet.
Q4. How is cloud edge different from cloud?
Cloud edge places selected services closer to users or sites but is still generally operated as part of a provider or central platform. On-premises industrial edge runs inside the plant or remote site, where the project controls the hardware, field interfaces and local failure behaviour.
Q5. How do the Robustel EG3120e Industrial Edge Computing Gateway and E2C Factory work together at a brownfield site?
The gateway connects serial equipment and supplies local compute with cellular or eSIM backhaul. On this supported hardware, Robustel E2C Factory adds data collection, local processing, alarms, workflows, visualization and northbound integration, giving the site a more coherent operational path while the approved PLC architecture retains machine and safety control.
Conclusion
The Robustel EG3120e Industrial Edge Computing Gateway is well suited to brownfield architectures where data must cross from several local interfaces into edge and cloud workflows. Place workloads from failure behaviour and ownership. Then size the gateway for what truly remains local and validate the disconnected state before rollout.
Explore more articles about Robustel’s edge computing gateways in industrial IoT:
À propos de l'auteur
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.