I have spent a bit of time thinking about how to get started on some kind of HMI. I think that for my first pass I'll have to simply use a graphics library and write a C program. My wife really wants me to get that hole in the wall filled with the touch screen that I promised her. Once that is done I can start building an HMI and finish refining the backend. I hesitate to finalize the entire backend API before I try and build some of these other modules. Each module has some unique requirements and as I write code for the modules I start to see how the backend can be tailored to make the module building easier. This is important because the easier and cleaner the module building API the more modules will be built, and that will dictate the success of this project more than anything else.
The HMI module will probably be more of a programming challenge than all the rest of the system combined. I am the worlds worst programmer when it comes to using other peoples code in my own projects. I tend to want to write the code myself instead. That's fine when the goal is to learn something. It doesn't work too well when the goal is to get a piece of software out the door. With that in mind, I have been trying to find ways to shortcut the HMI module and use existing software when available.
First it seems almost obvious that SVG should be used as the file format for HMI screens. Everything needed to render an HMI screen including hooks for animations is included in the SVG specification. SVG is to images what HTML is to text. One of the biggest problems with most traditional HMI's is scaling the images. That's what the S in SVG is all about, scaling. The DOM (Document Object Model) is part of the SVG specification. This exposes all the properties of the objects to other parts of the system. This is how the animations can be produced. Properties like fill color, border width etc are all exposed through the DOM and therefore should be able to be manipulated via scripts and/or code. I'm sure the DOM was designed with JavaScript in mind but there is no reason that we can't use it for our own benefits.
Obviously with SVG we will almost certainly have to use libxml or something similar to parse the SVG file and feed it to the rendering engine, but the more popular SVG gets the more likely this functionality will be built into some other library. There is a library that is part of the GNOME project called librsvg, that renders SVG files directly. It may work okay for our purposes but it seems very static in nature. (I haven't really looked at it that closely yet) It looks like it is designed with the idea of turning SVG files in to raster images. I can't find where it has any hooks for animations. It will use the Cairo drawing library (see below) and I'm convinced that Cairo is the way to go for drawing to the screen. I'll have to keep a close eye on librsvg. Once a browser (probably FireFox) starts exposing the DOM to JavaScript we'll probably have the library that we need. Of course we could always add the functionality to librsvg ourselves. That is after all the beauty of open source.
Cairo is a 2D vector graphics drawing library. It has multiple output channels that can be used to render the resulting graphics. It can render to Win32, GTK+, Quartz, PDF, PNG etc. Once the code is written to tell libcairo how to draw the screen it doesn't really matter what the screen is. Firefox uses Cairo to render SVG files now and will use it to render everything in Firefox 3.0. If the Mozilla team is planning to use the library it will be a reliable, full featured library, that should suit our needs perfectly.
We'll need some kind of scripting language. I have not spent much time looking into the different extension languages. The four that come to mind are Ruby, Python, TCL and Guile (I know, Perl should be in this list, but I hate Perl). As much as I like Ruby it's ability to be embedded into other programs is weak. It wasn't written into the language from the start and it's not a priority of the developers. The other end of that spectrum is Guile. This is the GNU projects embedded scripting library. It would suit our purposes but the primary language is Scheme. Scheme is a LISP lookalike language that is going to turn people off. I know there are some interpreters that will let Guile use other languages and I'll keep my eye on those. So what about Python and TCL? I don't know that much about Python. It seems to be pretty popular so there must be something good about it. Of course Perl is popular and I despise programming in Perl, so who knows. TCL was designed to be an extension language and is the one that I am looking at right now. I reserve the right to change my mind though.
In any case the scripting language should be one that newcomers will find easy to learn. HMI scripts don't need to do much so it won't have to be too feature rich. If anything complex needs to be done it's easy enough to write other modules to handle them in other languages that are more appropriate to the task. The HMI scripting language needs to be something that Bubba can learn quickly.
Traditional, commercial HMI's have capabilities that I personally believe shouldn't be included in the HMI module for OpenDAX. In DCS type systems these features tend fall somewhere in the gray area between the logic and the interface. In OpenDAX I think that any feature that is not displaying information to a user or getting information from the user, should not be part of the HMI module. The two most obvious examples are Alarming and Trending. Most (if not all) standalone commercial HMI applications have some kind of alarming infrastructure built in. This becomes troublesome when the philosophy of the built in system is not exactly what the user requires. Then it becomes a configuration problem or some kind of workaround that uses external logic or scripting to handle the exceptions.
Why not have the alarming functionality in another module? When that module decides that there is an alarm that needs to be displayed it can store it in a database. Then when the HMI decides to show the alarms it asks the alarm module to give it a list of all the alarms that need to be displayed. This frees the HMI from having to make these decisions and it simply becomes a matter of displaying a list. This separation allows for different alarm modules to exist and different HMI modules to exist and neither cares about the other. Imagine an HMI that is nothing but a single line marquee display. The user simply decides which HMI he/she likes and which alarm module has the features they want. There will need to be some kind of protocol decisions made on how the information in the alarm module is transfered and that may evolve but I think it's still better than trying to get HMI software to do things other than interface with the human.
Similar arguments apply for event logging and trending as well. I could even be convinced that security should be handled in a module outside of the HMI. These are all things that should be discussed
Once we've figured out a way to render the graphics and handle the animations and scripting, we'll need a way to generate the SVG files to begin with. This is what I had always thought would be the most difficult part. Now I think it may be the easiest. Once it's decided to use SVG as the format for the screens it becomes almost trivial to generate the graphics. There are all kinds of SVG editors out there and as the format grows in popularity there will be more and more. Right now it looks to me like Inkscape is the king of the mountain. It has everything we need. It runs in Linux, OS X and Windows, and SVG is it's default file format. It has the capability to be extended with plug-ins (I think they call them extensions) but I don't know to what extent these 'extensions' can be used to add functionality to the program. It would seem that at some point an OpenDAX extension could be created that would allow for animations and scripting to be edited right in Inkscape.
I still need to look into how to make all this stuff talk to each other but at first glance it seems like at the very worst all the HMI module needs to be is a way for SVG files to be converted into animated images on the screen with hooks to the SVG DOM to the OpenDAX backend and an embedded scripting language. I'm sure that it'll be more complex than that in practice but it sure seems like the direction to go.
I've seen some hints at other SVG based HMI's but I don't know if any of them are mature enough to simply use yet. I'll keep my eye on those too.
As always suggestions are welcome.