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?

 

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.

 

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.

 

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.

 

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.