OPC-UA integration for Hungarian manufacturing 2026

Hungarian manufacturing is full of Siemens S7, Beckhoff TwinCAT, and Mitsubishi Q-series PLCs. Most of them still talk Modbus or a vendor protocol, but OPC-UA (IEC 62541) is the answer for modern IT/OT integration. This is the bridge architecture we actually ship.

Architecture

One OPC-UA client runs on a gateway (x86 Linux or industrial Debian on Raspberry Pi 5), subscribes to the relevant nodes on each PLC, and forwards changes to a cloud MQTT broker. On the cloud, an ingest worker pulls from MQTT and writes into TimescaleDB continuous aggregates.

• Gateway: node-opcua (Node.js) or open62541 (C) · we default to node-opcua for DX.
• Transport: MQTT over TLS to AWS IoT Core or Mosquitto on own infra.
• Storage: TimescaleDB continuous aggregates at 1s / 1min / 1hour granularity.
• Alerts: rule engine on top of the 1min aggregate · fires webhooks / email.

Certificate handling is the hardest part

OPC-UA security is certificate-based. The default server config rejects unknown certificates. Provision the gateway client cert into the PLC's trusted store before connecting · otherwise you chase a silent 'connection refused' loop.

Five gotchas that bit us

1. Siemens S7-1500 OPC-UA server throttles above ~100 monitored items per subscription. Split.
2. Beckhoff TwinCAT uses its own DataType encoding. Use the generic xml-encoded path, not the binary fast path.
3. Mitsubishi MELSEC OPC-UA is a separate license. Verify before scoping.
4. Time sync · PLCs often drift. Timestamp on ingest is the only reliable reference.
5. Network segmentation · OT VLAN is usually firewalled against IT. Plan an explicit bridge.