Web based HMI article by Steven Hechtman

N

Thread Starter

Nathan Boeger

In this article Steven Hechtman, president of Calmetrics Company, a Sacramento, CA integration firm, explains why web based SCADA systems are growing in popularity and describes advantages over traditional SCADA systems.

http://www.automation.com/sitepages/pid2418.php
http://www.engineeringtalk.com/news/csk/csk101.html
http://calmetrics.com/site/index.php?id=articles.php

I'd really like to hear what you guys have to say about it. I'm personally interested in these kinds of technologies especially among the open source community. The company that I work for is one of a few vendors that have commercially launched with this approach. The product is called FactoryPMI and details can be found here:
http://www.inductiveautomation.com/products/factorypmi

I'd love to answer questions that you may have about the web based HMI system architecture/approach. Better yet, we could debate advantages/disadvantages of technical specifics.

----
Nathan Boeger
Integrator, MCSE
Inductive Automation
"Design Simplicity Cures Engineered Complexity"
 
This our opinion about web based scda.
Thus we have created an Open Source SCADA system
http://pvbrowser.org

Download archive with source+binaries for Linux and Windows (Qt4 version):
http://pvbrowser.de/pvbrowser/tar/pvb.tar.gz

Introduction to pvbrowser

The “ideal” process visualization would run in a standard web browser. In this case nothing had to be installed on the client computers, because web browsers are standard. Unfortunately web browsers have not been invented with process visualization in mind. In principle a web browser reads a HTML file from the webserver and displays it's content. Each time a HTML file is read the network connection is opened and closed. Dynamic changes in the content are difficult and inefficient.

A Java Applet might be a solution. Unfortunately complex Java Applets need a long time to load. Furthermore Java Applets are not famous for being fast. We have build a new browser in C++, which is optimized for process visualization. Instead of HTML it dynamically handles Qt Widgets. pvbrowser can be run as standalone application or as Kpart for konqueror.

Because pvbrowser is a browser it can display any visualization. There is no need to update client computers running pvbrowser, when you change your visualization. This is in contrast to many process visualization systems which use the “fat client” model. Furthermore pvbrowser supports many platforms at the same time.

When you choose the URL of your pvserver from within pvbrowser a TCP network connection is opened. The network connection will stay open until you terminate the session with your pvserver. After opening the network connection pvserver will start sending commands to pvbrowser. Each command is a line of text which is terminated by a newline. pvbrowser will interpret the text and call the according functions from the Qt widget library. Thus pvserver handles the whole widget tree within the main window of pvbrowser. When the user triggers an event (e.g. hit a button), a line of text will be send from pvbrowser to pvserver. In pvserver there is an event loop, in which these events can be handled.

For programming pvserver we provide a library that encapsulates the lines of text send to pvbrowser. The reference for this library can be found under “pvslib” in the manual, which is also available from the online help of pdevelop.
A substantial part of pvserver is not written manually. Instead pdevelop will gently generate the code for you. The functions provided by the library can be inserted by choosing from a menu in pvdevelop.

The whole layout and design of the masks you are using in your visualization is made graphically using the integrated designer from pvdevelop.
 
N

Nathan Boeger

What an interesting idea! You've created your own GUI builder and client, with the ability to update clients without upgrading them. Is this true of installing new versions in addition to project updates? I like the look of your GUI. You also appear to be programatically flexible. I've been by your web site numerous times. I'd always assumed that the client was Java based. Thank you for your open source efforts. I truly believe that they will lead to higher overall quality of industrial software.

To address your specific points

"The ideal process visualization would run in a standard web browser. In this case nothing had to be installed on the client computers, because web browsers are standard." - I couldn't have said it better myself.

As far as I'm concerned a zero client side installation and configuration is a must! If it does take client side installation, it had better be easy and NOT store any important data locally. What is required with pvbrowser to upgrade the clients? Our (Java) approach in FactoryPMI deals with this with Java Web Start. It is a very cool technology. Client side installation is pretty lightweight (typically a one time download of about 2 megs that is trivial for an end user to do). I agree that HTML is not the way to go for SCADA apps. Other alternatives for web launched applets could use: Flash, AJAX, or Microsoft's new technologies (ActiveX replacer, I think).

I see that you guys have lots of drivers implemented including Modbus - very cool. Do you have a generic OPC client? Most of my customers already have OPC servers for their specific PLCs.

Do you have a sample application that I can run? I'm interested in loading up the client on a windows machine, Linux machine, and OS X, if possible (penguin powered, right), then connecting to a server somewhere to run it. What types of commercial applications are running pvbrowser (I did see the motor relay and bio-gas applications featured on your web page)? What is your distribution of users in terms of: software programmers, integrators, OEMs, and end users? Thanks for the input. You're the only open source SCADA project that I've seen that I would consider to describe as viable (This is where other projects post links...).

I'd appreciate it if you guys try out FactorySQL and FactoryPMI.

http://www.inductiveautomation.com/products/factorysql
http://www.inductiveautomation.com/products/factorypmi

I'd like to hear your feedback. Perhaps we could give each other good ideas. I think Inductive Automation is as close to open source as any commercial SCADA company will ever come. We certainly like to work with open source projects.

----
Nathan Boeger
http://www.inductiveautomation.com
"Design Simplicity Cures Engineered Complexity"
 
M

Michael Griffin

In reply to Nathan Boeger - This might not be the sort of answer that you are looking for, but I had a look in your support forums and most of your registered "members" seem to be spam bots. I think there's a web technology involved here that you still need to get a handle on.
 
N

Nathan Boeger

Thanks for the input. We're using a popular forum, phpbb, that gets frequently exploited due to its widespread use - it's a big target. We're waiting for 3.0 to get out of beta to upgrade, which should take care of the problem.

"Web based" refers to SCADA packages utilizing standard communication/authentication/launching methods/protocols so that HMI packages don't need to be installed/configured on the client side. It has little to nothing to do with the Internet, HTML, or precanned PHP forums that users have automated registration bots and exploits for.

I'd love to discuss security for control applications.

----
Nathan Boeger
http://www.inductiveautomation.com
"Design Simplicity Cures Engineered Complexity"
 
M

Michael Griffin

In reply to Nathan Boeger - I would say that web based control *does* have something to do with the internet, because once you add a web interface, people are going to start thinking of ways that having it on the internet can be useful. To give you an example, I will before too long be able to remotely monitor my electrical power consumption over the internet as part of a "real time" billing project.

Perhaps your particular product isn't intended to be used over the public internet, but the topic was "web based HMI", not just your particular product. There are plenty of good applications for having publicly accessible web interfaces, so people need to think about security. They also need to think not just about how people might "hack into" their MMI, but also how people might try to make malicious use of features in ways that were not intended.

If you would like another good example, think about a conservation authority making their river flows and reservoir levels available over the internet. If someone on this list was asked to bid a project like this, could they use an industrial type web based HMI product, or would they need to write a completely custom web site because of security concerns? If they used an off the shelf web based MMI and it had an operator comment log feature, what would prevent people from using that for spamming?

P.S. - I know your web site doesn't use your product, but I had a look at it because of your posting (which is perhaps what you intended). A spam bot problem isn't really an "exploit", it's a web site admin problem. The spam bots are simply using the standard user interface in a way that is "impolite", they're not breaking into your site (which is what an "exploit" would be). I mentioned it though as it didn't make a good impression on me, and I thought you would like to know about it. I would suggest just taking that page (list of forum members) down permanently. You can keep deleting their postings, but as long as they have a web site listing on one of your web pages they are boosting their search engine rank, which is all a lot of them really want anyway.
 
N

Nathan Boeger

Michael,
You have excellent points backed by solid examples. And, yes, you're correct that the Internet is very relevant to Web based HMI technologies. In response:

Spam bots are an exploit and a problem. There are patches that I can and will employ to fix that problem. They do not register by the normal means of your forum- they are engineered to post predefined variables with expected values, skipping your first registration page. This is easy to script. They then often employ the use of cheap or free human input to get the coded image. Web scripts that offer free adult content make you verify a few to get in. Or they hire web labor at $2/hr, etc. Then there are companies that maintain databases of all sites using specific forums. And you're right, that link in the profile is helping them. I've been meaning to add a no follow tag to those for Google bots.
htt p://w ww.icontool.com /fp/buy.htm

To address your issue of security - there are varying degrees of truth to your point. A totally custom application properly written that is then placed on the Internet COULD be more secure than a precanned package. However, this is not typically the case. Responsible commercial packages should be using encrypted sessions (ie public key system to transfer a one time random symmetric key), and employ standard IT based security technologies. IE VPNs, serious Cisco equipment, etc.

Your point about a custom written web app being more secure because it isn't precanned is largely irrelevant. You're counting on security by "obfuscation", that is not knowing implementation details. This is widely recognized as NONEXISTANT security.

You are certainly correct that being in the spotlight can lead to more attacks - look at Microsoft. But it's also their responsibility to keep on top of updates, patches, etc. (I'm certainly not about to take a stance defending MS right now).

You are also correct in that there are many applications that make sense to offer over the Internet. Interesting choice of example, I have personally written a web application to monitor realtime and short term historical lake level and stream flow information for a water district. We also custom wrote a program that had a voice card and answered 4 lines of an 800 number to get that same info. They needed it in order to appease their board before they could secure federal relief funding for an accident years prior. This application would have worked great (if layed out properly, with FactoryPMI). You're right that implementation matters significantly.

Anyway, I've seen lots of janky implementations of home brewed apps: Linux, Windows based, PHP, ASP, .NET, VB, various scripting languages, C, Java, etc, etc. I've found that home applications lack much of the security, database layout, etc in that they just take too much time/expertise for these 1/2 man shows that implement them. They tend to be expensive and difficult to upgrade. A good HMI/SCADA package should be able to deal with a lot of these issues (there is still a lot to be said about admining them as you mention).

But to support what you say, there's not a lot of standardization/good security in most HMI/SCADA packages. They tend to be home brewed and not standards based. That's what I'm trying to get away from at Inductive Automation as well as my personal interest.

Nathan Boeger
http://www.inductiveautomation.com
"Design Simplicity Cures Engineered Complexity"
 
N

Nathan Boeger

Michael,
I forgot to acknowledge your main point in my previous response - that security needs to be kept in mind when dealing with web enabled applications.

Your point is critically important. It's very relevant to a custom written application as well as an app created with an off the shelf product - any software in controls for that matter.

You're right that the world's moving to web based control. As users realize the convenience of doing things from home/offsite/whatever it drives projects in that direction. All the major industrial software vendors are catering in that direction - and will have to whether they like it or not. It's a matter of what's convenient to the buyer.

Security's interesting in our industry to me because it's so loosely regulated (read not really at all) and without some major event probably won't be. Yet it's becomming increasingly important.

One thing that you shouldn't get hung up on is that an off the shelf HMI package is an application designed to create custom software. If it has a feature that allows operators to input comments, then it better have some way of protecting that or turning it off. It's not fundamentally much different than any other programming/scripting environment.

What's really important with respect to security is the implementation of the project. You can do a good job or a very dangerous shoddy job with pretty much any package out there. This includes software programming environments, scripting languages, industrial software HMI/SCADA builders, whatever. You've astutely pointed out that certain applications can have exploits - Microsoft's already proven that one. But these pale in comparison to a poorly implemented application. How many industrial sites have you seen where the control software auto logs in or many users share the same high privledged password? Or slightly more subtle, I can walk on to most sites and plug into their PLCs directly - I'd be able to do whatever I want. I could go on and on with this sort of thing: blank or default passwords, terrible networking configurations, rediculously old versions of software, etc, etc - I've seen too many of these to count. What do they do if they have a disgruntled employee? Even ignorant malicious users have free reign. Software vendors should stay on top of their bugs, but THIS is the kind of thing that needs to be fixed. It's an issue of education and priorities. People take airport security seriously, why not the also dangerous industrial security?

----
Nathan Boeger
http://www.inductiveautomation.com
"Design Simplicity Cures Engineered Complexity"
 
C

Curt Wuollet

The reason this hasn't become really big is that it's pretty difficult to make it hopelessly non-interoperable and useless like the current paradigm in automation networking. If it can't be completely owned, controlled, and exploited it's a problem for big automation, not a solution. The net operates on cooperation and compatibility and standards. This and automation are like oil and water. Users and non-proprietary interests are the only real way to fulfill the great promise this could hold for ubiquitous connectivity. Dozens of proprietary schemes will simply inhibit any effective use of this tremendous asset. That's why the field buss market is still in the dark ages. That example hasn't seemed to enlighten many, they still dream of owning the whole market. Think of the issues in the light of public ownership and cooperation and many will go away.

Regards
cww
 
M

Michael Griffin

In reply to Nathan Boeger - Your response was in two separate messages, so I will address both of them here.

First, I didn't say that a custom web interface would be more secure *because* it isn't "precanned". I said that if an off the shelf web interface was not secure, then a custom web interface may *have* to be used (so that it could be written securely). This is an important point because many industrial systems have little or no security. For example, there was a posting here some time ago where someone mentioned that with a particular (unnamed) brand of PLC, if you did a port scan on the built-in Ethernet port the PLC would crash.

As for auto-log-in on industrial equipment, whether that is a good idea or not depends upon the application and what the log-in does. If it just enables the machine to run and be used in its routine fashion then a log-in accomplishes little or nothing except getting in people's way (who will then find a way to turn it off). If it is to protect certain rarely altered critical data from unauthorised change, then that is an application issue, and it is typically looked at as "password protection" for that data (and is not considered an excessive inconvenience as it is only ocassionally used).

This is different from a "personal computer", where you are expecting someone to be sitting in front of the computer and using it all day. Interfaces for typical industrial equipment should be designed so that a password isn't *needed* for routine use, only for rarely used functions. In many applications, physical presence means authorisation for routine functions.

Web interfaces may have a particular problem with this in some applications if it means they can be accessed from remote locations. The application software may need to have some way of determining where a user is before granting them access (or to at least limit their access to certain functions). Perhaps there is some way of easily determining the location?
 
N

Nathan Boeger

Michael,

I agree on every point - Great insight!

To answer your question, it shouldn't be tough to determine client location within your HMI/SCADA application. Simply use IP subnets. My recommendation (if security's a big issue) would be to have separate projects. You need a really simple way of dividing functionality between running locally and remotely. In other words don't depend on a complex user or password based system where the same user logs in with 2 separate passwords, etc. For example, you might only allow remote access via a secure VPN, and further only allow that IP range to communicate with the more restricted project. Or do the same with a project that's open on the 'net. Keep in mind that when there's a possible route IP spoofing is an option. In other words, there's no "one fix" for security. Your restriction will tend to be more powerful, flexible, and easier to maintain if you have your IT department set it up/work with you and you utilize security standards.

----
Nathan Boeger
http://www.inductiveautomation.com
"Design Simplicity Cures Engineered Complexity"
 
Nathan,

What if there are 4 or 20 + million clients (or more). How would IP subnets work? Is there a limit on the number of addresses?

Dennis
 
N

Nathan Boeger

Dennis,
I didn't catch this until now. IPv4 uses 32 bit addressing giving you roughly 4 trillion addresses. Depending on your subnet mask, you can choose anywhere from 0-32 bits describe the address within the network versus the network (trivial cases are included here). This is a property of the version of TCP/IP that the Internet currently uses. IPv6 is substantially larger with 128 bit addresses. Read about it here:
http://en.wikipedia.org/wiki/IPv6

----
Nathan Boeger
http://www.inductiveautomation.com
Total SCADA Freedom

Nathan
 
M

Michael Griffin

In reply to Nathan Boeger: IPv4 has 4 billion addresses, not 4 trillion addresses. More to the point of the original question, there is no problem with duplicating the same addresses on different networks provided the networks are not connected with each other.
 
N

Nathan Boeger

Yep - 2^32 is 4 billion not 4 trillion - I'm a retard. Good point - whereas "real" IP addresses used to be much more valuable, NAT has allowed us to expand greatly with non-routable (illegal/duplicate) addresses. IPv6 and 128 bit addresses will still force their way in eventually.

----
Nathan Boeger
Inductive Automation
Total SCADA Freedom
 
Top