OPC UA, MQTT and REST API: Practical S7-1500 and WinCC Explorer Architecture

Choose an explicit data path

Connect the Unit 101 tank-and-pump example to SCADA and a reporting application without confusing the protocols. TIA Portal configures the controller. WinCC Explorer configures the Classic SCADA project. A broker distributes MQTT messages. An edge gateway can translate controller data into MQTT payloads or an application-facing REST API.

Use three named paths in your design: Path A: S7-1500 OPC UA server → WinCC OPC UA client. Path B: S7-1500 OPC UA server → edge client → MQTT broker. Path C: S7-1500 OPC UA or supported Web API → edge gateway → REST client. A fourth optional path uses Siemens LMQTT_Client in a compatible PLC project to publish directly to a broker.

The S7-1500 Web API is JSON-RPC over HTTPS, not a native REST resource such as /api/tanks/101. The REST route in these lessons is an original gateway design. Likewise, do not assume every WinCC Explorer version has the same native MQTT or REST facilities.

Lab scope: use an isolated training CPU/network, TIA Portal compatible with its firmware and a supported WinCC Classic release where required. Check the exact CPU order number, firmware, license and installed software before following configuration steps. Examples use read-only telemetry; no example writes a motor command. The addresses, tag names and values are teaching choices.

Use the same five values in every protocol

Create the DB in a training TIA project. Record the five tag types and engineering units. For the test sequence, hold level at 50 %, flow at 12 m³/h and pump feedback true, then change one value at a time. Increment SampleSeq from a deliberate sampling routine. Reading several tags separately does not guarantee a coherent snapshot; use a designed snapshot/sequence scheme when that matters.

For each exported sample, record source identity, value, source/collection time, quality and sequence. Do not label a gateway collection timestamp as the PLC source timestamp.

Assign each protocol a practical job

Choose a gateway for the first combined exercise so protocol translation and application credentials are separate from screen graphics. Keep the tested WinCC-to-PLC path available when the broker or REST client is offline.

Build the lab in an order that isolates faults

1. Record CPU model/firmware, TIA version, WinCC version and needed licenses.
2. Create DB_IIoT, compile the training PLC project and verify the values in a watch table.
3. Complete the S7-1500 OPC UA server lesson and read the five nodes with one client.
4. Complete the WinCC client lesson and compare its display to the watch table.
5. Publish the same data through the MQTT bridge; inspect it with a separate subscriber.
6. Expose a read-only REST representation through the gateway. Check stale/error responses as well as success.
7. Disconnect one path at a time and record which displays should remain available.

Keep network endpoints, certificates, namespaces and topic names in a worksheet. Use placeholders in shared learning notes; store actual credentials in the appropriate runtime configuration.

Acceptance and troubleshooting

• Every arrow has a named source, destination, protocol and authentication method.
• WinCC level and MQTT/REST level match the PLC after allowing for their different update intervals.
• A stopped sample counter results in a stale indication, not a healthy frozen value.
• Broker failure does not silently turn a pump indication to STOPPED.
• REST errors are distinguishable from a legitimate zero process value.
• No example depends on exposing the CPU directly to the public internet.

Deliver: one architecture sheet and five-value mapping. Continue with OPC UA server configuration, then the WinCC client. This article is the roadmap; the remaining lessons contain the practical configuration and test steps.