thin Clients

I presently run a small network of about 130 nodes. Of which approx' 115 are plcs. My company is pushing the use of thin client technology for user interface and data collection. Each of the thin clients will run windows embedded standard 2009.
The HMI's would run on the thin client with the data collection on the servers. Has anyone tried to do this or have any thoughts on the process?

I have dabbled in this area with varying degrees of success.

Are you talking a 'true' thin client where the presentation layer graphics, mouse and keyboard is the only thing handled by the thin client? And you're using VDI on server-based VM's for the remote OS?

Or are you talking the simpler case of a remote OS and viewer, with a server-based HMI server? That seems to be one of the permutations bandied about by industrial 'thin client' vendors.

In either case, thin-client architectures require thoughtful design of the servers and network architecture. You can get cost-effective redundancy and acceptable performance but there is a lot more to it than the usual 'slap a network together' approach.

I just finished a redundant PLC/HMI/network/servers design that used dual redundant Dell T310 T410 dual power supply dual Xeon with Cisco switches and Zyxel routers. We use the routers to carefully separate multiple PLC networks, multiple HMI networks and allow specific VPN / Internet connections. The servers all run VMWare ESXi to serve up all the virtual machines: domain servers, SQL servers, presentation servers, VDI's. And I test everything using Fluke's high-end network analyzers since its so easy to end up with network scenarios you did not anticipate.

I've tried running the viewers as true thin clients using nothing but VNC and RDP protocols. They work, but sometimes the windows do not refresh as anticipated. I want to try PCOip since it is supposed to solve numerous problems at the expense of higher bandwidth requirements.

If you are going to run Windows Embedded and install local viewer HMI SW on each client, I can say we have had good luck doing so (given an appropriate network design).

But if you are planning to run a true thin client network using VDI, I have yet to release such an architecture to a customer since I have not yet tested a solution that I would consider acceptable. If someone has an HMI VDI application out there it would be great to hear from them.

Thank you for your thoughtful reply. I'm still trying to wrap my head around 'thin client' as it is a new concept for me. It appears that they are talking a 'true' thin client with a VDI using VMware. There are a lot of 'ifs' yet. We are still trying to work through the process. Thanks again.

Are your HMIs going to have touch screens? If so, make sure that your hardware touch drivers will run on the intended thin client. We had two thin clients at one time, and did have issues with getting the touchscreen drivers installed and working correctly.

Eventually, we ended up with standard Dell desktop PCs located in a safe and dry environment with Digi Connectports linking them to the Touchscreens out on the floor.

PCs are so cheap and relatively reliable, they are easier for us to maintain than the thin clients (at least those we had).

It's all a matter of opinion and mine is that thin clients are good for operators to enter data into the buisness system or something of that nature but for controls they are a PITA.

To me, "thin-client" is a SCADA term that means zero-base-install software on your client machines. They come with internet explorer, and that's all you need. Easy to swap out, simple for migration.

I've had very good luck with this thin-client solution for SCADA applications. I imagine when you mention you have 130 nodes, 115 of which are PLCs means you have 15 PCs as view nodes for monitoring as well as some data collection etc..

I recommend a pair of web servers running your favourite flavour of SCADA software to handle the data collection and data access to your PLCs. The other 13-15 PCs will then just run internet explorer and be able to monitor, change setpoints, view historical data, alarms, etc...

It's a simple solution, just use the built-in redundancy feature of your software combined with Network Load Balancing on your servers to keep your web server redundant and Bob's your uncle.

I've personally implemented this in critical infrastructure (natural gas, water & waste water) installations with great success. PM me if you want some details, I'd be happy to share my experience.

Cheers,
Paul

Yes, I agree with Paul that if all you want is a 'web client', 'browser client' or 'web app' like Paul suggests, you have quite a few choices of HMI's with web servers that allow you to view your HMI as a simple web page.

We use the GE Cimplicity Web Server (fairly expensive) or the GE Cimplicity Viewers (require a small app to be installed on each client) for our client solutions and have relatively good luck with them.

The Cimplicity Viewer has the downside of requiring a proprietary app installed at each client.

The Cimplicity Web Client has the downside, IMO, that it runs using Java so Java has to be installed on each client instead of a proprietary viewer app. I also STRONGLY dislike Java's performance: since it is an interpreted language that must be virus-checked each time, it has the irritating feature of starting slowly with little user feedback during the startup. I just have never found a Java app I consider acceptable performance.

But back to the topic of thin clients: a web app is NOT generally what is considered a 'true' thin client in the vernacular of the thin client world. In a thin client, the OS is installed on a central server remotely from the client and the remote thin client simply presents the graphics and handles the keyboard / mouse. The OS and applications run entirely off the (redundant) central server and the thin client essentially amounts to nothing more than the equivalent of a remote graphics card driving the video. The Ethernet protocol between the virtual server and the thin client will be something like VNC, RDP, ICA or PCOip. Even in the case of Internet Explorer, IE would be running from the server, with IE's graphics being generated locally by the thin client.

So in the context of GE Cimplicity running as a thin client that would imply something like Windows Virtual Machines running the Cimplicity Viewer (not the Cimplicity Web App) from a central server. You'd create an entire OS virtual machine image, add Cimplicity Viewer and license the whole mess. The advantage is that every time you need to add a new client, you would clone the OS image, buy new licenses and in a matter of a couple minutes have a new client ready. Cimplicity Viewer would have no idea that it is running from a virtual machine on a server and being presented on a remote thin client: it would simply think its a regular viewer app running on a PC. I have built this configuration and tried it with VNC but been unhappy with the screen refreshes / redraws.

If someone out there has built a 'true' thin client architecture and gotten it to work (with RDP or PCOip), it would be great to hear from them. The advantages of being able to stamp out new clients in a few minutes, guarantee complete client consistency, perform centralized upgrades, and offer full server-based redundancy would be worth looking into the 'true' thin client approach.

Thank you all for you replies. They have helped.

Check out Ignition for this application. It does require Java on the client as nwboson alluded to with Cimplicity. There is a "mobile module", currently in beta, that works purely with a browser. It's designed for smartphones (iPhones, iPads, Droids, etc), but works with any browser that supports the <canvas> element as defined in HTML 5. Instances run on the server, so it's "truly" a thin client in the context described in this thread.

nwboson - I have successfully implemented a thin client environment, although it wasn't for an industrial network. We used Wyse terminals that connect via RDP to Terminal servers (both Windows 2003 and 2008). It worked reasonably well, but didn't scale as well as I would have hoped. You would also run into weird problems that you wouldn't ordinarily expect, particularly with user/roaming profiles, audio/mic, and certain graphics intensive applications. Do you have specific questions?