Architectural Guidelines and Third-Party Software Restrictions on PCS 7 OS Servers

Architectural Guidelines and Third-Party Software Restrictions on PCS 7 OS Servers

In SIMATIC PCS 7 architectures, installing non-qualified third-party data collection software (such as AspenTech InfoPlus.21 CIM-IO, OSIsoft PI interfaces, or custom database agents) directly on redundant OS Servers violates Siemens system integrity guidelines and risks OS runtime failures. Third-party software competes for CPU, memory, and SQL Server database locks, threatening real-time alarm delivery and WinCC Redundancy synchronization. The approved Siemens architecture requires deploying OpenPCS 7 or Process Historian on dedicated interface computers to serve external enterprise historians securely.

Table of Contents

Siemens Policy on Third-Party Applications on Critical DCS Nodes

In continuous process industries upgrading from legacy PCS 7 versions (e.g., PCS 7 V6.1 to V8.1 or V9.x), enterprise historians such as AspenTech InfoPlus.21 (IP.21) or OSIsoft PI System play a vital role in long-term reporting and production optimization. The interface between the DCS and the enterprise historian is typically managed via dedicated connector software (such as AspenTech's CIM-IO server).

Engineers frequently propose co-locating the CIM-IO server software directly on redundant PCS 7 OS Servers to eliminate standalone bridge PCs and achieve software redundancy.

However, Siemens explicitly restricts and advises against installing third-party applications on PCS 7 OS Servers:
* PCS 7 OS Servers are real-time mission-critical systems designed strictly for supervisory process control, alarm annunciation, and immediate operator intervention.
* Installing uncertified third-party software, background services, or custom database connectors on OS Servers compromises operating system qualifications, invalidates Siemens technical support SLAs, and can trigger unpredictable real-time task starvation.

System Architecture and Interface Boundary Comparison Matrix

Compare unsupported co-location against approved decoupled integration architectures:

Architectural ApproachSystem Deployment LocationImpact on OS Server Real-Time PerformanceWinCC Redundancy ImpactSiemens SupportabilityDirect Co-Location (Prohibited)Installed directly on OS Server 1 and OS Server 2Severe Risk: CPU spikes and memory leaks starve SCADA processesHigh risk of split-brain or delayed redundancy syncUnsupported; requires removal before crash dump analysisDedicated OpenPCS 7 Station (Recommended)Dedicated PC or VM on Terminal Bus / DMZZero Risk: OS Servers isolated from external query loadRedundancy handled cleanly via OpenPCS 7 interfaceFully supported and certified by SiemensProcess Historian Gateway (Enterprise Choice)External connection to Process Historian (PH)Zero Risk: Data pulled from long-term archive, not live OSNo impact on real-time OS Server operationsFully supported enterprise architectureStandalone Bridge ClientExternal Windows PC running CIM-IO as OPC ClientMinimal Risk: Connects over DCOM/OPC DA to OS ServerNormal client DCOM polling loadSupported if client bandwidth is throttled

Security notice: Industrial security standard IEC 62443 mandates separating corporate IT networks from real-time control servers.

Technical Risks of Installing Third-Party Agents on OS Servers

Installing third-party software like CIM-IO directly on OS Servers introduces three critical failure modes:
1. Database Lock Contention: WinCC relies on a real-time Microsoft SQL Server instance (WINCC) for Tag Logging and Alarm Logging. Third-party agents attempting local ODBC/OLE DB queries or high-frequency file I/O compete for SQL Server worker threads, causing delayed alarm annunciation during major process upsets.
2. WinCC Redundancy Desynchronization: Redundant OS Servers maintain continuous synchronization over the Terminal Bus via CCRedServer.exe. If a third-party process consumes 100% CPU on Server 1 while processing historical backfills, Server 1 fails to respond to keepalive pings within the watchdog timeout. Server 2 assumes Server 1 has died, causing an unnecessary and chaotic master-standby failover.
3. Memory Leaks and OS Instability: Third-party connectors that accumulate unmanaged COM/DCOM handles or leaked memory can force unexpected server reboots or freeze the graphics runtime engine.

Approved Integration Topology: OpenPCS 7 and Process Historian DMZ

To connect AspenTech InfoPlus.21 or OSIsoft PI safely and redundantly:

  1. Deploy an OpenPCS 7 Station:
    * Install a dedicated industrial PC or virtual machine running SIMATIC PCS 7 OpenPCS 7.
    * Connect OpenPCS 7 to the Terminal Bus.
    * OpenPCS 7 aggregates process tags and alarms from both redundant OS Servers, presenting a unified, redundant OPC DA / OPC HDA / OPC UA server interface to enterprise clients.
  2. Install CIM-IO on the Enterprise DMZ Computer:
    * Install the AspenTech CIM-IO server on a separate computer located in the plant demilitarized zone (DMZ).
    * Configure CIM-IO to connect to the OpenPCS 7 station via OPC UA or secure DCOM.
  3. Configure Redundant Data Pathways:
    * OpenPCS 7 automatically handles server failover: if OS Server 1 goes down, OpenPCS 7 transparently switches its data queries to OS Server 2 without disconnecting the enterprise historian.

Verification

Verify safe external data communication:
1. From the enterprise historian (AspenTech IP.21), initiate continuous polling of 5,000 process tags through the OpenPCS 7 interface.
2. Monitor Windows Task Manager on both OS Servers: Confirm that OS Server CPU utilization remains below 25% and memory utilization remains stable.
3. Simulate a failover by disconnecting OS Server 1 from the plant bus: Confirm that OS Server 2 assumes mastership seamlessly while the enterprise historian continues receiving live data via OpenPCS 7 without dropped values.

Limitations and Operational Precautions

  • Never connect enterprise historian servers directly to the PCS 7 Plant Bus; all third-party communications must be restricted strictly to the Terminal Bus or an industrial DMZ.
  • If deploying OPC DA over DCOM across network domains, configure dedicated domain trust relationships and enforce packet authentication (Packet Privacy) per Microsoft hardening guidelines.
  • Verify that total cyclic tag queries through OpenPCS 7 do not exceed the licensed Process Object and tag limits.

Engineer FAQ

Can third-party software be installed on an OS Client instead of an OS Server?

While installing on an OS Client is less risky than an OS Server, it is still discouraged. Dedicated interface stations (OpenPCS 7) are the only fully tested and supported topology.

What license is required for OpenPCS 7?

Deploying OpenPCS 7 requires the 'SIMATIC PCS 7 OpenPCS 7' runtime software license package, sized according to the number of concurrent external client connections.

Does Process Historian provide an OPC HDA interface for third-party historians?

Yes. Process Historian includes an integrated OPC HDA (Historical Data Access) server interface, allowing IP.21 or PI to query historical data directly from the long-term archive.

Technical References

Related Articles

Related Tags

  • OpenPCS 7
  • Third-Party Integration
  • OS Server Integrity
  • InfoPlus.21
  • AspenTech
  • CIM-IO
  • OPC DA
  • PCS 7 OS
6 respuestas