A fairly new device has started to draw the attention of the media. Usually identified as a "web based Thin Client", this device has actually been around in one form or another ever since the first web browsers were introduced. Unfortunately, many people make the assumption that anything called a Thin Client works the same way. But there is a big difference between a web based Thin Client and what we will call a true Native Thin Client, and a basic explanation of each will make these differences readily apparent.
A web based Thin Client is nothing more than a computer that uses a browser to display web pages. In fact, after a little consideration, one realizes that most people who use the Internet are actually using a model of a Thin Client system. The graphic and text images that are displayed in a browser screen are not created on the computer where they are displayed. They are generated (sometimes even in real time) or stored on a server at a secure location, compressed into a special code that the browser understands and sent over a network. The Thin Client parallel becomes even more apparent when the user starts a complicated query at a search engine. The search engine running completely on the server does all of the work and a results page which it then transmits it to the client (the browser). All of the processing has been offloaded to the server.
But when the web based device is taken away from its original purpose (surfing the web) and moved into use as a Thin Client, some of its limitations become apparent. Many times a full computer is used as the host for the browser, bringing back one of the problems that Thin Clients were designed to address - namely a local hard drive and a local operating system, both of which have to be maintained. There is the benefit of being able to view the server pages with any computer that has a browser, which gives great universal access to the web pages, but this approach keeps a user from being able to fully take advantage of the Thin Client model. And while there are dedicated machines (Thin Clients) that do run a local browser, these embedded browsers must be updated, meaning that these clients are destined for obsolescence unless care is taken to keep all of the equipment current. Think of the changes that have occurred in the standard pages used on the internet in just the past year (like XML), and realize how unlikely it would be that displays would look and work identically on slightly different versions of the client web browsers.
What many see as the biggest obstacle that must be overcome by web based Thin Clients is the generation of the web pages in the first place. Most applications (and this is especially true in the industrial world) have evolved with a special non-web based interface. Conversion of this interface is extremely difficult, if not impossible. Think of operator interface screens that use features such as scripting and realize what it would mean to your plant to have to go back and redo all of the current displays. Even if the displays from one package could be converted, what about all of the others? Any application that is to be displayed on a web based Thin Client will have to be able to output its interface in a form that the version of browser running on the client can understand, and at the current time, with as many legacy applications as are found in a traditional plant, this is just not possible.
Another hindrance encountered when trying to display data in a plant is the difficulty of bringing together information from several different sources at once. For this to work correctly on a browser, the information must be collected, packaged and redisplayed as a single web page.
If you are calling the first device that we discussed here a web based Thin Client, then it is difficult to know exactly what to call the other type of Thin Client. So for this discussion we will call it a "Native Thin Client". This type of Thin Client has no local applications and no hard drives. It is truly a terminal that connects to the server and displays the output from ANY application. The only requirement is that the program run under Windows 2000. Once that condition is met, the operator at the Thin Client sees the display exactly as if he was running the application locally.
A native Thin Client has no applications (browsers, etc.) stored locally, so there is no chance of the device ending up with an old version of a display program. And with ACP enabled Thin Clients, even the drivers that are used by the Thin Client are loaded each time that the unit is powered on, assuring that the device is always running the latest copy of these as well.
The native The Thin Client typifies the centralized computing model. The client hardware itself is designed to minimize complexity, eliminating components prone to failure (such as disk drives) and scaling back parts (like memory) that are required for a traditional PC. On top of this cut-down (or "thin") hardware a minimal operating system is loaded, with just enough power to drive the graphics card, some I/O and an Ethernet Port. The Thin Client now has been streamlined to allow it to do just what it was designed to do - separate the application processing layer of a program from the user interface.
A Thin Client relies on a Windows Server to actually run the standard Windows based software, while it handles all of the user interface - displaying the graphics and getting the user input via the keyboard and mouse/touchscreen. By offloading the majority of the processing to the Server, it is able to handle all of its tasks with just its limited hardware compliment. Its requirements are well defined, and they do not increase even if the user loads a more complex software package on the server. This means that the Thin Client hardware will not grow obsolete for many years to come.
If there is no requirement to run any existing applications, and if all new interface screens can be designed and maintained as web pages, then using traditional PCs running a browser is a viable option. While you still have to maintain a number of PCs, at least the application that they need to run (the browser) is simple, and you do get the ability to display the screens on any PC that has a browser. But if the Thin Client system is to function as a replacement for an existing system, one where the existing operator interface screens and programs do not need to be modified in order to be displayed correctly, then native Thin Client hardware is the only choice.
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