Poll about Open Source DCS/SCADA system.

R

Thread Starter

Robert Perez

Hi,

I'm the designer and sponsor for an Open Source DCS/SCADA system in development and would like to create a poll to gather information to decide the feasibility of investment in this project.

By this mean I'm asking you to respond to the poll and suggest/comment what comes to your mind about this subject, everything is welcomed.

Would be great to hear the responses from people that actually has decision power inside the companies to make the information more valid for decision making, but all the people linked to process control is welcomed.

The basic idea of this poll is to gather information to confirm a statement like "1 out of 10 companies is interested in such a system."

Thanks to all in advance, Robert.

I would use/upgrade to an Open Source DCS/SCADA system if it has:

1) Backup from a company that could give me support when needed with different response time options.

2) Well tested IO modules and CPU, with various options of redundancy

3) Freedom of information. Being an open source project the source code for the system is already available. But this also includes public forums for user discussions and places to share user made Function Blocks and code for instance.

4) A totally integrated system in which I could design the HMI, control logic, download to field CPUs and force variables from the same engineering PC.

5) A system that has integrated history information about the most important process variables defined by the user.

6) A system in which I could propose improvements and see them implemented in short term.

7) Standard or below average price when compared with similar systems.
 
R

Robert Perez

> I think a candidate for such a system will be
> http://pvbrowser.org
> (our own system)

Very impressive to see pvbrowser installed in all those places !! I think I have seen it when I decided to start with my project, but I wanted to take a different approach.

Correct me if I'm wrong but i think pvbrowser misses the point number 4.

"4) A totally integrated system in which I could design the HMI, control logic, download to field CPUs and force variables from the same engineering PC."

I didn't dig too much in your website but I think you cannot create control logic from your application and download it to controllers/plcs. This system will be more of a DCS than a SCADA, with all the functions integrated.

I was thinking on a system where you could design your control logic with function blocks, or sequential control and then load those control modules to the process controllers.

Either way, the idea was not to mention any specific system, but to know what percentage of the industry is interested in this kind of business model for their systems, open source with commercial support.

Regards, Robert.
 
> Correct me if I'm wrong but i think pvbrowser misses the point number 4.

> "4) A totally integrated system in which I could design the HMI, control
> logic, download to field CPUs and force variables from the same engineering PC."

Since shared memory and mailboxes can be used by several processes in parallel you can implement your control logic within a separate process. We already have some classes that give you support for implementing control logic. But we currently implement control logic only in C/C++ and not in ladder logic. Thus we can't download the control logic to field CPUs.

But new credit-card-sized single-board-computers may become a rival of PLCs. We can run control logic and visualization server on such systems.
 
R

Robert Perez

Of course this its possible, as it's possible to connect a windows computer and load the program there but it has many drawbacks:

- Average control technicians don't know how to program C/C++, but it know function blocks or ladder.

- Should use an RT OS to be sure your control logic executes at the required intervals.

- Computer and modules capable of being used in industrial environments and well tested should be used for robust designs, not any credit card sized computer.

- Normal automation technician tasks would be a headache, forcing variables, diagnosing control issues, looking for connections between variables in control modules, etc.

The idea is not having to do all this by hand, but having a plug&play system with all this supported and well tested.
 
> Of course this its possible, as it's possible to connect a windows computer and
> load the program there but it has many drawbacks:

The difference is the size of the computer. Now it is a credit-card-sized computer and probably runs some kind of Linux because Windows does not support the SoC and a Windows license would be too expensive for the application. And this computer will be headless, no screen, no keyboard, no mouse, only operated by ssh and some kind of web interface.

> - Average control technicians don't know how to program C/C++,
> but it know function blocks or ladder.

Yes, but ordinary web pages make use of PHP for example.
If C/C++ is too complicated for your staff they may be able to use Lua for example.

> - Should use an RT OS to be sure your control logic
> executes at the required intervals.

There are also Linux distributions with RT extensions.
But if you only run a dedicated set of software on the embedded device
it may be possible to determine a worst case for the intervals.

> - Computer and modules capable of being used in industrial environments
> and well tested should be used for robust designs, not any credit card sized computer.

Even for hobby hardware like the Raspberry Pi you can get extension cards for the GPIO port. I do not know if someone already sells such devices packed into a box that fits well into the control cabinet. But this would not be a big step.

> - Normal automation technician tasks would be a headache,
> forcing variables, diagnosing control issues, looking for connections
> between variables in control modules, etc.

Why? In my opinion a modern router with a web interface is easy to operate.
Why should a PLC not be as comfortable?
 
R

Robert Perez

pvsource, thanks for your input.

The purpose of this thread/poll is not about discussing what you can do with php/web interface for robust and scalable control applications, but to gather information about the vision of the industry related to open source control systems.

If you like you could open another thread and I would love to discuss it there.

Regards, Robert.
 
I don't know why anyone would be specifically be interested in open source for their SCADA system unless they are just a tinkerer.

I have worked in a lot of industries and have worked for companies who used open source for as many things as possible, so I do have some experience here.

For my 24/7 SCADA system, I want someone who I can call for full support, not some webpage or community pages. The cost of a SCADA system is nothing compared to the cost of downtime or a mistake in operation.

I don't really care what language it is written in or whether it is proprietary because I am not going to change anyone's source code. Does it provide the reliable functionality that I need.

That doesn't mean that it has to be a big company either. My current primary SCADA vendor is very small, but I get great support and it meets my needs.

For people who are actually trying to get things done and who are buyers, not just tinkerers who want crap for free or cheap. Open Source would be a negative for me. When I hear the words Open Source, I just think Free or cheap.

Give me a solution that actually solves a problem for me, open source, proprietary will make no difference to me.

With all that said, I often look for open source tools, software for my son, such as Gimp, because I am really looking for free.

And btw, I don't work for free I am not open source, lol

GBrown
 
B

Bob Peterson

To me, Open Source in the industrial control market just means another essentially proprietary system that has no factory support, and very little in the way of support from integrators.

It usually ends up tying you very closely to the programmers involved even more than using AB PLCs and software ties you to AB. At least with AB there are plenty of people out there who can handle the work and there is factory support.

the other thing is that it ties you to the programmers' ideas of what is an appropriate way to handle industrial control problems and often that is all but impossible for the guys trying to debug it at 2 am on a Sunday morning.
 
D
The goal of free and open-source software (FOSS) is not free as in "free beer," but as in "free speech." The advantage of a reliable FOSS SCADA system would be reduced reliance on single-source vendors, pushing their proprietary protocols and closed-system products. Also, if you need a change or addition, you could make (or contract) the change yourself, rather than waiting for a closed-source vendor's update cycle.

As to support, many FOSS projects enjoy a robust support community, often by large commercial enterprises (think Red Hat Linux). These products provide functions comparable in criticality to control systems. That said, no large company has stepped up to provide support for any of the FOSS SCADA projects. Since the major SCADA companies benefit from keeping you locked into their proprietary platform, they are unlikely to offer such support.

While there are benefits to potential users of a FOSS SCADA product, the corporate stars are also not aligned for its success. The corporate users of SCADA are product- or process-oriented, and not often skilled in software; likewise, the IT folk who might know how to maintain the software are unfamiliar with control systems. So unless a large-scale corporate sponsor can be found, FOSS SCADA systems will likely be limited to tinkerers, as GBrown notes.

If someone were to develop a FOSS SCADA system in Java, perhaps Oracle could be enticed to provide corporate support like Red Hat does for Linux. Although not FOSS, Inductive Automation's Java-based Ignition SCADA package has gained some attention from Oracle. In my opinion, however, the control systems market is too fragmented, risk-averse, and technically primitive to make sponsorship worthwhile.

--Dan
 
C

Curt Wuollet

Having just come from a stint programming with FOSS for SCADA of a sort. I think it will find a place with integrators and machine builders. What we were doing couldn't be done adequately with OTS shrinkwrap. But the projects I've seen generally did the whole control systems with FOSS as well. If you do a system with AB or XYZ controllers, you can bet that it's going to be arranged so that it's much easier to do the SCADA, etc. with their stuff and/or their "partners" stuff and since some of the "partners" delight in shutting out alternatives by any means possible, I see a mixture of FOSS and proprietary stuff as being only marginally less difficult than simply using an all FOSS solution and commodity hardware. And no, not everyone can do that, but , it's coming. When I see a multimillion dollar printing press that runs Linux because the old proprietary way wasn't flexible enough or cost effective enough, times are changing. Lock in is on it's way out. That doesn't mean the end of proprietary systems, but we've seen which way consumers vote with their checkbook in telecommunications just lately. The company that opens up and eschews perceived evil stands a chance to be the Google of automation. The hardware is there already and trivial to adapt.

Regards
cww
 
C

Control_Lurker

> Also, if you need a change or addition, you could make (or contract) the change yourself, rather than waiting for a closed-source vendor's update cycle. <

One comment on the vendor's update cycle. Some vendors have long update cycles because they are too busy, poor schedulers or provide poor customer support. You probably don't want to work with these vendors.

Other vendors have development cycles that include fully understanding the change, requirements definition, software documentation, code review, internal tests, and possibly on-equipment tests and change verification. Tinkerers and bean-counters don't think any of this "expense" is necessary. What those who hack together code or think they can change just one "little" thing forget, is that that one little change could cost them dearly later.

As GBrown put it:
>I don't know why anyone would be specifically be interested in open source for their SCADA system unless they are just a tinkerer

There are lots of tinkerers out there open-source or not.
 
The net is littered with failed Open Source projects:

1. Just weren't good enough.
2. Had a poor business model.
3. The creators/maintainers got real jobs.

This of course could be true for any commercial company also.

As far as integrators go, yes, I can see them loving a "free" solution that will allow them to bid lower. And I will avoid these like the plague. I am so tired of these integrators creating some black box package that has who knows what inside. How many orphan PLCs with obsolete or unsupportable interfaces do I need?

This is true for almost all my products. I am a heavy user of virtualization, and I pay VMware a ransom for the privledge to use their products. I could go to some open source solutions, even supported ones such as RH, But they have excellent support, their products work. which is what I care about.
 
R

Robert Perez

First of all thank you all your input, is great to know the opinion of people with experience.
Let me answer to each one.

To GBrown:

"For my 24/7 SCADA system, I want someone who I can call for full support, not some webpage or community pages. The cost of a SCADA system is nothing compared to the cost of downtime or a mistake in operation."

The idea of this post was to consider a company backing up the project, whose revenue comes from support and consulting. So you will have 24/7 support, that's for sure and was one of the things that I see missing in some interesting open source projects. There is no commercial support, except for some huge companies like red hat, oracle, etc. But I totally agree that this is a must for success.

"I don't really care what language it is written in or whether it is proprietary because I am not going to change anyone's source code. Does it provide the reliable functionality that I need."

Totally agree, but other people who could be interested has the possibility of doing it (ie university student or a person that has time or will to follow a bug until it reaches).

"For people who are actually trying to get things done and who are buyers, not just tinkerers who want crap for free or cheap. Open Source would be a negative for me. When I hear the words Open Source, I just think Free or cheap."

Open source doesn’t mean it has to be free or crap. In fact if some time in the future I start this company, we will charge for licenses, its one way to keep things going on !. But of course the prices will be lower than big companies that lock you in with proprietary software.

"Give me a solution that actually solves a problem for me, open source, proprietary will make no difference to me."

That’s a very positive thing, because some people think that open source software is just a toy, but it could be a real business model in which all the parties benefit.

"And btw, I don't work for free I am not open source, lol"

There is no need to do it !, but at least there is the possibility of digging into the application for those who want.

To Dan Ingold:

"The goal of free and open-source software (FOSS) is not free as in "free beer," but as in "free speech." The advantage of a reliable FOSS SCADA system would be reduced reliance on single-source vendors, pushing their proprietary protocols and closed-system products. Also, if you need a change or addition, you could make (or contract) the change yourself, rather than waiting for a closed-source vendor's update cycle. "

Totally right, I think the same way.

"As to support, many FOSS projects enjoy a robust support community, often by large commercial enterprises (think Red Hat Linux). These products provide functions comparable in criticality to control systems. That said, no large company has stepped up to provide support for any of the FOSS SCADA projects. Since the major SCADA companies benefit from keeping you locked into their proprietary platform, they are unlikely to offer such support. "

That could be about to change in a future. Don't has to be a big company, but a small one trying to start up :)

But what we are seeing just that coming from the IT industry, the phrase that applies is "open or die". Linux is growing a lot and is being used in huge commercial projects out there, and many companies are following this trend. If your company doesn't do it the competition will.

Think about all the commercial applications that have an open source alternative, they are increasing every day.

Control systems are doing it too, but it has to be better.

"While there are benefits to potential users of a FOSS SCADA product, the corporate stars are also not aligned for its success. The corporate users of SCADA are product- or process-oriented, and not often skilled in software; likewise, the IT folk who might know how to maintain the software are unfamiliar with control systems. So unless a large-scale corporate sponsor can be found, FOSS SCADA systems will likely be limited to tinkerers, as GBrown notes"

The key here as you said is to have a corporate sponsor, who can respond for the software and invest in its development. Allowing open source use but giving the possibility to have good support 24/7 and consulting services, etc. to make the solution attractive to companies looking install such a control system and couldn't rely on community support because they need an answer now.

To Curt Wuollet:

"Having just come from a stint programming with FOSS for SCADA of a sort. I think it will find a place with integrators and machine builders. "

Absolutely, to me it depends on having a solid DCS/SCADA package that make things easier as top edge commercial systems and as many said to have a company backing up the whole thing. It's not easy but knowing that the people working with these systems is interested it's a good step to start making some numbers.

"And no, not everyone can do that, but , it's coming. When I see a multimillion dollar printing press that runs Linux because the old proprietary way wasn't flexible enough or cost effective enough, times are changing. Lock in is on it's way out. That doesn't mean the end of proprietary systems, but we've seen which way consumers vote with their checkbook in telecommunications just lately. The company that opens up and eschews perceived evil stands a chance to be the Google of automation. The hardware is there already and trivial to adapt."

Absolutely Curt, to me open source is the way to go in many applications, although I'm not an Open Source purist, but I see win-win situations with it many times. In which you could create a company around a project to backit up and make some bucks out of it to make the company running, and also help the comunity of people using the product to continue receive good quality software free of charge.
You will not be a millionaire of course, but you will work on what you love and earn enough to have a decent life.

To Control_Lurker

"One comment on the vendor's update cycle. Some vendors have long update cycles because they are too busy, poor schedulers or provide poor customer support. You probably don't want to work with these vendors. "

That happens a lot I've seen it, and I can't believe it when it happens considering the money they charge! One small company will be pleased to offer support or fixing that bug for you for less money than that!

But it should be the same for big companies, if you don't respect your clients, that client will leave some time. Of course big companies know that they have the client locked in and they take advantage of that. But that breaks the trust relationship between them and that couldn't be a good thing.

To Bob Peterson:

"To me, Open Source in the industrial control market just means another essentially proprietary system that has no factory support, and very little in the way of support from integrators."

That depends on how the business model is thought by the company backing up the project. I understand perfectly the importance of good support, being an automation supervisor myself in one mill. I receive a call at 3am and if we couldn't solve the issue we have to call a specialist.
Creating a network of integrators is a key step too. But having the whole documentation available is a great resource for them and that's not something that every control system company out there has. That could make life a lot easier.

"the other thing is that it ties you to the programmers' ideas of what is an appropriate way to handle industrial control problems and often that is all but impossible for the guys trying to debug it at 2 am on a Sunday morning."

But a good control system should be made using IEC standard programming languages like ladder, FBD, SFC, etc.

Guys, what I'm talking here is about making a fully fledged open source control system with hardware and all the functionalities found in the big players.

And as said in the beginning of the poll, to me, a company baking up the project is essential to success. It should give great 24/7 support, including going to your mill if there is a need. Of course there should be different contract options because not all the needs are the same.

With that all the things you've mentioned about lacking of support, etc. are covered. And the open source thing is something that only brings added bonus to you all. Because the same system will be used by students in universities that means more people who know how to use it and increased work force.

They will also discover new bugs and perhaps fix them, reducing the load on the company backing the project, and letting you having quick bug fixes.

Being the software open also helps to reduce or eliminate the lock in situation. If the company is charging 10 times more than usual for support or hardware, others could come that could do the same and regulate the market.

Sorry for the huge post!
 
C

Curt Wuollet

And there are lot's of us who would blow coffee out their nose if you were to suggest the commercial offerings are the epitome of the programming art. A very few are excellent, some competent, and a lot are hacked together, totally illogical, examples of shipping the first thing that worked. If you write a package, it is what it is, whether you publish the source or not. I think some of it is secret out of embarrassment rather than profit motive. But source access would really be useful in cases where the only com ports selectable are 1 and 2 or worse, when it's hard coded. Or those hard coded for screen resolutions that don't fit modern monitors or many other cases where the PC platform has changed, particularly in the handling of interrupts and memory. True, most folks wouldn't want to spend the time to learn enough to make substantial changes, but very often being able to make a trivial change would save a project or prevent having to start over. In an OSS project a lot of the best, most innovative code comes from the community and the value of that is greatly understated. The value comes from the fact that they are actually _using_ the product in the real world and can code for things the originators would never have thought of or anticipated. And they get the benefit of being able to find out how some feature really works. I doubt there is a reader who hasn't hit a roadblock or had to change plans because some small detail didn't work the way they needed it to. I know I've changed an address and interrupt in the binary (machine code) when the alternative was a massive loss of time and expense to use a different package. It would have been trivial had the source been available.

Regards
cww
 
C

Curt Wuollet

I've heard varying estimates, but at least a third of _all_ automation projects fail due to performance or scope issues. Since the penetration of FOSS has been approximately zero. it could reasonably be assumed that the status quo has not achieved a very high standard of overall effectiveness in utility to the body general of practitioners. I tend to think some measure of increased flexibility or adaptability might improve that. But, it's hard to tell. IT/IS has found it to be so, but that's a different arena.

Regards
cww
 
<.... That said, no large company has stepped up to provide support for any of the FOSS SCADA projects.
> Since the major SCADA companies benefit from keeping you locked into their proprietary platform,
> they are unlikely to offer such support.

Why should they???? Aren't they in the business of making money? Why would they waste their resources on such an endeavor. Resources that are financed by their regular customers.

> While there are benefits to potential users of a FOSS SCADA product, the
> corporate stars are also not aligned for its success.

Nor should they be.
 
Top