In equipment-room power and environment monitoring projects of earlier years, plan discussions often started from "industrial PC or embedded device." Device forms and computing capability now gradually overlap. In industrial-grade AIoT projects, Guangzhou Tongwei Smart Technology Co., Ltd. (Tongwei Smart) pays more attention to another question: after IoT data has been acquired, which tasks must stay on site, and which are suited to centralized processing? This decides the system architecture, and it also decides how the site will run when the network is down or a device fails.
Industrial PCs, embedded devices, gateways, and edge computing: what is each one describing?
These words are often put side by side and compared. They do not actually describe the same thing.
| Concept | What it describes | The question to ask at selection |
|---|---|---|
| Industrial PC (IPC) | A class of industrial computing device, usually used to run an operating system and application software | How much CPU, memory, storage, expansion-card, display, and software-compatibility capacity is needed? |
| Embedded device | A computing device or control terminal designed for a specific use. Form and resource configuration vary widely | Is the task fixed? Do the interfaces, power consumption, environmental tolerance, and long-term supply match? |
| Edge computing | Computing tasks are placed close to the equipment or the site. It is an architectural arrangement | Which data and judgments must be completed on site? What capability needs to be kept during a network outage? |
| Gateway | The connection role in the system, responsible for on-site access, protocol adaptation, data organization, and upward communication | Which devices and protocols are connected? How is data normalized, cached, protected, and maintained? |
So an IPC and an embedded device are mainly a comparison of device form and platform capability. Edge and centralized computing arrange where tasks sit. A gateway describes a system duty. An IPC can have gateway software installed and take the on-site access role, and it can also run an HMI or a local application. A small edge gateway may also be able to run lightweight rules or services. A device name cannot stand in for architecture design.
When IPC and embedded were discussed in earlier years, it was often assumed by default that one device would take on acquisition, the interface, the database, and management all together. The more practical approach now is to split tasks by network conditions, response time, data volume, continuous-running requirements, and maintenance method: part stays on site, and part is given to the central platform. It is not simply substituting "edge computing" for a new device name.
In power and environment monitoring, which tasks suit the edge?
Temperature and humidity, water leak, access control, UPS, power distribution, air conditioning, and similar equipment in an equipment room often have different interfaces, and their sampling frequencies and data meanings also differ. An edge node can be responsible for taking this data in and completing protocol adaptation, point mapping, organization of unit and time information, basic filtering, and local caching. During a short network outage, necessary data is kept according to the project configuration, and backfilled after the network recovers. Simple rules that need an on-site response can also be handled on the edge side.
This work does not necessarily need a large IPC. If the main load is multi-channel equipment acquisition, protocol conversion, caching, and a small number of rules, a dedicated industrial gateway is usually more direct. If you also need to connect multiple cameras, run machine vision, maintain a local database, or connect multiple displays, then evaluate an IPC or a dedicated edge computer, and verify sustained load, heat dissipation, expansion interfaces, and storage write capacity.
The value of edge processing is that it makes the on-site data path more resilient and reduces dependence on the remote network. Microsoft's Azure IoT Operations architecture places the edge message broker, device connectors, and data-flow processing on the site side. AWS IoT guidance also suggests that, when the data volume is large or the remote connection is unreliable, a gateway be considered to preprocess, filter, or cache the data. Microsoft: Azure IoT Operations architecture; AWS: use a gateway at the edge to preprocess and cache data
Which tasks suit centralized processing?
A central platform is better suited to managing many devices, many equipment rooms, and many sites in one place, for example the equipment ledger, permissions, historical trends, cross-site comparison, alarm policy, work orders and inspection, and operations reports. Central computing can bring together more historical data, maintain rules and accounts in one place, and also make it easier for operations staff to work together across locations.
But centralized processing cannot solve every on-site problem. If acquisition records must not be lost after a network outage, and on-site alarms must keep running, the edge-side cache and local logic have to be specified. If the analysis load is heavy, you also have to judge whether data-upload bandwidth, response time, privacy requirements, and central resources meet the conditions. Video analysis can be placed on an on-site IPC or an edge AI device, and it can also run centrally when the network and latency conditions are in place. Which one depends on the task constraints.
Tongwei Smart industrial gateways, expansion modules, and the AIoT platform cover on-site access, edge processing, and central management. On a power and environment project, the gateway can be responsible for access and the data channel, and the platform takes unified operations across devices and sites. If an on-site application needs stronger local computing, you can also evaluate whether an IPC takes the gateway role at the same time. Whether to use an SG series rack-mount edge gateway, a BEC series companion edge gateway, or a split deployment of "gateway plus IPC" should be confirmed from the equipment list, protocols and point tables, sampling requirements, the network, and the fault boundary.
Confirm these five things before selection
- List the real load. Count the number of devices, the number of points, the sampling frequency, the number of protocol connections, and the data retention time. If there are video or algorithm tasks, also check the number of cameras, resolution, response time limit, and sustained load.
- Design the behavior during a network outage and a fault. Which data is cached, and for how long? Does acquisition resume automatically after an edge node restarts? How is an alarm raised when storage space is insufficient? When the central platform is unavailable, which on-site functions must continue?
- Check interfaces and data semantics. Device model, register table or information model, timestamp source, unit, quality status, reconnect after disconnect, and write permission all have to be verified. "The protocol can connect" does not mean the upper layer already has data that is usable and comparable.
- Draw the control and safety boundary. PLCs, DCS, motion controllers, and safety control systems continue to take on verified real-time control and interlocks. A gateway or IPC may acquire data or perform limited operations under authorization, but permissions, range checks, fault fallback, and operation audit have to be set. A general-purpose computing device must not be treated by default as a safety controller. Microsoft's OPC UA connector provides the ability to write data to server nodes. Having a write interface does not mean the system automatically has a safety-control function. Microsoft: OPC UA connector description
- Bring long-term operations into the plan. Check the operating-system and driver support period, the remote monitoring and upgrade method, account and certificate management, network isolation, logs, recovery after power loss, storage life, and spare-parts supply. If an IPC takes on both the gateway and business applications, assess whether the two classes of service will contend for CPU, memory, disk, and network, and whether a fault in a single application will drag down the acquisition path.
Conclusion: assign duties first, then decide which device to buy
"Industrial PC or embedded" in power and environment monitoring is still a useful hardware-selection question, but it does not answer how the system should compute. What has to be clarified first is: where device access and basic processing are placed, who is responsible for cross-site management and analysis, which functions are to be kept during a network outage, and where control authority stops.
If the project focus is multi-protocol access, edge caching, and reliable upload, evaluate from the gateway role. If the focus is vision, complex local applications, or a large amount of expansion, evaluate from the IPC's sustained compute and interface capacity. If both classes of task are present, then decide whether one device takes them on, or the data channel and application computing are separated. Products can be combined. Duties, the fault boundary, and the safety boundary still have to be stated clearly.
When preparing an equipment-room power and environment retrofit or equipment connectivity, you can first organize the equipment list, protocols and point tables, sampling frequency, outage requirements, and the control boundary. Tongwei Smart can use that to sort out, together with you, the tasks taken on by the on-site gateway, the IPC, and the central platform, and then move into device selection and joint-commissioning assessment.