Sample Thin Client Installations

ACP created its industrial Thin Client solution to make it easy for a typical plant to incorporate Thin Clients into their existing design. This means that all of our factory specific clients have to work as drop-in replacements, picking up the functions currently done by PCs scattered throughout the plant. These PCs operate on a traditional distributed computing model, where the compute power is spread throughout a large area. This is in opposition to a Thin Client model, which is a centralized system with the computing power all being handled by Windows servers.

This first figure shows a model of a small installation, with a single server and a PC located at each station. Each PC collects information from its line and displays a local user interface for the operator. This information is then combined and stored for later use on the server.

Notice in this second figure that the PCs have simply been replaced with Thin Clients, and the traditional server has been replaced with a Thin Client server (such as Windows 2000 Server). Data is still collected at each station (this time by using the local Thin Client) and the operator interface is still shown at the local displays. Except now the applications that were installed and maintained on each PC are running on the Terminal Server. For the operators, however, the system looks and functions exactly the same, and runs the same applications. In fact, it is possible (and actually advisable, especially during the early phases of a project) to mix Thin Clients with full function PCs. This allows the changeover of just a few units at a time, allowing everyone to achieve to a good comfort level with the technology.

The simplified diagrams above are typical for an installation that uses some type of serial communication, usually when the bandwidth is fairly low or the amount of data required is limited. In many cases, receiving the data has moved beyond the capability of a PCs serial port. Because of that plants are increasingly turning to various Fieldbus technologies, or even Ethernet, to give them the bandwidth that they need, and they end up with an installation that looks more like that found in the following figure:

Here the data is traveling along a high-bandwidth connection to a single collector, a dedicated data collection PC, called a Data Server. This is done not only to simplify the installation of drivers (they are only now needed on the Data Server) but also to save money. While you may not have to pay for every installation of a driver on the network, you certainly will have to pay for the specialized hardware that must be installed in the PCs that will connect to that network.

The above figure now shows the same solution, but this time using Thin Clients in place of the operator interface PCs. In this case we have even gone ahead broken out our Thin Client management software, ThinManager, onto its own box as well. Something to notice is that we are using a full PC here as the data server. This is done because if we were to use a Thin Client, it would simply act as a shuttle and put the data back on the Terminal Server, and what we want is to have a completely different device receiving all of the data. This diagram presents a really good system model, because it lets Thin Clients do what they do best, display the interface. Remember, Thin Clients work exactly as terminals - they have no processing or storage power of their own. Now take a look at two variations of this diagram:

These two figures show alternate solutions with Fieldbus devices. One possibility is to take the data network all the way back to the Terminal Server itself . While probably not the best solution, it does save the expense and upkeep of that additional PC. Notice that in this diagram we are back to running ThinManager on the Terminal Server. In the second figure above we have shown the same system, but this time are doing all data collection from a single Thin Client that has been outfitted with the correct data acquisition card.

An important thing to examine is bandwidth utilization. A Thin Client requires a small amount of free network bandwidth, and if a high speed data network (like Profibus) is converted to Ethernet (as it is when the data is being received on a Thin Client) and transmitted on the Thin Client's network it could impact the performance of the Thin Clients.

A more interesting scenario is to consider what happens if a user moves from a traditional distributed PC setup where one of the user interface PCs is being used to gather data to a parallel Thin Client system. Consider the data flow shown in the following diagram:

In this case, each PC is running an interface that requires 100 points of data for scripts running locally. Once this data is processed, the results need to be stored on the Data Server. In this case the data is flowing all around the network just to end up on the Data Server - and if the points are updating every second, and the system grows in size and complexity, the network will be overwhelmed very quickly.

But take a look at the same system implemented with Thin Clients:

Nothing else has changed, but now the data is only traveling to the terminal server. Every application is running on the same machine (the terminal server) and so every application has access to the data for any scripts that need to be executed. In this diagram we have even broken out the Data Server on a private network. This means that any queries or scripts from any Thin Client operator interface (with the application actually running on the terminal server) are sent along this private network to the data server, greatly reducing network traffic.

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