InTouch Classic Architecture Guide

Windowviewer

Runtime environment for InTouch.  After an application is developed, it can be compiled into windowviewer.  Once compiled, the logic, I/O and other aspects of the application are running and the application becomes available. 

Device Integration

Device integration is achieved through Data Acquisition Servers (DA Servers).  These DA Servers are independent software applications of InTouch and are typically hardware specific.  Usually it is either the PLC Brand or communication protocol used for PLC communication that determines what DA Server is used.  InTouch interacts directly with DA Server reading / writing data to the PLC. 

 

Concepts

 

Intouch Architecture

Architectures for Wonderware InTouch typically are driven by multiple factors.  These can range from the number of users / operators that will use the application to the manufacturing process / environment that the application is deployed within.  When developing an architecture for a system one should review specific application requirements.  These requirements should include items such as the number of clients the implementation will require, the number of IO (data points from PLC's) that will be required, physically where will these clients be located and do these locations have the necessary network connections to other systems. 

 

In general a small system could be a certain number of clients that connect to a DA Server and the DA Server communicates with the PLC or other field device.  Below represents a small architecture depicting this scenario:

 

In the scenario above, there is a single path for IO communication with the PLC's.  To add resiliency to the implementation it is a good practice to add a primary and backup DA server.  This setting is configured within the access name(s) in the InTouch application.  Essentially this allows for continuous communication to the PLC's in the event of hardware or some other issue with the DA Server. Below is a diagram that depicts this scenario. 

 

 

 

In both of the examples above, changes would be made to the application using WindowMaker on what is typically referred to as an engineering workstation. In a lot of cases the application is copied directly onto the windowviewer machine and windowviewer is restarted.  Another approach to this would be to configure Network Application Development or NAD.  NAD is, in simple terms, an automated way to distribute applications. One node, called the Master NAD node, is a central repository for InTouch Applications. It is the source of the application files for all other NAD Client nodes, which get a local copy of the application files. Any node can be the Master NAD (even with no Wonderware software installed.)  To configure a node to be a NAD Client all that has to be done is to find the application in the Master NAD, enable NAD, and specify the local directory to store the application files. It is important to make clear that NAD is architecture independent. In other words, NAD can be used with applications designed to be stand-alone (no communication with other InTouchnodes), Master/Slave applications, or a completely distributed architecture with a Tag Server and Clients with no local tag dictionary but using remote references to the server.  What the application does or how it communicates with other nodes is irrelevant to NAD; all NAD does is to copy the files to other nodes and updates them when the application changes. The next sections explain how NAD works and some things that should be taken into account when using NAD. The diagram below represents a typical NAD configuration:

 

 

 

Notes and Warnings

Note that this article is related to Classic InTouch application development.  With the use of system platform, InTouch applications are now managed through the integrated development environment in Wonderware Application Server.  In this architecture and application would be a "Managed" application and deployed to multiple clients after new revisions of the InTouch application(s) are made.