A PCS 7 client-server system uses different network connections for controller communication, operator access and OS Server redundancy. Understanding these connections comes before choosing switches or assigning addresses.
This first article explains the bus roles, then compares a redundant single Plant Bus with a dual Plant Bus distributed across two rooms. The examples use two OS Servers, two OS Clients, one Engineering Station (ES) and one redundant AS 410-5H.
What are the Plant Bus, Terminal Bus and OS redundancy connection?
The Plant Bus (PB) is the Ethernet network connecting the automation systems to OS Servers and the ES. It carries AS-OS communication, including process values, alarms and operator commands, and provides the ES with access to the AS for engineering and diagnostics. [1]
The Terminal Bus (TB) connects OS Clients to OS Servers and supports communication between PCS 7 PC stations, including engineering access to the servers. An OS Client obtains process data from its OS Server. In this client-server architecture, the client therefore needs a Terminal Bus connection and does not need its own Plant Bus connection to the AS. [1]
The OS redundancy connection, also called the redundancy bus, is the connection configured between the two OS Server partners for redundancy operation. It is a separate communication relationship from client-server traffic and AS-OS communication. Its detailed traffic paths and configuration will be covered in Part 3. [3]
For example, an operator command follows this logical path: OS Client → Terminal Bus → OS Server → Plant Bus → AS. The return path provides the client with updated process information through the server.
Why use a separate Plant Bus?
The AS and OS Servers need a network to exchange process information and commands. In PCS 7, this network is the Plant Bus. Separating it from the Terminal Bus allows AS-OS communication to be sized, maintained and protected independently of OS Client traffic. [1]
This distinction also makes failures easier to understand. If an OS Client loses its Terminal Bus connection, that client loses access to the server. If an OS Server loses its Plant Bus communication, it may remain reachable by clients while its AS data becomes unavailable or stale. Neither event, by itself, means that the AS has stopped executing its control program.
PCS 7 networks in the Purdue model
The Purdue model provides a functional view of an industrial system. In a simplified PCS 7 example, the AS performs basic control, while OS Servers, OS Clients and engineering functions occupy the supervisory environment. The Plant Bus connects these functions; the Terminal Bus mainly supports communication within the supervisory environment. [2]
This is a useful orientation, rather than a physical cabling plan. A Purdue level does not automatically define a VLAN or require a firewall at every boundary. Security zones and permitted communication flows still need a design for the actual system. [2]
The reference system and naming convention
The OS Servers run as VMs on two separate ESXi hosts. Host 1 normally runs OS Server A and the ES; Host 2 runs OS Server B. The two OS Clients are separate stations on the Terminal Bus. The AS 410-5H contains CPU 0 and CPU 1, with one CP443-1 per CPU in the main examples. [3, 4, 5]
Both concepts use two physical uplinks per host for each Plant Bus. A single PB therefore needs two PB uplinks per host; a dual PB needs four. The ES VM shares its host's physical uplinks. Adding an ES vNIC does not create another physical switch cable.
The switch suffix identifies location: A = IT/OT Room 1; B = IT/OT Room 2. Numbers identify switches. In the dual concept, ISW-PB-01A and ISW-PB-01B belong to PB1, while ISW-PB-02A and ISW-PB-02B belong to PB2. The room names and device tags are illustrative.
Single Plant Bus: one network with redundant connections
The single-PB example uses ISW-PB-01A and ISW-PB-02A, both SCALANCE XR526-8 switches in IT/OT Room 1. They form one common Plant Bus. One CP from each AS subsystem connects to a different switch.
Each host has one physical uplink to each switch. The reference uses active/standby NIC teaming on a standard vSwitch: Host 1 prefers ISW-PB-01A; Host 2 prefers ISW-PB-02A. A failed host cable or uplink adapter has an alternative connection within the same PB. The AS communication must also have its configured alternative CP path. [3, 4, 10]
The switches have two 10GbE interconnections configured as one LACP aggregate. A member-link failure leaves the second member available. A complete switch failure still removes every endpoint attached only to that switch; the host and AS alternatives handle different parts of the recovery.
LACP and MRP solve different connection problems
LACP groups parallel links between the same two logical peers into one connection. MRP manages an alternate path around a ring: the ring manager prevents a forwarding loop during normal operation and changes the forwarding path after a ring fault. The two-switch example uses LACP for its inter-switch links; a larger distributed switch network may instead justify an MRP ring. These are topology choices, not interchangeable names. [7]
Host-side LACP is another decision. A standard vSwitch does not support LACP; it is available on a vSphere Distributed Switch. A LAG also cannot simply span two independent switches because an inter-switch aggregate exists between them. The reference therefore uses independent active/standby host uplinks, with no host LAG. [10, 11]
Dual Plant Bus: PB1 and PB2 across two rooms
The dual concept uses four XR526-8 switches. Each room contains one switch for PB1 and one for PB2. PB1 and PB2 remain separate Plant Bus networks, with separate TCP/IP subnets in this example. There is no switching link between them. Each same-PB switch pair has its own two-member 10GbE LACP aggregate.
Host 1 is in Room 1 and Host 2 is in Room 2. Each host has two physical uplinks to PB1 and two to PB2, one to each switch of the corresponding network. Each PB uses its own teaming policy and vSwitch. The local-room copper uplink is preferred; the other-room 1GbE fiber uplink is standby. This reference requires compatible optical host adapters and switch optics. [3]
CPU 0 and CP-0 are in Room 1, with CP-0 connected to PB1 at ISW-PB-01A. CPU 1 and CP-1 are in Room 2, with CP-1 connected to PB2 at ISW-PB-02B. After loss of Room 1, Host 2 and CP-1 still have a local PB2 connection. After loss of Room 2, Host 1 and CP-0 still have a local PB1 connection.
A surviving PB path is one part of room-loss resilience. The surviving OS Server, AS subsystem, Terminal Bus, power and storage must also remain usable. Inter-room fibers need physically diverse routes, and H-system synchronization must be designed for the separation. The network drawing alone does not establish a complete room-loss solution. [4]
Two CPs or four CPs: what changes?
The CP count describes the AS attachments. It is separate from the number of switches and host uplinks.
| AS arrangement | Single PB | Dual PB |
|---|---|---|
| Two CPs in total: one per CPU | Both AS subsystems attach to the common PB | In this example, CPU 0 attaches to PB1 and CPU 1 to PB2 |
| Four CPs in total: two per CPU | Additional CP paths may be configured within the common network | Each CPU has its own CP connection to PB1 and its own CP connection to PB2 |
Consider maintenance on the Room 2 AS rack: CPU 1 and its CPs are de-energized. If CPU 0's PB1 connection then fails, the depicted two-CP arrangement has no remaining AS-OS path. With four CPs, CPU 0 can still have a separate physical attachment to PB2. The additional CPs are useful when a second communication fault during subsystem maintenance must be addressed. [9]
The main drawings retain two CPs, following the two-way ESXi communication example in the Siemens virtualization guide. Four physical CPs do not, by themselves, establish four-way S7 communication. The OS communication software, project configuration and released version combination must support the intended paths. [3, 4]
The two Ethernet ports on a CP443-1 EX30 belong to its integrated switch. They must not be used as independent PB1 and PB2 interfaces: doing so would bridge the networks. [6]
Switch-port budgets for the complete PB connections
The budgets below count physical switch ports, not VM adapters. They include every depicted PB attachment, both inter-switch LACP members and one reserved management data port per switch. Management uses an isolated management VLAN. The reference does not assume a separate out-of-band management interface.
| Concept / switch | Host ports | CP ports | LACP ports | Management port | Used ports |
|---|---|---|---|---|---|
| Single PB: ISW-PB-01A | 2 | 1 | 2 | 1 | 6 |
| Single PB: ISW-PB-02A | 2 | 1 | 2 | 1 | 6 |
| Dual PB: ISW-PB-01A | 2 | 1 | 2 | 1 | 6 |
| Dual PB: ISW-PB-01B | 2 | 0 | 2 | 1 | 5 |
| Dual PB: ISW-PB-02A | 2 | 0 | 2 | 1 | 5 |
| Dual PB: ISW-PB-02B | 2 | 1 | 2 | 1 | 6 |
The single concept consumes ten PB data ports and two management ports across its switches. The dual concept consumes eighteen PB data ports and four management ports. Moving to four CPs in the dual concept adds one CP port on ISW-PB-01B and one on ISW-PB-02A, bringing every switch to six used ports.
The ES adds no PB switch port because it is a VM sharing Host 1's uplinks. A separate physical ES would need its own connections and a revised budget. OS Client, Terminal Bus, OS redundancy, host-management and storage connections terminate on their corresponding infrastructure; they are not hidden inside these PB counts. Parts 2, 3 and 5 will budget those interfaces.
The single concept uses four copper ports and two 10GbE SFP+ slots per switch. In the dual concept, each switch needs one local-host copper port, one remote-host 1GbE optical port, two 10GbE optical LACP ports and one copper management port; the CP adds another copper port on ISW-PB-01A and ISW-PB-02B. Each dual-PB switch therefore needs three simultaneously usable optical interfaces, not just the two used by the inter-switch aggregate.
For the inter-switch links, the single concept needs four 10GbE SFP+ modules and two fiber links; the dual concept needs eight modules and four fiber links. The dual concept also has four remote-host fiber links, requiring eight compatible 1GbE optical transceivers across the hosts and switches. Select host adapters, optics and fiber types as one compatible set. A two-member LACP aggregate must carry the required load on its surviving member. [7, 8]
Minimum switch requirements and selected models
For these small examples, an eight-port managed switch is the compact starting point: up to six used ports plus two spare ports. A complete project must also reserve the actual copper/optical port mix and enough capacity for additional ASs or hosts. Two spare ports are not a plant-wide expansion allowance.
The switch needs managed Layer 2 forwarding, LACP support, compatible endpoint speeds, appropriate optical interfaces, redundant power arrangements, event diagnostics and configuration backup. Feed redundant supplies from independent sources. The figures use 1GbE host access and two 10GbE inter-switch links per PB; Layer 3 routing is not required for these PB paths.
| Selection | Model | What changes or stays the same |
|---|---|---|
| Compact Gigabit option for the single-room case | SCALANCE XC206-2SFP G | Six Gigabit copper ports and two Gigabit SFP slots. It changes the inter-switch links to 1GbE after a load check. Its two SFP slots do not satisfy the dual reference's three-optical-port requirement. [12, 13] |
| Layer 2 rack alternative | SCALANCE XR326-8 | A rack platform with copper access and eight 1/10Gbps SFP+ slots for the 10GbE link choice. Routing is not needed for this example. [14] |
| Selected upper-tier reference | SCALANCE XR526-8 | The XR-500 model used throughout the drawings: 24 copper access ports, two additional multigigabit copper ports and eight 1/10Gbps SFP+ slots. Select the required redundant-supply variant. [8] |
XR526-8 provides substantially more ports than the reference consumes. It is a consistent rack-mounted platform with room for optical expansion, rather than the minimum hardware needed for six connections. XR526-8 and XR526-8C have different port maps. Final selection requires the exact order number, supply variant, firmware, supported optics and PCS 7 release. [8]
Plant Bus link speeds do not define a vSAN or other storage-network requirement. Storage capacity, resynchronization traffic and host compatibility need their own assessment.
Choosing the architecture from operating requirements
| Operating requirement | What the single-PB example provides | What the dual-PB example adds |
|---|---|---|
| One equipment room; tolerate a host cable or one switch failure | Alternative host uplinks and the surviving AS attachment, using two switches | A second PB is optional if network-wide and room-wide outages are outside the requirement |
| Isolate an entire Plant Bus for planned maintenance while retaining an AS-OS path | The common PB cannot be fully isolated while it remains the only AS-OS network | PB1 can be isolated while PB2 retains a path to CP-1; the released connection configuration must provide this alternative |
| Retain an AS-OS path after loss of either equipment room | The depicted one-room installation does not cover room loss | A local host, PB switch and AS attachment remain in the other room; application, power, TB and storage availability must also be provided |
| Retain AS communication during maintenance of one AS rack plus loss of the remaining CPU's PB1 attachment | No second CP remains on the running CPU in the main example | The main two-CP dual design also lacks that attachment; consider two CPs per CPU, with one on each PB |
For a small system with one equipment room and an accepted common-network outage risk, the single concept is the simpler candidate. For a process that must retain operator access during a complete PB maintenance isolation or room outage, the dual concept is the relevant starting point. The extra requirement may concern network separation, room separation, additional CPs or all three; each needs its own provision.
Mapping the design through ESXi
Each OS Server VM needs a Plant Bus vNIC for each PB it uses. The dual-PB ES VM also has separate PB1 and PB2 vNICs for its engineering access. Host-side physical teaming protects the cables within each PB; the two Plant Buses remain independent. [3]
A host failure removes the VMs running on it until the relevant recovery mechanism acts. The partner OS Server is therefore placed on the other host. The ES is a single engineering station in this example and is not an additional redundant OS Server. Its placement and recovery are engineering-service decisions.
Management access and the next parts of the series
Reserve one copper management connection on every PB switch and connect it to the management infrastructure using its own VLAN. Keep PB1 and PB2 process traffic isolated from that VLAN and from each other. The shared administration network is still a common management dependency.
Use the management connection to configure, diagnose and back up the switch. Its management IP is not automatically the AS gateway. The shown PB communication stays within the corresponding local subnet; routing and management-access controls will be designed in Part 6.
Terminal Bus resilience, the OS Server redundancy connection and ES access must be visible in the overall architecture, even when the current drawing expands only PB cables. Switch-link redundancy, host NIC teaming, S7 communication paths and OS Server redundancy each protect a different part of the service.
Commissioning checks for these two examples
Before accepting either design, apply faults to the actual configured system and record the operator-visible result:
| Test | Required evidence |
|---|---|
| Disconnect the preferred PB uplink of one host | Its VMs use the standby uplink; record the duration of stale AS data and the effect on commands and alarms |
| Disconnect one inter-switch LACP member | The remaining member carries the required traffic without overload |
| Isolate PB1 in the dual concept | The OS retains the configured AS-OS relationship through PB2, not merely an IP response from a surviving switch |
| Stop one OS Server VM | Clients continue through the partner server; assess alarm, archive and command behavior in the OS redundancy test scope |
| For a room-loss requirement, remove the Room 1 services in a controlled test | Verify the surviving OS, AS, TB, power and storage dependencies together; do not substitute a single switch power-off test |
Define acceptable interruption times before the test. Restoring a cable must also restore the intended redundancy state without unexpected traffic paths. Detailed commissioning procedures will be developed in Part 7.
The next article is Terminal Bus Design. Parts 3 and 4 cover OS Server Redundancy and Engineering Station Connectivity. Part 5 follows the paths through ESXi, Part 6 develops the VLAN/IP and switch configuration, and Part 7 tests the resulting system.
Sources and design scope
The system labels, switch placement and capacity choices are original worked examples. The references support the communication roles and hardware features; exact PCS 7, SIMATIC NET, hypervisor and device compatibility must be established for the project release.
- Siemens, Operator Station (V10.0). Configuration Manual, 07/2024, A5E52520058-AA. Sections 4.2-4.3: client-server roles and bus connections. Official PDF
- NIST SP 800-82 Rev. 3. Guide to Operational Technology (OT) Security, 09/2023. Section 5.2.3.1 and Figure 16: functional models and segmentation context. Official PDF
- Siemens, PCS 7 Virtualization - Project Engineering and Configuration (V10.0 SP1). Entry 109987369, 04/2025. Sections 4.1.5, 4.5.3, 4.5.5-4.5.6 and 5.1: host networks, OS redundancy, AS communication and engineering. Official PDF
- Siemens, High Availability Process Control Systems (V10.0). Function Manual, 07/2024, A5E52546694-AA. Sections 4.3.1 and 5.3.4: room separation and Plant Bus communication concepts. Official PDF
- Siemens, SIMATIC PCS 7 Standard Architectures. Entry 109973672, V4.2, 05/2025. Network and AS architecture examples. Official PDF
- Siemens, CP443-1 EX30. Equipment Manual, 12/2015, C79000-G8976-C255-04. Sections 2.7 and 5.2: integrated Ethernet switch. Used for this hardware characteristic. Official PDF
- Siemens, SCALANCE Layer 2 / Layer 3 Web Based Management V1.3. 11/2024, C79000-G8976-C661-04. MRP and link-aggregation operation. Official PDF
- Siemens, SCALANCE XR-500 Operating Instructions. 10/2025, C79000-G8976-C692-04. XR526-8 interfaces and supply variants. Official PDF
- Siemens, Catalog ST PCS 7, update 05/2021. AS 410H Plant Bus communication: one CP per subsystem and additional interfaces across redundant networks. Used for the AS connection concept. Official PDF
- Broadcom, Example Configuration of LACP on VMware, Cisco, HP, Dell switches. Article 324490: standard/distributed switch distinction. Official documentation
- Broadcom, Host requirements for link aggregation in ESXi. Article 324555: physical peer and virtual-switch requirements. Official documentation
- Siemens, SCALANCE XC-200 Operating Instructions. 06/2025, C79000-G8976-C442-16. Section 9.7: XC206-2SFP G interfaces and power. Official PDF
- Siemens, SCALANCE Layer 2 Switches Command Line Interface V4.4. 02/2023, C79000-G8976-C361-14. Link aggregation for the documented families. Official PDF
- Siemens, SCALANCE XR-300 Operating Instructions. 04/2024, C79000-G8976-C586-05. XR326-8 interface and supply variants. Official PDF