Fog Computing vs Edge Computing: Architecture and Industrial Use-Case Comparison
The Robustel EG5200 Industrial Edge Computing Gateway is an edge node: it can connect local equipment and run selected applications close to the data source. “Fog computing” is commonly used for a wider distributed layer between many edge nodes and central cloud systems. The terms overlap, so architecture diagrams should name responsibilities instead of relying on labels.
Edge Is Usually the Asset- or Site-Level Execution Point
An edge gateway may acquire industrial data, translate supported protocols, filter information, buffer during an outage or run a compatible local model. Its physical proximity makes it useful when WAN dependency or raw-data volume matters.
Fog describes coordination above or across those nodes: a plant server, regional node or distributed service may aggregate several gateways, apply common policy or provide a nearer shared application than a remote cloud.
| Responsibility | Edge node | Fog/intermediate layer | Cloud/central layer |
|---|---|---|---|
| Device interfaces | Direct | Usually aggregated | Indirect |
| Immediate local processing | Strong fit | Cross-node coordination | WAN dependent |
| Site-wide aggregation | Possible on larger node | Strong fit | Central alternative |
| Fleet history | Limited | Regional window | Strong fit |
| Failure radius | One asset/site | Several edge nodes | Many sites |
| Operations | Field plus platform team | Regional/platform team | Central platform team |
The Important Difference Is Failure Radius
Placing a service on one gateway limits some faults to that site but multiplies software instances. A fog node can simplify coordination for several gateways while becoming a shared dependency. A central cloud maximizes shared context but depends on the WAN path from each site.
Document what happens when each layer fails. If the fog node disappears, should edge collection continue? If the WAN to cloud fails, can the fog layer retain data? If one edge application stops, how is that state reported without affecting other sites?
Add a Fog Layer Only for a Named Shared Service
An intermediate layer earns its place when several edge nodes need something they should not each implement independently. Examples include site-wide data aggregation, a shared local user service, regional retention, policy distribution or coordination across production areas. “Lower latency” is not enough as a justification unless the required response time and network path are measured.
The shared service also creates a new operational boundary. Teams must decide how edge nodes discover it, how identities and certificates are managed, which data is retained when it is unavailable and whether another instance can take over. Capacity should be tested for the combined peak of its dependent nodes, including the replay surge after an outage.
If those responsibilities are absent, calling an ordinary gateway deployment “fog computing” adds terminology without adding architecture. A direct edge-to-central design may be simpler and easier to own.
How Robustel EG5200 and E2C Factory Fit the Edge Layer
Robustel EG5200 edge computing gateway provides five Gigabit Ethernet ports, flexible serial interfaces, DI/DO, relay, HDMI, USB, 4 GB RAM, 32 GB eMMC and a documented 2.3 TOPS NPU. It fits a site where several local devices and applications converge, but it does not automatically become a fog cluster or central platform.
On EG5200, Robustel E2C Factory turns the gateway’s local compute and interfaces into an operational layer for supported data collection, processing, alarms, workflows, visualization and northbound integration. Site teams gain a more direct route from connected equipment to usable local information, while a plant, fog or cloud service can concentrate on coordination shared across gateways. Device and protocol selection still follows the requirements of the actual equipment.
The Smart Parking Application Example illustrates several distributed roles, including local camera-related processing and central operations. It is a useful architecture analogy for edge/fog layering, not proof of a named customer deployment.
The Public Safety CCTV Application Example presents a focused edge site where an EG5100 combines connectivity with lightweight applications. A fog layer would be justified only if multiple such sites need shared intermediate coordination.
Select Hardware from the Named Role
| Role | Robustel direction | Selection reason |
|---|---|---|
| Lightweight single-site integration | EG5100/EG5101 | Focused local application |
| Serial-dense brownfield edge | EG3120e | Multiple RS-485 connections |
| Compact higher-compute node | EG5120 | 64 GB eMMC and NPU |
| Multi-device site edge | EG5200 | Broad Ethernet/peripheral layout |
| Fog coordination across sites | Separate architecture decision | Requires a separately designed coordination layer |
The gateway model does not define the fog layer. Messaging, data models, orchestration, identity, storage and failure recovery across nodes need their own design.
Draw the Deployment, Then Test Each Failure Boundary
A useful design diagram shows assets, gateways, intermediate services and central systems, then marks protocols, trust boundaries, data direction and failure dependencies. Add the owner and recovery objective for every service. Only after that should the team decide whether “edge,” “fog” or another label helps communicate the design.
This avoids a procurement mistake: buying a larger gateway does not automatically create coordination across sites. Conversely, introducing a regional server does not guarantee resilience if every edge node stops when that server is unavailable. Architecture comes from service placement and tested behaviour, not from the category printed on a product shortlist.
Use the diagram as the commissioning script. Test one edge node independently, then its connection to the intermediate service and finally the central platform. Remove each upstream layer in turn and record what continues, what queues and what becomes unavailable. When the link returns, check replay and alarm ownership before moving to the next boundary.
This order matters. If the complete stack is tested only as one working system, a replay failure can be misdiagnosed as a gateway problem and a shared-service outage can look like several unrelated site faults. Layer-by-layer results show whether a failure belongs to one asset, one site, the intermediate group or the central service—the operational distinction that the edge/fog terminology is supposed to communicate.
The EG5000 Series Quick Pitch video introduces the relevant gateway family. It does not define the multi-node fog architecture.
Foire aux questions
Q1. What is the difference between fog and edge computing?
Edge computing usually describes processing at or very near the asset. Fog computing describes an intermediate distributed layer that coordinates services across multiple edge nodes before data reaches central systems; in practice, the boundary depends on the responsibilities assigned to each layer.
Q2. What is an example of fog computing?
A plant-level server that receives selected data from several line-side gateways, coordinates a site-wide rule and forwards consolidated information to the cloud is a useful example. The gateways remain responsible for their local equipment, while the fog layer handles work shared across the plant.
Q3. Why is it called fog computing?
The term extends the cloud metaphor: computation is distributed closer to the ground, between remote cloud services and endpoint devices. The name is less important than defining which layer owns data, decisions, updates and failure recovery.
Q4. Which is better, edge computing or cloud computing?
Neither is universally better. Edge suits functions that need local data handling, a shorter response path or defined operation during WAN loss, while cloud suits shared services, fleet-wide analysis and centralized resources; many industrial systems deliberately use both.
Q5. How do the Robustel EG5200 Industrial Edge Computing Gateway and E2C Factory fit into an edge-and-fog architecture?
The gateway can host supported equipment connectivity and substantial local applications at a multi-device site edge. E2C Factory adds local processing, operational views, alarms and workflows on that compatible hardware, allowing an intermediate fog or central layer to focus on services shared across gateways instead of rebuilding each site’s operational layer.
Conclusion
The Robustel EG5200 Industrial Edge Computing Gateway is a strong site-edge platform when several local devices and applications converge. Use edge and fog as location shorthand only after naming workload, owner and failure radius. That keeps an overlapping terminology debate from obscuring the actual industrial design.
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.