SCADA system for Windows and Linux ?

N

Nathan Boeger

I've yet to see a good free or Open Source SCADA package. By "good" I mean something that I would trust to control a real industrial process.

FactoryPMI is a low cost commercial SCADA package that will run on both Windows and Linux. You can download a fully functional free trial (limited to 2 hour runtime at a time) from the web site.

You'll definately want to go with something that's Java based. I second Andrew in that PVbrowser seems to be the most developed open source SCADA project. It's been around for quite a few years and they are actively working on it. There are a few other similar projects on Sourceforge, but they're much less mature. I would avoid the open source controls C projects like the plague.

--
Nathan Boeger
http://www.inductiveautomation.com
 
C

Curt Wuollet

Hi Nathan
I'm curious, why would you avoid the Open Source Controls C packages like the plague? Particularly since Microsoft supports Java like a rope supports a hanging man.

Regards
cww
 
N

Nathan Boeger

Cww,

You make an excellent point! Here's my opinion on the matter:

-If you want to go with Microsoft on the SCADA (presentation layer), that's not a bad choice. For device communication in general, OPC is the reigning champion. OPC is DCOM based so Microsoft works out great. You also have the flexibility to use modern technologies for web launched applications, and in doing so, are moving toward the direction of OPC-UA and forward. I'm specifically referring to the use of: XML, web services, security models, etc that have been lacking by implementing the project in .NET. Doesn't really matter if you prefer C# or VB.NET, the point is to avoid ActiveX, COM, and older more painful technologies as much as possible. The bad about going with Microsoft is that your stuck in a Windows environment and that they hose their users all the time with new OSs/technologies, service packs, patches, flaws, etc that programmers will have to support over time.

-Java is my personal preference for the application layer because it works so well on pretty much any platform. Java Web Start in particular is awesome for launching applications, specifically SCADA, without a client side install of any kind. It also does a great job handling version updates. Check out FactoryPMI if you want an example of how that works. As far as Microsoft not supporting them, legality issues of MS writing and distributing their own JVM and refusing to distribute Java with new machines is futile. There's far too large a Java install base for Microsoft to slow them down.

-As far as C - I have no particular qualm with the language - but all the open source projects for controls, especially HMI/SCADA systems that I've seen written in C are light years behind. They are typically old projects where participants totally re-invented the wheel from scratch. They tend to be the most immature projects with the longest to go before being useful - or stable. And managed code is so much nicer! My guess is that most programmers would begin with modern technologies. The obvious exception is when doing projects that are very device specific and limited in scope. Well, that's why I would avoid the C Open Source Controls projects like the plague. If there are mature ones that work well I'd love to be proven wrong. Post a link and I'll check 'em out.

----
Nathan Boeger, MCSE
Inductive Automation
"Design Simplicity Cures Engineered Complexity"
 
N

Nathan Boeger

Paul,

Good point about the insufficient demand for open source software. End users have been fed stories about open source not being viable for manufacturing. Last time I checked it's the industial software companies that have all the: bugs, patches, fixes, crashes, etc. It's interesting to present Open source software to manufacturing managers who ask questions like, "...MySQL, what has that ever run?" when they're depending on flat file logging or DDE connections over Excel or whatever. Trying to "sell" them on Linux has been even worse for me. Totally upsidedown and backwards! But you're right, the (industrial) open source community can only thrive if Industrial users subscribe to it.

----
Nathan Boeger
Inductive Automation
"Design Simplicity Cures Engineered Complexity"
 
R

Rainer Lehrig

We have build pvbrowser

http://pvbrowser.org
http://pvbrowser.de/home/mediawiki/index.php/En:pvbrowser_manual

It is already used in several industrial areas.
See screenshots and documentation.

pvbrowser is based on Qt from trolltech and thus is very portable.

Here are our characteristics.

pvbrowser is a [SCADA] software under [GPL] or commercial license.
With the GPL license you have to contribute the code of your pvserver to our project
With the commercial license you are allowed to create and sell closed source software
This are the features of pvbrowser:
Client/Server
Qt Widgets
Custom Widgets
platform independent
SVG Graphics
xy Graphics
3D Graphics
pvbuilder
Design by Qt Designer
C/C++, Python, Perl, PHP, Tcl
Multithreaded or Inetd
Unicode support (Chinese, Arabic, Cyrillic, ...)
Support for ssh-urls
Connections to Fieldbuses
Connections to PLC's
Manage background processes
Central event log
Build your own authorization
GPL License
commercial License
 
M

Michael Griffin

One of the problems with both Java and dot-Net is that the applications are sometimes sensitive to the version of the VM you have installed. If the PC is only used to run the SCADA application and nothing else, this may not matter. If several different Java or dot-Net programs are being used, this can be a problem (rather like "DDL hell"). This tends to be of a problem on client applications than on the server side. How do you deal with this?
 
R

Rainer Lehrig

I forgot to tell you which version to download:

pvbrowser+pvdevelop Qt-4.x version for all supported operating systems (binary+sourcecode):
Download:
http://pvbrowser.de/pvbrowser/tar/pvb.tar.gz

### Installation ################################
### Windows: ###
With WinZIP unzip pvb.tar.gz where you want it.
goto the unzipped directory
double click setup.bat
logout and login again, so that the registry settings become active.
then double click:
pvb\win\bin\pvdevelop.exe
or
pvb\win\bin\pvbrowser.exe
# Visual C++ must be installed in order to use pvdevelop
# pvbrowser does not need any registry settings,
# you can simply copy pvb/win/bin/pvbrowser.exe and Qt*.dll to any directory

### Linux: ###
# install Qt4 if not already installed
tar -zxvf pvb.tar.gz
su
./install
exit

Then use:
pvdevelop
or
pvbrowser
################################################

pvbrowser Qt-4.x
http://pvbrowser.org

Qt4 and Qwt are NOT sourcecode compatible with Qt3 versions.
Thus we have build a completely new pvbrowser + development package,
which should be compatible with existing pvserver's.
The beta can be tested on Linux, Windows and OpenVMS.
Please download the Beta and test it with your existing pvserver's.
All issues should be solved prior to the release version of pvbrowser Qt4.
 
C

Curt Wuollet

> Cww,
> You make an excellent point! Here's my opinion on the matter:
> -If you want to go with Microsoft on the SCADA (presentation layer), that's not a bad choice. For device communication in general, OPC is the reigning champion. OPC is DCOM based so Microsoft works out great. You also have the flexibility to use modern technologies for web launched applications, and in doing so, are moving toward the direction of OPC-UA and forward. I'm specifically referring to the use of: XML, web services, security models, etc that have been lacking by implementing the project in .NET. Doesn't really matter if you prefer C# or VB.NET, the point is to avoid ActiveX, COM, and older more painful technologies as much as possible. The bad about going with Microsoft is that your stuck in a Windows environment and that they hose their users all the time with new OSs/technologies, service packs, patches, flaws, etc that programmers will have to support over time.
>

Yes, tomorrow all your bright shiny new "innovations" will be abandoned just as
surely because investment protection is the nemesis of the MS business model.
Each year you can use the old, is a year they can't sell you the new.

If you can tolerate this manipulation and afford the churn and are willing to tithe to Redmond, you derive some benefit, which escapes me at the moment. But it is surely wonderful for them. I like that I can re use and run code from decades ago and no one can render it obsolete whenever they need to prop up their stock price.

> -Java is my personal preference for the application layer because it works so well on pretty much any platform. Java Web Start in particular is awesome for launching applications, specifically SCADA, without a client side install of any kind. It also does a great job handling version updates. Check out FactoryPMI if you want an example of how that works. As far as Microsoft not supporting them, legality issues of MS writing and distributing their own JVM and refusing to distribute Java with new machines is futile. There's far too large a Java install base for Microsoft to slow them down.
>

Yeah, right. They've done a pretty good job so far. Not that I dislike the idea behind Java. Imagine what it could be if the monopoly wasn't doing everything in their power to derail it. That's what C flat and much of the new stuff is
really about. They are the Dog in the Manger.

> -As far as C - I have no particular qualm with the language - but all the open source projects for controls, especially HMI/SCADA systems that I've seen written in C are light years behind. They are typically old projects where participants totally re-invented the wheel from scratch. They tend to be the most immature projects with the longest to go before being useful - or stable. And managed code is so much nicer! My guess is that most programmers would begin with modern technologies. The obvious exception is when doing projects that are very device specific and limited in scope. Well, that's why I would avoid the C Open Source Controls projects like the plague. If there are mature ones that work well I'd love to be proven wrong. Post a link and I'll check 'em out.
>

I'm pretty sure your Java tomes become C someplace along the way. The machinery is all written in C as well as all the fancy .NUT stuff. If it's modern enough for them
I suppose I'll have to suffer through. When you gain some perspective, you'll see that
what you are doing with the new languages is simply mechanizing re-use of canned
C routines. All you have to do to see that is to actually write a language. That's
why it's so hilarious to deprecate C. C++ for example is simply a preprocessor
for C. So, obviously, you can't do anything with XYZ that can't be done in C.
You only make it somewhat easier and much less efficient. There is a problem with OSS for automation in that there simply aren't that many programmers interested in automation for many reasons, not the least of which is that software quality, suitability and efficiency are at the bottom of the list as factors in what software automation people select. This is proven by the
fact that most choose the least reliable, least suitable and most inefficient base available for their products.

Regards
cww
 
C

Curt Wuollet

On Nov 1, 2006 12:05 am Nathan Boeger wrote:
> Cww,
> You make an excellent point! Here's my opinion on the matter:
>
> -If you want to go with Microsoft on the SCADA (presentation layer), that's not a bad choice. For device communication in general, OPC is the reigning champion. OPC is DCOM based so Microsoft works out great.

CWW: Except that the base technology has been deprecated by Microsoft and so is obsolete from the get go. Microsoft is a lousy choice for this and many, many other reasons, MS is perhaps the worst available choice because of their churn, record for reliability, forced obsolescence, bloat, resource requirements, immutability, monolithic structure and basic unsuitability for control or other hi-rel purposes. But this is not a reasoned, defensible technical engineering decision. It is what the rest of the company runs on, by reason of their monopolistic business practices making it as difficult as possible to select "best of breed" and mix technologies. That's why everyone in _this_ arena feels they have to use it and make the best of a bad situation. With anything like a clean sheet of paper or a level playing field, one would be ridiculed or fired for suggesting that you make your "line of business" systems dependent on 50+ million lines of demonstrably
insecure and notably unreliable code from a convicted monopoly with no second source. Especially one with a propensity to obsolete
technologies and leave you twisting in the wind. That is totally irrational and should get you kicked out of Business 101. So tell me again why Microsoft is a good choice. Or feel free to
correct me on anything that isn't true.

NB:
> You also have the flexibility to use modern technologies for web launched applications, and in doing so, are moving toward the direction of OPC-UA and forward. I'm specifically referring to the use of: XML, web services, security models, etc that have been lacking by implementing the project in .NET. Doesn't really matter if you prefer C# or VB.NET, the point is to avoid ActiveX, COM, and older more painful technologies as much as possible. The bad about going with Microsoft is that your stuck in a Windows environment and that they hose their users all the time with new OSs/technologies, service packs, patches, flaws, etc that programmers will have to support over time.
>

CWW:
Yes, which makes a rather stunning case for using technology you have some semblance of control over. Once the monopoly blinders are off, engineering and sanity may yet prevail.

Gotta run.
cww
 
N

Nathan Boeger

Michael,

Good point about virtual machine support - It is certainly something to consider.

Sun has been very good about this with Java. They've avoided the overimplementation that CWW complains about and have been good about backward compatibility. In windows, it's easy to have multiple versions of the JVM installed, and launch different applications with whatever JVM you want. This is something that Sun and IT departments will continue to support.

.NET has so far been good about backward compatibility, but M$ doesn't have the best record in terms of this. Further, they are notorious for requiring the VERY LATEST .NET framework whenever the program is compiled with a later version of Visual Studios. There will also be a combination of trusting them (ughh) and trusing that there's a large enough user base for them to support with similar issues.

Both are better than typical alternatives - albeit most SCADA applications have a long way to go to get to the quality of most commercial (and open source) software packages. It's a smaller market that we're dealing with and, in my experience, Integrators and end users have been very cautious to get away from the big (monopolistic) companies that have been ripping them off for a long time when controlling THEIR manufacturing processes. Let's face reality, I wouldn't want to get "cheap" with software costs on a package that will cost you 3-10x as much for the customization work and is running my $50mil plant.

----
Nathan Boeger, MCSE
Inductive Automation
"Design Simplicity Cures Engineered Complexity"
 
N

Nathan Boeger

Cww,

I get a kick out of your M$ rant and share many stated opinions. However, the readers here are probably more interested in what their current options are instead of an ideological battle of wits over theoretical implementations.

I wish that I could go to sourceforge.net and have tons of options of free controls projects that work well - like the myraid of free, solid SQL databases available or OpenOffice. This is just not the case. Other than that one previously mentioned project (forgot the name), I wouldn't let ANY of those projects near a production environment. Again, I wish I could, I want my message to WHOLLY SUPPORT open source, but at the current level of development the software should stick to running science fair projects.

That said, how do you communicate with industrial processes? I guarentee that your above average end user AND Integrator working together will not be able to write custom code to deal with their controls. If they do, kudos to them, but I've had to go back and try to work on these sort of projects 5 years later and they're orders of magnitude more difficult to go back to than old depricated HMIs AND MUCH TOUGHER to expand upon.

OPC-DA is built on old technologies (DCOM), but it's the best out there (Modbus has been around a long time too). It allows software to communicate with PLC devices. Yes, it's rooted with windows, but APIs are available in different languages. Here you don't have much choice - writting your own device drivers is a terrible idea in most cases.

To address your language comments:
-Java will never be "the next C" in terms of compatibility. Java is compiled down to Java Bytecode to be run on the "Java Virtual Machine". Operating systems must natively implement the JVM for support. This pretty much guarentees that Java will be able to run on whatever platform. C, by contrast, is "portable" meaning that you can compile the same code on different platforms, but one compilation will not necessarily run on future platforms. This leads to problems with higher bit operating systems, for example. For the record, .NET, is similar to Java in this regard.
-With regard to your C comment, machine controls are still written in C, but machine control is INCREDIBLY BASIC (not easier) in function. Newer and higher level languages shine in higher level function (like GUI work for SCADA systems, etc). And yes, C++ is a library extension of C, but I don't see how you can use that to conclude that everything should be done in C. Memory management, for example, is a pain in C or C++.

In conclusion, I think you're dead on when it comes to software quality, suitability, and efficiency in controls. This deals with both technology choice and actual implementation. The big companies especially have milked their monopolies and user's lack of education of existing commercial packages (SQL databases come to mind). Don't even get me started on their pricing schemes! But that's another topic entirely...

----
Nathan Boeger
Inductive Automation
"Design Simplicity Cures Engineered Complexity"
 
C
Hi Nathan

On Nov 9, 2006 1:38 am by Nathan Boeger wrote:
> Cww,
> I get a kick out of your M$ rant and share many stated opinions. However, the readers here are probably more interested in what their current options are instead of an ideological battle of wits over theoretical implementations.>

Attitudes like that certainly will help preserve the monopoly and keep automation shamefully behind the times contrary to logic and engineering imperatives. But, fortunately, I predict that the flock will be lead out of the badlands by those with the most to gain from having control over the OS situation. That would be the large automation vendors, to whom it means the difference between compromised reliability and enormous cost due to churn or the ability to further integrate and tailor systems to the requirements of automation rather than GeeWhiz office and document monopolization schemes.

Already one can purchase machines and systems free of crashware, using Linux for those functions that must keep running and benefit the most from flexibility and extendability.
Not from the US, but places where the adoration for Microsoft is eclipsed by more practical considerations. In my small orbit of influence alone we will have two such machines, printing being a business where crashes are exceedingly
expensive and interaction with the system is a critical part of process control. I expect to see this trend increase markedly as Windows goes the wrong direction.

Vendors are catching on to the fact that the Windows thing is customer driven and their interests are better served by letting their hardware and software drive the OS choice than the other way around. Engineering and pragmatism can't be ignored forever.

> I wish that I could go to sourceforge.net and have tons of options of free controls projects that work well - like the myraid of free, solid SQL databases available or OpenOffice. This is just not the case. Other than that one previously mentioned project (forgot the name), I wouldn't let ANY of those projects near a production environment. Again, I wish I could, I want my message to WHOLLY SUPPORT open source, but at the current level of development the software should stick to running science fair projects. >

With the inherent and extreme resistance to change and long life cycles in automation, that there is any development at all is rather a strong showing. And the chances of hanging in there long enough to become established
are certainly much better if you don't need to show a profit on the very high burn rate for new Windows development and overcoming churn.
It's no coincidence that the market is dominated by hardware vendors and diversified companies to whom software is a necessary evil or at
least can take the long view to making money. The advantages to them of severing the MS chains will only become more compelling as time goes on.

> That said, how do you communicate with industrial processes? I guarentee that your above average end user AND Integrator working together will not be able to write custom code to deal with their controls. If they do, kudos to them, but I've had to go back and try to work on these sort of projects 5 years later and they're orders of magnitude more difficult to go back to than old depricated HMIs AND MUCH TOUGHER to expand upon.
>
> OPC-DA is built on old technologies (DCOM), but it's the best out there (Modbus has been around a long time too). It allows software to communicate with PLC devices. Yes, it's rooted with windows, but APIs are available in different languages. Here you don't have much choice - writting your own device drivers is a terrible idea in most cases. >

Something simple, universal, and tailored to automation would be a vast improvement here as well. Getting the ball rolling is the big problem, after all it wouldn't be as hard to make Windows a participant in really
good solution as it will be to deal with the MS whim of the day.

> To address your language comments:
> -Java will never be "the next C" in terms of compatibility. Java is compiled down to Java Bytecode to be run on the "Java Virtual Machine". Operating systems must natively implement the JVM for support. This pretty much guarentees that Java will be able to run on whatever platform. C, by contrast, is "portable" meaning that you can compile the same code on different platforms, but one compilation will not necessarily run on future platforms. This leads to problems with higher bit operating systems, for example. For the record, .NET, is similar to Java in this regard.>

I know of very few real "write once and deploy anywhere" applications of any size in Java although the browser bits are manageable. But if past history is any indication, MS will perturb the .NET picture anytime there is a risk of any
true platform independence. C must be written specifically for portability and is not the whole solution here either. But at least you stand a good chance of compiling and running the OS independent parts on most platforms and
the compatibility is really pretty good, except on MS where what's behind the APIs is secret and the whole structure is much different. This is
not at all a technical problem, the incompatibilities are deliberate. Everyone
else values the advantages of portability and easy porting.

> -With regard to your C comment, machine controls are still written in C, but machine control is INCREDIBLY BASIC (not easier) in function. Newer and higher level languages shine in higher level function (like GUI work for SCADA systems, etc). And yes, C++ is a library extension of C, but I don't see how you can use that to conclude that everything should be done in C. Memory management, for example, is a pain in C or C++.>

I suppose it depends on your criteria. Working from a common body of tested libraries accomplishes much the same result as the "higher level" languages and the trend is towards interface builders rather than hand coding
anything. The output code may just as well be something efficient as long as it's reasonable to code the callbacks, etc. There are the scripting languages for trivial applications. Most Windows programs are nearly _all_ GUI,
the heavy lifting, if any, is done by the servers or services which IMHO should be written in the native systems language for which C is a good choice.

And as for memory management, the reason it's a pain is that everyone seems to want to do their own. The reason that HLLs avoid
this is simply that they enforce one system or another. There is no real reason that this can't be done with a C library, in fact most folks that code C for a living have written such a thing, its just that they can't see using anyone else's. If such a thing were made a standard library for GCC, for example and people could be convinced to write to it, the pain would go away. But such is the route to bloat
and overhead, so it will remain an option. All the automatic and convenient features of HLLs are not without their price, the efficiency and resource usage can be dismal, especially in a small program.

> In conclusion, I think you're dead on when it comes to software quality, suitability, and efficiency in controls. This deals with both technology choice and actual implementation. The big companies especially have milked their monopolies and user's lack of education of existing commercial packages (SQL databases come to mind). Don't even get me started on their pricing schemes! But that's another topic entirely...>

But.....the other views are merely extensions of our common ground uncolored, in my case, by not being snared in the regimented world of Windows development. It looks a lot different from the outside.

I have many more choices as to what language I use. For most code which will not be sold in volume or likely touched by anyone else, I could use anything I want. I use C because I like it, and it meshes with the systems programming. If you can know the systems code this provides great advantage. If you must program to blind APIs and the OS is a black box, the choices kinda go away, but that is also another story. Working _with_ Linux, I can do amazing
things with relatively little code. Writing to Windows, or another closed system, I might make other choices. I hope I never have to find out.

Regards
cww
 
N

Nathan Boeger

I wanted to set the record straight here. I've known about PVbrowser for awhile and never had the time to test it. It's one of the viable open source controls projects. Based on the look and feel of the screenshots I thought the client was Java based. That makes an open source C/C++ project worth looking into that supports both Linux and Windows - that I wouldn't "avoid like the plague".

http://pvbrowser.de/pvbrowser/index.php

I've yet to find any other C/C++ open source projects that are anywhere near this stage. I frequent sourceforge.net for this reason. Feel free to post links to correct me. I'd love to see more "developed" controls projects.

----
Nathan Boeger
http://www.inductiveautomation.com
"Design Simplicity Cures Engineered Complexity"
 
R

Rainer Lehrig

Why not test it?
It's simple and not time consuming.

Download:
http://pvbrowser.de/pvbrowser/tar/pvb.tar.gz
(appr. 20MB)

Windows:
Unzip pvb.tar.gz to destination
Double click Setup.bat in destination directory
reboot

Linux:
veryfy you have installed the Qt4 libraries
ls /usr/lib/libQt*
tar -zxvf pvb.tar.gz
cd pvb
su
./install.sh
exit
 
N

Nathan Boeger

It's worth mentioning again that FactoryPMI clients will run on both - as should all Java based clients. FactoryPMI isn't Open Source, but is considerably cheaper than its commercial counterparts. It works with open source SQL databases and is fueled by many open source projects: Tomcat core, JGroups multicasting, JFreeChart for graphing, HSQL internal database, and many other open source projects for functionality and drivers. This open source approach maximizes the "bang for your buck" factor and is probably as close to the idea of "open source" as any commercial industrial software vendor will come. I'd like to think that we are delivering much more value than you can currently get for a cheap price.

I would also point out that FactoryPMI/FactorySQL are considerably more mature and feature rich than any open source industrial control package. I say that without getting into it with PVBrowser. I commend their web based approach, efforts, and maturity. I can do a web demo for anyone that will prove this point. If any open source projects have a similar arrangement, I'd love to participate. I'm very open about discussing many products online.

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

----
Nathan Boeger
Inductive Automation - Total SCADA Freedom
 
Umm, but Java is non-deterministic. How can you use Java in situations that require event driven actions? IOW, where time is of the essence for, say, accurate and comprehensive data collection.

Losing several seconds worth of data (do I speak from experience here?) because Java suddenly decides to do some garbage collection rules it for anything time-critical.
 
Top