We sometimes install our equipment, often in multiples, in tough environments that include corrosives, humidity and intermittent vibration. Our normal approach to operator interface is ruggedized industrial PCs where we store programs, some operating data, recipes, operating manuals and schematics. Now there's revived interest in doing this via thin client. In some cases, we even would have use of the customer's server. What do we really need to know to make a good decision about staying with what we know or switching?
- from May '10 Control Design
Understand the Licenses
Thin clients offer many benefits. They can be deployed as fixed devices on large or long machines as a distributed architecture, or they can be deployed on mobile handheld devices that make the operator more efficient. The latter method also can reduce hardware costs by keeping the number of required displays to a minimum.
Thin-client hardware often can be lower-horsepower PCs that can be diskless/fanless and offer more long-term reliability in harsh environments.
Evaluate how the thin clients are licensed. If the licenses for multiple thin clients are stored on the server—not on each individual client—when one goes down, nothing special has to be done to the thin client to get it or a replacement running again. Connect the power cable, connect the network cable, and you are running again.
There are other considerations. Will the HMI/SCADA software run on a current server operating system? Do the thin clients support security that is authenticated back at the server? Can each thin client view and interact with screens independent of what the server is viewing? Does it use standard Web-browser technology, or is something special needed? Is redundancy supported?
Working with the IT department is important, too. If the application will be run on a server that is most likely managed by an IT department, is the software flexible enough to adjust to the open TCP/IP ports that will be dictated by the IT policy, and not by the HMI/SCADA software?
Our thin-client solution is more optimized than the traditional terminal thin-client solution because the communication between the thin clients and the server is implemented by exception—only when values displayed on one station change in other station and the thin client is able to execute algorithm locally, resulting in a high level of flexibility and scalability to the system.
Verify how the thin client's communication is initiated. Does the communication occur all of the time to all workstations on the network, or does it happen only by exception and determined locally on thin client? This optimizes communications, reduces overall network traffic and allows the system to be very scalable.
Fabio Terezinho, Product Manager,
Safer Storage Space
The line between industrial PCs (IPCs) and thin clients is blurring, as the latest IPCs add fanless, energy-efficient CPUs, solid-state drives and embedded operating systems.
It becomes more a matter of application, rather than selecting a different PC/thin-client form factor. Today's IPCs easily exchange data to central servers if the application calls for it.
Cost-efficient, non-rotating media can replace traditional hard-disk drives (HDDs) in the IPC, eliminating any concerns about shock and vibration issues. The latest solid-state drives (SSDs) offer considerably more storage space than HDDs from just a few years ago; thus, they can handle even larger applications with ease.
Bjoern Falke, Product Marketing Lead Specialist,
Phoenix Contact, www.phoenixcontact.com
With the use of thin clients today, the network becomes more and more important. When you use thin clients, all critical tasks now run on remote servers generally in a more friendly, temperature-controlled environment. Redundancy of your network itself should be taken very seriously. Implementing rapid spanning tree protocol (RSTP), proprietary ring or chain redundancy protocol technologies should be the very least that is done to ensure smooth computing on your new thin-client installations.
Jim Toepper, Product Manager,
Industrial Ethernet infrastructure,
Consider I/O and OS
To make an informed decision, it is important to consider that there are two basic approaches to deploying thin-client solutions. The first uses a central core server or cluster of servers running a terminal services environment that allows multiple thin clients to log in to the server and start an application set. Resources are shared among all clients logged in to the server. Should one of the terminal sessions experience a fault, it potentially could affect every thin-client terminal session running on the server.
The second approach involves running multiple virtual machines on the central core server or cluster of servers. Each user logs in to a virtual operating system (OS) environment that uses a unique, dedicated set of resources. In this case, when one thin-client session experiences a fault, it is unlikely to affect any of the others attached to the server. A virtualized approach most closely represents a distributed-client-computing environment in that each operator station still runs in its own environment. However, a virtualized solution usually is more expensive and more complicated to deploy than the traditional terminal services thin-client model.
Which I/O does the operator interface need to serve its purpose? Most industrial PCs offer great expansion capabilities to accommodate standards-based and proprietary I/O. A thin client might not support the various I/O that the industrial computer system was designed to accommodate. I/O functions can move to the central server, but there are limitations. The server must physically be able to accommodate the interface cards required in the existing solution, and device drivers that are compatible with the server's OS must exist. This is especially true when implementing a virtualized thin-client approach, as many of the virtualized platforms available today do not support the non-commercial I/O often used in industrial control environments.