Thin or Fat

J

Thread Starter

Jeff McBride

Do I go fat or thin. My multiplier on WW run time licences is excellent but at what point do I consider thin clients and do I need terminal services or is there an alternative?
 
R

Raymond van der Tas

MS Terminal Server Cons & Pros for SCADA/HMI

Pros
- zero based installation on client computer. Only TS Client software required
- supports Microsoft and Non-Microsoft operating systems on the client computer (DOS,CE, Unix,...)

Cons
- requires more bandwidth on the network which could lead to slow screen updates.
- requires more expensive hardware on the server computer
- requires knowledge about TS
- your TS becomes could become the single point of failure.

Other alternatives:
- Fat Clients

- Webserver base solution

 
D

Donald Pittendrigh

Hi All

> - supports Microsoft and Non-Microsoft operating systems on the client
> computer (DOS,CE, Unix,...)

In fact most thin clients I have evaluated use citrix or linux. (damn, there's that "L" word again)

>
> Cons
> - requires more bandwidth on the network which could lead to slow screen
> updates.

I am sorry but as I understood it this enquiry is in a Scada context, the thin client does NOT!! increase network traffic, in comparison to the traffic it would contribute if it was an independant IO server talking to a PLC to update its database. By comparison the screen update and
mouse/keyboard data exchanged with the server is nothing.

> - requires more expensive hardware on the server computer

60 meg of RAM per client, thats not really a consideration, a far more significant expense is the cost of a server operating system such as win2k server vs the cost of a workstation one.

> - requires knowledge about TS

I did a one day course with wonderware and have since set up 4 servers with thin clients, it is definitley much much simpler than setting up the
alternative Scada IO server.

> - your TS becomes could become the single point of failure.
>

This is misleading, there simply is much hardware in a thin client device to fail, I expect the MTBF can't be compared to a standard PC with all its electromechanical ills. I have used NCD and Wyse thin clients, I wouldn't use the Wyse ones again if I can avoid it, but neither of them had any moving parts, not even fans.

There are so many benifits of running the same app a few times over on the server, than servicing a distributed network of independant machines, simply the consideration of upgrading software or hardware or even making program
changes to a centralised machine rather than several distributed machines counts BIG points.

Thin clients should NEVER need to be upgraded, at least not the hardware as they hardly do any work.

There are problems associated with drivers for hardware you may need to hang onto the thin client and this should be thoroughly researched before making a decision.

Microsoft TS CALs are a hidden cost and aren't cheap.

If you need to run remote applications as well as the server application you have to think carefully about it as well.

I could go on all night but in short, hit the Yahoo button and search for reference sites, there are plenty, and read all about it before you make a decision.

Regards
Donald Pittendrigh
 
R
Jeff:

Your multiplier may be great on WW, but how about the PCs that it is installed on. Thin Clients are an excellent replacement for the Industrial
PC. Three advantages I can think of are (1)Price (2)Solid State (no hard drive) and (3)Redundant HMI. What do I mean by that. Well let me
explain- If your Thin Client comes loaded with its own runtime package. No expensive tag license necessary. The screens you develop using the
thin client app can be simple local control screens for the machine or process. A terminal services software driver is loaded into the thin
client (this should be free) for connection capability to the server. Once you log into your server then the screens that were developed using WW or other SCADA packages can now be run on the thin client. Here is the interesting part. Let's say for some reason your Server crashes or you lose the connection. If you are using a thin client loaded with its own HMI, then that HMI will take over control of the machine. Thus
redundancy. What PC can do that?

Here is the disadvantage. SCADA companies are getting savvy to the thin client explosion and they stand to lose some money if people no longer buy licenses from them to run on the fat clients. So guess what they are planning on doing if not already have done- you guessed it- some are charging 80% of the standard license fee for every thin client that is connected. So if you are considering thin then you may want to find a SCADA that will not charge for thin connection licenses. You will still save money over the fat client solution either way, but you can save a bunch of money if you go with a company that doesn't penalize you if you go the
thin way. Feel free to call me if you'd like and we can discuss your application.

Ron Powers
SR. Product Specialist-HMI/IPC
Siemens Energy & Automation-Solutions Business Unit
Validation Center
5300 Traingle Pkwy
Norcross, GA. 30092
770-871-3940
 
P

Patrick Cross

We run an NT 4 terminal server to support 20 Citect 'read-only' licenses for about 300 users on our business network.

Out Citect project is large (~450,000 tags) and uses about 80MB RAM per session. To support 20
simultaneous clients, the machine we use is a quad
700 MHz Pentium III Xeon with 2GB RAM. This was a
$50,000 (Australian) machine at the time, however I could by the same machine for $30,000 now.

I've found that the machine is size about right and could probably support another 5 simultaneous clients before it ran out of RAM and performance starts to drop-off.

I did some investigation of network traffic in order to size the firewall between the process control network and the business and found that it is difficult to compare to two setup's directly. While the client is starting up, the fat clients use considerably more bandwidth (loading tag databases establishing connections to servers etc); using a thin client, all of this network traffic occurs between the terminal server and the process control servers (in our case across a high-speed backbone). While
running, the thin client uses more bandwidth, mainly when change pages and the new page is loaded across .. or when running a large trend page, where a lot of the screen is changing all the time (Windows 2000 terminal services has an additional feature which allows caching the screen background bitmaps on the client) ; the fat clients only transfer data or a (typically)
small file containing the graphic info.

The total cost of ownership is a huge advantage.
Setting up a client takes no time at all, especially if you can use the advanced client which is an ActiveX object that runs in your browser. We've no problems with the terminal server itself. It has crashed once since I started it in December last year .. and that
is the only time I've even had to look at it.

I didn't have any knowledge of terminal server and it only took me a day to setup and configure. The options you get get for managing the client connections are excellent, eg. forcing user to log on with a pre-determined account, logging off users after a certain amount of idle time etc.

Obviously a failure of the terminal server results in loss of all clients, and the only way I would run this in an environment which required redundancy would be to have a minimum of two clients at each workstation running off separate terminal servers.

Of the big advantages I can see for the terminal
server in the near future is that Windows Pocket PC 2002 now support terminal services, which means that we'll be able to run access our entire plant on a pocket pc using wireless LAN or possibly GPRS.


Regards

Patrick Cross
Control Systems Engineer
WMC - Olympic Dam
[email protected]
 
R
Patrick:

If you use a client that has a pre-installed HMI runtime this will solve your problem of losing the client if the server crashes or the connection is lost. There are some manufacturers of CE boxes that embed their HMI image. If you develop a couple of simple local control screens, compile and download into the clients, that application will take over local control when and if there is a crash, and believe me you will get one. Why shut down your whole process just because the server fails. We can discuss this
further if you would like.

Ron Powers
SR. Product Specialist-HMI/IPC
Siemens Energy & Automation-Solutions Business Unit
Validation Center
5300 Triangle Pkwy
Norcross, GA. 30092
 
P

Patrick Cross

You could .. but then is it still a thin client?

The major benefit of a thin client is that is doesn't require any configuration or maintenance. Once you put a HMI on it, would you then have to upgrade it and regularly update the configuration on it ?

Regards

Patrick Cross
Control Systems Engineer
WMC - Olympic Dam
[email protected]
 
P

Patrick Cross

I agree. There is definitely merit in having some
form of local control in the event of a failure.

The problem with a single 'smart' thin client is how would it handle a network failure rather than a server failure ? I haven't found a thin client which supports redundant ethernet connections, and in the event that the HMI client loses connection to its IO server, how does the 'smart' thin client communicate to PLC's etc. ? Will it support proprietary protocols like DH+, MODBUS+, PROFIBUS etc. ?

The only thin-client architecture, that I've come up with so far, that will be completey single-fault tolerant is to have two thin-clients and two servers. To cut costs, the backup server could be a cut-down version which only ran a couple of screens so that you don't need as powerful a server ? This would even allow you to buy 50 point licenses, as opposed to 5000 point licenses ..

Patrick Cross
Control Systems Engineer
WMC - Olympic Dam
[email protected]
 
Top