English is currently available.
SCADA & HMI DISCUSSION
Our site has three generations of equipment: Siemens and Allen-Bradley PLCs, an older SCADA package that only offers OPC DA, and a few Modbus TCP power meters. Management wants all of it in one reporting database with about 5,000 tags.
Is OPC UA the sensible common interface for this, or is it overkill compared with reading each device using its native driver? I also do not understand how OPC UA relates to the older OPC that needed DCOM settings.
Classic OPC (DA for live data, HDA for history, A&E for alarms) is built on Microsoft COM/DCOM. It works only on Windows, is awkward through firewalls because DCOM uses dynamically assigned ports, and the DCOM security settings are a well-known source of lost days.
OPC UA is a redesign, not an update. It is platform independent, runs over a single TCP port (4840 is the registered default for the binary opc.tcp transport), and has encryption, signing and user authentication built into the protocol. Many current PLCs have an OPC UA server in the CPU, so no PC driver is needed in between.
For a mixed site the usual pattern is one aggregation layer: a connectivity server or gateway that speaks the native protocols downward (S7, EtherNet/IP, Modbus TCP, and OPC DA through a wrapper for the old SCADA) and exposes everything upward as a single OPC UA address space. Your reporting database then needs exactly one client. Writing four native drivers yourself is possible, but you take on the maintenance of each one.
Put the OPC DA wrapper on the same machine as the old SCADA server so that DCOM never has to cross the network; only OPC UA leaves that PC.
Use subscriptions rather than polling reads. In OPC UA the client creates monitored items with a sampling interval and, for analog values, a deadband; the server sends a notification only when a value changes by more than that. With 5,000 tags of which perhaps 5 percent change in any given second, that is about 250 notifications per second instead of 5,000 reads, and the load on the PLCs drops accordingly.
Every value arrives with a status code and a source timestamp. Store both. A reporting system that ignores the quality will happily record the last good value for hours after a device has gone offline.
Two practical cautions. First, security setup is where most first attempts stall: client and server exchange application certificates, and each side must trust the other's certificate before a secure session opens. Plan for that instead of falling back to the "None" security policy with anonymous login, which is acceptable on a test bench and not on a plant network.
Second, check the limits of embedded servers. A PLC's built-in OPC UA server has a maximum number of sessions, subscriptions and monitored items, and the minimum sampling interval depends on the CPU. Those numbers are in the controller's manual and should be compared with your 5,000 tags before you commit to the architecture.
It is not overkill for reporting, but keep the scope clear: make the connection read-only unless there is a real need to write, and give the reporting client an account that cannot write.
Also agree on tag naming and engineering units in the aggregation layer rather than in the database. Fixing a scaling mistake at the source is far easier than correcting months of stored data afterwards.
