Does anyone have any experience with web based HMI/SCADA systems. I have been doing some research and have come across Inductive Automation's FactoryPMI/SQL, APROL. Are there any other major players in this market.

Any help will be appreciated, Thanks!

 

The following is from the primer at
http://pvbrowser.org

"The '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."

 

PVBrowser promoter,

It is really quite ignorant at this stage of Java development to make general statements like "complex Java Applets need a long time to load" and "Java Applets are not famous for being fast". That may have been true in the 90s, but advancements in (JIT) compilers, general development, and faster hardware makes this irrelevant today. This is especially true with inherently 2D HMI/SCADA applications - nobody's anywhere near the bleeding edge of technology with respect to being hardware intensive. Java's automatic memory management (like .NET) is a definite stability feature over C++ and the platform independence of the virtual machine easily trumps C's portability in practice. In particular, Java Web Start is an amazing technology (how gotomeeting.com or gotomypc.com "install" and launch new clients). Wikipedia puts it best:

"In a paper written in 1999 by Lutz Prechelt it is outlined that, statistically, programmer efficiency and experience has a bearing many standard deviations greater on run-time and memory usage than language choice. This paper specifically uses Java as a basis for the comparison, due to its then bad reputation."

That said, I've made comments before about the lack of development of open source controls software, particularly the Linux/C++ versions. I still hold this to be true until proven otherwise - and I am looking forward to seeing usable GPL/LGPL industrial apps. I periodically search sourceforge and google for newcomers. I have specifically mentioned you guys (pvbrowser) numerous times as the most developed GPL HMI/SCADA package that I know about, but I still question your commercial viability for a non-programmer.

----
Nathan Boeger
http://www.inductiveautomation.com

 

check opcsystems a customized solution of asp.net with ajax interfacing plc driver via remoting may be right solution

 

We have been able to write AJAX applets that run in MSIE or Firefox and can update as fast as 1ms, however that's on an isolate network with nothing else happening.

In truth, real world would probably be more like every 1000-1500ms, which is still "adequate" for an HMI.

Having said that, we've only delivered one to a customer, and it was lot of work that he paid for. There's no real tool kit, and there's absolutely no way the average maintenance engineer in a plant nor the average IT guy could maintain it. Anybody with a real in-plant job to
do who isn't devoting at least 16-20 hours a week to the AJAX stuff would have a hard time sorting out all the details. It certainly isn't
"magic" that is beyond the average guy, but it also certainly doesn't condense down to a 2 page summary that a guy whose main job is to put
out the next fire could pick up and mess with - at least not yet.

My gut sense is that it's not far off, but the act isn't ready for prime time yet.

Michael
--
Michael R. Batchelor
www.ind-info.com

Industrial Informatics, Inc.
3281 Associate Dr.
N. Charleston, SC 29418

843-329-0342 x111 Voice
843-412-2692 Cell
843-329-0343 FAX

 

indusoft.
http://www.indusoft.com/
Complete tool box. Mostly private labelled for OEMs as far as I can tell.

relies on OPC.

 

I looked into the idea of going with a web based HMI for a while but decided against it for a few reasons...

1) Initial infrastructure investment - In a typical web infrastructure you have at least three servers. A Dev, Stage, and production. If you have a large number of users you may also have load balancing (3 production servers). If these are spread across multiple sites you may need multiple production servers, some for each site if you do not have reliable communication between sites. This puts the server count for my company at 10, at a total cost of about $50,000. This does not include software to run on the servers.

2) User Issues - I have a large number of users that think they are "experts" and try to "fix" stuff on their own. If they find out the web address they will try typing it in on their office computer. With some of the automated equipment we have this could cause issues if they started something. I realize there are ways around this, but it is still a concern.

3) The down time dilemma - What happens if you have a web server go down? Before if a PC went down you lost one line. Now if you have a server go down you could lose lots of lines. There are ways to address this if you spend the cash.

We currently use Visual Basic .NET and interact with our PLCs through Ethernet. We are looking for some ideas on how to change a few things, but I will put this in a different post.

 

There exists an open source Linux solution. The HMI part is Java-centric, and does/can run within with in a web environment.

It is located at
http://visual.sourceforge.net/new/index.php

Please contact me icspl through this site for additional files to make visual a little more polished.

 

In reply to Brandon T: You seem to have conflated the requirements for large high volume custom mission critical systems such as banks and e-commerce sites with the much simpler requirements of typical industrial MMI. I will try to deal with each of your points in turn.

> In a typical web infrastructure you have at least three servers.
> A Dev, Stage, and production. <

The web infrastructure you describe (with dev, stage, and production servers) is true for any sort of software which runs on large scale systems which require extensive testing and cannot be shut down for any reason. This not unique to web based systems. Developing for a web based system is no different from any other software in that respect. It is overkill though for most industrial MMI applications except perhaps for some applications in large power plants, refineries, and other similar systems.

For typical development though, the "dev" server would be the PC you use for all your other software development (i.e. the one with your PLC programming software, VB compilers, etc.). There would be no "stage" sever (this is for final full scale testing and approval prior to deployment). The "production" server would be the one running the software for the production line. In other words, this is pretty much the same as you would use if you were creating any other MMI application.

Where some people get into a problem is in trying to use things like the Microsoft IIS web server, which is tied to the "server" versions of MS-Windows. Microsoft have "toy" versions which run on the desktop version of MS-Windows, but while these might be OK for students, they aren't intended for real life use. Microsoft ties it to their server OS versions for license revenue reasons, not for technical reasons. If you use Apache or one of the other many available web servers you don't have this problem and you can run the full scale system on your desktop PC. There are also web servers which are just libraries that you use in a Python or Ruby program.

> If you have a large number of users you may also have load balancing
> (3 production servers). <

Load balancing is how you handle situations where one server is not powerful enough for the load and you need to run several in parallel. In that case you also separate the servers by function, such as
database, dynamic web server, static content, etc. However in this case you are talking about running a web site like Google or a major news or e-commerce site. I am not familiar with any industrial applications with many thousands of simultaneous users. If you have an industrial web based MMI that needs load balancers, then likely
there is something very seriously wrong with your software that is bogging it down.

If you have an application where you need redundant servers (e.g. a power plant), then that is a different set-up. You need redundant servers no matter what sort of software you are using though (just like some people need redundant PLC CPUs). Web applications have an advantage in these applications because it is easier to replace client workstations (which fail more often than servers do). This is because they don't need any special software installed, and the client session isn't lost because it is stored on the server.

> 2) User Issues - I have a large number of users that think they are
> "experts" and try to "fix" stuff on their own. If they find out the
> web address they will try typing it in on their office computer.
> With some of the automated equipment we have this could cause
> issues if they started something. I realize there are ways around
> this, but it is still a concern. <

You should separate the office and plant networks, unless you really need to access the plant from the office. In any event, the system should authenticate with the user before showing them any control screens. Cookies are very commonly used to remember the log-in so the user doesn't have to type it in each time. This also has the advantage on a combined network in that you can show people in the office status summary screens that lets them see if the equipment is running without showing them screens that actually control anything. You can tell who they are (office versus plant) by the log-in credentials (or lack thereof). There are a variety of standard means
of tracking sessions to control what people do (and to prevent them from bypassing the log-in process).

> 3) The down time dilemma - What happens if you have a web server go
> down? Before if a PC went down you lost one line. Now if you have a
> server go down you could lose lots of lines. There are ways to
> address this if you spend the cash. <

You have this problem with any centralised system. There is no reason for an MMI system to be centralised though. Why wouldn't you have a server for each line? Why wouldn't it be part of the line?

> We currently use Visual Basic .NET and interact with our PLCs
> through Ethernet. We are looking for some ideas on how to change a
> few things, but I will put this in a different post. <

I'm not going to claim that a web based system is better for your particular situation than a VB application. Indeed, I don't know why you are using VB instead of one of the packaged MMI systems such as Citec or WinCC.

However, you seem to have some misconceptions about web applications. If you look at the typical literature available on the internet or in a bookstore the, you will find information relating to business applications. These applications typically involve presenting web interfaces to very large numbers of people who are interacting with a database. The web application is providing the user interface for the database.

Indeed, this is the same application that VB was meant for. Web based systems though have for some years been replacing VB in that market. The problem with VB applications is that you have to install, test, and debug them on each PC. This can be quite painful when you have a large number of PCs. The web based systems move the software from the user's PC to the server, making deployment and maintenance much easier and more cost effective.

A web server isn't magic. It basically consists of the following:

1) A computer to run it on. This isn't necessarily a PC or an IT server. You will find web servers embedded into a lot of hardware. Some PLCs have web servers built into them, as well as do a lot of things like DSL modems. More and more embedded devices are using a web interface for configuration and monitoring.

2) The basic web server software package. By far the most popular is Apache. There are others though, such as Microsoft IIS, lighttpd, Boa, thttpd, Netscape, and many others. There are also web servers which are just libraries in a program. What a web server package does is very simple. You send a request to it asking for a file, and it sends you the file. Usually the file is an HTML file which your web browser will render into a web page. For the simplest web servers, that is *all* they do (these are "static" web sites) and the items described below are not present.

3) The scripting interface. This is where the magic comes in to play. With many web server packages, if the file you ask for contains a script, it runs the script first and then gives you the output of that. This means the HTML pages can be generated on the fly instead of being simple "static" pages (these are called "dynamic" web sites). Scripting can be done in several ways. I won't go into the details of that except to say that an older method is called a "CGI" interface, and the newer method is through what Apache calls "modules".

4) The server side scripting language. The two most popular scripting languages are Java and PHP. Java is typically used by large business sites, while PHP is used were speed and ease of development are more important. There are many others, and if you use a CGI interface you can even do web scripting in things like 'C' or assembly language if that's what you want to do. Note that in this case we are calling it a "scripting" language even though technically, Java is compiled to machine code rather than interpreted like conventional scripting languages. The scripting language is what you use to write your program. The user asks for a web page, the server runs the script, which in turn generates the web page on the fly (often pulling information out of a database to do so), and the web server sends the output to the user.

5) The database. Most web servers use a database because the application happens to revolve around a database. It isn't actually necessary to have a database but if you need to work with historical
data then you typically use a database. By far the most popular database is MySQL, but many others will work as well.

6) The client side scripting language. Scripting can also be done in the client (the web browser on the client PC). This doesn't replace server side scripting, it just provides additional user interaction features. Most internet web sites don't use any client side scripting. Most client side scripting is done using Javascript (which
despite the name, is not the same thing as Java). Less common is Java, although that is sometimes used in closed networks and therefore is a possibility for industrial MMI use. There is another sort of software, which although strictly speaking isn't client scripting is used with one web browser, and that is Microsoft Active-X. The primary use for that though is as an interface for
viruses, which it why it is obsolete.

Note that the above describes "web" browser based systems, but it is possible to have browsers which don't use a web (http) protocol. For example there is an MMI system called "PVBrowser" which uses a set of non-http remote procedure calls. The basic principles are the same though.

I'm not going to suggest that everyone should use web based MMI systems. There are both advantages and disadvantages to them. One advantage is that you don't have to install any software in the
client PC provided it has a suitable web browser (and a Java run-time if the system uses Java). A disadvantage though is that web based systems tend to be less interactive than systems which run entirely on the client. For simple MMIs, this might not be a problem. For systems with complex and rapidly changing graphics though, a web based system might not work as well.

It is possible to take advantage of both systems. You could have a conventional highly interactive system that runs on the client together with some simpler status information that runs on a web
server (which could be in the same PC). The operator can use the conventional client software, while people in the office can use the web system to see if the line is running and how many parts have been made. If you are logistics coordinator who has a line down and a truck waiting in the dock for the parts, this is saves a lot of time
over running out to the line to see if someone has got it fixed yet.

On a more general note, for anyone who is interested in getting some hands on learning experience with web systems, things like web server software, languages, databases, programming editors, etc. are all available for free and can be installed on any PC. There are a lot of basic introductory books available for the Apache/MySQL/PHP combination which are oriented towards people who are not computer experts. Once you have mastered the basic concepts, it is not really any more difficult than any other sort of computer programming.

 

Indusoft is an excellent alternative for a Web based HMI/SCADA system. And you wouldn't necessarily need a complicated network server design. With ICP DAS USA's Windows CE based Programmable Automation Controllers - WinCON PAC - your Indusoft HMI program would reside/run on the controller, and you can handle your automation or data acquisition via Web, without needing an additional PC. You can learn more at http://www.icpdas-usa.com and visit the WinCON PAC page with Indusoft Runtime License.

Cordially,

Vimaris Grau
ICP DAS USA, Inc.
www.icpdas-usa.com

 

Brandon,

I found your more in depth post here:
http://eng-tips.com/viewthread.cfm?qid=197685&page=1

I believe that FactoryPMI and FactorySQL from Inductive Automation can exactly meet every one of your 8 listed needs. The best way to learn would be to sign up for a free web demo and ask questions specific to your application. I think you'll find exactly what you were looking for. Worst case, you've wasted an hour.

http://www.inductiveautomation.com/products/webdemo/

----
Nathan Boeger
Inductive Automation
Total SCADA Freedom

 

In addition to Browser-based viewing, InduSoft offers a secure viewer that, when properly configured, prevents access to the OS and dedicates the PC only to designated applications. It's an inexpensive way to resolve the issue of users "fixing" things.