Bridging External OPC Data from WinCC into S7-400 CFC Control Logic in SIMATIC PCS 7

In SIMATIC PCS 7, bringing external process data acquired by WinCC via an OPC DA/UA client driver into AS controller CFC charts for closed-loop control logic cannot be executed directly across standard SCADA tags. Process tags residing purely in WinCC are supervisory and do not automatically propagate down to the controller. To bridge this data reliably into CFC logic, engineers can: (1) deploy SIMATIC OpenPCS 7 or a dedicated OPC-to-S7 bridge script that writes to AS data blocks via Named Connections, (2) utilize an Industrial Ethernet CP 443-1 with Modbus TCP/Open User Communication (OUC) to read data directly at the controller level, or (3) configure WinCC Raw Data/Tag handshakes.

Architectural Separation Between WinCC Supervisory Tags and AS Controller Memory

In SIMATIC PCS 7, the engineering paradigm enforces strict hierarchical segregation:
* The AS Layer (Deterministic): The S7-400 / CPU 410-5H executes deterministic control logic in cyclic interrupt OBs (OB35). It relies on physical I/O and S7 communication blocks.
* The OS Layer (Supervisory): WinCC acts as an HMI/SCADA client. When WinCC reads data from a third-party OPC server (e.g. Kepware, Matrikon) via the OPC.chn driver, the tags reside solely in the WinCC Tag Management database.
* The Challenge: The AS controller has no native awareness of WinCC internal tags. To utilize external OPC variables in closed-loop control, a reliable data bridge must transfer values from the OS down to the AS.

Why Direct SCADA-to-CFC Routing Poses Operational Risks

Before implementing a software bridge:
1. Lack of Determinism: Windows OS-level communications are subject to network latency, buffering, and PC restarts. Critical safety interlocks must never depend on data routed through a Windows PC.
2. Quality Code Degradation: If the third-party OPC server disconnects, the SCADA bridge must reliably signal ST = 16#00 (Bad Quality) to the CFC block to prevent stale value latching.
3. Heartbeat Requirement: The AS logic must implement a watchdog timer that trips if the WinCC OPC bridge stops strobing a heartbeat variable.

Implementation Architectures for Bridging OPC Data into CFC

Three proven engineering patterns exist to bring external OPC data into CFC:

[Method 1: Direct Fieldbus / Modbus TCP to AS Controller (Recommended)]
   │  • Bypass WinCC entirely for critical control logic:
   │  • Install an Industrial Ethernet CP 443-1 (or onboard PN port)
   │  • Execute Open User Communication (OUC) or Modbus TCP blocks directly in CFC
   │  • The AS reads data autonomously without PC dependency!
   │
[Method 2: WinCC VBScript / C-Action Periodic Write (Standard Solution)]
   │  • In WinCC Graphics Designer or Global Scripts:
   │  • Create a cyclic script (e.g. 1-second cycle):
   │      - Read tag from OPC channel: "OPC_Tag_Pressure"
   │      - Write value to AS S7 tag:  "AS1/DB_OPC_Data.Pressure"
   │      - Write incrementing watchdog heartbeat: "AS1/DB_OPC_Data.Watchdog"
   │  • In CFC: Read value from instance DB via standard channel driver (Pcs7AnIn)
   │
[Method 3: SIMATIC OpenPCS 7 Industrial Gateway]
   │  • Deploy an OpenPCS 7 server station
   │  • External OPC client writes directly to OpenPCS 7 S7 variables
   │  • OpenPCS 7 writes directly to the AS controller via high-speed Named Connections

OPC Integration Methods Comparison Matrix

Compare technical capabilities between OPC-to-CFC bridging strategies:

Integration ArchitectureDeterminismPC Failure ResilienceEngineering ComplexityBest Suited ApplicationsDirect Controller Bus (Modbus TCP)High (Deterministic)100% AutonomousMedium (CFC blocks)Critical interlocks, closed-loop PIDWinCC Script BridgeLow (Windows timing)Vulnerable to PC stopLow (Basic script)Non-critical setpoints, weather dataSIMATIC OpenPCS 7MediumRedundant server capableMedium (DCS Option)High-volume MES / SCADA exchangesOPC UA Server on CPU 410HighAutonomousFirmware dependentModern IoT and controller integration

Verification

To confirm that external OPC data bridges reliably into CFC:
1. In WinCC Explorer, verify that the OPC channel indicates active connection status.
2. In the AS CFC chart, open the data block receiving the OPC value in Test Mode online.
3. Modify the process variable on the third-party OPC server.
4. Confirm that the value updates in CFC within the expected 1-second cycle.
5. Sever the third-party OPC network cable; verify that the AS watchdog timer detects the heartbeat loss within 3 seconds and flags a communication alarm.

Limitations and Operational Precautions

Never use WinCC script-bridged OPC variables for emergency shutdown (ESD) or personnel safety loops. If the Windows OS server reboots, freezes during a Windows update, or experiences network congestion, the control loop will lose updates. Always implement an active watchdog timer (Watchdog_Err) in CFC that sheds the loop to a safe manual state if data stops updating.

Engineer FAQ

Can CFC read directly from an OPC server without WinCC?

Standard S7-400 CPUs do not have an onboard OPC client. However, they can communicate directly via Modbus TCP, ISO-on-TCP, or PROFINET using standard communication function blocks (FB63-FB66).

How fast can WinCC scripts write OPC data to the AS?

WinCC cyclic scripts can reliably write data at 1-second or 500-millisecond intervals. Faster rates (e.g. 100 ms) risk overloading the WinCC script engine and Terminal Bus.

What happens to the CFC value if WinCC Runtime is closed?

Without active scripting, the data block variable in the AS will hold its last received value indefinitely unless a watchdog timer is implemented in CFC to clear it.

What is SIMATIC OpenPCS 7?

OpenPCS 7 is an official Siemens interface software that exposes PCS 7 AS and OS tags directly to external OPC DA, OPC A&E, and OPC UA clients across the network.