Definition
OPC (OLE for Process Control) is an industrial automation data exchange standard, including OPC DA, OPC UA, etc., used for data interoperability among PLC, SCADA, and MES.
Protocol Evolution
The classic version of OPC includes OPC DA (Data Access), OPC A&E (Alarms & Events), and OPC HDA (Historical Data), based on Windows COM/DCOM and dependent on the Microsoft technology stack. OPC UA (Unified Architecture) is the next-generation standard, cross-platform, supporting TCP/WebSocket, featuring an information model and security mechanisms, and has become mainstream for industrial connectivity. OPC UA supports publish/subscribe, redundancy, and certificate authentication, suitable for full-chain data exchange from sensors to the cloud.
Integration with communication modules
Industrial gateways, edge computing boxes, and other devices have built-in OPC UA clients or servers to collect OPC data from PLC , SCADA , etc., and upload it to cloud MES or industrial internet platforms via 4G/5G modules. The modules are responsible for establishing secure tunnels and transmitting OPC UA messages, supporting reconnection and data caching in weak network scenarios. On the edge side, an OPC UA server can run locally, allowing devices to subscribe directly, reducing cloud round-trip latency.
Use Cases
Factory equipment data collection, remote monitoring, predictive maintenance; SCADA data upload to the cloud in the energy industry; building automation, smart buildings, etc. OPC addresses the heterogeneous connectivity problem of industrial equipment, communication modules address on-site industrial networking issues, and the combination of the two achieves the 'last mile' access and remote transmission of industrial data.
Engineering Practice Supplement
Regarding the implementation of 'OPC' in IoT and cellular module projects, it is recommended to write network constraints (target market frequency bands and sunset plans, APN and private network strategies, roaming and tariffs, power-saving modes such as PSM/eDRX) and terminal constraints (antenna and RF layout, power ripple and surge, thermal design and derating, EMC/safety) into verifiable acceptance items during the project initiation phase. In the R&D phase, use weak network simulation, high/low temperature, and voltage deviation to reproduce boundary faults, keeping logs and waveforms; in mass production, establish batch and calibration traceability, and handle component substitution through change review. After going live, include connection success rate, reconnection times, latency, and power consumption in the operation dashboard, making anomalies traceable to version and batch.
Information-Model Nodes and Subscription Deadbands
Classic OPC splits data, alarms, and history into three interfaces and binds them to the Windows component model, so a cross-host setup also has to deal with remote activation. OPC UA replaces that with a session that can run on different operating systems. The client opens a secure channel, creates a session, then reads, writes, or subscribes by node id. A node is not only a register address. It carries a data type, an engineering unit, an access level, and a source timestamp. The deadband in a subscription decides how far a value must move before it is pushed. The sampling interval decides how often the server looks at the underlying source. The cellular module does not interpret these nodes. It only provides the exit for the client or server running on the gateway.
How you use it depends on whether the data is for monitoring or for control. Monitored values can be aggregated at the gateway and sent up on a scale of seconds or slower. Interlocks and motion setpoints must finish on the plant network. Certificates, the trust list for application instance certificates, and the security policy have to be in place before commissioning. When a self-signed certificate expires, the session drops with nobody watching, and it looks like the module went offline. A namespace index can change after the server restarts. A client that hard-codes the index instead of the namespace URI reads the wrong node.
Gateway Certificates and Sampling-Period Mismatch
The most common mistake is to copy the PLC scan period straight onto the cellular subscription. A temperature point at a hundred milliseconds, pushed once a second, is invisible on a plant switch. On a cellular bill and on the air interface it becomes a stream of small packets that pulls a low-power module out of its power-saving state. The opposite mistake is a deadband set so wide that alarm edges are filtered out. The cloud curve becomes a staircase, and the event cannot be reconstructed later. Another error is to expose writes on a public-network session: permission bits are not split, the maintenance account and the read-only account share one certificate, and a mistaken setpoint lands directly on the field device.
Mixed timestamps also create false faults. If server time, gateway time, and the module's cellular network time disagree, the historian files one event as two. If the disconnect cache stores the value and not the status code (good, bad, uncertain), the platform treats uncertain values as valid process data after the link returns. For the boundary between plant real-time Ethernet and this kind of gateway, compare the real-time domain split in PROFINET. For the part of central monitoring that should stay in a local loop, see the control-time limits in SCADA.
The gateway cache also has to keep a status code for each node, not only the last engineering value. When status moves from good to uncertain, the cloud curve should break or be marked. Connecting two good values with a straight line makes a communication hole look like steady production. After the server reconnects, the subscription revision must be aligned again. Reusing the old revision makes the server believe the client is still watching items that have been deleted. A write must come back with its source and time, and it must be limited to a maintenance account. A read-only session must not write setpoints even when its certificate is valid. History reads piled up during a cellular reconnect should be paged. Pulling several hours of raw samples at once fills the narrow uplink, and live alarms cannot get out. If the sampling interval is shorter than the rate this cellular link can deliver steadily, the server queue fills first while the client still shows the subscription as healthy, so alarms wait until the queue drains. Queue depth and the drop count should be reported on their own. Subscription-up is not enough.