advertisement
from the Automation List department...
SCADA system for Windows and Linux ?
Human-Machine Interface and SCADA. topic
Posted by Jim on 21 October, 2006 - 8:26 pm
Is there a good Open Source solution for SCADA on both Windows and Linux ?


Posted by Rokicki, Andrew \(Andrew\) on 24 October, 2006 - 8:38 pm
Try this it works with Windows and Linux.
http://pvbrowser.de/pvbrowser/index.php

I have tried it and it works very well.
Good luck.
Andy R.


Posted by Nathan Boeger on 28 October, 2006 - 3:48 pm
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


Posted by Paul Jager on 29 October, 2006 - 8:27 pm
Open source industrial doesn't really exist because there is insufficient demand to foster development, at least in North America.

You can run PLC-less and in Windows or Linux for a year with a nomimal fee at http://www.automationX.ca

Paul Jager
www.automationX.ca


Posted by Nathan Boeger on 2 November, 2006 - 11:45 pm
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"


Posted by Curt Wuollet on 29 October, 2006 - 8:21 pm
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


Posted by Nathan Boeger on 1 November, 2006 - 12:05 am
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"


Posted by Michael Griffin on 4 November, 2006 - 9:22 am
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?


Posted by Nathan Boeger on 9 November, 2006 - 1:05 am
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"


Posted by Marc on 12 September, 2008 - 12:32 am
On my first "big" project it was fascinating to work with a SCADA system built, by the maintenance manager, in a fit of petulance and anger at vendors.

(VENDOR: "You don't REALLY mean you REALLY want us to do ALL of that, did you?")

Scenario was to totally abandon 1930's Waste Water plant and build a new one from scratch.

He wrote it in DOS. Totally self taught he coded, created GUI's, created his own SCADA, wiring, communications, PLC programming, etc. etc. Win NT 3.5, All from scratch.


Posted by Curt Wuollet on 4 November, 2006 - 3:41 pm
> 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


Posted by Nathan Boeger on 9 November, 2006 - 1:38 am
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"


Posted by Curt Wuollet on 12 November, 2006 - 6:31 pm
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


Posted by Curt Wuollet on 5 November, 2006 - 8:29 pm
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


Posted by Jimmy on 16 February, 2007 - 11:58 pm
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.


Posted by Stefan Tomecko on 2 March, 2007 - 7:30 pm
Thanks for supporting Linux platform. By my opinion Linux will we major platform for controling industrial processes in a few years. Combine your SCADA with Linux-based PLCs we have a great solution

Stefan Tomecko
KSA s.r.o., Slovakia
stefan.tomeckoNOSPAM@ksautomation.sk


Posted by Rainer Lehrig on 3 November, 2006 - 2:37 am
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


Posted by Rainer Lehrig on 4 November, 2006 - 9:26 am
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.


Posted by Nathan Boeger on 13 November, 2006 - 11:46 pm
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"


Posted by Rainer Lehrig on 21 November, 2006 - 10:50 pm
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


Posted by Anonymous on 13 February, 2007 - 12:43 am
Good Scada system at http://www.neutech.co.in
product: Alavu


Posted by Anonymous on 26 February, 2007 - 11:58 pm
Thank you.


Posted by Nathan Boeger on 13 February, 2007 - 8:51 pm
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


Posted by Matthew Lohbihler on 11 April, 2007 - 10:46 pm
Mango M2M is also Java based, and so will run on Windows and Linux (see http://mango.serotoninsoftware.com). And unlike the other options mentioned above, it is in fact entirely open source and free to use. Some details...

Mango M2M is browser-based, Ajax-enabled M2M software that enables users to access and control electronic sensors, devices, and machines over multiple protocols simultaneously. It provides an interface with which diverse data sources can be created and configured along with an intuitive rules engine for setting up access, monitoring, alerts, data logging, control, transformation, and communication.


Posted by Wayne on 16 October, 2008 - 1:49 am
You should have a look at MacroView.

It's a Linux, Solaris and Windows based SCADA/HMI system that has been proven on many sites.

It's not open source buta free linux download available at http://www.sencom.com.au/


Posted by Bill McEachen on 12 February, 2009 - 9:51 pm
Well, to update this thread, we are using an open source system (Linux/Java) packaged by Transdyn. It is not free - see their website transdyn.com. We are a real-life industrial full scale wastewater facility


Posted by Nathan Boeger on 2 February, 2010 - 10:01 am
This thread is old but still relevant. There is now a viable Linux control software package - Ignition by Inductive Automation is a full fledged SCADA platform that runs pure Java - so it'll run on Linux or Windows. It uses OPC-UA, which is much more cross-platform friendly than the old DCOM based legacy OPC (OPC-DA). They're working on releasing an API that would allow developers (hopefully including the Open Source community) to freely write modules that would also run cross-platform.

----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com


Posted by David Lutolf on 25 August, 2010 - 1:22 pm
I am currently in the process of writing an open-source framework (in python) to allow easy integration of any type of devices into a larger system and provide a unified interface. short and simple code, retrofit of existing installations and implementing custom hardware were major concerns during development

while this may sound crazy, it was made possible by using an architecture very similar to that of PVSS, using HALs (hardware abstraction layer) where PVSS uses drivers. it should be possible to implement HALs directly on microcontrollers.

desired behaviours can be implemented in ANY LANGUAGE, providing it can use stdin and stdout for communication

a web-based GUI is in writing just now ; already available is a simple CLI (less than 20 lines of code)

for now, the beta version is available for download on http://david.lutolf.net/dt/locmon


Posted by pvbrowser on 27 August, 2010 - 3:05 am
We use separate daemons for acquisition of variables across the field also.

See:
http://pvbrowser.de/pvbrowser/pic/prinzip.png

Each daemon can speak the protocol of the fieldbus or PLC. Many daemons can run on different protocols at the same time.

The result is stored in a shared memory.

You could store the result in a database also.

You could use OPC UA or the protocol of your device.

You can implement the daemon in any programming language. But there exist daemons for the most popular protocols that need only to be adjusted with an INI file (written in C/C++).

See:
http://pvbrowser.org


Posted by Alejandro on 31 October, 2009 - 11:58 am
Argos SCADA Project: www.cintal.com.ve/argos


Posted by Kurt Braun on 4 February, 2010 - 6:22 pm
Here is a list of open source SCADA software:

-- Released Versions --
1. pvbrowser.com linux/gpl/gtk/opc/germany

2. mangom2m.com linux/gpl/java/usa

3. www.proview.se linux/gpl/modbus/java/swedish

4. www.openscada.org linux/java/beta/germany

5. likindoy.org linux/gpl/python/spanish

6. szarp.org linux/gpl/modbus/polish
-- Still in development --

7. beremiz.org linux/gpl/iec editor/beta/china

8. visual.sourceforge.net MSwin/alpha

9. linuxcnc.org linux/cnc control/serial/alpha

10. lintouch.com linux/WW clone/alpha

11. mblogic.sourceforge.net MSwin/.net/alpha


Posted by M Griffin on 5 February, 2010 - 12:41 am
In reply to Kurt Braun: Some of the items on your list are incorrect.

1) pvbrowser.com linux/gpl/gtk/opc/germany
The person behind that one posts on here regularly, so he can address the details himself, but a couple of points are: it is Qt, not Gtk, and most of the main protocols it supports are through rlib, not OPC. I believe that it does have an OPCXMLDa shim, but that is through rlib.

3) www.proview.se linux/gpl/modbus/java/swedish. I think it's actually C/C++, but it does have a Java interface. It also supports several other protocols besides Modbus.

7) beremiz.org linux/gpl/iec editor/beta/china. This is a soft logic system and nothing to do with SCADA. Also, it is based in France, not China. I also would consider it to be production software as a company is scheduled to be shipping products based on it this spring.

9) linuxcnc.org linux/cnc control/serial/alpha. This is CNC controller software and nothing to do with SCADA. It is also not "alpha" software. They are on version 2.3, and people have been controlling CNC machines with it for a while now.

11) mblogic.sourceforge.net MSwin/.net/alpha. That is my own project, and none of that information is correct. I do not consider it to be a SCADA system. It is multi-paltform (Linux and MS Windows, *should* work with BSD and Mac OS/X but does not tested on those platforms). It is all Python, not DotNet. It is not alpha software, but ready for production use.

For some of the others I can't say whether the information is correct or not.


Posted by pvbrowser on 5 February, 2010 - 9:13 am
The URL is http://pvbrowser.org
Yes, we use Qt http://qtsoftware.com
We support various protocols either with rllib or foreign software.

Our principle for data acquisition is shown here:
http://pvbrowser.de/pvbrowser/pic/prinzip.png

You can have daemons for almost any protocol.

For example OPC XML/DA is implemented by "nanohttp", "libcsoap" and "libxml2".


Posted by Kurt Braun on 5 February, 2010 - 3:09 pm
Thanks for the clarification, these were some notes that I had made a while back and thought I'd post them. I apologize for any errors the list contained! I probably should have left off my comments in the list..


Posted by bixo on 31 May, 2012 - 4:28 pm
12. sourceforge.net/projects/argos-scada/linux/gpl/fltk/venezuela

> Here is a list of open source SCADA software:


Posted by Nathan Boeger on 22 December, 2010 - 8:20 pm
As an update - FactoryPMI and FactorySQL are still relevant to this post, but have been unified to a single platform, Ignition. The SCADA package runs equally well on Linux, Windows, or any platform that supports Java. Ignition also includes a native OPC-UA driver for PLC connectivity.

This video depicts how it all fits together.
http://www.youtube.com/watch?v=7RWmfIVDkN8

-----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com


Posted by fede on 15 April, 2011 - 3:49 pm
Thanks for the discussion, it was quite interesting to read. Although it is such a pity that there is no open source SCADA. OpenERP is a fantastic open source ERP, why could not be possible to create a similarly openSCADA? And a module to link them both ;) ?

Thanks again


Posted by avra on 18 November, 2011 - 5:37 am
An open source SCADA available for Windows, Windows CE and Linux:
http://pascalscada.blogspot.com

Moderator's note: this site is in two languages, scroll down for English.

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
The road to hell is paved with good intentions. And littered with
sloppy analysis!
Advertise here
Advertisement
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive