Safely Initializing Redundant SIMATIC BATCH Standby Servers During Active Production

Starting Batch Runtime on a redundant SIMATIC BATCH Standby Server (Server 2) while production recipes are actively executing on the Master Server (Server 1) is a standard, fully supported operational procedure designed for high-availability batch plants. When Batch Server 2 is started from an uninitialized state (Maintenance or Manual start mode), it establishes communication with Master Server 1 across the Terminal Bus, initiates an online database synchronization protocol, copies active batch control states, and seamlessly transitions to the Standby state without interrupting active recipe execution. However, engineers must strictly avoid issuing "Restore Database" or downloading modified engineering projects during active batch execution.

Redundant SIMATIC BATCH Server Architecture

SIMATIC BATCH supports redundant server architectures to ensure that recipe control, unit allocation, phase execution, and electronic batch records (EBR) survive hardware or software server failures. In a redundant pair:

Master Batch Server (Server 1): Actively executes recipes, communicates with AS interface blocks (BSTATUS, IEPH, IEOP), manages unit allocations, and records batch events into the local Microsoft SQL Server batch database.
Standby Batch Server (Server 2): Mirrors the state of the Master server. If configured in Manual Start Mode (Maintenance), Server 2 remains passive until explicitly started by plant personnel.

When Server 2 displays the status Uninitialized and Batch Runtime is stopped following server maintenance or a reboot, operators frequently hesitate to start Runtime, fearing that starting the secondary server might reset active recipes, release allocated equipment, or bump Master Server 1.

Standby Initialization and Database Synchronization Flow

The startup behavior of SIMATIC BATCH Server is governed by an automated synchronization state machine:

Phase / StepServer 2 Internal StateMaster (Server 1) InteractionImpact on Active ProductionInitial StateUninitialized / StoppedActive Master controlling recipesZero (Master operates autonomously)Startup TriggeredStartingServer 2 queries Terminal Bus for active MasterZero (Master acknowledges secondary connection)Database SynchronizationSynchronizingMaster transfers runtime batch DB and recipe statesBrief network transfer; recipe execution continuesOnline StandbyStandby (Redundancy OK)Continuous real-time event mirroringFull redundancy achieved; zero process interruption

Because Master Server 1 is already established as the active controller of the AS batch blocks, Server 2 will never attempt to seize Master status during startup unless Master Server 1 fails. Instead, Server 2 acts exclusively as a client requesting a fresh state snapshot from Server 1.

Safe Operational Sequence for Starting Batch Server 2

To safely bring Batch Server 2 online while production is actively running on Server 1:

Verify Master Server Health:
- On Batch Server 1, check the Batch Launch Coordinator icon in the Windows notification tray.
- Confirm that Batch Server 1 status is Master and that active batches are executing normally.
- Verify that WinCC Runtime on the OS Server pair is fully operational and synchronized.
Check Network Connectivity:
- On Batch Server 2, verify that Simatic Shell displays Batch Server 1 with healthy communication.
- Ping Batch Server 1 by hostname to confirm low-latency Terminal Bus response.
Initiate Batch Runtime on Server 2:
- Right-click the Batch Launch Coordinator icon in the Windows notification area on Server 2.
- Select Start Batch Runtime (or open SIMATIC BATCH Control Center and click the Start Runtime button).
- Observe the status transitions: Starting -> Synchronizing -> Standby.
Confirm Redundancy Handshake:
- Open Batch Control Center on an OS Client or Server 1.
- Check the System Status view; verify that Server 1 is listed as Master and Server 2 is listed as Standby.

Critical Operational Constraints During Live Production

While starting Batch Runtime is completely safe, specific administrative actions are strictly forbidden while batches are running:

DO NOT Execute 'Restore Database': Restoring a backup .sbx or SQL archive onto Server 2 while Server 1 is in production can overwrite active recipe tracking data.
DO NOT Download Batch Engineering from ES: Downloading a new BATCH recipe or unit configuration from the Engineering Station during live production will force a download lock or abort running batches.
DO NOT Force Server 1 into Maintenance: Never stop Runtime on Server 1 until Server 2 has completely reached the Standby state and database synchronization has completed 100%.

Verification

To verify successful standby synchronization without process disruption:
1. In SIMATIC BATCH Control Center, open the 'Control' view and inspect running batches; confirm that recipe phase steps, timers, and transition conditions continue advancing without pausing.
2. In the Windows Event Viewer on Server 2 under Application logs, locate the SIMATIC BATCH event source; verify event logs confirming successful database replication from Master Server 1.
3. On Batch Server 2, inspect the Batch Launch Coordinator icon; confirm that the hover text reads SIMATIC BATCH Server: Standby.

Limitations and Operational Precautions

If the Terminal Bus network bandwidth is severely congested or experiencing high packet loss, database synchronization between Server 1 and Server 2 may take extended time (several minutes). Ensure that large file downloads or OS project compilations are not conducted simultaneously over the Terminal Bus while Batch Server synchronization is taking place.

Engineer FAQ

Can starting Batch Server 2 cause active batches to stop?

No. SIMATIC BATCH is engineered so that starting a secondary server triggers a synchronization request. The running Master server remains in absolute control of recipe execution.

What happens if Server 1 fails while Server 2 is synchronizing?

If the Master fails before synchronization completes, Server 2 cannot achieve seamless failover. Therefore, ensure Server 1 is physically and electrically stable before starting Server 2.

Why was Server 2 in 'Manual (Maintenance)' start mode?

Manual start mode is typically configured during planned plant maintenance or software patching so that the server does not automatically attempt to start and synchronize until maintenance engineers verify system health.