Every MES, historian and dashboard project eventually knocks on the PLC’s door. OPC UA is the door with a lock and a guest book — configured properly.
Serving deliberately
The S7-1500 server activates per CPU (license per size class) — the design decision is what to expose. Default-exposing every DB is the lazy path to both performance pain and information leakage. The clean pattern: one or two “interface DBs” per concern (production data, energy, machine status), exposed explicitly via server interfaces, versioned like any contract, everything else invisible. Consumers get a stable, documented address space; your internal refactoring stays free.
Security is configuration, not luck: certificate-based endpoints with the insecure policies disabled, application authentication decided (anonymous read-only at most, and only on isolated networks), and the guest list managed — every client presents a certificate you chose to trust. The CPU’s global security settings and the plant firewall finish the segmentation story: OPC UA belongs on the plant-integration interface, not the machine I/O network.
Performance is a budget: sampling intervals and monitored-item counts multiply; a thousand items at 100 ms is a real communication load on a mid-size CPU. Negotiate need — the historian wanting 10 ms trends should subscribe to the drive or use a dedicated gateway, not squeeze OB1.
FAQ
Companion specifications worth it? When your customer names one (Euromap, PackML-flavored models), yes — modeling to a standard beats inventing structure. Otherwise clean UDT-mirrored interfaces already serve well.
OPC UA methods or just data? Data first. Methods (writable commands) re-open the “who may write” question — treat every writable node as a control-system change with sign-off.
Zone Otomasyon integrates machines into MES/ERP with contract-style OPC UA interfaces. Integration engineering.