WinCC to SAP Integration: Network and OPC Architecture Guide

Overview

Connecting 15 or more independent WinCC SCADA stations to a central SAP ERP for bidirectional production data exchange is one of the most common greenfield MES/SCADA integration scenarios in discrete manufacturing. The technical challenge is not a single protocol conversion but a layered architecture decision covering network segmentation, firewall placement, data aggregation topology, and licensing model. This guide consolidates the architectural choices for a Siemens WinCC V7.5 SP2 / V8.0 / V8.1 SCADA estate exchanging production orders and actuals with an SAP S/4HANA or SAP ECC backend, with emphasis on the three viable data paths: per-station WinCC Connectivity Pack, a central OPC aggregation server, or a full SIMATIC IT / Opcenter Execution MES layer.

Engineers approaching this problem typically ask two questions in sequence: (1) should the plant LAN connect directly to the office LAN or be separated by an industrial firewall and DMZ, and (2) should SAP pull data from each WinCC station individually or from a single aggregator. The answer to the first question is unconditional (always segment), and the answer to the second depends on tag count, latency targets, and licensing budget.

Problem Decomposition: Data Flows and Trust Boundaries

WinCC to SAP integration involves two asymmetric data flows that drive different architectural choices:

The asymmetric latency requirements mean a single monolithic interface rarely fits both flows. Plan order distribution tolerates an overnight batch or hourly poll; actuals reporting usually requires near-real-time event handling for OEE dashboards. Map each flow to the component best suited to its volume and cadence before selecting the integration middleware.

Network Segmentation: Plant LAN vs Office LAN Architecture

Plant LAN and office LAN have fundamentally different objectives. The plant network optimizes for deterministic real-time traffic, broadcast containment, and uptime; the office network optimizes for throughput, mobility, and internet access. Coupling them without a stateful inspection firewall violates the IEC 62443 zone-and-conduit principles documented in the Siemens Industrial Security compendium for PCS 7 and WinCC installations.

Recommended segmentation pattern:

• Plant zone (Level 3 of Purdue model): 15 WinCC stations, optional SIMATIC IT server, OPC aggregation server, engineering stations. Subnet isolated from corporate. Use managed SCALANCE switches with IGMP snooping and broadcast limiting enabled. Default VLAN for plant traffic.
• Industrial DMZ: Hosts the integration middleware (SIMATIC IT historian, SAP Plant Connectivity, or OPC aggregation server with dual NICs). DMZ sits between two firewalls and is reachable from neither side without explicit allow rules.
• Office zone (Level 4/5): SAP application servers, SAP HANA, SAP routers, AD, DNS, end-user workstations.

For a 15-station deployment, the minimum physical segmentation stack is:

1. SCALANCE XC-200 or SCALANCE XR-500 ring in the plant (HRP or MRP redundancy).
2. SCALANCE S615 or S623 industrial firewall at the plant boundary.
3. DMZ switch (SCALANCE XC-200) hosting the OPC or MES server.
4. Secondary perimeter firewall (or second instance of SCALANCE S in back-to-back mode) facing the office network.
5. Office core switch terminating the SAP VLAN.

Firewall Selection and Industrial DMZ Design

Use a purpose-built industrial firewall rather than an enterprise firewall repurposed for the plant boundary. The Siemens SCALANCE S family (S615, S623, S627) provides DIN-rail mounting, conformal coating options, and preconfigured Siemens automation protocol filtering profiles that natively drop PROFINET, S7, Modbus TCP, and OPC Classic broadcasts at the boundary. Enterprise firewalls (Fortinet, Palo Alto, Check Point) lack DPI profiles for S7 communication and often misinterpret PROFINET frames as malformed packets, generating false positives that interrupt plant traffic.

DMZ design rules for SAP connectivity:

Physical Topology

Reference topology for a 15-station WinCC estate integrating with SAP:

The DMZ is the only host reachable from both sides. Both firewalls default-deny, with explicit allow rules for the SAP RFC destination (typically TCP 33nn where nn is the SAP system number, e.g., 3300 for system 00) on the office side and the WinCC OPC UA port (default 4840) on the plant side.

Data Connectivity Options Compared

Three viable architectural patterns exist for the WinCC to SAP bridge. Each trades licensing cost against integration depth and operational complexity.

For a 15-station estate exchanging production plans and actuals with SAP, Option B (central OPC aggregation) is the most common and cost-effective choice when no MES-level logic (routing, genealogy, OEE roll-up) is required. Option C becomes attractive when the customer has committed to a Siemens MES roadmap or already operates Opcenter Execution on another plant. See the Opcenter Execution product page for current MES capabilities.

Option A: Per-Station WinCC Connectivity Pack

The WinCC Connectivity Pack provides standardized OLE DB and OPC access to WinCC runtime and archive data. For SAP integration, the typical pattern is:

1. Enable the WinCC OPC UA Server on each station. WinCC V7.5 SP2 and later ship OPC UA Server as a licensed option; WinCC V8.0 and V8.1 integrate it.
2. Install an RFC-capable SAP connector on each WinCC station, or have SAP JCo or NCo libraries invoke the WinCC OLE DB provider from a central SAP J2EE cluster.
3. Define SAP function modules (BAPIs or custom RFCs) to read order data from WinCC and write actual counts back.

Limitations: SAP JCo or NCo from a J2EE engine reaching across 15 RFC destinations consumes basis-team capacity for SM59 maintenance, transport management, and authorization objects. Avoid this pattern for more than 5 stations.

Option B: Central OPC Aggregation Server

A single Windows Server (VM or physical) in the DMZ runs:

• OPC UA client aggregating tags from 15 WinCC OPC UA Servers (one TCP session per station, port 4840).
• An OPC UA server endpoint exposed to the SAP side.
• Optional internal historian buffer (e.g., WinCC IndustrialDataBridge or a custom .NET service) to ride out SAP maintenance windows.

For SAP-side consumption, three sub-patterns exist:

1. Custom RFC or BAPI: SAP ABAP calls an external program via CALL FUNCTION ... DESTINATION using an RFC destination pointing at the OPC UA bridge (typically via a Java or .NET wrapper around the OPC Foundation .NET Standard stack).
2. SAP MII / SAP ME: SAP Manufacturing Integration and Intelligence (MII) reads OPC UA natively through its Plant Information Catalog. This is the lowest-friction path when the customer already licenses MII.
3. SAP Plant Connectivity (PCo): SAP PCo acts as the OPC UA / MES agent on the DMZ host, exposing a flat management cockpit for tag configuration and agent management. PCo is the canonical SAP-blessed pattern for OPC-based plant data acquisition.

Option C: SIMATIC IT / Opcenter Execution MES Layer

SIMATIC IT was rebranded as Opcenter Execution within the Siemens Digital Industries Software portfolio (SISW). It provides a dedicated MES layer with native bidirectional SAP connectivity through its Production Suite and Integration Framework. Architecture:

• Opcenter UAF (Unified Architecture Framework): Collects shop-floor data via OPC UA from WinCC stations.
• Opcenter Historian: Persists high-resolution actuals.
• Opcenter Integration Framework: Maps shop-floor events to SAP BAPIs or IDocs (e.g., BAPI_PRODORDCONF_CREATE_TT for production confirmations, BAPI_PRODORD_GET_DETAIL for order distribution).

Order distribution workflow:

1. SAP issues a production order via BAPI or IDoc (e.g., LOIPRO / IDoc LOIROU01).
2. Opcenter Integration Framework receives and persists the order in its MES database.
3. Opcenter pushes the order as a structured message to the target WinCC station via OPC UA write or WinCC OLE DB.
4. WinCC dispatches the order to the appropriate S7 PLC.

Actuals reporting workflow:

1. WinCC detects a production event (count, scrap, downtime reason).
2. WinCC exposes the event via OPC UA / archive.
3. Opcenter receives the event and applies routing rules, OEE calculations, and genealogy mapping.
4. Opcenter posts the confirmation to SAP via BAPI_PRODORDCONF_CREATE_TT or BAPI_PRODORDCONF_CANCEL.

For plants with regulatory traceability, OEE reporting, or complex routing requirements, the MES-layer approach is the most maintainable despite higher initial licensing.

WinCC Connectivity Pack Installation and Configuration

Procedure for adding the Connectivity Pack to a single WinCC V8 station (use with Option A or as the OPC UA source for Option B/C):

1. Insert the WinCC installation media or mount the installation ISO. Launch Setup.exe in elevated mode.
2. Select Install components / Additional components.
3. Check WinCC Connectivity Pack. On WinCC V7.5 SP2 and later, the OPC UA Server is bundled; on V8.0 and V8.1 it is integrated.
4. Confirm installation path (default C:\Program Files\Siemens\Automation\WinCC\Connectivity Pack).
5. After installation, verify the service WinCC Connectivity Pack Service is set to Automatic startup and running under the SIMATIC HMI user account (or a dedicated service account with read access to the WinCC project directory).
6. Open the WinCC Configuration Studio and navigate to Project Properties > OPC UA Server. Enable the server, set endpoint to opc.tcp://<station-fqdn>:4840, and assign a security policy (None for DMZ-internal, Basic128Rsa15 or Basic256Sha256 if crossing trust boundaries).
7. Configure the WinCC tag database to expose the production tags under a custom namespace (e.g., ns=2;s=Plant01.Production.OrderNo).
8. Test the endpoint with the Siemens OPC UA Scout utility or any third-party OPC UA client (Unified Automation UaExpert) from the aggregation server host.

Production Plan Exchange (SAP → WinCC)

Distribution of production orders from SAP to WinCC follows the standard SAP production planning flow. The MES layer (or custom RFC) translates SAP orders into WinCC tags.

For the SAP to WinCC direction, prefer pull from MES on a scheduled interval (e.g., every 5 minutes via the Opcenter scheduler) over ALE push. Pull avoids the operational complexity of maintaining an ALE distribution model across SAP release changes and gives the MES layer a deterministic view of the order book.

Actual Production Data Exchange (WinCC → SAP)

Production confirmations are posted to SAP via the standard PP-PI confirmations BAPI family:

Confirmation batching rule of thumb for a 15-station plant: batch confirmations per shift end and per lot completion; do not post per-cycle. Posting per-cycle saturates the SAP RFC gateway and creates an unrecoverable audit trail of micro-confirmations. Opcenter and SAP PCo both provide configurable buffering for this exact reason.

For each confirmation, populate the following minimum fields:

• ORDERID — production order number (CHAR 12)
• OPERATION — operation number (NUMC 4)
• PHASE — confirmation phase (1 = partial, 3 = final)
• YIELD — good quantity (DEC 13,3)
• SCRAP — scrap quantity (DEC 13,3)
• EXEC_START_DATE and EXEC_START_TIME
• EXEC_FINISH_DATE and EXEC_FINISH_TIME
• WORKCENTER — HR or equipment work center

OPC UA Server Configuration in WinCC

Beyond the Connectivity Pack install, the OPC UA Server endpoint must be hardened for DMZ placement:

Security Hardening Checklist

1. Patch WinCC stations to the current SIMATIC Security Update. Monitor the Siemens ProductCERT advisories feed monthly.
2. Apply Windows hardening per the Siemens Industrial Security whitepaper: disable SMBv1, enforce SMB signing, disable guest account, restrict NTLM.
3. Replace the default WinCC user Administrator with named accounts and enforce password rotation (90-day maximum).
4. Enable WinCC audit logging and forward events to a central SIEM in the office zone via the SCALANCE S firewall allow list.
5. Disable the WinCC WebNavigator external interface unless required; if required, terminate behind a reverse proxy with TLS 1.2 minimum.
6. Run the OPC UA endpoint on a dedicated NIC where possible, with Windows Firewall restricted to the OPC aggregation server IP only.
7. Use SAP Secure Network Communication (SNC) between SAP and the DMZ host. Configure SNC with X.509 certificates issued by the SAP PSE.
8. Restrict SM59 RFC destination authorizations using SAP authorization objects S_RFC and S_ICF; deny * wildcards.
9. Log all firewall denials and review weekly.
10. Maintain an offline backup of the WinCC project, the OPC UA certificates, and the Opcenter configuration database.

Performance and Sizing

For 15 WinCC stations each holding approximately 2,000 process tags with 500 active production tags per station, the aggregate rate into the OPC aggregation server is calculated as:

tags per second = 15 stations × 500 active tags / 1 s = 7,500 tag updates/s

With OPC UA binary encoding (~150 bytes per data change notification after compression), the bandwidth is:

7,500 updates/s × 150 B = 1.125 MB/s = 9 Mbps

A gigabit plant LAN plus a gigabit DMZ link carries this trivially. Watch points are the OPC UA session count per server (default 50, raise to 200 for the aggregator) and the SAP RFC gateway throughput (default ~100 RFC requests/s, batch to 5 to 10/s with buffering).

For cloud-based SAP analytics on top of the DMZ integration layer, modern platforms such as Microsoft Fabric SAP Table connector provide direct CDS view and SAP table access via the SAP application or message server, allowing replicated OEE datasets to land in OneLake without touching the WinCC estate directly.

Verification and Commissioning

Verify each layer independently before end-to-end testing.

1. OPC UA layer: From a UA client, subscribe to ns=2;s=Plant01.Station01.OrderNo. Confirm value updates and subscription keep-alive at 1 s interval.
2. Firewall layer: From the SAP basis host, attempt Test-NetConnection dmz-host -Port 33400 (SAP RFC). Expect success. From the DMZ host, attempt Test-NetConnection wincc01 -Port 4840. Expect success. From an unauthorized plant host, attempt the same test — expect timeout.
3. SAP layer: From SAP, run transaction SM59 → RFC destination test against the DMZ host. Expect Connection OK. Then call BAPI_PRODORD_GET_LIST against a known order. Expect populated result.
4. End-to-end: From SAP, create a test production order via BAPI_PRODORD_CREATE. Confirm it appears in the target WinCC station within one scheduled poll interval. Trigger a manual count on the WinCC station. Confirm the confirmation reaches SAP via BAPI_PRODORDCONF_GETLIST.
5. Failure scenarios: Disconnect the DMZ aggregation server from SAP and trigger 50 production events on WinCC stations. Reconnect. Confirm all 50 events are buffered and posted (no duplicates, no losses).

Troubleshooting Matrix

Frequently Asked Questions