Promotion for Open Source HMI / SCADA system

[pvbrowser 0]

Process Visualization, HMI and SCADA as simple as browsing the internet http://pvbrowser.org pvbrowser is an application framework. It provides a specialized browser for the client computer and an integrated development environment for creating servers that implement your visualization. It also provides data aquisition programs (daemons) for a lot of protocols that connect the real world with your server. You can surf these visualizations as you do with an ordinary webbrowser. Many users from different places can use the visualizations at the same time. This can be limited to your local area network or across the internet. I do not know if this is classified as spam. At least it is on topic

[JesperMP 2]

You get my vote for that it is not spam. I am interested in how it goes. It looks slightly intimidating to my opinion. Is the server programming entirely in C or C++ ? Is there no graphical IDE ? Maybe it is not so difficult for a beginner if there are simple templates to start with. Apart from Qt, what software tools do you use yourself ? How does web clients update ? As far as I have seen with other Web-server solutions, they use a special Java component to achieve fast updates of the Browser HMI.

[paulengr 44]

No graphical IDE as such unless you use one of the common "forms builders" out there which gives you template code, but again, not the typical editting environment that you are probably used to. It's one of the biggest problems with that particular HMI. It's more like a specialized version of say the built-in forms system that you get with all major IDE's such as Netbeans, Eclipse, Visual Studio, etc. Java is NOT per se necessary to achieve fast updates. That's a bit of a myth. But if you were to do true browser-based HMI's (with Javascript), there are some problems to overcome: 1. How to connect the HMI to the data, with real time updating. The problem here is that a web browser is traditionally a "pull" system...the browser side initiates actions, while what one would desire is to "push" data. The solution is in the "comet" protocol. Essentially the web browser opens a data update request to the server. The server in turn responds as-needed with updated data. Then the browser immediately pushes out another request. If you overlap them, you can even defeat any round-trip time delay issues. 2. A related problem...how to get an HMI to pull data from non-HTTP sources. Alas this one is fairly hard to solve. There are ways to "jail break" a browser by the use of plugins but there is no general solution to make a browser for instance do "Modbus/TCP" without involving a server of some sort. Since many modern HMI's are in fact client/server based, this appears to be a non-issue. 3. Security. This is another tough nut to crack. The simplest backend would be say an OPC server (OPC/DA). The problem here is that if you made this sort of server accessible in a "raw" form via the web browser, then it wouldn't be long before someone would figure out that you can read/write ANY data to the backend with no security. So clearly the security aspect of things has to be handled at the server end. Similarly, protection has to be built in to prevent someone from simply doing a "Save As..." and then passing a secure web page to a non-secure browser. This is simple to do with session keys and such at the server level, but again, must be implemented properly. 4. The speed question. I think this one is much less of an issue than folks make it out to be. Here are some demos to show what I mean: http://maps.google.com/ http://www.simile-widgets.org/ http://demos.dojotoolkit.org/demos/cropper/ Note that 2 or 3 years ago, the speed question was a big issue. And development was just plain horrible in the Javascript world. However, times have changed. Very modern libraries such as http://www.dojotoolkit.org/ have come into play and are getting better all the time. They are also being highly compressed and modular to make them very light weight so that you don't spend a considerable amount of time downloading unnecessary overhead code. Most browsers are now starting to support very high end graphical features such as SVG and Canvas. This is not a prerequisite to high quality HMI's (especially with a library like Dojo) but it certainly doesn't hurt! The final problem of course is that like it or not, in the end, Javascript really isn't all that fast since it is interpreted. However, even that issue has very recently in the last year or two become a moot point. The key to the solution is something called a tracing compiler: http://www.usenix.org/events/vee06/full_papers/p144-gal.pdf http://andreasgal.com/2008/08/22/tracing-the-web/ The amazing thing about this style of compiler is that it can achieve close to 90% of the speed of the Sun Java 5/6 compiler but does so with a fraction of the code size, memory footprint, and coding time. Essentially the entire compiler can be realistically built in about a year as a graduate project. Fortunately, nobody has to do this. Firefox 3.5 (going to be released any day now), Safari, Chrome, and I think even Opera all have such compilers today. The performance that these javascript compilers bring to the table is nothing short of amazing. That leaves just one final sticky issue. None of these features are available in Internet Explorer. So if you want across-the-board support for these kinds of features, you have to make it browser-specific, or at least browser-antagonistic towards one particular 90 pound weakling in the browser wars. Items 1-3 can be neatly sidestepped using Java outright since it can directly handle all 3 issues even in a serverless scenario. So to be fair, it's not that Java is a prerequisite. It just makes life easier in many cases. Now here's an experience where I actually implemented such a monster. In the last plant I worked at, it was a GE Fanuc Proficy Cimplicity house. We had extensive experience with it all the way around. We used the web-based version a lot in many places where we needed a "temporary" HMI (such as giving supervisors an "HMI" on an as-needed basis to monitor/control plant-floor activities). The actual implementation is a bit long in the tooth but works like this. It runs a captive version of the standard Cimplicity HMI on a server. The captive version writes to a screen buffer rather than to the normal desktop. Then the server portion does screen scraping and sends the updates to a special Java applet. It works almost identical to RDP or VNC in practice. Even more interestingly, Neoware was a thin client manufacturer. Before they were absorbed by HP, version 4 of their software supported plugins, of which one such plugin was Firefox 2 and Java. We actually loaded up Firefox/Java and pointed it to the Cimplicity web server, which produced a "serverless thin client"...the thin client was directly running the Java version of Cimplicity off the Cimplicity server without a "thin client server" involved in the middle. It ran alongside a traditional thin client operator station. In terms of stability, both systems were rock steady. There were three limitations on the web-client version. First, the Cimplicity Java implementation is getting very long in the tooth (still almost identical from version 4 and Cimplicity is now at version 8). Many ActiveX plugins just don't work quite right. Second, we never quite got "kiosk" mode to work in Firefox so we could never quite get rid of the very obvious Firefox menu bar at the top of the screen. Third, and this was our setup,

[pvbrowser 0]

We do NOT use a standard web browser based on html and http. Instead we have build a specialized browser for HMI / SCADA purpose which uses Qt http://www.qtsoftware.com/ This browser operates on widgets that Qt provides. > Is the server programming entirely in C or C++ ? The client is programmed in C++ using Qt. The user of pvbrowser will not have to change the client. The server is programmed in C/C++ without usage of Qt. Furthermore the server may also be done in Python. > Is there no graphical IDE ? There is an IDE (pvdevelop) that supports the user. The IDE will generate the sourecode framework for your server and allows you to graphically design your masks. Alternatively you may design your masks using "Qt Designer" provided by Nokia with it's Qt. > Apart from Qt, what software tools do you use yourself ? - We use g++ / MinGW depending on operating system. - We use Inkscape for designing SVG graphics used within the masks. http://www.inkscape.org/ - We use Qt Designer - We use Autodesk/Autocad DWF files for importing CAD graphics. - We use swig for integrating language bindings like we have done with Python. http://www.swig.org/ - http://qwt.sourceforge.net/ is integrated within pvbrowser > How does web clients update ? The server sends a string with a newline at the end. The client will interpret that string and call the according Qt method. The client sends a string with a newline at the end, when the user does a action like clicking a button. No scripting, no Java Script ... is needed. The solution is much faster than html based HMI with normal web browsers.

[JesperMP 2]

Thanks for the feedback "pvbrowser". This is all very interesting.

[pvbrowser 0]

> 1. How to connect the HMI to the data, with real time updating. The problem here is that a web browser is traditionally a "pull" system... We solve this with a connection oriented client/server architecture on the TCP/IP transport level. Both client and server may send ASCII strings terminated with "\n" at the same time. The opposite side will interpret that string and do something. (The client call a Qt method to update the widgets. The server will call a "slot" function where the developer of the server can handle the event) > 2. A related problem...how to get an HMI to pull data from non-HTTP sources. We use a shared memory and a mailbox for this. A separate daemon will talk the protocol of your fieldbus or PLC and write the data read into the shared memory. At the same time it is waiting on a mailbox where you can send messages to when you want to output something to the interface. See: http://pvbrowser.de/pvbrowser/pic/prinzip.png > 3. Security. This is another tough nut to crack. You may implement your own authorization within the server. (Remember that we use a connection oriented client/server scheme) Additionally you can use ssh for your connection http://en.wikipedia.org/wiki/Secure_Shell

[Sleepy Wombat 27]

A little off topic, but Paul.. when are you going to write a book or novel.... judging by the effort you seem to put into your responses you clearly have an extensive knowledge and a talent of putting thoughts to words..

[paulengr 44]

Wouldn't it be better if I put thoughts into code? At one time, let's just say about 5 years ago, I did a lot more coding than I have time for now. I was slowly working my way down a road to perhaps do something like an HMI. At the time, it was a much bigger uphill battle because the level and quality of tools available just wasn't there...would have been a lot more effort on my part. Now I still keep up on these things but I have far less time on my hands. It's not the job. It's having little ones running around the house.