Configuring SIMATIC PCS 7 Virtualization (SIVIRT): Architecture, Network Topologies, and Host Sizing

Configuring SIMATIC PCS 7 Virtualization (SIVIRT): Architecture, Network Topologies, and Host Sizing

SIMATIC PCS 7 Virtualization (SIVIRT) officially supports hosting Engineering Stations, OS Servers, OS Clients, and Process Historian instances on VMware vSphere ESXi hypervisors. Automation Stations (AS controllers) must remain physical hardware. Key prerequisites include dedicating separate virtual switches (vSwitches) for Terminal and Plant buses, disabling VMware Tools host clock synchronization in favor of dedicated NTP masters, and enforcing static 100% RAM and vCPU reservations.

Table of Contents

PCS 7 Virtualization (SIVIRT) Scope and Released Boundaries

Virtualizing process control system infrastructure offers compelling benefits for modern industrial plants: reduced server footprint, centralized backup management (VMware snapshots), simplified disaster recovery, and hardware independence.

Siemens formally validates and supports virtualized deployments under the framework known as SIMATIC PCS 7 Virtualization (SIVIRT):
* Approved Hypervisor: VMware vSphere ESXi (versions 5.5, 6.0, 6.5, 6.7, and 7.0 depending on the specific PCS 7 release). Microsoft Hyper-V is not released for PCS 7 OS Servers.
* Released Virtualized Roles:
* Engineering Stations (ES)
* OS Single Stations and Redundant OS Server Pairs
* OS Clients (often paired with thin client hardware consoles using RDP)
* Process Historian (PH) and SIMATIC Information Server (IS)
* SIMATIC BATCH, SIMATIC Route Control, and OpenPCS 7
* Non-Virtualized Hardware Boundary:
* Automation Stations (AS controllers)—including CPU 410-5H and S7-400H fault-tolerant controllers—must remain physical hardware. Field level I/O control and safety interlocking cannot be virtualized in software.

Network Architecture: Terminal Bus vs. Plant Bus in VMware ESXi

Virtual networking must strictly replicate the physical network segregation mandated by Siemens Industrial Security guidelines (PCS 7 Compendium Part F):

  1. Virtual Switch (vSwitch) Segregation:
    * Terminal Bus vSwitch: Interconnects OS Servers, OS Clients, Engineering Stations, and Historian nodes. Bound to dedicated physical network adapter uplinks (e.g. 1 Gbps or 10 Gbps Ethernet).
    * Plant Bus vSwitch: Interconnects OS Servers and Engineering Stations with physical Automation Stations (S7-400 / CPU 410-5H). Bound to isolated physical NIC ports connected to the industrial plant bus switches (SCALANCE X).

  2. Plant Bus Communication Options (SOFTNET vs. HARDNET Passthrough):
    * Option A: SOFTNET-IE S7 (Standard Virtual NIC - Recommended):

    • Deploy standard virtual network adapters (VMXNET3) inside the VM.
    • Install SIMATIC NET SOFTNET-IE S7 (or SOFTNET-IE S7 REDCONNECT VM for fault-tolerant controllers). Communication operates over standard ISO-on-TCP (RFC 1006).
    • Option B: HARDNET with VMDirectPath I/O (PCI Passthrough):
    • Install physical CP 1623 communication processors in the ESXi host server PCI slots.
    • Configure VMware VMDirectPath I/O to assign the physical CP 1623 directly to a specific OS Server VM. This allows the VM to utilize native hardware CP processing, though it restricts VM migration (vMotion).

Time Synchronization and Resource Reservation Rules

Two strict operational rules govern stability in virtualized PCS 7 environments:

  1. Absolute Time Synchronization Independence:
    * In VMware ESXi, the default VMware Tools configuration synchronizes the guest operating system clock with the ESXi host hardware clock.
    * In PCS 7, this must be explicitly disabled: ESXi host clock drift will corrupt WinCC Tag Logging time series and alarm sequencing.
    * In the VM properties, uncheck Synchronize guest time with host.
    * Configure all guest virtual machines to synchronize directly via Windows Time Service (NTP) to a central external hardware master clock (e.g., SICLOCK TC 400 or corporate GPS NTP server).

  2. Strict CPU and Memory Reservations (Zero Overcommitment):
    * Real-time SCADA databases (Microsoft SQL Server in WinCC and Process Historian) cannot tolerate memory ballooning or CPU throttling.
    * Configure 100% RAM Reservation: The entire assigned memory (e.g. 16 GB for OS Server) must be locked in physical host RAM.
    * Configure vCPU Reservations: Ensure sufficient MHz is reserved to prevent CPU starvation during heavy process alarm bursts.

Virtual Machine Sizing and Configuration Matrix

Virtual Machine RoleRecommended vCPUReserved RAMVirtual NICs (VMXNET3)Disk ProvisioningTarget PCS 7 LicenseOS Server (Redundant Pair)4 vCPU16 GB (100% Reserved)2x (1 Terminal, 1 Plant Bus)Thick Provision Eager ZeroedStandard OS Server + RedundancyEngineering Station (ES)4 to 8 vCPU16 to 32 GB2x (1 Terminal, 1 Plant Bus)Thick Provision Lazy/Eager ZeroedStandard PCS 7 Engineering SuiteOS Client (Standard)2 vCPU4 to 8 GB1x (Terminal Bus)Thin or Thick ProvisionedStandard OS Client LicenseProcess Historian (PH)8 to 16 vCPU32 to 64 GB (100% Reserved)2x (1 Terminal, 1 Dedicated Storage)Thick Provision Eager Zeroed (RAID 10)Process Historian Server + POInformation Server (IS)4 vCPU16 GB1x (Terminal Bus / Office LAN)Thick ProvisionedInformation Server Basic + Clients

Verification

  1. In VMware vSphere Client, verify the OS Server VM shows:
    * Memory Reservation: Equal to configured RAM size.
    * Time Synchronization: 'Synchronize guest time with host' is UNCHECKED.
  2. In the OS Server VM, open Command Prompt and run w32tm /query /status; confirm synchronization to the external NTP master clock with jitter < 10 ms.
  3. In Simatic Shell on the OS Server, verify both the Terminal Bus adapter and Plant Bus adapter show active communication.
  4. Launch WinCC Runtime on the virtual OS Server; verify dynamic process tags update continuously from the physical CPU 410-5H.
  5. In ESXi host performance monitors, confirm zero CPU contention or memory ballooning during peak runtime operation.

Limitations and Operational Precautions

  • Redundant Partner Host Placement: Redundant OS Server pairs (Server 1 and Server 2) must never be hosted on the same physical ESXi server. They must reside on separate physical host chassis with redundant power feeds to prevent single-point-of-failure plant blackouts.
  • No VMware Snapshots in Runtime: Never take quiesced VMware snapshots of active production WinCC OS Servers or Process Historian VMs while runtime is logging to SQL Server. Snapshot disk locking can cause SQL database dismounts and archive corruption.
  • Commercial and Licensing Notice: Software licenses for virtualized PCS 7 stations are identical to physical stations. However, special communication licenses (e.g. SIMATIC NET SOFTNET-IE S7 REDCONNECT VM, MLFB 6GK1704-0HB14-0AC0) are required for virtualized fault-tolerant connections. Confirm requirements with an authorized distributor.

Engineer FAQ

Can I use Microsoft Hyper-V to run PCS 7 OS Servers?

No. Siemens officially validates and supports only VMware vSphere ESXi for PCS 7 OS Servers. Hyper-V is not released for PCS 7 server infrastructure.

How do operators interact with virtualized OS Clients?

Operators utilize rugged industrial thin clients (such as SIMATIC ITC) or standard PCs connecting to the virtual OS Client via Remote Desktop Protocol (RDP) or VMware Horizon View.

Can I use VMware vMotion to migrate an active OS Server between hosts?

Yes, vMotion is supported for maintenance, provided SOFTNET-IE S7 virtual networking is used and shared SAN/NAS storage performance meets Siemens I/O latency requirements.

Technical References

Related Articles

Related Tags

  • Virtualization
  • VMware ESXi
  • SIVIRT
  • OS Server
  • SOFTNET-IE
  • PCS 7 V8.1
6 respuestas