pvbrowser

Is Open Source HMI/SCADA mature enough for you ?

7 posts in this topic

Today we have published pvbrowser 4.5.6 http://pvbrowser.org Have you ever tried pvbrowser or other open source solutions for HMI/SCADA ? How mature are open source solutions in your opinion ? pvbrowser, pvdevelop are under GPL license our libraries are under LGPL license

Share this post


Link to post
Share on other sites
1. The achilles heel with most PC/PLC communications is just that...communications. If you are using Modbus or Modbus/TCP since it's an open standard then no problem. However, not every PLC supports this. In the U.S., the most popular hardware platform (Allen Bradley) chose to support the ODVA's "open" protocols rather than Modbus and Modbus/TCP. There is support but it's limited. Right to begin with, this is tantamount to a nonstarter. On the proprietary platforms today, they almost always default to using an OPC server. In the past this was a major nonstarter unless you tied yourself to a Windows platform for the most part. Recently Inductive Automation released their OPC-UA server which is written in Java. Not open source but a major step forward. Last I looked, pvbrowser doesn't support OPC at all, so then it becomes a question of whether or not a particular PLC platform has direct driver support. 2. I'm not impressed at all with doing any sort of development that requires me to use Glade or QtDesigner or something like that to develop HMI screens followed by hard coding in C. That model of development is not the way it's done anymore. That's not the way that PC or web programmers do it (they use Microsoft Visual Studio, Netbeans, or Eclipse). And it's certainly a far cry from the way it's done on proprietary HMI/SCADA systems where sometimes you don't even have access to the raw code. No commercial HMI on the market in this day and age uses this model for development. 3. In this respect, pvbrowser is nothing special at all. I can get better support and a better IDE overall if I use Netbeans, Eclipse, or Microsoft Visual Studio. Of those, both Netbeans and Eclipse are open source projects. I don't even have the closed source problem of dealing with the Qt libraries and their anti-Microsoft licensing should I choose to do development on a Microsoft platform. The huge downside here is that you have to be a PC programmer to do development. Many (most?) HMI/SCADA developers are NOT PC programmers, yet they can crank out pretty good HMI's using proprietary platforms. Doing the same thing on Netbeans/Eclipse/Microsoft Visual Studio to say nothing of QtDesigner+some sort of C IDE is daunting to say the least. So in closing at this point, my answer is a resounding no. We aren't anywhere near mature in the open source HMI/SCADA development arena yet, and pvbrowser is a far cry away from this. Mind you it would not be hard at all to implement a customized interface on top of Netbeans similar to how Jasper Report's "ireports" works which hides some/all of the ugly details while harnessing the Netbeans IDE. Certain pieces (the PC/PLC interfacing, "historian" style data collection to a database, an expression interpreter that understands "tags", a dozen carefully chosen typical faceplate/animation objects that duplicate expected HMI functionality) are all that separate a truly great open source HMI/SCADA from the commercial ones. The amount of code actually necessary to do this is not onerous at all. It might even be possible to do this with pvbrowser by harnessing Netbeans or Eclipse. But to suggest that we are "there" is simply not the case. Take a look at Ignition from Inductive Automation. It's not open source and it's definitely not free (in many cases), but it's darned close to what I was hoping pvbrowser would eventually become. I believe the problem with pvbrowser at this point is that at the time that it was originally written, it used arguably one of the best development environments available at the time, and still does pretty good for C programmers. Times have changed however and at this point in the open source world, we would be better arguably with a more "JSP" or "JSF" type model. The model could of course be based on Python or outright Javascript, but it's unlikely to be based on C because C is more of a systems/backend development system and just doesn't have the required richness or interactivity of a modern web application server environment. If I did a refactoring of the "pvbrowser" model today, first, I'd adopt Netbeans as the IDE for constructing the system. It doesn't suffer from the "schizophrenia" issues of Eclipse and it is very easy to plug into it with your own development environment customizations. Second, I'd implement the "server" code in Java, probably with Jython or Javascript (Rhino) extendability built into the core. Third, I'd take a hard look at Inductive Automation Ignition as an implementation model, even if I make completely different design decisions. Fourth, I'd use outright Javascript (probably using Dojo) as the language for the HMI front end. Reason being that Java and java servers are really well built when it comes to back-end functionality and have a lot of nice features (like built-in multiprocessor/multi-server support), while Javascript is very light weight and works well with web browsers (since it's the browser's native language) and has support on every browser available. After playing with Dojo for a while over time, I'm convinced that Javascript is very maligned as "slow" when in fact it definitely isn't that way anymore. We already have the hardware if this is the model. I have a thin client sitting right here on my desk for $200. It supports touch screens and has Iceweasel (a version of Firefox) built in. All I need is for someone to write the HMI application server that I'm going to key in as a web server address to point it to, and it becomes my "open source HMI" hardware platform for plant floor machines with the addition of a Nematron touch screen/monitor. Arguably pvbrowser is already "there" as far as the HMI hardware is concerned but just providing similar look-and-feel at the very end (in the browser) isn't enough.

Share this post


Link to post
Share on other sites
my opinion is, every works has it own class, no works is unused in this world keep on the good working if you will create, that's ok, if you will buy, that's ok, every thing has it own risk if you want to steal, well that's NOT ok

Share this post


Link to post
Share on other sites
Some comments to your reply. I think dismissing C/C++ for development is a mental problem. The C code necessary to do in pvbrowser isn't more complex that doing script programming. I have seen PHP code for websites that is much more complex. In fact you only fill out the "slotFunctions" that handle high level events. We use our own IDE (pvdevelop) for creating the servers, especially the integrated designer. But you can use Qt Creator and Qt Designer without problems, because you can import/export UI files and the Makefile is generated by qmake anyway. If you want to use SVG for your masks you can use inkscape for example. Furthermore WebKit is integrated into pvbrowser. We support more than Modbus. See: http://pvbrowser.de/pvbrowser/index.php?menu=4&topic=4&subtopic=2 Where OPC XML-DA is the only OPC version we currently support. But you can interface to any datasource with our shared memory and mailbox. See: http://pvbrowser.de/pvbrowser/pic/prinzip.png

Share this post


Link to post
Share on other sites
Those who do not like C programming can do it in Python.

Share this post


Link to post
Share on other sites

Hello,

I have an issue doing the installation process. I am not able to open the pvdevelop the erro message is:

/opt/pvb/pvdevelop/pvdevelop: error while loading shared libraries: libQt5WebEngine.so.5: cannot open shared object file: No such file or directory

 
Could you please help me with it?

 

 

Share this post


Link to post
Share on other sites
On 12/12/2010 at 6:14 PM, paulengr said:

Recently Inductive Automation released their OPC-UA server which is written in Java. Not open source but a major step forward.

Ignition isn't open-source, but their OPC comms, both client and server, are built on top of the open source Milo project in the Eclipse Foundation.  To which Inductive Automation donates the time of one of their top programmers.

Concur on your points, fwiw.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now