Web-based HMI Discussion

From: http://www.control.com/

SVG and OPC-DA
====================

Posted by Paul Campbell on 13 October, 2005 - 1:11 am

I've been reading up on the whole idea of AJAX technology and the idea of having your entire HMI implemented as web pages. Personally, I think it's a great idea. It solves a whole lot of problems.

However, there's one issue that I can't seem to get past. Looking at OPC-DA by itself, it pumps XML data to you... great. Looking at SVG by itself, it's a graphics engine... great.

However, most of the information on SVG assumes that the world is relatively STATIC. That there's no "point" or "tag database" of data in the background that is dynamically updating.

In my mind, it seems fairly simply to construct an XML document that would have your entire HMI "screen" written in SVG with pointers connected somehow to a set of data points. This will come up and display nicely, and you'd have a nasty little piece of Javascript running on it to periodically grab OPC-DA data and then tear it down and feed it into all the right places in the DOM tree to update the SVG.

But, that just seems very clunky. I've looked at RDF and such until my eyes start to glaze over. But am I missing something? It just seems like it should be possible to put something other than relatively "static" definitions in the SVG code and have SVG more or less "update itself" without a bunch of man-handling by the Javascript in the background. In other words, some way to provide "variables" or "placeholders" in an SVG object that get dynamically updated...possibly by something as simple as writing an ugly little bit of RDF and/or CSS which reads the OPC-DA output which is being periodically refreshed by a much smaller and cleaner Javascript code snippet that is timer-driven.

Anybody going down this road or have any ideas on how to do it cleaner than simply implementing a giant Javascript scan-and-poke creature?

----

Posted by Michael Griffin on 14 October, 2005 - 2:15 am

I have also been thinking more or less along the same lines, although not it appears to the same depth that you have.

However, since the point of AJAX is to use client side scripting, I'm not sure why you would want to use AJAX without much in the way of client side scripting. Your MMI screens need to accept and validate inputs as well as display outputs. *Something* has to manipulate the data.

You also left out the web server. The pages (screens) could get served up conventionally. The point of AJAX is to push the more interactive portions of the MMI out to the client side scripting, while leaving the major data
handling to the server side scripting. In this sense, OPC is irrelevant to the client, as the server would pre-digest the data (from whatever source) before passing it on to the client.

I suspect that this sort of techology is best suited to an MMI that is not overly graphics intensive. A large graphical display of a refinery would probably be a bit sluggish. An MMI for a typical production machine would
probably be quite acceptable though.

Something else that you might consider looking at for at least some MMI features is XUL. It has been around for a while, but reasonable documentation on it has only appeared recently.

As for how to avoid writing the Javascript for each and every screen, I think it will need to be auto-generated by the server side scripting from templates. This means that you would have to write some PHP scripts for each page (screen), but once the templating library exists, this would be much less work than writing the client scripts manually.

I expect to eventually see some drag-and-drop type editors available for AJAX web development, at which time we could adapt those for use in our industry. At present though, this is still considered to be leading edge software technology.

----

Posted by Paul Campbell on 18 October, 2005 - 10:33 am

You can trivially poll an OPC-DA server to serve up an XML file full of the inputs directly. This saves you the effort of shoehorning the inevitable laundry list of various drivers to communicate to the PLC's directly. From an AJAX point of view, you can do this DIRECTLY without any server whatsoever except for the OPC-DA server.

Because OPC-DA can be accessed directly from within the browser, it means that you can do a variety of configurations. You can have a "server/client" model by creating one very large OPC-DA server. You can do a "peer" style model by putting an OPC-DA server on each individual machine; or a sort of hybrid by allowing "browsing" around your plant where the OPC "servers" are the plant floor machines serving up data to all interested parties.

On Oct 14, 2005 Michael Griffin wrote:
<clip>
> However, since the point of AJAX is to use client side scripting, I'm not sure why you would want to use AJAX without much in the way of client side scripting. Your MMI screens need to accept and validate inputs as well as display outputs. *Something* has to manipulate the data.

True...but doing it at the receiving PC means that it is far more robust to the usual server crashes and administrative difficulties by going to a totally distributed architecture. There are no single points of failure other than potentially the network itself.

That's also why I left out the web server. The web server becomes optional. It is just as easy to serve the web pages from a file server, a local hard drive, or on any convenient web server with no special capabilities (such as a PHP engine).

Michael Griffin wrote:
> I suspect that this sort of techology is best suited to an MMI that is not overly graphics intensive. A large graphical display of a refinery would probably be a bit sluggish. An MMI for a typical production machine would
> probably be quite acceptable though.

True, but there are ways of handling that. In my experience by the time you get more than 30-50 individual data items on a single screen, it's probably time to break it down into subdisplays with a sort of "overview" anyways. Otherwise the screen gets so cluttered that it becomes impossible for operators to separate out and understand the important parts.

Michael Griffin wrote:
> Something else that you might consider looking at for at least some MMI features is XUL. It has been around for a while, but reasonable documentation on it has only appeared recently.

Funny you should mention XUL. XUL has a couple things going for it. It does a really good job of doing more "traditional" window-type screens with pull down menus and such. It is simply not well suited to graphics-driven applications like almost every MMI. Thus, the choice would be SVG. Of course SVG by itself doesn't do much so it would be embedded in either HTML, XML, or XUL.

The other much more important XUL feature is templates. XUL has the capability built-in to create a "template" which will consume an RDF file and produce a display. Hence, the very technology that you are alluding to (populating the web page in whatever form with data) is inherently built into XUL.

Michael Griffin wrote:
> As for how to avoid writing the Javascript for each and every screen, I think it will need to be auto-generated by the server side scripting from templates. This means that you would have to write some PHP scripts for each page (screen), but once the templating library exists, this would be much less work than writing the client scripts manually.

Or...let XUL do it. Right now, this is how I see it. Start with reading XML (xmlhttpget) from the OPC-DA server of choice. Then translate it to RDF. The RDF file is already attached to a XUL template file. Then on each update of OPC-DA data, send a refresh command to the XUL template to cause it to rebuild itself. Since not everything changes, this would actually happen fairly quickly (minimal "flickering").

Michael Griffin wrote:
> I expect to eventually see some drag-and-drop type editors available for AJAX web development, at which time we could adapt those for use in our industry. At present though, this is still considered to be leading edge software technology.

I'm actually contemplating exactly how to do that in an HMI environment. The nice thing about doing an HMI development environment vs. a more "traditional" RAD (rapid application development) environment is that HMI's are usually restricted to about a dozen or two dozen well-defined objects with fairly simple functions. A traditional RAD usually almost always dissolves into essentially a template/layout engine which you hang all your scripts on.

My issue here is simply that I can see at least theoretically how the underlying web technology could do most of this stuff directly. For instance, if the OPC-DA server acted as an RDF datasource instead of a WSDL (XML-style RPC's) server, then it's a matter of creating a XUL template with a very small "refresh" javascript fragment which causes the template to update itself.

Some other alternatives that I thought of were to produce an SVG template directly at the server with the tags stuffed in it with a simple script that does XMLhttpget's to poll a non-standards-based XML server, a Java object to do the same kind of thing at the client side (which is what most HMI's already do except at a lower level), writing PLC drivers directly in the "chrome" side of Firefox via XPCom (it's actually reasonably fast in spite of being a scripting language, and side-steps the "standards" issue entirely), and various versions of HTML and XUL but those mostly ended up being lame things like Cimplicity's "broadcast" web screens which are just a short "refresh" script and a server-side process that continuously recreates a pure graphics image of the desired screen.

---

Posted by Michael Griffin on 24 October, 2005 - 10:17 pm

I agree in general with your ideas, but I differ in some of the implementation details.

One point is that you seem very bent on avoiding a web server. I don't find your reasons very compelling. You seem concerned that a web server is some sort of large complex system. A typical http server is a relatively small program. It could reside on the same computer as your OPC-DA server, or on the PC with the web browser (either of which are typically much larger and more complex programs than most web servers). There is no requirement to have a centralised web server system.

Perhaps what you may need is an Apache module that can act as an interface to the OPC-DA server. This also has the advantage that you aren't limited to OPC-DA servers as sources of data for your MMI.

It would also give you access to all the other capabilities that are available for standard web server systems. For example, how do you intend to provide access to databases for logging and retrieving historical data? What sort of scripting capabilities do you intend to provide? Using a web server would give you numerous scripting languages as modules and their associated database interfaces.

Another point on which we differ is that you seem to feel that all MMI applications require extensive graphics. There are many MMI applications, such as many machine control interfaces, that do not require any graphics at
all. If graphics are provided, these in many cases are simply "decorative" and do not provide operating information. Standard AJAX type interfaces may work well with these applications. In these cases, SVG would be just one of the tools available in the toolbox, and not always the most important one.

I will say again, that I agree with the general thrust of your argument. However, I believe that you should try to make more use of all the components of an AJAX type architecture. This involves an interactive browser client
working with a web server. The server does the data manipulation, while the browser concentrates on user interaction. The server could be located on the MMI computer, or it could be embedded in the machine.
Reply to this post...

--------------------------------------------------------------------------------

Posted by sundog on 31 October, 2005 - 5:10 pm
SVG1.2 defines a general socket connection but I have no idea when this will be supported by Firefox and Adobe. I have also not yet figured out how exactly this socket connection can be used. Anyways, something to keep an eye on. I don't think you will ever get away from client side scripting but I am sure there are many companies out there working hard on building a template driven rapid application development environment, myself included.

 

Web based HMI - your thoughts
===============================

Posted by Nathan on 2 February, 2006 - 3:16 am
I'm currently promoting/providing information for FactoryPMI, a web deployed (Java Web Start) HMI. I'd appreciate links to other products as well as your thoughts (pros/cons, viability, etc). What has your experience been with APROL and ProcessViewBrowser?

Thanks for your time,
Nathan

-----------------

Posted by nathan on 9 February, 2006 - 2:05 am
Has anyone used a database driven scripting language to provide realtime web access to process data (PHP or ASP with a database backend)? I've also seen projects to connect PHP to certain AB PLCS. Anyone have experience with this?

FactoryPMI works well as a commercial web based HMI package. I like to follow the latest open source projects. Any info?

Nathan
--------------------------------------------------------------------------------

Posted by Terry Miller on 10 February, 2006 - 1:38 pm
Take a look at Indusoft Web Studio. They have a nice browser based approach and very cost effective. www.indusoft.com

Terry Miller
FlashPoint Technologies

Posted by Steve on 16 February, 2006 - 12:42 am
DHTML and AJAX are okay technologies in some places but if you want a real, full featured HMI and want to have it fully web-deployed without a per client licensing scheme then take a look at FactoryPMI.

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

--------------------------------------------------------------------------------

Posted by Steve on 9 February, 2006 - 12:31 pm
Nathan,

Seems like end-users love web-based solutions.

I'm all for Java Web Start because it gives you realtime interactive data and control and because it automatically deploys and keeps up to date any application deployed. Our customers think this is really cool stuff.

Steve
--------------------------------------------------------------------------------

Posted by Tim on 13 February, 2006 - 12:16 pm
Take a look at WebHMI from ICOINCS. Configuration is a snap, you can drag your existing GENESIS32 HMI screens into and they beome Web enabled. HTTP://WWW.ICONICS.COM
--------------------------------------------------------------------------------

Posted by Anonymous on 10 March, 2007 - 3:33 pm
Also, you can look at Outlaw Automation's webHMI demo at

http://www.icscada.ca
--------------------------------------------------------------------------------

Posted by Michael Griffin on 14 February, 2006 - 1:06 am
Be careful of ones that use MS "Active-X" controls. This is a technological dead end and should be avoided.
--------------------------------------------------------------------------------

Posted by Anonymous on 18 April, 2006 - 10:19 pm
Here's an article written by Steven Hechtman of Calmetrics Company that addresses you question on web based hmi systems. It specifically discusses pros and viability of web based hmi systems over traditional the hmi model.

http://www.engineeringtalk.com/news/csk/csk101.html
--------------------------------------------------------------------------------

Posted by CH on 13 March, 2007 - 1:47 am
Nathan,

I've used http://www.bastools.com/catalyst/default.php with really good success. Their direct drivers are limited, but they have an OPC Client driver.

I've also used the ICONICS WebHMI product. The ICONICS software's learning curve isn't nearly as steep as Catalyst PRO, but its cost may be a prohibiting factor.

CH

Web based HMI/SCADA
===========================
Posted by Anonymous on 14 July, 2007 - 9:18 pm
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!

--------------------------------------------------------------------------------

Posted by Anonymous on 15 July, 2007 - 1:38 pm
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."

--------------------------------------------------------------------------------

Posted by Nathan Boeger on 7 September, 2007 - 10:47 pm
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

--------------------------------------------------------------------------------

Posted by Michael Batchelor on 8 September, 2007 - 8:19 pm
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
--------------------------------------------------------------------------------

Posted by abhishek on 8 September, 2007 - 12:24 pm
check opcsystems a customized solution of asp.net with ajax interfacing plc driver via remoting may be right solution
--------------------------------------------------------------------------------

Posted by Carl on 9 September, 2007 - 11:43 am
indusoft.
http://www.indusoft.com/
Complete tool box. Mostly private labelled for OEMs as far as I can tell.

relies on OPC.
--------------------------------------------------------------------------------

Posted by Vimaris Grau on 22 September, 2007 - 12:49 am
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
--------------------------------------------------------------------------------

Posted by Brandon T on 10 September, 2007 - 11:34 pm
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.

--------------------------------------------------------------------------------

Posted by Michael Griffin on 12 September, 2007 - 1:21 am
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.

--------------------------------------------------------------------------------

Posted by Nathan Boeger on 28 September, 2007 - 1:05 am
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/
--------------------------------------------------------------------------------

Posted by Guy Oliver on 14 November, 2007 - 12:28 am
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.
--------------------------------------------------------------------------------

Posted by Keith Harris on 12 September, 2007 - 12:22 am
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. 

 

http://www.schneider-electric.co.uk/electricity.nsf/automation-control/hmi-human-machine-interfaces/web-based-hmi-solution

http://www.automation.siemens.com/hmi/html_76/products/software/wincc_optionen/navigator.htm

http://us.wonderware.com/products/appserver/