Configuring Wonderware InTouch Redundant Server with S7-400

Configuring Wonderware InTouch Redundant Server with Siemens S7-400 over Ethernet

Plant-floor HMI/SCADA deployments frequently demand that the supervisory layer tolerate a single point of failure. A typical configuration uses two I/O Server hosts polling the same PLC, with the InTouch HMI switching from a primary to a backup access path on communication loss, then re-attaching to the primary once it recovers. This reference documents the engineering steps, parameter values, and verification procedures for building that redundant architecture with Wonderware InTouch 10.1, Archestra MMC 5.2 R2, the DASSIDirect and FSGateway I/O Servers, and a Siemens SIMATIC S7-400 controller on Industrial Ethernet.

1. Reference Architecture

The logical topology separates the data-acquisition tier (DA Server) from the presentation tier (InTouch). The S7-400 exposes its data over the ISO-on-TCP protocol (RFC 1006) on its built-in PROFINET/Industrial Ethernet port. Two Windows hosts run an instance of the same I/O Server pointed at the same PLC; an InTouch application on a third node consumes data through the Archestra framework and switches to the backup server when the primary disappears from the namespace.

Figure 1 — Logical topology: dual DA Server hosts polling the S7-400; InTouch client uses one Access Name with a primary and a backup node.

2. Prerequisites and Licensing

Before installing components, validate the licenses and the operating system level. InTouch 10.1 and Archestra 5.2 R2 were validated on Windows Server 2003 in the source architecture; for new deployments, Schneider Electric's compatibility matrix lists Windows Server 2016 / 2019 as supported by InTouch 2020 and later, which is the recommended path for greenfield work. If you must remain on the 10.1 codebase, lock the host OS to Windows Server 2003 R2 x86 and disable Windows Firewall, exactly as the reference plant-floor configuration required.

3. Network and Operating System Configuration

All three nodes must share the same subnet and belong to the same Windows workgroup. Domain membership is acceptable on modern platforms, but for the 10.1 / Server 2003 combination the workgroup model is the most reliable and matches the validated configuration.

1. On each host, open Control Panel → Network Connections → Local Area Connection → Properties → Internet Protocol (TCP/IP) and assign the static addresses shown above. Disable the second NIC if one is present to avoid ambiguous routing.
2. Disable Windows Firewall on all three nodes. For Server 2003 this is Control Panel → Windows Firewall → Off. For Server 2016+ use the PowerShell command Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False only inside a segmented industrial enclave.
3. Open a command prompt on PC-3 and verify the round trip to the PLC and to both DA Server hosts:

   ping 172.16.254.1 -n 10
   ping 172.16.254.5 -n 10
   ping 172.16.254.4 -n 10

   The reference plant reported sent = received with an average of 1 ms on the loopback-segment LAN. Anything above 5 ms on a switched /24 indicates duplex or STP issues that must be resolved before commissioning redundancy.
4. Confirm Windows network discovery is enabled and that the workgroup names match exactly (case-sensitive on older Windows versions).

4. Selecting the I/O Server: DASSIDirect vs FSGateway

Both products can read data from a S7-400, but they differ in protocol coverage, redundancy model, and tooling.

Use DASSIDirect when both server hosts will be permanently active and the topic definitions are mirrored. The Archestra platform coordinates which instance is the active publisher, and InTouch simply subscribes to the logical topic name. Use FSGateway when the deployment is more loosely coupled; redundancy is then provided at the InTouch layer by configuring a primary and a backup Access Name that point to the two FSGateway instances, and InTouch will perform the cutover when the primary's $AccessName fails to update within the configured timeout.

5. Configuring the DASSIDirect DA Server for S7-400

Repeat this section on both PC-1 and PC-2. Only the host IP and the topic name differ.

1. Install DASSIDirect from the Wonderware installation media. The installer registers the service ArchestrA.DASDirect.3 (version-dependent) and the configuration shortcut in the Start menu.
2. Open the DASSIDirect Configuration utility. Create a new Port and select the S7-300/400 TCP/IP driver (also called TCP/IP V4 or S7 TCP/IP depending on the build).
3. Configure the port with the values below. These settings are the conservative defaults validated for S7-414/416 CPUs.

4. Add the items to be polled. The S7 address syntax is DB<n>,BYTE<offset>.BIT<bit> for bits and DB<n>,REAL<offset> for floating-point values, for example:

   DB100,BYTE0.0   ; discrete bit 0 in DB100
   DB100,INT2      ; 16-bit signed at byte 2 in DB100
   DB100,REAL4     ; 32-bit IEEE-754 at byte 4 in DB100

5. Save the configuration and start the DASDirect service. Confirm that the topic transitions to Active in the System Management Console of Archestra.
6. On the engineering node, register the two remote servers under Archestra MMC → System Management Console → DASSIDirect → Server and confirm both topics report Good.

6. Configuring FSGateway 2.0 for S7-400 Ethernet

FSGateway is the simpler path and was the route originally exercised in the reference architecture. Install it on PC-1 and PC-2 with the same procedure, then create a device and a topic per host.

1. Start the FSGateway Manager and add a new Siemens S7 TCP/IP device.
2. Enter the PLC IP 172.16.254.1, rack 0, slot 2. The default port is 102.
3. Set the scan rate to 250 ms and the timeout to 1500 ms. These are the same as the DASSIDirect defaults so that a like-for-like swap is possible.
4. Define the topic name as S7400_PRIMARY on PC-1 and S7400_BACKUP on PC-2.
5. Save and start the FSGateway service. Verify in the Manager that the topic status is Active with valid quality.

FSGateway does not coordinate failover at the server level. Redundancy is provided in InTouch by configuring two Access Names (or a single Access Name with a primary and a backup server) and letting the runtime detect when the primary stops publishing.

7. Building the InTouch Access Name with a Redundant Source

The Access Name is the glue between an InTouch tag and an I/O Server topic. Configuring redundancy is a property of the Access Name, not of individual tags.

1. In WindowMaker, open Special → Access Name and click Add.
2. Name the Access Name S7_Access.
3. Set Application to DAServer for DASSIDirect or FSGateway if you went with the simpler path.
4. Under Topic Name, enter S7400_PRIMARY for the primary path. If your I/O Server uses a logical Server Name (e.g. \\PC1\DASDirect), enter it here.
5. If you want a true redundant Access Name, click Add → Secondary and define a second path to the backup I/O Server, typically \\PC2\DASDirect with the same topic name S7400_PRIMARY if the backup server mirrors the topic, or S7400_BACKUP if you kept distinct names per host.
6. Enable Use Backup and set the failure timeout. The recommended starting value is 2000 ms, which gives the S7 telegram and the DA Server enough room to declare the link dead without false switches on short network blips.

Once the Access Name is defined, all tags that reference it will switch to the backup path automatically. Use the built-in attribute $AccessName on a discrete or memory tag to expose the current path name to scripts and the operator, for example to drive a banner that reads "Connected to PRIMARY" or "Connected to BACKUP".

7.1 Detecting Failover in InTouch Logic

Wire the quality attribute of a memory tag to a script to log each transition. A minimal example in the InTouch QuickScript editor:

' Application script — runs once at startup
AddItem("\\Sec\Status", "Memory", 0);

' Data-change script on tag \TagQuality.PLC_Heartbeat
IF PLC_Heartbeat.Quality <> 192 THEN
    LogMessage("Access Name degraded, switching to backup path.");
ELSE
    LogMessage("Access Name healthy on " + $AccessName("S7_Access"));
END IF;

Quality 192 (0xC0) is the OPC Good code. Anything else warrants operator attention. A non-exhaustive mapping is shown below for the most common values you will see during failover.

8. Deploying WindowsViewer Standalone on the Client Node

PC-3 is the operator node. It must run only the InTouch runtime (WindowViewer), not the development environment (WindowMaker). The reference architecture confirmed that installing only the runtime prevents operators from opening the application source and editing it.

1. On the engineering node, run the InTouch Application Publisher. Select the application, choose Deploy to remote node, and target \\PC3\InTouch.
2. On PC-3, install only the InTouch runtime components. The custom setup screen allows the engineer to deselect WindowMaker, the database manager, and the application developer tools.
3. Confirm the registry value HKLM\SOFTWARE\Wonderware\InTouch\InstallType reads Viewer and not Developer. This guarantees that no development shortcuts are present on the operator's desktop.
4. Configure PC-3 to auto-launch the deployed application. Add a shortcut to view.exe /<appname> in the Startup group of the operator's profile, or use the InTouch Startup utility for service-style launch.
5. Lock down the local disk. Disable the USB ports, set NTFS permissions on C:\InTouch to Read / Execute for the operator group, and configure a screen-saver password to discourage tampering.

9. Failover Detection, Switchback, and Tuning Parameters

The InTouch runtime monitors each Access Name's last successful update timestamp. When the primary path exceeds its configured timeout without a successful read, InTouch marks the Access Name as degraded and starts consuming data from the backup path. When the primary path returns to health, the runtime switches back automatically. The decision points and the knobs that control them are listed below.

Set the Switchback delay to at least 5 seconds in redundant networks. A primary that has been re-started may take that long to register all its topics and become ready to be polled; without the delay, InTouch will attempt to switch back, fail because the topic is still warming up, switch to backup, and oscillate.

10. Verification Procedures and Acceptance Tests

Every redundant HMI project must be commissioned with a scripted failover test. The acceptance sequence below is derived from the reference architecture and is the minimum bar to declare the system production-ready.

1. Connectivity baseline. From each Windows host, ping the other three IPs for 60 seconds. All four must show 0% loss with average RTT below 5 ms on a switched /24.
2. Single-server health check. Stop the DA Server service on PC-2. PC-1 must continue to deliver tags. Restart the service on PC-2 and confirm both topics report Good in the System Management Console.
3. Primary-down failover. Stop the DA Server on PC-1. Within timeout + 1 s the operator screen on PC-3 must continue updating values sourced from PC-2. Confirm by reading a moving tag (e.g. a counter incremented in OB35 of the S7-400).
4. Primary-up switchback. Restart the DA Server on PC-1. Within switchback delay + timeout the Access Name must show S7400_PRIMARY again and tag quality must return to 192.
5. Network pull test. Disconnect the LAN cable from PC-1. The behaviour must be identical to stopping the service: failover to PC-2. Reconnect the cable; switchback must occur cleanly.
6. PLC pull test. With both servers running, power-cycle the S7-400. Both servers must log a device failure, recover automatically when the CPU is back, and InTouch must not require operator intervention.
7. Concurrent heavy load. Force a 100% CPU load on PC-1 (for example with BurnInTest) and verify that failover still occurs within the configured timeout. This catches DA Server threads starved of CPU, which is one of the most common real-world causes of unexplained failover.
8. Operator node smoke test. Confirm that on PC-3, WindowMaker cannot be launched and that the deployed application starts under the operator's restricted account without administrative prompts.

11. Troubleshooting Matrix

12. Field-Proven Caveats

• Workgroup vs. domain: With InTouch 10.1 and Windows Server 2003, the workgroup model is the most reliable. If the host must be domain-joined, ensure the InTouchApp share and the view account have read/execute rights for the operator group on every node, otherwise application deployment from the engineering station will fail intermittently.
• Virtual PC hosts: The reference architecture runs all three Windows nodes on a single VMware Workstation / Hyper-V host for testing. This is acceptable for a lab validation; for production, each node should run on physically separate hardware (or at least on separate hypervisors) so a host failure does not take down both servers.
• CPU load on the DA Server host: DASSIDirect and FSGateway are both single-threaded for the protocol driver. A noisy-neighbour application (anti-virus scan, Windows Update) can stall the driver thread long enough to trigger a false failover. Exclude the C:\Program Files\Wonderware directory from real-time AV scanning.
• STEP7 coexistence: Never leave STEP7 connected with a PG link to the S7-400 while commissioning redundancy; the PG connection occupies a slot that the OP connection of the second server may need. Open STEP7, download the project, disconnect, and re-test.
• License server: Schneider Electric's licensing is host-bound for DA Servers. Confirm the license is registered to the host's HostID (MAC address or SSD volume serial) and not to a USB dongle that may be ejected by a careless operator.

FAQ