Thin-Client Architecture can reduce network bandwidth.

Although it may sound improbable a brief explanation can help you see the possibilities. First, let's take a look at a typical HMI Monitor and Control system architecture.

Let's look at a process controlled by a single PLC that requires operator interface screens at four locations within the plant. The network is 10BaseT Ethernet. We expect to record values from 1,000 distinct data points at 10 second intervals to an Alarm Points table of an SQL database. The SQL engine will be running on a separate "Data Storage Server" to be used for statistical analysis of historical alarm conditions. Additionally, each Operator Interface will display local alarm conditions, with the alarm data coming from the equipment local to the computer. The Diagram shows that this system consists of six NT Workstation computers linked together with a single Ethernet hub. A driver application running on the "Data Acquisition System" communicates with the PLC via its native protocol, sending and receiving analog and discrete data points. This same Communication Driver then serves up the data for use within the Windows-based HMI and storage applications.

The most common protocols used to serve data to HMI applications are DDE and OPC. DDE uses shared memory space to pass data between Windows applications on a single PC, or across a network as Net-DDE (between applications on two or more Windows-based PC systems). DDE works on an advise, request and poke basis. Basically, if an application wants a data point from the PLC Communications Driver it can either request it, and the Driver will respond immediately with the most current data, or the application can advise on it, and the Driver will send a new data value each time the value changes. If the application wants a value in the PLC to change, it can poke a new value to the Driver and the Driver will, in turn, update the value in the PLC.

So let's assume that each Operator Interface in Diagram 1 needs to be advised of 250 analog data points in its "local" PLC. Additionally, these points will cause an alarm if they have a value less than 10 or greater than 20. Within the application running locally on each Operator Interface, it is necessary that each of the 250 alarm points be in DDE "advise" mode so that any value change can be tested against the alarm limits. If a value is outside of the limits an alarm screen is displayed for operator notification and action.It might be an additional requirement that the alarm event data be added to the SQL Alarm Status table in the "Data Storage Server".

If this same functionality is required at each of the four Operator Interface Systems shown in the Diagram, then all 1,000 data points being read by the "Data Acquisition Server" must be continuously sent over the network. Each Operator Interface system would receive 250 values for local Alarm condition processing. This is an example of a condition that can and does occur in typical systems throughout the industry. What follows is a diagram and explanation of this same application running on a ThinTermT Thin Client architecture.

In Diagram 2, we have replaced the Data Acquisition System with an NT TSE Server running Citrix MetaFrame. This server does two things. First, it acts as a Terminal Server System capable of running multiple hosted sessions of Windows NT for connected ThinTermT Windows Terminals. Second, it acts as the Data Acquisition Server for communications to the plant PLC. As with the original client-server architecture defined in Diagram 1, the Data Acquisition System is a single point of failure. If your lose your data channel you cannot monitor or control your process. In place of the Operator Interface Systems we now have ThinTermT Terminals.

In the simplest terms possible we now have a server-centric operational model and all of the data collected by the communications driver is processed locally at the Server. Thus there is actually no Net-DDE traffic on the network at all. Network traffic is limited to the ICA protocol data required for HMI display and operator input from keyboard and mouse from the ThinTermT Thin-Clients. Because the operator screen changes are highly dependent on alarming conditions and it is probable that positive alarm conditions are an exception and not a rule, ICA traffic for screen changes should be less frequent when compared to Net-DDE traffic. Additionally, because the specific intent of the ICA protocol is to transmit keyboard, mouse and screen data between Server and clients it was engineered for very low bandwidth availability.

Effectively we are distributing limited screen results against mass amounts of data. In instances where alarm data is being sent to the Alarm Status table on the Data Storage Server we could actually reduce network traffic across our hub by creating an inexpensive private network directly between two Ethernet adapters on our Data Acquisition and Storage Servers.

For more information on ACP Industrial Thin Client computers, please visit our web site at http://www.thinmanager.com

To sign up for the E-mail newsletter go here: ACP newsletter signup

For an archive of past newsletter articles go to: ACP Newsletter Archive

Top