For a long time, the industrial edge seemed to have a straightforward job. A machine generated data; a gateway collected it, translated protocols and passed information to a SCADA system, a database or the cloud. More advanced processing usually happened elsewhere.
That model still has a place, but it no longer describes everything happening close to the machine. Industrial devices can now run visualization, process data locally and support applications that once needed separate computers or remote infrastructure. The relevant design question for a machine builder is changing with them: which functions need to run close to the process, and which can run elsewhere?
Thinking about the edge as a computing layer helps answer that question. It brings connectivity, processing and application requirements into the machine architecture from the outset, while leaving room for different devices to perform different jobs.
A continuum rather than a single location
The word edge can suggest a fixed point in the system. In practice, it can describe a compact gateway beside a PLC, an HMI that runs additional applications or an industrial PC that processes information from several automation assets. These nodes may work with local servers and cloud services, each taking on work that fits its capabilities.
LF Edge describes an edge continuum extending from field devices to centralized data centers. Its taxonomy emphasizes the tradeoffs involved in placing computing resources along that path, including latency, bandwidth, autonomy, security and privacy. The European Commission similarly describes a cloud–edge–IoT continuum and notes that processing may need to move closer to where data is produced to address latency, security and privacy needs.
For OEMs, this is more useful than a simple choice between local computing and the cloud. An operator interface may need to remain usable if an external connection fails. A fleet dashboard may be more useful when information from many machines is brought together. An application that reacts to a local event has different requirements again. The architecture should reflect those differences.
From transferring data to using it
The traditional gateway has been an effective bridge between protocols and systems. Its communication role remains essential, particularly where a machine must exchange information with equipment from different generations or manufacturers. Yet collecting and forwarding every raw value is not always the best way to make that information useful.
Consider a machine producing a continuous stream of measurements. Before those values leave the machine, an application might filter or aggregate them, add context, detect a relevant change or provide an operator with an immediate view. Some information may stay local; a smaller, more meaningful set may travel to higher-level systems. This is an architectural choice about what work should happen close to the process, not merely a question of network capacity.
Industrial standards bodies are addressing the same shift. In June 2026, the OPC Foundation observed that industrial digitalization requires “much more than protocol connectivity” and described gateway requirements that include secure and semantic integration across OT, enterprise and cloud environments. That does not mean every gateway must perform every computing task. It does mean that access to data is only one part of making it reusable.
A temperature value, for example, is more useful when another application can identify the asset that produced it, its units and its relationship to the process. The OPC Foundation puts the point plainly: “Industrial data becomes truly reusable only when its meaning travels with it.” Its discussion of OPC UA information models explains how shared descriptions of assets, types and relationships can provide that context across edge and cloud applications.
Different workloads need different places to run
As more computing becomes available close to the machine, an edge node can take on work beyond communication. It might host visualization, local data logging or analysis while connecting to a remote platform for longer-term storage and visibility across a fleet. A more capable industrial PC can support applications that need additional processing capacity or a different operating environment.
These possibilities do not erase the distinctions between automation functions. Visualization, analytics and deterministic control have different timing and availability needs. Safety-related functions require their own engineering assessment. Software updates, cybersecurity and maintenance also have to be considered for every workload introduced into the machine.
This makes workload placement a practical design discipline. Which functions must keep running without an internet connection? Which data should be processed or retained locally? Which applications need to be isolated? Which software will change most often during the machine’s life? Answers to those questions are more valuable than choosing a device category first and fitting every function into it afterward.
An architecture that can evolve with the machine
A machine’s digital requirements rarely stop at commissioning. Remote diagnostics may come first, followed by richer data collection, energy monitoring or integration with a customer’s systems. New software services can add further requirements. If each step requires another isolated device and its own connections, updates and configuration, the overall architecture can become harder to maintain.
Planning the edge as a computing layer does not mean sizing every machine for every possible future use. A compact gateway may be sufficient for one application; another may need dedicated control alongside a more capable edge computer. What matters is understanding how functions can be added and where they can run without repeatedly rebuilding the entire system.
The right architecture is therefore likely to vary by machine. The lasting shift is in the method: start with the operational and software workloads, assess their constraints, and then select the hardware and connectivity that support them.
How EXOR International technology fits into this architecture
EXOR’s portfolio reflects these different levels of computing. MicroEdge Plus is a compact gateway and edge controller with industrial communication through OPC UA, MQTT and JMobile protocols. EXOR lists JMobile Web HMI, a Linux/Yocto platform and optional CODESYS PLC capabilities among its features. It is an example of how connectivity and local functions can coexist in a compact device.
For applications with greater computing requirements, the Xedge Series provides industrial PC formats for data management and industrial IoT integration. JMobile contributes visualization and industrial communication across HMIs, gateways and edge devices. EXOR also describes XPLC within its broader software control offering. The exact combination depends on the machine’s requirements; these technologies represent different resources within a wider architecture.
What matters to a machine builder is the ability to decide deliberately what runs locally, which computing level supports it and how that level connects to the rest of the system. A gateway, an HMI and an IPC can serve different workloads without being treated as unrelated technological islands.
The edge as an architectural decision
The industrial gateway continues to matter. Its role is growing as machine data increasingly needs to be processed and understood near its source. At the same time, more capable platforms make room for local applications that previously had to run elsewhere.
The industrial edge is therefore becoming a computing layer rather than a single box in the cabinet. For OEMs, the useful question is no longer only how to connect a machine. It is what needs to happen close to it, what can happen elsewhere, and how those decisions will hold up as the machine evolves.
