Server-Based Software Creates a Single Point of Failure

The Server Part of Thin Clients: IT Can Help With Server-Based HMI

Jeremy PollardBy Jeremy Pollard, CET

In May, I wrote about thin clients ("Thin Down Your HMI Apps," www.ControlDesign.com/thinclients). A touchscreen with a thin client is very attractive from an implementation point of view. But what about the server side of things?

Server-based software creates a single point of failure. A plant operator who has a problem needs to be guaranteed immediate access. If the server is down or the network has failed and the connection to that server is down, you're in trouble.

You have to design in some contingencies, such as server clustering, redundant network paths and even a mobile operator terminal, to be sure that they are able to perform their tasks. Terminal services and server-based tools can guarantee 99.99% uptime.

A server-based approach simplifies tasks such as central data logging, alarming and reporting.

Visual Basic/VB .NET is the most commonly used language on the planet. Most industrial solutions support VB scripting or have a scripting language similar to VB. It works for most stuff. VB is a statement-based language that has the support of hundreds of thousands of programmers and developers.

ActiveX and .NET controls allow access to devices on the floor. OPC drivers have their API exposed to allow for connection using VB. There are lots of graphics libraries are out there.

So the new HMI is born. Companies such as Maple Systems sell a touchscreen unit running Embedded XP for less than $1,000. You buy your controls once. You develop your application and reuse it many times, and you therefore have a dedicated HMI of your own flavor inexpensively.

A four-screen conveyor monitoring system uses an $8,000 dedicated HMI—don't forget the cost of development. Using VB and a touchscreen computer, this application would cost less than $3,000.

The applications running on this HMI could be the application itself, or it could be running remote desktop protocol (RDP) or a browser to access the server-based VB applications that you've written. You can selectively run from the server or locally, thus giving you a measure of redundancy.

One issue with running an application from a server is deciding when you maintain the server. Many IT guys talk about clustering—to take one server down, perform upgrades and then bring the server back up. Depending on the application, you might need to do this. Having a real-time backup is important. Another concern is updating the application. The user has to be logged out in order to upgrade.

I have written most of my HMI solutions in VB for more than eight years. You also can use common standards and APIs without restriction. Runtimes are free when you use VB. Distribute the application to as many devices as you want. The under-the-hood stuff will take a little time and talent to develop, but, once you are onto it, you can do most of the basic HMI functions very quickly.

A thin client and a TS environment really allow for the development of a rich application suite for your users. In two hours you can write a small application to upload the timer presets from three PLCs, store them in a file and allow a user to open them in an Excel spreadsheet. They could change the data, and your application could detect the change and then reload them back down to the PLCs. Quick and easy, and the operator/user doesn't need a copy of any programming software to make those changes. The applications do not have to be big and bulky.

You can download free software from Microsoft to get started. Using SQL databases, graphics screens and operator interaction is only a few clicks away.

You have to become proficient in error handling on your own, however. You also will have to create your own scan list or addresses with variable names for your application to use. I use the PLC code and symbols to create a configuration file and import that. No sense putting in data twice.

We also might want to get the IT group involved if it isn't too much trouble. Server-based solutions are what they're used to. They can help.

A server-based solution might not be the way for you. With all the benefits, there are drawbacks, and our own knowledge level could be one of them.

If you don't want to venture into this arena, there are options. Tune in next month.

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments