Today is...
Monday, March 27, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
New forum topic - Open Control
People who have been regulars at Control.com and on the Automation List will recall that our principal mission as an organization is to encourage the advent of open control, in the sense of multi-vendor standards-based systems...

Hi all,
People who have been regulars at Control.com and on the Automation List will recall that our principal mission as an organization is to encourage the advent of open control, in the sense of multi-vendor standards-based systems.

We feel that a global peer community of working automation engineers is an important step toward making this vision possible. We are well on the way toward accomplishing this goal, with over 50,000 unique visitors each month, and the world's most active discussion venue for automation topics.

I'm pleased to announce that we are now introducing a new topic to our website and to the companion Automation List, that will be a gathering place for discussions on open control technologies. This topic, Open Control (OPENC), will include discussion on:

- open control architectures and components
- open interfaces, including:
--bus structures (cPCI, PC/104, ISA, PCI, etc.)
--device-level busses (Modbus, Profibus, DeviceNet, etc.)
--networking (TCP/IP and related protocols)
--APIs
--language standards
- open source software
- portable control software
- interoperability issues
- performance and benchmarking of open system components

We hope this new topic makes an important contribution to our industry and to the people who make up the Control.com forum. We're inviting you all to contribute to the discussion, share experiences, and help the controls world become a bit more open.

Regards,
Ken Crater, President
Control.com Inc.
ken@control.com

Hi Ken Crater:

Can you give me your definition of "open control", one that everyone can agree to?

Bob Pawley
250-493-6146

In response to Bob Pawley...
>Can you give me your definition of "open control", one
>that everyone can agree to?

Bob Old posted:
>And the way to World Peace, too, while you're at it, Ken.

Nah, World Peace is too easy (in comparison) :-).

Actually, I would not equate "open control" with PC-based control. It is conceivable (and, in fact, has been done) to create a closed control
system using a PC-architected system. All you have to do is use a proprietary bus structure, write closed-source code, and use a proprietary protocol -- result: a closed PC-based system.

I don't hold to any finite criteria as a threshold of "openness", but rather see it as a question of "preponderance of evidence". Peter has already mentioned some of the key attributes of an open system, which I'll elaborate:

- adherence to published, freely-usable standards at key interfaces (bus, protocol, physical form factor, signal levels, etc.).
- commercial availability of meaningful choices from a variety of vendors in an open market, for any unit of functionality.
- unbundled support available at a variety of levels from a selection of providers.

Although not absolutely necessary (in my book) to have an open system, open source software is certainly helpful in meeting the above criteria.

The whole point of open control is to reduce cost and risk, and increase flexibility to respond to change. This can only be accomplished byopening each component choice to multiple suppliers competing in a free market. Instead of being "stuck" with the offerings of a single company, the user gets to choose best-in-class technology from among dozens of companies for each piece of the puzzle.

I think that's why people have been talking about this for 15 years. And before anyone says it's impossible, it's already happened in the PC world. Go to the Dell site and look at the menu choices for any component of one of their systems:

> ATI, RageT 128 Ultra, 32MB, VGA [subtract $109]
> nVidia, Quadro2 EXT, 32MB, VGA Dell Recommended
> nVidia, Quadro2 ProT, 64MB, VGA/DVI [add $311]
> ATI Fire GL2, 64MB,VGA/DVI [add $611]
> ATI, RadeonT VE, 32MB, VGA (dual monitor capable) [subtract $49]
> ATI, RadeonT VE, 32MB, VGA/DVI (dual monitor capable) [subtract $29]

If I've learned anything in 25 years in this field, it's that you need to have an enormous toolbox to handle the diversity of applications that come along even in a single plant. One vendor just can't keep up with the pace of technology in all requisite fields anymore. That's why we thought it was time to make open control a practical reality.

Best Regards,
Ken Crater, President
Control.com, Inc.
ken@control.com

World Peace *next* year...

Thanks for answering Ken.

I wonder what form open control should take.

Is it the Linux model where anyone and everyone who does some work in the plant is able to 'remodel' the control software in any way he or she desires? Where innovative solutions are either freely distributed or remain a plant asset? Where the effort of supporting the plant's software continues to burn out highly skilled workers and retains the $100+ per I/O price tag?

Or should we look for another solution to open control - a solution that is cost and time effective? A method of incorporating proprietary and "free" software in such a way that control solutions can cross various protocols, hardware (both virtual and real) and vendors offerings. Solutions that will assist the user in their implementation cutting costs and opening new business opportunities.

Personally, I have always had a problem with 'free' that has no structure nor boundaries. Everything has to be anchored to something real; and those people developing solutions, real solutions should be rewarded for their creativity.

Bob Pawley
250-493-6146
www.automating-automation.com

By Curt Wuollet on 6 February, 2002 - 4:49 pm

Hi Bob

That's an excellent question. As a practical matter we have nearly all closed systems for financial reasons. Lock-in and incompatibility do serve the purpose of maintaining a revenue stream. I think there are other models that would work. Nirvana would be for there to be equal opportunity for everyone to compete for seats at a particular solution table. We Open folks are obviously ready to do that because it would certainly be much easier than having to reverse engineer everything. An all Open world would not neccesarily be the best either as there is valid need to recover investments etc. Unfortunately they run the world at the moment and are highly unlikely to move in a direction that involves risk for them even if it would provide great benefit to the consumer. The only way that I see the situation changing is if Open Solutions gain enough traction to make openness a requirement that shows up on RFQs and requirement documents. Since the major vendors have shown zero willingness to cooperate amongst themselves, I doubt that it is realistic to ever expect them to cooperate with Open Systems providers. That's why as I have said before, Openness tends to be absolute rather than relative and it will be an either or situation until it begins to seriously affect their revenue and they have no other choice.

There is absolutely no doubt that a mix of closed and open and more choice would be better for the consumer. Unfortunately there is no other way to get there than to buy Open Systems until they play ball. This requires that there be Open Choices available. That's what we are trying to do. We have a chance because we don't have
to make big money doing it. As close as I can tell, no one wants choice, but we're betting they will once we make the benefits tangible.

Regards

cww

Hi Curt:

It would seem there is a bipolar reality in the control world these days.

At the south pole are numerous control software packages. Systems that do the job, but are so rigid in application that everyone finds some fault.

At the north pole is Linux, the ultimate open source software, but without the structure and organization to instil the confidence and acceptance required for mass appeal.

Somehow these apparently disparate systems need to meet at or near the equator with at least some pretence of harmony.

I suggest that the present situation is not sustainable. When these two bipolar systems do harmonize there will be an explosion of change within the industry. Those who prepare for this change will be the only ones who survive.

Bob Pawley
www.automating-automation.com
250-493-6146

By Curt Wuollet on 11 February, 2002 - 11:12 am

Hi Bob

I pretty much agree. But vendors like IBM have shown that the percieved lack of structure and organization is mostly propaganda. They bet a
Billion dollars on Linux and are saying they have recouped their investment.
"http://zdnet.com.com/2100-1106-826983.html":http://zdnet.com.com/2100-1106-826983.html
Nearly all their mainframe revenue from 4Q2001 was from sales of very, very, serious Linux machines to very serious people. In fact the have a new mainframe model that runs only Linux. "http://news.com.com/2100-1001-822771.html":http://news.com.com/2100-1001-822771.html
Now this is from people who are just about as conservative as you can get and they seem quite unconcerned about all the well worn FUD sown by their competitors. On the low end, there is an unbelievable amount of Embedded Linux development
going on including of course my humble projects.
And the FAA is piloting Linux for their new ATC systems. And Oracle is gonna run their whole business on Linux, according to Larry.
"http://www.computerworld.com/storyba/0,4125,NAV47_STO67867,00.html":http://www.computerworld.com/storyba/0,4125,NAV47_STO67867,00.html
I humbly submit that the lack of structure and organization might be killing these guys, but they just don't know it.

Ultimately this will trickle down to the automation market which is several years behind the times. (Not neccesarily a bad thing). But it's unlikely to be much of a shock. The very long lifetime of solutions in automation will stretch out even the most abrupt changa and give people adequate opportunity to change. I'm simply impatient.

Regards

cww

Curt:

My comments were made with industrial control as the focus. However, IBM, imbedded, and specialty applications such as Pixar, are providing the
structure I was mentioning. Some of this structure and organization is part of the application such as workstations, animation and devices with Linux imbedded.

Within the control world Linux open source has the potential of one plant, within a group of plants, being programmed quite differently than the other plants within the same organization. If new personnel take over the operation of that different plant they would have little or no expectation of what to expect. Similarly, most companies strive to have common practices and procedures across the organization such that moving from plant to plant people know what to expect. This common practice, the definition of proprietary software, is quite handy when solutions in one plant are to be instituted in other plants - or when trouble-shooters move from plant to plant. Linux without some type of common structure does not assure that this level of common practice would survive. Therefore, Linux, less expensive in the short term, could become quite costly in the longer term.

My point is, we do pay a rather hefty price to ensure an across the board standard practice. This price is forcing changes upon the industry.

Bob Pawley
www.automating-automation.com
250-493-6146

By Curt Wuollet on 11 February, 2002 - 11:17 am

Hi Bob

> Curt:
>
> My comments were made with industrial control as the focus. However, IBM,
> imbedded, and specialty applications such as Pixar, are providing the
> structure I was mentioning. Some of this structure and organization is part
> of the application such as workstations, animation and devices with Linux
> imbedded.
>
> Within the control world Linux open source has the potential of one plant,
> within a group of plants, being programmed quite differently than the other
> plants within the same organization.

Actually we intend to look as much like what exists as possible. While we can't for example use the same setup tools, editors, etc. we are
going to support ladder logic, ST, and possibly the next great thing. In this manner it shouldn't be any worse than AB in one building and GE in the rest. If it were legally possible we could come closer than that. I would hope we wouldn't be held to greater standardization than
the status quo, after all, it's they who are preventing it.

> If new personnel take over the
> operation of that different plant they would have little or no expectation
> of what to expect. Similarly, most companies strive to have common practices
> and procedures across the organization such that moving from plant to plant
> people know what to expect. This common practice, the definition of
> proprietary software, is quite handy when solutions in one plant are to be
> instituted in other plants - or when trouble-shooters move from plant to
> plant. Linux without some type of common structure does not assure that this
> level of common practice would survive. Therefore, Linux, less expensive in
> the short term, could become quite costly in the longer term.

Again, you could provide that common structure in the only way possible now, instead of an all AB shop or all GE shop, you could have an all LPLC shop. Or do you see more consistancy between vendors than I do? Or are you really thinking about the advantages of an entrenched position in the market, large installed base, etc.? If the latter is the criteria, there is little hope for change of any kind. Instead I see the structure migrating a step closer to the consumer with the user community providing a level of support and assurance much higher than any corporation can in these troubled times. Witness Honeywell, TI, the users support each other long after the corporation has flown. Try to at least consider that there are other models that would work and might even work better. Communities don't quit or get merged or go out of business. And they don't have to be profitable in the same sense which makes them more likely to help rather than having you jump through hoops..

> My point is, we do pay a rather hefty price to ensure an across the board
> standard practice. This price is forcing changes upon the industry.

There goes that structure :^)

Regards

cww

By Michael Griffin on 11 February, 2002 - 2:19 pm

On February 10, 2002 02:30 pm, Bob Pawley wrote:
<clip>
> Within the control world Linux open source has the potential of one plant,
> within a group of plants, being programmed quite differently than the other
> plants within the same organization. If new personnel take over the
> operation of that different plant they would have little or no expectation
> of what to expect. Similarly, most companies strive to have common
> practices and procedures across the organization such that moving from
> plant to plant people know what to expect. This common practice, the
> definition of proprietary software, is quite handy when solutions in one
> plant are to be instituted in other plants - or when trouble-shooters move
> from plant to plant. Linux without some type of common structure does not
> assure that this level of common practice would survive. Therefore, Linux,
> less expensive in the short term, could become quite costly in the longer
> term.
<clip>

I'm not sure I really understand your point. Linux is just an operating system. If you are going to construct a soft logic system, you also need hardware and application software (the actual soft logic software which you program). The hardware and soft logic application software should be an even bigger concern for your maintenance personnel.
If your company's equipment standards specify a particular set of hardware and software, how does this result in different software and hardware between different plants just because it incorporates Linux? Either the various plants are following your equipment standards, or they are not. If they are not following your equipment standards, it doesn't matter whether the systems are proprietary or open - they are going to be different. If this is the case, I'm afraid you are going to find a bigger difference between different brands of proprietary systems than you will between different Linux distributions.

************************
Michael Griffin
London, Ont. Canada
************************

Bob Pawley:
> It would seem there is a bipolar reality in the control world these days.

> At the south pole are numerous control software packages. Systems that do
> the job, but are so rigid in application that everyone finds some fault.

> At the north pole is Linux, the ultimate open source software, but
> without the structure and organization to instil the confidence and
> acceptance required for mass appeal.

That's where distributions come in - they're the sales departments of the Linux world, and that's where you go when you want a structured, organized
package.

One can modify anything in Linux, but one rarely does. Indeed, I would expect that a plant would standardize on a particular combination of
packages from a particular distribution, perhaps customized, and then refuse to change a thing for years (without good reason). Only the actual
control logic would change.

Obviously, if two such companies merge, there will be two different versions, but it'll be easy for them to interoperate, or the opportunity
can be taken to upgrade both to a common new version of the company-wide standard.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

So paraphrasing, let me know if I understand the gist of what you are saying.....

Rockwell, GEFanuc, and the others are completely closed and currently have no intention of untrenching.

You and others that promote the 'completely open' approach are taking up the position that is diametrically opposed, in the hopes of convincing the 'closed systems' providers to meet somewhere in the middle?

Just checking my bearings......

--Joe Jansen

Joe

I don't know about others, I speak only for myself.

I came into this open control and open source discussion later than most with no preconceived ideas other than what I have lived with for the last 30 some years.

It does seem to me that we as an industry have moved from total proprietary systems, to a point where we aren't absolutely required to purchase hardware and software from the same source.

The other extreme that has come about because of Linux causes me to note that there is a definite movement toward systems being as open as possible. This trend will continue regardless of what individuals think.

What I am suggesting is that a totally open system such as Linux - standing by itself - is to much the opposite extreme to have great appeal. Some boundaries, some anchor is needed so that all concerned have a solid place to stand in order to see what needs to be done or to see what has been done.

Proprietary systems have this solid place upon which everyone, technician to corporate bureaucrat, is comfortable. The fact that this proprietary place is so vast gives me reason to consider a melding of the two extremes.

Bob Pawley
www.automating-automation.com
250-493-6146

By Greg Schiller on 10 February, 2002 - 1:14 pm

I would agree. People who use technology only want one thing from it. Does it work. The next thing they want is if it is broke where can I get a replacment. Forklifts do amazing things for our economy.

Totally free, open system can fill niches but no one dedicates real R and D dollars to making something they may never own in the future. Imagine it from the venture capitalist's viewpoint.

I would like to take your money to make this very cool niche product that I will then give the rights away to the public. How am I going to pay you back? I'm not. I can't. No one has bought my idea from me.

Venture caps and Corporations with money hate backing up this stuff. It goes against everthing they were taught about in business school. The only way this gets any legs is if it is tagged to hardware sales. But then isn't that why we started this whole mess anyway?

What suffers the most are longterm big payoff ideas that have this type of ending. It took our government persuing a distributed information model to come up with TCPIP. That is the only invester I know that would underwrite large projects for the benifit of all.

Don't take me to far away though. I'm sick too of paying the vender manytimes over the original cost of the product. Membership fees...,
maintenence fees..., buy the hardware and by the way you need to buy our software to make our hardware run...

Open has been most effective when it is used as communication standard. MODBUS RTU/TCPIP, TCPIP, RS232, RS485, USB, Ethernet Etc. Published and then practiced.

Greg Schiller
gregs@automatica.biz
www.automatica.biz

By Curt Wuollet on 11 February, 2002 - 11:26 am

Hi Greg

This money thing is the easisest to answer. I'll be brief. You simply have to take a different approach.

> I would agree. People who use technology only want one thing from it. Does
> it work. The next thing they want is if it is broke where can I get a
> replacment. Forklifts do amazing things for our economy.
>
> Totally free, open system can fill niches but no one dedicates real R and D
> dollars to making something they may never own in the future. Imagine it
> from the venture capitalist's viewpoint.

That's assuming that R&D dollars buy you better brainpower. In many cases that researcher also writes OSS. Is the stuff he writes for money better? Is the stuff that Linus writes for Transmeta better than the stuff he writes for Linux? Great products take great people not great money. OSS has some of the best. And they're doing it because they _want_ to.

> I would like to take your money to make this very cool niche product that I
> will then give the rights away to the public. How am I going to pay you
> back? I'm not. I can't. No one has bought my idea from me.

I'm working out the details of truly Open Hardware. The needs are quite modest and the risk is much less than if I did a VC start up to do it. I'm not at all sure it would produce better results to have to answer to money people. On the contrary, spending _my_ money makes for great care and accountability. There isn't a lot of rocket science in this field. Edison said: "Genius is 1% inspiration and 99% perspiration" I hope he's right.

> Venture caps and Corporations with money hate backing up this stuff. It goes
> against everthing they were taught about in business school. The only way
> this gets any legs is if it is tagged to hardware sales. But then isn't that
> why we started this whole mess anyway?

So shouldn't we try something different? I don't think VCs would be killing each other to buy into the status quo either. Most of them are warts on the arse of hugely diversified corporations and hardly the bright spots on the annual report. Even with lock-in and pretty generous margins.

> What suffers the most are longterm big payoff ideas that have this type of
> ending. It took our government persuing a distributed information model to
> come up with TCPIP. That is the only invester I know that would underwrite
> large projects for the benifit of all.

It could be argued that the success has more to do with openness and public ownership than the seed money DARPA put up. Indeed the greatest public network the world has known was started with unpaid student labor. A class of folks remarkably similar to the Linux community. In fact, a lot of the same folks.

> Don't take me to far away though. I'm sick too of paying the vender
> manytimes over the original cost of the product. Membership fees...,
> maintenence fees..., buy the hardware and by the way you need to buy our
> software to make our hardware run...

Me too. I think I've got the skills and determination to do something about it. Well, the determination anyway :^)

> Open has been most effective when it is used as communication standard.
> MODBUS RTU/TCPIP, TCPIP, RS232, RS485, USB, Ethernet Etc. Published and then
> practiced.

Yes, it seems to have worked well in all areas where it has been seriously tried. Hmmmmm.

> Greg Schiller
> gregs@automatica.biz
> www.automatica.biz

Regards

cww

By Michael Griffin on 11 February, 2002 - 2:32 pm

On February 10, 2002 01:17 pm, Greg Schiller wrote:
<clip>
> I would agree. People who use technology only want one thing from it. Does
> it work. The next thing they want is if it is broke where can I get a
> replacment. Forklifts do amazing things for our economy.
>
> Totally free, open system can fill niches but no one dedicates real R and D
> dollars to making something they may never own in the future. Imagine it
> from the venture capitalist's viewpoint.
<clip>

The problem with that argument is that it doesn't conform with what is actually happening. People are doing precisely this.

> Venture caps and Corporations with money hate backing up this stuff. It
> goes against everthing they were taught about in business school.
<clip>
Not exactly. One of the strategies which is taught in most business schools is "give away the razor and sell the blades". This was used by a company who was obviously in the razor blade industry but is always held up as a brilliant marketing strategy which can be emulated by others. Essentially what it means is to give away something which allows you to get your foot in
the door, and make your profit from selling an associated product or service.

I think the argument that "open" means everybody will be building their own home-made soft logic systems from parts they dug out of a junk pile and software they downloaded from the internet is a red herring. It may be possible, but I don't think it will be common.
I think that most people will want to buy something which is already put together and tested by someone else. They will do so for precisely the reasons you said - they just want something that works, and they want to be able to buy a replacement if it breaks. In other words, they want someone who can bundle the various bits together and sell them a complete system together
with service and support.
There is no reason why this package cannot include open systems to greater or lesser degrees. I am not sure why you conclude that this is only possible with completely proprietary systems.


************************
Michael Griffin
London, Ont. Canada
************************

By Greg Schiller on 12 February, 2002 - 2:02 pm

Michael Griffin wrote:
> Not exactly. One of the strategies which is taught in most business schools is "give away the razor and sell the blades". This was used
by a company who was obviously in the razor blade industry but is always held up as a brilliant marketing strategy which can be emulated by others.
> Essentially what it means is to give away something which allows you to get your foot in
the door, and make your profit from selling an associated product or service. <

As a marketing tactic that is correct and longterm viable one. But Open software systems are free. They are by liscence. Any changes and releases to those software systems will be free as well. I think we are in agreement on this that only when we give away the razor (linux, etc.) do we get the blade sales that make a profit. The linux PLC project and others applications
involving linux must have some other form of revenue otherwise how can they provide techsupport for the complexities that arise post sale and pre production.

> I think the argument that "open" means everybody will be building their own home-made soft logic systems from parts they dug out of a
junk pile and software they downloaded from the internet is a red herring. It may be possible, but I don't think it will be common.
> I think that most people will want to buy something which is already put together and tested by someone else. They will do so for precisely the reasons you said - they just want something that works, and they want to be able to buy a replacement if it breaks. In other words, they want someone who can bundle the various bits together and sell them a complete system together
with service and support.
> There is no reason why this package cannot include open systems to greater or lesser degrees. I am not sure why you conclude that this
is only possible with completely proprietary systems. <

I can see your point. I guess that to me proprietary systems means a business owns the whole design. I would agree that you can provide new inovation from more open systems design.

I am looking at all this development and energy being put into making a version of linux that will provide an alternative to the competition in the PLC market. I am looking how I can contibute or benifit by helping develop this technology or by using it. I'm not sure how it would feed me down the road.

Please I'm not negative about this subject. Just insanely curious about how we are all going to be using this technology down the road.

By Michael Griffin on 13 February, 2002 - 2:21 pm

I can give you one good example here. I am aware of several companies which make machinery controlled by their own proprietary soft logic systems. These are more or less standard machines which are customised for each application. The soft logic system allows easy customisation by either the OEM or the customer.
The problem is that each of these companies has their own system which they wrote themselves. You can't apply your knowledge and experience of one system to another, except in the most general sense. The documentation they provide is also usually fairly poor. However, a customer isn't going to base their equipment purchase decision upon the qualities of these soft logic systems unless everything else about the machines was equal.
These companies don't sell soft logic systems, they sell complete machines which happen to include soft logic systems. However, they have to provide support for these soft logic systems now in conjunction with the machines they sell. Why couldn't they do the same if they used a common open source system on their machines?

This is a "give away the razor and sell the blades" strategy in that these companies are not in the soft logic business, they are in the OEM machinery business. The value of the soft logic system is insignificant compared to the cost of the machine and there are no special features or technology bound up in the design of their proprietary software.
They've apparently decided for business reasons not to use a soft logic system purchased from a third party. However, if they were to all use a common open software system everyone (including the customer) would benefit. The benefit to the customer would come from not having to learn a unique system from inadequate or non-existant documentation for each OEM's machine. The benefit to the OEM would come from having to provide less support (the customer can apply existing knowledge) and from the greater credibility of using a widely available system (no questions about whether their particular system is debugged yet).

> Please I'm not negative about this subject. Just insanely curious about how
> we are all going to be using this technology down the road.
<clip>
Another example is from something which is an existing product. Sixnet sells RTUs, and they have a new product out which they call the "Linux RTU". This is proprietary RTU hardware which uses a Linux operating system. You're still buying an RTU from them, but it happens to use an open operating system.
I think this would be the model for a general purpose "open" PLC. You are still buying a complete PLC package from a company which sells PLCs. However, if they all used the same software, we would have the compatability which we hoped for with IEC-61131-3, but never achieved.


--

************************
Michael Griffin
London, Ont. Canada
************************

By Alex Pavloff on 14 February, 2002 - 12:12 pm

One of my products is in this boat. Its a leaky boat too, as the company and people that created the software have vanished off the face of the
earth. We have the source code, but quite frankly, it doesn't help us much, as we don't have the faintest clue of where to look to fix the problems. Open sourcing a product might help, but unsupported code is unsupported code, no matter what the license is. You're still going to need someone familiar with the code willing to fix the problems.

The other problem that companies like mine might have is that licensing issues may discourage me, as an OEM, from adding features to my product to make it better than the other guys. I add a new feature, and poof, all my competitors that are using the same open source system have them. (I realize, of course, that this is entirely dependent on the licensing, and has nothing to do with the OS or anything).

Sure, the end user gets lots of features, but I'm not the end user! I'm the OEM! I can no longer differentiate my product from other on a technical
level -- removing ONE of the ways I can get ahead of my competitors.

Alex Pavloff
Software Engineer
Eason Technology

By Greg Goodman on 15 February, 2002 - 9:45 am

> One of my products is in this boat. Its a leaky boat too, as the company
> and people that created the software have vanished off the face of the
> earth. We have the source code, but quite frankly, it doesn't help us much,
> as we don't have the faintest clue of where to look to fix the problems.

> Open sourcing a product might help, but unsupported code is unsupported
> code, no matter what the license is. You're still going to need someone
> familiar with the code willing to fix the problems.

You're a software engineer, in possession of the code you depend on, with what seems to be a strong motive for gaining familiarity with it.
I assume you're busy, that you're time is at a premium, but you only have a few options. Assuming that you have a legal right to do anything with the source (and I'll assume you do, if only for the sake of discussion):

1. live with the problems
2. replace the system with something supported
3. fix the problems yourself
4. pay somebody else to fix the problems for you

#1 may actually be an option, depending on the severity of the situation.

#2 is expedient, but probably pretty costly, and leaves you at risk to end up in the same situation you're in now if your new vendor goes belly up.

#3 & #4 are less disruptive to your plant than #2, and probably less costly (assuming that the problems are not fundamental design flaws in
your current system). Whether you or a contractor fixes the existing system, there's a learning curve to work through, and an expense (either the cost of the contractor, or the alternative disposition of your time). The advantage I see that #3 has over #4 is that you end up owning the expertise you will continue to depend on.

As with all such choices, there's a cost-benefit analysis to be done, but you do have the choice. If your current system were completely closed, your only choice would be how long you live with a faulty and unsupported system until you replace it.

> The other problem that companies like mine might have is that licensing
> issues may discourage me, as an OEM, from adding features to my product to
> make it better than the other guys. I add a new feature, and poof, all my
> competitors that are using the same open source system have them. (I
> realize, of course, that this is entirely dependent on the licensing, and
> has nothing to do with the OS or anything).

I understand your concern. OEMs are, in fact, capable of believing that there's no point in improving the system they offer their clients if
competitors might also benefit.

However, the circumstance you describe doesn't support that concern.

a) If an OEM's product is based on open source, or contains open source components, then the OEM's competitive advantage does not and cannot
depend on the features of the open source. Everybody already has the open source, so the competitive advantage must lie in market
penetration, or in quality of service (expertise, availability, etc), or in the features of the proprietary components.

b) There is, in fact, a benefit to adding a feature that other vendors then adopt. As the author and copyright holder, your name is in the
code they distribute; you and your expertise are being advertised to their clients. As the author of a module or feature, you are the recognized expert, and clients - either yours or your competitors' - are as likely to come to you for support and enhancement of that feature as they are to go to the vendor that supplied it.

c) Arguing from a different tack, I (and most open source advocates) maintain that you will not survive in the marketplace if your competitive advantage rests entirely on features you've implemented in your software that are unavailable anywhere else. Short of a patented software mechanism (a concept I strongly oppose), there is no feature you can provide that won't be copied and/or improved on by a competitor as soon as it is shown to be of value to the customer. All you gain from your proprietary feature is whatever market advantage accrues to being first. And that's an advantage you have to earn over and over and over, as your competitors release the next version of their software that incorporates you ideas.

> Sure, the end user gets lots of features, but I'm not the end user! I'm the
> OEM! I can no longer differentiate my product from other on a technical
> level -- removing ONE of the ways I can get ahead of my competitors.

This is true. For the most part, open source is about protecting software users from vendors, not protecting vendors from their competition. This is not to say that vendors are necessarily abusive or coercive or rapacious toward their customers; it is simply that the nature of the relationship between a customer and the vendor of a closed system places the customer at an inherent disadvantage. The open source model presumes that software is a commodity component of a larger system, and that vendors make money on something other than software unit sales.

Regards,

Greg Goodman
Chiron Consulting

Coming in a bit late to the conversation, but here is another two cents to add. FDA controlled businesses will have a very difficult time using open systems because of validation issues. Mass produced software, which is typically proprietary, is typically installed and accepted by the FDA because of it's install base and common configurations. With all of the special drivers and variations of code and configurations the FDA will require more stringent testing to confirm the systems reliability. These companies are busy enough with validations that they will not want to add more to it. FDA compliance and for that matter CE compliance is killing these companies and their innovation. For this reason these companies will want Microsoft and Allen Bradley type systems.

Dale Witman

By Alex Pavloff on 15 February, 2002 - 10:20 am

This argument doesn't hold water.

Microsoft has constant updates to Windows to fix bugs and add features. Hardware manufacturers have updates to drivers on a constant basis. How is the FDA supposed to validate Windows in the first place? What happens when the next Windows security bug is discovered? Are FDA controlled business supposed to leave their systems open to abuse while the FDA "certifies" each and every security patch for Windows?

This is a fundamental problem with any modern operating system -- not just Windows. Certification procedures designed for machines and embedded code fall completely apart when you bring in the complexity of an OS, drivers, web servers, networks, and hardware that can change OVERNIGHT.

The only difference, from a certification perspective, is that a Linux distribution has all its code freely available, while proprietary software doesn't.

Alex Pavloff
Software Engineer
Eason Technology

By Curt Wuollet on 17 February, 2002 - 12:33 pm

That's really interesting. The FAA is working with Linux for their next generation ATC systems because it is the only system on their list that can be completely audited because the source is available. I fail to see how you can approve something secret simply because a lot of other users have no idea what's inside either. If you want audited systems, using systems that are impossible to audit is something only the government could dream up. That's as insane as certifying Microsoft as a supplier of reliable systems when it's arguably the least reliable in aggregate of any OS in modern history. I think we've flipped over into the bizarro world.

Regards

cww

cww,

I believe this happened because there were too many systems installed before the FDA really got involved and they had to reach a compromise with the industry. They allow any applications that are mass produced to be installed and only validate the special functions we add for our applications. If a software manufacturer cannot prove an install base (I believe 100 or more) with identical configurations an audit would be done at their facility to confirm they meet FDA control standards. We or the FDA do not want to audit every line of code for these software packages, so we choose accepted packages to minimize our work.

Dale

By Curt Wuollet on 19 February, 2002 - 11:32 am

Hi Dale.

I think the DOJ ahould talk to the FDA regarding anticompetitive practices. You can't practically use software that isn't already in place because it's not certified so it's impossible to get the installs to get certified unless you can 100 new customers that want to go through a complete audit in order to use your software. I'll bet Microsoft is involved someplace in that one. That sounds like their peculiar idea of competition. That's like the deal they offered PC manufacturers: You can install whatever you want on a PC as long as you pay for a Windows bundle license. Disagree and you pay full retail or we just don't ever get down the list to your allocation. These kinds of tactics are exactly why we need OSS.


Regards

cww

By Michael Griffin on 20 February, 2002 - 2:55 pm

Does that mean 100 systems used in that application, or does it mean 100 systems used anywhere in any application? If the latter (used in any application), then that isn't really very restrictive at all. Virtually any off the shelf product could meet that criteria.

If the former meaning is intended (used in that application), then no system would meet the exempt criteria, as there would always be that first system which must be audited.
The "identical configurations" clause would seem to imply that a major software upgrade (e.g., new OS version) would require re-certification. There could be as much or more difference between successive versions of the same system as there is between alternative systems, so an "upgrade" of a commercial product could not be reasonably exempted until it meets the "100 systems in use" criteria.

I suspect that the criteria you mention is intended to ensure that custom code is audited, and also that new versions of commercial products are avoided until other people have had a chance to find the bugs. Is this the case?


--

************************
Michael Griffin
London, Ont. Canada
************************

My understanding is that what Michael describes is the definition of a proprietary system. I can't think of anyone I have ever known, that would go to the trouble of organizing, testing and distributing this software without a payback. Furthermore if this system is "open sourced" the moment anyone but the distributor touched the code that bundles the package into a standard format, therefore destroying the foundation of "tested by someone else", the distributer has every right to cease supporting the software or charging plenty to fix it.

I am not sure how 'open source', under these conditions, can be cheaper, easier, and prime for a mass market.

Everybody is trying to decrease costs. An "open source" solution, as presently proposed, seems to only increase costs.

Bob Pawley
www.automating-automation.com
250-493-6146

By Joe Jansen/ENGR/HQ/KEMET/US on 13 February, 2002 - 2:59 pm

Doesn't sound like you know the right type of people, then.....

RedHat
Debian
Mandrake
Slackware
SuSE
TurboLinux
FreeBSD

KDE
GNOME
Free Software Foundation

Shall we continue? All of these packages (some are large enough that they fill 6 CD's with software) are available for *FREE* download.

I even suspect that Mr. Woullet is not looking to make his fortune and retire in Jamaica after rolling out ver. 1.0 of the LinuxPLC. Some of us
enjoy what we do enough that we do it for the pleasure, not just because of how much money we can make at it. I realize that doing something without grabbing at cash may be difficult for some to understand, but don't try todeny that it occurs.


--Joe Jansen

By Greg Schiller on 17 February, 2002 - 12:54 pm

Yes these are companies today that sell services around the linux kernel that was converted by Linus but largely concepted by AT&T (a fortune 500 company no less). But, none of those companies above have had to deal with physics being connected to their software. Automation comes with a guarantee to work, be on time, or what was the point. The whole underlying message here is who is responsible for it working.

I'm looking at this from my customers needs. I start down a path where I am going to integrate a LinuxPLC into my system. First of all I need something to run it. OK Let's put it into a white box. I can get a Device net card to run IO. Now I need a motion controller. Nothing fancy just a 2 axis point to point stepper controller. How about that 2 axis AT card. Hmmm. Alright now I need an HMI. Wait I'm running Linux so I can use some XLib/Microwin/Nanowin. Now to make it all work. I do have a Linux driver for the AT card but it was made to be put into a standard Linux environment. It has no real knowledge of the RT environment. Guess I better start writing a driver in C to do that.

Then the HMI adds complexity. At the end of the project I have Frankensteined the whole thing together and find out that the NanoX HMI side is causing something in the RT kernel to not make its rounds every time. By the way it only happens every 3-4 days and I'm supposed to ship the machine by Friday. Guess I better start combing the internet for that How 2 make an HMI, Motion controller, RT Linux work in the same box page. (sorry for the embellishment)

Now my customer wants to take what I did, copy it because its all open source and call me when something goes wrong. No way.

What is my point. The only thing that the LinuxPLC has really gotten me in the above scenario is a real-time engine for free with no guarantee's it will work for my scenario. The only place I can see this stuff being of use is in the small to medium embedded dedicated devices. The machines get made, tested, fixed in design, and sold for money. RTLinux, LinuxPLC, and others provide one approach to getting this done just like other proprietary os's like RTos, Qnx, BlueCat. It does allow smaller companies to produce more complex devices. But that is just it, devices. No changes just hardware.

Truly open automation starts with a feature rich programming tools so that I can save huge amounts of time putting my machines together. People like being able to hit ctrl-z and undo the ladder they just did while the machine was live. They like being able to step their way through the code and see the automation as it is actually working. The like being able to hook up to the Ethernet port and run Modbus TCP and get access to all of their data.

I do not envy the hurdle the LinuxPLC folks have. They have to save us all a bunch time before a FreePLC becomes worth the risk.

> I even suspect that Mr. Woullet is not looking to make his fortune and
> retire in Jamaica after rolling out ver. 1.0 of the LinuxPLC.
> Some of us
> enjoy what we do enough that we do it for the pleasure, not
> just because of
> how much money we can make at it. I realize that doing
> something without
> grabbing at cash may be difficult for some to understand, but
> don't try to
> deny that it occurs.

It does occur.

We are not all greedy. Most of us do this for a living. If some one helps me pay my bills I will help them pay theirs.

-Greg Schiller

By Greg Goodman on 17 February, 2002 - 12:57 pm

> Automation comes with
> a guarantee to work, be on time, or what was the point. The whole
> underlying message here is who is responsible for it working.

Those guarantees come from the integrator, not from the software vendors. Every commercial automation/SCADA/HMI software product I can lay my hands on at the moment has a user license agreement with some (very minor) variation on the following clauses:

1. THIS SOFTWARE IS LICENSED EXPRESSLY WITHOUT WARRANTY OR CONDITION AS TO ANY STANDARD OF PERFORMANCE, OR FITNESS FOR A PARTICULAR PURPOSE. In no event shall the manufacturer have any liability to the customer or any third party arising from the failure of the software to meet any standard of performance or to be fit for any particular purpose.

2. In the event that the master copy of the software should prove defective by reason of materials or the coping process, the manufacturer will replace ... the master copy, provided that replacement under such circumstances shall be the sole liability of the manufacturer.

3. In no event shall the manufacturer have any liability to the customer or to any third party or any claims, damages or causes of action other than replacement of the master copy...

4. The customer and any other party using or relying upon the software agrees that he will perform such checks and verifications of the operation of the software as may be reasonably necessary to insure its proper functioning, and that he will exercise due diligence in the application of the software and the review of the results of the use of the software to avoid loss, injury or damage.

5. The customer and any other party using or relying upon the software agrees to indemnify and save harmless the manufacturer from all claims, actions or suits...

6. In no event shall the liability of the manufacturer to the customer or any other party extend to consequential damages.

It all boils down to this:

All the vendor guarantees is the physical integrity of the copy you received; not the quality of the software, not the soundness of its design or the freedom from bugs, not even that the package is an appropriate tool for the task it's supposedly being marketed for (much less whatever task you put it to use doing).

If you want to build a system using the software, it's on your head to satisfy yourself that it does what you need it to do. (According to the license quoted above, it's on your head to verify that it even does what the manufacturer claims it does.)

If you hire an integrator to build a system using this software, and he guarantees it, then it's on his head; if it doesn't work right, or if it fails and kills somebody, you can sue the integrator, but the buck stops short of the software vendor.

I challenge you to find a single vendor of commercial off-the-shelf software who is willing to assume liability for any loss of life, limb, or your profits that results from your installation, configuration and use of software you bought from them.

Regards,

Greg Goodman
Chiron Consulting

By Greg Schiller on 19 February, 2002 - 11:46 am

You are 100% correct. Even integrators are not legally responsible for damage done. We all have seen the same lawyers and signed the same contracts. Liability has to almost always be proven then collected upon. Different forum.

The key difference between what is being said about being responsible for the system working is they guys who sold me commercial technology are doing their best effort to make sure I buy their services again. That in effect is why I am really buying all those keys or software licenses. They provide me service after the point of sale. The help me when my stuff does not work the way I want it too. But they are at least there waiting for me. Now granted the techsupport isn't always what it is cracked up to be. But I would be willing to bet that most of the time they do a heck of a job. And yes they limit what you are supposed to do with their hardware. They have to much like if I push the FreePLC technology past its window. I have to call its authors and pay money to talk.

Open systems are produced on a program today and consult tomorrow model. Which is fine. They serve a purpose. For those of us who want to take that risk and take the open system as my own. But if I get into trouble and need any assistance I have to call the authors where every they may be and pay them (sounds like an annuity to me.). Much like hiring the folks at red hat to answer my questions about Linux IT technology. This is where I actually end up paying for this product. And because the authors do not get paid per installation they charge me by the hour. One simple phone call and I can exceed the enter cost of a Koyo PLC plus the $500.00 program them all software package. The free plc is free if you can get it to work by yourself. This is a very large risk to short term (1 month) projects like installing production machines.

The Linux RT OS for long term projects like designing a product is awesome. But the product designer is still setting up his or her business to take tech support calls.

AB, Modicon, GE, Seimens, Automation Direct, all sell logic boxes. There are very slight differences between the technologies. But they all have staff that backs what they sell. That is the only reason why people buy off the shelf PLCs. A free PLC OS cannot stand all by itself to the end user market. If people really wanted to make a free PLC they could have bought a Z-World controller and programmed the whole thing themselves. Or used openDOS with a device net card.

On top of it all you have over 100000 sales folks stepping into the design meetings every day plugging a product. Having been one I would almost guarantee you that the first line out of their mouths will be about the lack of tech support for this product. The web you say? Who on the web. The people they are selling to do not have vast C programming knowledge and have better things on their hands to do then hope someone answers their email for free. Finally if the system they selected is not working for their application then they go and purchase another one from another vender.

The only thing that can replace the established PLC as a true mass scale alternative is another PLC/Automation company.

So go team FreePLC. Program for us the next gen open logic system. We need more competitors. Then maybe someone will box it up and support it with a business. I will bet though that after the first 10 calls about how the customer hooked up the unit to a 3 phase welding transformer the price will go up.

Regards all.

Greg Schiller
Automatica Inc.

By Curt Wuollet on 20 February, 2002 - 2:46 pm

You are measuring us with their yardstick again. With closed software you have to talk to the authors and bring a Visa card. With Open Source projects the number of folks that can help you out is greatly expanded. And while there is the potential for consulting for the authors, I don't think anyone is depending on your dollars down the road. As the user base expands there will be a community of users that can help each other. It's kinda like this list, you say "how do I do such and such" and other users can help you out. I would say at least in the early stages, there will be a high percentage of users who understand the source as well as the authors. There is no reason not to tell you whatever you want to know. OSS people tend to be eager to help from my experience so far. And the community will be waiting 24x7x365, no credit card needed.

> Open systems are produced on a program today and consult tomorrow model.
> Which is fine. They serve a purpose. For those of us who want to take that
> risk and take the open system as my own. But if I get into trouble and need
> any assistance I have to call the authors where every they may be and pay
> them (sounds like an annuity to me.).

Who has mentioned money?

> Much like hiring the folks at red hat
> to answer my questions about Linux IT technology. This is where I actually
> end up paying for this product. And because the authors do not get paid per
> installation they charge me by the hour. One simple phone call and I can
> exceed the enter cost of a Koyo PLC plus the $500.00 program them all
> software package. The free plc is free if you can get it to work by
> yourself. This is a very large risk to short term (1 month) projects like
> installing production machines.

I have been very impressed with the help I get on OSS projects and I have never been hit up for money, although I did trade a card once to get a driver written. You still don't get it, this is not a business. Most of us have a job we do for money, I do LPLC stuff to accomplish a goal and make the automation world a better place for me and others to work in.

> The Linux RT OS for long term projects like designing a product is awesome.
> But the product designer is still setting up his or her business to take
> tech support calls.
>
> AB, Modicon, GE, Seimens, Automation Direct, all sell logic boxes. There are
> very slight differences between the technologies. But they all have staff
> that backs what they sell. That is the only reason why people buy off the
> shelf PLCs. A free PLC OS cannot stand all by itself to the end user
> market. If people really wanted to make a free PLC they could have bought a
> Z-World controller and programmed the whole thing themselves. Or used open
> DOS with a device net card.

You will have a community that backs you up. And you can back yourself up If it's broken you can fix it. If an executable gets corrupted you can recompile. If software that once worked stops working that should fix it. Hardware problems on PC platforms can be economically fixed by putting the drive in another machine or swapping cards. This is ususally much faster than the commercial alternatives. And no muzak on hold or dialog with someone who asks you how many wires are sticking out the back and tells you you need the latest version.

> On top of it all you have over 100000 sales folks stepping into the design
> meetings every day plugging a product. Having been one I would almost
> guarantee you that the first line out of their mouths will be about the lack
> of tech support for this product.

I agree with this, the loss of control over you scares the hell out of them. But, if you believe everything a salesman says........

The web you say? Who on the web.

The Mat project of course, specifically the users list.

> The people they are selling to do not have vast C programming knowledge and have
> better things on their hands to do then hope someone answers their email for
> free.

Yeah, like hoping you will get a meaningful helpful answer when you pay for it. Instead of "we don't support that version anymore, you need the latest and the 15 in between. What was that Visa number?"

>Finally if the system they selected is not working for their
> application then they go and purchase another one from another vender.
>
> The only thing that can replace the established PLC as a true mass scale
> alternative is another PLC/Automation company.

I think the last thing we need is more functionally identical closed systems.

> So go team FreePLC. Program for us the next gen open logic system. We need
> more competitors. Then maybe someone will box it up and support it with a
> business. I will bet though that after the first 10 calls about how the
> customer hooked up the unit to a 3 phase welding transformer the price will
> go up.

Hardware sales would be enhanced, but I don't see where there would be a software problem.

> Regards all.
>
> Greg Schiller
> Automatica Inc.

Regards

cww

Greg Schiller:
> The key difference between what is being said about being responsible for
> the system working is they guys who sold me commercial technology are
> doing their best effort to make sure I buy their services again.
...
> They have to much like if I push the FreePLC technology past its window.
> I have to call its authors and pay money to talk.

Of you can call someone else and pay money to talk. Competition (generally) lowers prices. That's an important difference.

Another important difference is that these would be competing on tech support directly. This contrasts with commercial vendors, where tech support is not a profit center and therefore tends to be somewhat poor.

> On top of it all you have over 100000 sales folks stepping into the
> design meetings every day plugging a product. Having been one I would
> almost guarantee you that the first line out of their mouths will be
> about the lack of tech support for this product.
...
> Finally if the system they selected is not working for their application
> then they go and purchase another one from another vender.

They can go and purchase just the support from another vendor. Typically, this will be a much smaller disruption than switching between PLC makers, because the existing investment can continue to be used, both hardware and software.

Obviously, if the whole product ain't working and can't be made to work, they'll have to go through the pain of switching to another PLC vendor. Even there the FreePLC will have an advantage in that interoperability with other vendors is a priority rather than a grudging afterthought.

> So go team FreePLC. Program for us the next gen open logic system. We
> need more competitors. Then maybe someone will box it up and support it
> with a business.

Yup - we hope so.

> I will bet though that after the first 10 calls about how the customer
> hooked up the unit to a 3 phase welding transformer the price will go up.

Not sure how this follows - I've yet to hear of any commercial vendor that would take any action on this beyond adding it to the fortune cookie file.

Replace the hardware, load the same software. No problem.


Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Richard Higginbotham on 13 February, 2002 - 3:15 pm

Who of those people testing, distributing, etc. the software wouldn't want bug fixed and features added that they don't have to pay for? As the tester, distributer you already have a job to do, if you can get the development(some/all) done for FREE, why in the world wouldn't you jump at the chance. The pay back comes from the services you offer, not the software itself. Testing, warranty, support, etc. Its the same as those big fees "sers pay yearly for support (patches, updates, etc.) to any of the vendors out their now. But instead of the vendors having a small group of developers with limited amount of equipment you have a huge group of developers who are all interested in bettering the software because most of them actually use it. It will make a big difference to them that it actually works, and since their code will be seen potiently by everyone using the software, they are far more likely to do things right. All you have to do is test, certify the software being released (same as now, although some vendors seem to skip this step) and charge money for your value additions. Its all gravy.

RedHat, etc. stay afloat because they DONT have to pay for all those development hours.


Richard Higginbotham

speaking for me

By Greg Goodman on 13 February, 2002 - 3:40 pm

>> "I think that most people will want to buy something which is already put
>> together and tested by someone else.

> My understanding is that what Michael describes is the definition of a
> proprietary system.

I disagree completely. "Proprietary" means that only the manufacturer has access to the internals, or the right/ability to fix or modify it. Michael is describing a product whose components are open, but whose initial assemblage and configuration and testing have been taken care of for you. When you buy such a package, you're paying for the effort and expertise that went into the packaging. You're not paying for the software, and you're not obliged to get your support, or your fixes, or your consulting, or your upgrades and add-ons and customizations, from the same provider. "Open" means you have the right and the access (whether or not you have the skill) to take over completely the management and maintenance of your system. Lacking the skill or the time or the inclination, you are also free to have someone else do it.

To use a mundane example, houses are "open" technology; the plans are published, the materials are readily available, and any technologist competent in the field can build one, or fix or modify one once it's installed. That doesn't mean that everybody builds their own house, or that there's no money to be made building houses for other people. What it does mean is that there are a variety of approaches to getting a house built. You can buy the materials and build one, or buy the materials and pay someone else to build one, or pay somebody else to take care of the whole thing. You are also free to buy a pre-fab that only the manufacturer can work on, but that's an idea that even Buckminster Fuller had trouble selling to the public.

The analogy can actually be pushed a bit further. A house has a number of complex subsystems, and any one person is probably not an expert in all of them. You may be a good carpenter or plumber or bricklayer, but
you may not know much about pouring concrete or wiring electricity. For this, you hire specialists, or hire a general contractor that employs specialists. Later, when you need the attic converted to a bedroom, or an alarm system installed, or a swimming pool that ties into your
plumbing and electricity, you're not beholden to the original builder.

As Curt frequently points out, "open" isn't just about low cost; it's about freedom. And that freedom isn't limited to the choice between doing it yourself and buying from one of the big-name distributors. It's a freedom that lasts forever, and survives the demise of the manufacturer, survives the abandonment of software packages by the provider, is immune to the obsolescence of standards and protocols and interfaces. As long as you can find (or be) someone competent in the technology, you can protect your investment.


> I can't think of anyone I have ever known, that would go
> to the trouble of organizing, testing and distributing this software without
> a payback.

The payback for packaging is a completely separate issue from whether "pre-packaged" is equivalent to "proprietary".

There are two easily identified revenue streams from packaging/distributing open source components:

1) people paying for the convenience of using your packaged version

red hat makes money from their distributions because most linux users don't want to collect the several hundred software packages it takes to make a usable desktop box, verify that the versions are current and correct, compile them in an appropriate development environment, and configure them from scratch. users are also happy to have the correct video driver (out of the several hundred possibilities) auto-selected and installed, the correct NIC driver, the correct ATAPI/CDROM driver, etc. red hat (and every other distribution provider) has done sufficient work that the dollars it costs me to buy their distribution (about $30) is much less expensive than the time it would cost me to accomplish the same thing (many hours, maybe days).

2) people paying for support

which brings us to your next point.

> ... the moment anyone
> but the distributor touched the code ...
> therefore destroying the foundation of "tested by someone
> else", the distributer has every right to cease supporting the software or
> charging plenty to fix it.

True; that's what warranties, service contracts and support agreements are for, which is a topic for another posting.

Regards,

Greg Goodman
Chiron Consulting

By Alan Brause on 14 February, 2002 - 9:50 am

Your house analogy is well taken and goes a long way to clear up some of the misunderstanding about "open" technology. But the problem I see is that home building is described in sets of established codes and automation isn't.

For instance, every lumber manufacturer knows 2X6 dimensional lumber is used in building, every electrical manufacturer knows if they build to UL specs they can sell their products, every plumbing
manufacturer builds fixtures that connect to standardized pipe sizes, you start to get the picture.

Where are the codes and standards in automation that can allow this type of open technology to work? Isn't this where it all has to start?

Alan Brause

Hi Greg:

One of the postings had this statement -

"That's where distributions come in - they're the sales departments of the Linux world, and that's where you go when you want a structured, organized package.

One can modify anything in Linux, but one rarely does. Indeed, I would expect that a plant would standardize on a particular combination of
packages from a particular distribution, perhaps customized, and then refuse to change a thing for years (without good reason). Only the actual
control logic would change"


I am still not convinced of the difference between a Linux package that a distributor puts together that "no one can touch" and a proprietary package, an original invention, that has the code protected. I agree that with Linux
you do have the option of changing the base code at any time. But, there are consequences of doing so, such as:

- warranty violation
- creating a non-standard format
- by definition you force people, newly exposed to any Linux installation to review the whole software package
- changing a "standard" software package can inhibit standardizing solutions across processes, plants and the whole enterprise.

These consequences all come at a cost that has to be calculated before adopting any open source system.

I would further suggest that trends in the software industry as a whole, automation always lags, is to make tools easy and intuitive to use. People want tools - the vast majority are not particularly interested in doing the coding. An example of this trend can be seen from the explosion of computer sales once Microsoft moved from DOS to Windows.

I agree as well, that proprietary software for systems needing flexibility, such as industrial primary and advanced control, is restricting. However, I have yet to be convinced that a purely open source system is the way to go.

Bob Pawley
www.automating-automation.com
250-493-6146

By Greg Goodman on 14 February, 2002 - 1:32 pm

> With a proprietary system the trouble-shooter knows the fundamental nature
> of the program can not be changed so he is perfectly comfortable standing on
> that knowledge. Not so with an open source system.

Huh? Whether your system is proprietary or open, you change the fundamental nature of a program by installing something else on top of it. With open software, such a change can be accomplished by modifying the code (or obtaining a modified copy of the code), compiling it, and installing it. I know of a number of sites whose control systems are running Linux, and not one of them has the sytsem source code or a development environment available to the operator login.

> One of the posts indicated that Linux is structured and organized by the
> distributor and the core programs are not touched unless absolutely
> necessary. Who makes this decision, The guy on the site?, His supervisor?
> The president of the company 5,000 miles away? How is this software
> structured by the distributor and never touched, so much different from
> proprietary software?

Who makes those decisions for your proprietary system? When somebody goes onsite to trouble-shoot your Windows + Wonderware + RSLogix installation, who decides whether it's okay to upgrade Windows from '98 to 2000? Who decides whether it's okay to overwrite a system DLL with one that's supposedly better? Who decides whether to swap out the SuiteLink Modbus driver for a 3rd-party OPC Modbus driver, or change the database interface from SQL to ODBC, or move the ethernet connection from the local firewall to a DSL modem dialed directly into an ISP?

If modifying the software architecture of the system is something anybody's allowed to do, it doesn't much matter whether it's proprietary
or open. And if there's a process for considering and approving modifications, it doesn't much matter whether the software's proprietary of open.

Greg Goodman
Chiron Consulting

Greg Schiller:
> I would agree. People who use technology only want one thing from it.
> Does it work. The next thing they want is if it is broke where can I get
> a replacment. Forklifts do amazing things for our economy.

> Totally free, open system can fill niches but no one dedicates real R and
> D dollars to making something they may never own in the future.

As you say in the first paragraph - does it work?

Once the core of an OSS product exists, people who take advantage of it can extend it in minor ways, add bits and pieces they need, swap the extensions the same way as they swap Lisp functions in the AutoCAD world.

Obviously, for that to work the core must be there; but we (MAT) are well on the way to building it, so it's not ridiculous to suppose it'll appear.

> I would like to take your money to make this very cool niche product that
> I will then give the rights away to the public. How am I going to pay you
> back? I'm not. I can't. No one has bought my idea from me.

No, but the machine now works - and that's worth something.

Most software in the Automation world is epiphenomenal - it has no meaning in itself except as a side-effect of producing something else, something real and useful.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

By Joe Jansen/ENGR/HQ/KEMET/US on 12 February, 2002 - 10:47 am

Bob wrote:

I don't know about others, I speak only for myself.

I came into this open control and open source discussion later than most with no preconceived ideas other than what I have lived with for the last 30 some years.

It does seem to me that we as an industry have moved from total proprietary systems, to a point where we aren't absolutely required to purchase
hardware and software from the same source.

Joe Replies:

I agree. DeviceNet is a good example of this trend, where I can use Omron, InterbusBT, and many other branded I/O components with my AB
processor/scanner module.

Bob wrote:

The other extreme that has come about because of Linux causes me to note that there is a definite movement toward systems being as open as possible.
This trend will continue regardless of what individuals think.

What I am suggesting is that a totally open system such as Linux - standing by itself - is to much the opposite extreme to have great appeal.

Joe replies:

Could be. However, as I was alluding to in my posting, sometimes you need a group at the far opposite extreme in order to get the mainstream to shift towards where you really want to be.

Bob wrote:

Some boundaries, some anchor is needed so that all concerned have a solid place to stand in order to see what needs to be done or to see what has been done.

Proprietary systems have this solid place upon which everyone, technician to corporate bureaucrat, is comfortable. The fact that this proprietary place
is so vast gives me reason to consider a melding of the two extremes.


Joe replies:

This is where I am getting confused. Is it simply their name that gives everyone a "warm-fuzzy" feeling? If RSLogix were released as a Linux app, would that apply? I don't pretend to think that they would open source it, but what if I could buy it, even at the same cost, for Linux?

Or do you feel there is something more than the names of the providers that provides that solid place? Is it the hardware? If LinuxPLC does manage to get some hardware platform, and a system that provides the stability of a PLC with data collection that isn't a PITA, does that provide the footing that management/others seeks?

Could you clarify a bit more for me what you meant at the end of your post? I feel that I -almost- "get it".

Thanks!

--Joe Jansen

Hi Joe:

Let me try to unmuddy the waters.

When an organization purchases software, the corporate cost effective strategy is to have as standard a set of programs as can be arranged throughout a single plant or throughout a complex of plants. This especially true with today's trend of multi-national corporations. The person responsible to implement this strategy feels a lot more comfortable with a system that operates the same everywhere - everytime.

It would be very uncomfortable, for him, to have a software system whose core components, the parts that make it work as it does, could be changed at anyone's whim. With this software, any time someone came in from outside to troubleshoot or to upgrade he would need to check, not only the various programs that make up the control itself, he would also need to check how the core bits and pieces were operating. This is extra time and money.

With a proprietary system the trouble-shooter knows the fundamental nature of the program can not be changed so he is perfectly comfortable standing on that knowledge. Not so with an open source system.

One of the posts indicated that Linux is structured and organized by the distributor and the core programs are not touched unless absolutely necessary. Who makes this decision, The guy on the site?, His supervisor? The president of the company 5,000 miles away? How is this software structured by the distributor and never touched, so much different from proprietary software?

Of course, once this distributor structured and tested software has been changed by others in the field, the distributor no longer warrants it and full price will be charged to return it to the structured, tested version.

Other than the run time cost of today's proprietary software, I don't see much advantage in open source as it has been presented to me, at this time. I do see a lot more time and cost involved just to ensure the core components are still as they were when the software was purchased.

Bob Pawley
www.automating-automation.com
250-493-6146
1-800-573-7703

> It would be very uncomfortable, for him, to have a software system whose
> core components, the parts that make it work as it does, could be changed at
> anyone's whim. With this software, any time someone came in from outside to
> troubleshoot or to upgrade he would need to check, not only the various
> programs that make up the control itself, he would also need to check how
> the core bits and pieces were operating. This is extra time and money.

This seems to me to grossly misrepresent "open source". A PLC (for instance) running on open source software would likely be compiled, and may not be even usable as a development platform; altering that code would require editing the source and recompiling, testing, etc., then moving the revised executables to the PLC. I can't imagine that every Tom, Dick, and Harry would be doing this sort of thing.

Further, your argument appears to assume that an "open source" system is necessarily anarchic. More likely, a plant or group would choose to use a particular distribution of PLC, MMI, etc., and only a few of the users (probably somewhere else) would actually work on the actual source code. Anyone could file bug reports, offer patches, etc., but the developers would commit such changes, documenting them, incrementing version numbers, etc., in an organized fashion.

> With a proprietary system the trouble-shooter knows the fundamental nature
> of the program can not be changed so he is perfectly comfortable standing on
> that knowledge. Not so with an open source system.

Huh? The fundamental nature of a proprietary system is known only to the extent the manufacturer wishes to document it, and to the extent that its users have probed and prodded its black box to try to understand it. An open source system, on the other hand, is completely exposed to any user who wishes to look, in all detail. If an open source system changes, a user could trivially (e.g., using diff) check to see what has changed, but there ought also to be a changelog describing changes and probably some discussion on a mailing list or other forum.

Re "the program can not be changed", I've seen proprietary black boxes (e.g., some modems) with the same model-release numbers that had demonstrably and annoyingly different code running in them. This caused unexpected downtime and expense, and the manufacturer offered no help. The answer to that is (obviously) to find another manufacturer, one who follows better development practices.

Now, the same sort of thing could happen in an open source system, but again, the changes would be visible. Inasmuch as such a screwup causes downtime and expense, the user would certainly be justified in complaining and finding a new system, railing against the miscreants publicly, and hopefully preventing more such screwups.

> One of the posts indicated that Linux is structured and organized by the
> distributor and the core programs are not touched unless absolutely
> necessary. Who makes this decision, The guy on the site?, His supervisor?
> The president of the company 5,000 miles away? How is this software
> structured by the distributor and never touched, so much different from
> proprietary software?

Anyone can monitor the very active development lists for Linux and other open software, or view weekly summaries of same. Projects can be organized in different ways, with one developer or a few able to modify the source. Anyone can view the code, compile and test it locally, develop and offer patches, but typically those changes must be approved before going into the system. The biggest difference from proprietary is that the source is visible and can be inspected for any minute problem, problem reports and fixes can be offered publicly in a useful way. If the responsible developer refuses to fix a problem, at least that's public knowledge and can be pursued and addressed. Not so with proprietary systems, IMHO.

> Of course, once this distributor structured and tested software has been
> changed by others in the field, the distributor no longer warrants it and
> full price will be charged to return it to the structured, tested version.

This "changing in the field" thing is perplexing to me. Is it the PLC ladder logic that's concerning you? That's what the users would be dealing with, or the HMI/MMI screens, point names, etc..

> Other than the run time cost of today's proprietary software, I don't see
> much advantage in open source as it has been presented to me, at this time.
> I do see a lot more time and cost involved just to ensure the core
> components are still as they were when the software was purchased.

Maybe it would be instructive to have a look at development in action, e.g.,

http://kt.zork.net/kernel-traffic/latest.html

is a weekly run-down of the Linux kernel development. The developers hash things out at great length, and major changes are hard won by their proponents, not just slipped in without a thought. And note that they're talking about the leading edge versions and not the older, stable versions most folks are using.


Ken

--
Ken Irving <jkirving@mosquitonet.com>

By Joe Jansen/ENGR/HQ/KEMET/US on 13 February, 2002 - 4:29 pm

Hey Bob, thanks for the reply ( again :^} )

I still have a question or two tho. Let me try laying this out in 2 different scenarios, and you can give me a pro/con list of each.

Plant #1: Standardized on Allen Bradly SLC processors 10 years ago. They have the full range from SLC 5/01's and Micro's, all the way up to the latest 5/05 processor. Over the years, they used APS, then upgraded to AI to do their programming. They never bought into RSLogix, as they had no need.....


Plant #2: Is using Linux / Open source based PC controls. All the I/O is based on Modbus/TCP and other TCP/IP friendly I/O. They are running kernel version 2.0 (an older version) and have not upgraded to the latest kernel, as they had no need.....


Ok. Both plants have a standard. They are both running along just fine. In plant 1, if an integrator brings in a new machine, they leave all the documentation and disk copies in AI compatible files, so the plant does not have to upgrade.

In Plant 2, if an integrator brings in a new machine, they implement the controls on Red Hat version 6.1, using kernel ver 2.0, as supplied to them by the plant, as their core operating system.

(Curt and others: I am not sure if that is the right kernel rev for RH6.1, as I am making this example up as I go)

My questions are:

How is plant 2 in any worse shape than plant 1? Don't they have the advantage of knowing that they can give the integrator (legally) a copy of
their core OS to use as the starting point?

If Rockwell decided that the next version of RSLogix would not be able to export files in AI format, and the exact same day, Red Hat announced that the distrobution disks for 6.1 were no longer available to download from their web site, who got the shaft harder? As integrators upgrade their software, isn't plant 1 being pushed into upgrading their programming software against their will? Plant 2 already has all the legal software purchased that they need to (1), and if they can't support it, they can still get support from many other locations.

I would think that the person in charge of the software platform would be cracking open a new roll of Tums on that day.

Don't get me wrong, I am not trying to cheerlead for Linux. I guess I am just looking for an example of how it is better to use proprietary software as a means of insuring continuity. I have seen myself that most new software releases insure that file formats are incompatable, thus forcing the upgrade. If the techs at my remote plants are a rev behind, they cannot look at my stuff.

Maybe the best way for you to reply would be to do the above, but give an example of the two plants illustrating the problem of the open source solution. I guess I just feel that since the plant is able to say "Use this disk as the core OS of the control" in the same way that they tell integrators "Use Allen Bradley SLC 5/04 processors as the core processor of the control", doesn't having the ability to reuse it endlessly without possibility of discontinuation a benefit?

Thanks. Hope to hear back soon!!!!!


--Joe Jansen

Hi Joe:

This thread is getting a little interesting.

See if I make any sense with the following comments.

Bob Pawley
www.automating-automating.com
250-493-6146
800-573-7703

> Hey Bob, thanks for the reply ( again :^} )
>
> I still have a question or two tho. Let me try laying this out in 2
> different scenarios, and you can give me a pro/con list of each.
>
> Plant #1: Standardized on Allen Bradly SLC processors 10 years ago. They
> have the full range from SLC 5/01's and Micro's, all the way up to the
> latest 5/05 processor. Over the years, they used APS, then upgraded to AI
> to do their programming. They never bought into RSLogix, as they had no
> need.....

I have been away from direct involvement with that part of the industry, but I suspect that the software and hardware are still required to be purchased as a package??

> Plant #2: Is using Linux / Open source based PC controls. All the I/O is
> based on Modbus/TCP and other TCP/IP friendly I/O. They are running kernel
> version 2.0 (an older version) and have not upgraded to the latest kernel,
> as they had no need.....
>
> Ok. Both plants have a standard. They are both running along just fine.
> In plant 1, if an integrator brings in a new machine, they leave all the
> documentation and disk copies in AI compatible files, so the plant does
> not have to upgrade.

Let's separate the two points. Both of your examples allows the user to manipulate the control elements to do whatever needs doing.

AB will not let you add features and change the core elements of their program by yourself. Linux does allow anyone and everyone knowledgeable enough, to change these core features.

> In Plant 2, if an integrator brings in a new machine, they implement the
> controls on Red Hat version 6.1, using kernel ver 2.0, as supplied to them
> by the plant, as their core operating system.
>
> (Curt and others: I am not sure if that is the right kernel rev for
> RH6.1, as I am making this example up as I go)
>
> My questions are:
>
> How is plant 2 in any worse shape than plant 1? Don't they have the
> advantage of knowing that they can give the integrator (legally) a copy of
> their core OS to use as the starting point?

If I were the plant operator, the one who purchases the software and pays your wages, I would be more comfortable with AB over Linux. With AB I am assured of a basic standard of software operation that I know will be the same from the time I purchase it 'till I am convinced to purchase an upgrade. This insures that in my plant's near future I will be protected by a warranty, I will know that one part of my empire has basically the same infrastructure as the other parts, I can send solutions from one plant area to another without worrying if some eager beaver has changed the infrastructure so that it is no longer compatible. I can hire new employees that will know the AB infrastructure, I can transfer employees, with the assurance that they will not need to spend their time and my money determining how the infrastructure is engineered. All this to keep costs and problems down and production constant.

Another point - If I were a plant operator I would not buy software. I would purchase tools, software tools that you were able to use without adding further expense. I would try to purchase tools that you would not need to take apart and then put back together in order to make it work. I would do my best to buy those tools that don't require further time, effort and my money to make them work.

Linux is a dream come true for the creative techs who want to solve problems effectively, quickly and by putting a little of themselves into the work.

But - until I, as a plant operator (example only), can be satisfied that my concerns outlined above are satisfied, then I will be extremely reluctant to purchase open source.

> If Rockwell decided that the next version of RSLogix would not be able to
> export files in AI format, and the exact same day, Red Hat announced that
> the distrobution disks for 6.1 were no longer available to download from
> their web site, who got the shaft harder? As integrators upgrade their
> software, isn't plant 1 being pushed into upgrading their programming
> software against their will? Plant 2 already has all the legal software
> purchased that they need to (1), and if they can't support it, they can
> still get support from many other locations.
>
> I would think that the person in charge of the software platform would be
> cracking open a new roll of Tums on that day.
>
> Don't get me wrong, I am not trying to cheerlead for Linux. I guess I am
> just looking for an example of how it is better to use proprietarysoftware
> as a means of insuring continuity. I have seen myself that most new
> software releases insure that file formats are incompatable, thus forcing
> the upgrade. If the techs at my remote plants are a rev behind, they
> cannot look at my stuff.

If this is happening purposely, rather than a needed method of making the application better, then it is clearly wrong.

> Maybe the best way for you to reply would be to do the above, but give an
> example of the two plants illustrating the problem of the open source
> solution. I guess I just feel that since the plant is able to say "Use
> this disk as the core OS of the control" in the same way that they tell
> integrators "Use Allen Bradley SLC 5/04 processors as the core processorof
> the control", doesn't having the ability to reuse it endlessly without
> possibility of discontinuation a benefit?
>
> Thanks. Hope to hear back soon!!!!!
>
>
> --Joe Jansen

By Michael Griffin on 17 February, 2002 - 1:54 pm

<clip>
> If I were the plant operator, the one who purchases the software and pays
> your wages, I would be more comfortable with AB over Linux. With AB I am
> assured of a basic standard of software operation that I know will be the
> same from the time I purchase it 'till I am convinced to purchase an
> upgrade.

This is based on the assumption that "EPROMS don't change". There are two
problems with this argument. The first problem is that if EPROMs can't be changed, then they won't change if you have open source or proprietary software.
The second problem is that a lot of newer proprietary systems are built with flash EPROM. If you use a newer version of programming software (or an integrator or one of his subcontractors does), the programming software may download a new firmware revision into the hardware. It may even do this without telling you what it is doing (you just notice that the program download is taking longer than normal).
Some newer proprietary hardware is being shipped with nothing loaded into the firmware except a simple loader. The version of firmware which ends up in it depends upon what was on the hard drive of the computer used to program it. You could buy two identical pieces of hardware, but end up with different firmware in them when you download your applications.
This of course doesn't deal with the question of new equipment or repairs. If you order a new PLC this year, it isn't going to come with the same firmware as the one you bought a year ago. The manufacturer will likely have fixed bugs and added new features.

Even having conventional EPROMs doesn't guarranty that they are stock parts. We have stuff (not PLCs though) with custom EPROMs. All we had to do was to supply the manufacturer with a spec for the modifications we needed. There is nothing to stop one of your employees from doing the same thing.

Given the above, I am not sure why you feel that buying AB hardware will result in the "fundamental features" of the hardware being identical. You might argue that AB sells very good hardware, but that is another issue (and
another topic) altogether.

> This insures that in my plant's near future I will be protected by
> a warranty, I will know that one part of my empire has basically the same
> infrastructure as the other parts, I can send solutions from one plant area
> to another without worrying if some eager beaver has changed the
> infrastructure so that it is no longer compatible.

Your warranty with any control hardware manufacturer will be limited at most to the return of any non-functional hardware or software. They aren't going to "protect" you from any other consequences of changes they make to their product line. It would be unreasonable to expect them to do so.

> I can hire new employees
> that will know the AB infrastructure, I can transfer employees, with the
> assurance that they will not need to spend their time and my money
> determining how the infrastructure is engineered. All this to keep costs
> and problems down and production constant.

This is training, not open source versus closed. You can hire new employees who have worked with AB's hardware before because there is so much of it already in use elsewhere. However, if AB were to introduce a new product
which was unrelated to any of their existing product lines, your argument would not be valid.


> Another point - If I were a plant operator I would not buy software. I
> would purchase tools, software tools that you were able to use without
> adding further expense. I would try to purchase tools that you would not
> need to take apart and then put back together in order to make it work. I
> would do my best to buy those tools that don't require further time, effort
> and my money to make them work.

Have you had any luck with this? I'm sure a lot of people would like to know where to buy software that works the way it is supposed to. I've spent far too much time and money on the usual kind, and there doesn't seem to be much correlation between the price of the software and the quality of the product.

> Linux is a dream come true for the creative techs who want to solve
> problems effectively, quickly and by putting a little of themselves into
> the work.
>
> But - until I, as a plant operator (example only), can be satisfied that my
> concerns outlined above are satisfied, then I will be extremely reluctant
> to purchase open source.
<clip>

I think your last sentence is pretty close to your real reasons. The real issue for you is that you are pretty happy with what you have been getting from AB, and don't feel any compelling reason to change. No doubt you have bigger problems to worry about than any that AB has been giving you.

However, let me ask you a question. If AB introduced a new product that used a Linux operating system, would you consider buying it? If all their new operator interface terminals used "Rockwell Linux" to host the application, would you then switch to a different brand of hardware to avoid it?


--

************************
Michael Griffin
London, Ont. Canada
************************

By Joe Jansen/ENGR/HQ/KEMET/US on 19 February, 2002 - 12:23 pm

OK Bob, back at ya!

<grin>

--Joe Jansen

btw: the link in your .sig.... Is that you? Or are you supporting someone else? Just curious. Poked around the site a bit...

-------------------------------------------------

Bob Pawley wrote:

Hi Joe:

This thread is getting a little interesting.

See if I make any sense with the following comments.

Bob Pawley
www.automating-automating.com
250-493-6146
800-573-7703

<snip>

From Bob:


> I still have a question or two tho. Let me try laying this out in 2
> different scenarios, and you can give me a pro/con list of each.
>
> Plant #1: Standardized on Allen Bradly SLC processors 10 years ago.
They
> have the full range from SLC 5/01's and Micro's, all the way up to the
> latest 5/05 processor. Over the years, they used APS, then upgraded
> to
AI
> to do their programming. They never bought into RSLogix, as they had
> no need.....

I have been away from direct involvement with that part of the industry, but I suspect that the software and hardware are still required to be purchased as a package??


Joe Replies:

No. The hardware does have the firmware included, of course, but the programming software is not a bundled purchase. It is 'available' seperately for a mere $1500 to $3000 USD, depending on what peice of hardware it supports. Of course the software for the SLC does not program the PLC 5 series, so to do both puts you out a bit under $5000 USD, and that is for 1 copy of each. If you have a developer and a technician, start coughing up the cash!

This is why the PLC companies now make each version's file format incompatible with the previous version. They will give a story about how it is necessary to provide better functionality, blah blah blah. It is a load of BS, though, since most times the 'new functionality' is a prettied up UI in the software. Parts of the latest RSLogix release I actually wish I could turn off, but cannot (Anyons from RS listening? I want rid of the little 'helper' box that pops up when I am entering instructions mnemonically. ie: I enter EQU and the yellow box pops up that says EQU SourceA SourceB. Problem is that if I am at the bottom of the window, it covers my text entry window, and I cannot see what I am tryiong to type). But I digress............


The reason for the incompatibility is chiefly to make you upgrade and enhance the revenue stream. If they didn't, most people would skip the 'service contract' and jsut keep what they have for many years. By pricing the cost of the service contract, which includes 'free' (note the
finger-quotes) upgrades at just slightly less than the cost of a whole new package, and then insuring that you 'want' to upgrade once a year (so you can still work on your equipment for another year), they insure a steady income for their software division.

Bob Continues:


> Plant #2: Is using Linux / Open source based PC controls. All the
> I/O
is
> based on Modbus/TCP and other TCP/IP friendly I/O. They are running
kernel
> version 2.0 (an older version) and have not upgraded to the latest
kernel,
> as they had no need.....
>
> Ok. Both plants have a standard. They are both running along just
> fine. In plant 1, if an integrator brings in a new machine, they leave
> all the documentation and disk copies in AI compatible files, so the
> plant does not have to upgrade.

Let's separate the two points. Both of your examples allows the user to manipulate the control elements to do whatever needs doing.

AB will not let you add features and change the core elements of their program by yourself. Linux does allow anyone and everyone knowledgeable enough, to change these core features.


Joe gleefully replies:

Yes! That is a big part of my point. Note that linux does not -require- you to do so, but if I want to write a custom function (similar to what Siemens processors let you do, I believe), my AB system 'just says no'. If I have a unique situation that requires a specially modeled PID loop for example, you sure aren't doing it in an AB processor. Conversely, I can write any special functions I need into a L-PLC implementation and it grows as I need it too. Heck, someone may have already written a better one and felt like sharing it (it isn't required tho).


Bob posits:


> In Plant 2, if an integrator brings in a new machine, they implement
> the controls on Red Hat version 6.1, using kernel ver 2.0, as supplied
> to
them
> by the plant, as their core operating system.
>
> (Curt and others: I am not sure if that is the right kernel rev for
> RH6.1, as I am making this example up as I go)
>
> My questions are:
>
> How is plant 2 in any worse shape than plant 1? Don't they have the
> advantage of knowing that they can give the integrator (legally) a
> copy
of
> their core OS to use as the starting point?

If I were the plant operator, the one who purchases the software and pays your wages, I would be more comfortable with AB over Linux. With AB I am assured of a basic standard of software operation that I know will be the same from the time I purchase it 'till I am convinced to purchase an upgrade. This insures that in my plant's near future I will be protected by a warranty,

Joe cannot help but interrupt:

Warranty?! We don't have no stinkin' warranty! (accent intended). Read carefully what you assume is your warranty from Allen Bradley. They warrant that it won't turn into smoke the first time you plug it in. If you plugged it in, and a day later it turned to smoke, it is your problem. I know this *first hand* on several occaisions. And don't assume that they warrant that the application is appropriate for your system. I would like you to show me what warranty you think you have with their stuff....


Bob continues after the interruption:


I will know that one part of my empire has basically the same infrastructure as the other parts, I can send solutions from one plant area to another without worrying if some eager beaver has changed the infrastructure so that it is no longer compatible. I can hire new employees that will know the AB infrastructure, I can transfer employees, with the assurance that they will not need to spend their time and my money determining how the infrastructure is engineered. All this to keep costs and problems down and production constant.

Joe replies:

In the plant(s) I currently work at, we have defined software version control procedures in place for all control software. This includes ladder files, motion controller configurations, touchscreen program files, etc. Nothing is allowed to be modified without a formal (written) description of the changes required by the process engineers. Once the changes are done, process engineering and equipment engineering get together to run an acceptance test. Upon acceptance, the documentation is updated, the new files are archived and distributed to the technicians file areas so they have the required documentation for troubleshooting, etc.

How would any of this change? Having an Open source based system does not require me to allow operators to hack code in their spare time. Just as I cannot go off and write myself an app that will generate huge levels of network traffic, you would simply make the OS code off limits to anyone developing, and handle required exceptions as needed, if needed at all.


Bob continues:


Another point - If I were a plant operator I would not buy software. I would purchase tools, software tools that you were able to use without adding further expense. I would try to purchase tools that you would not need to take apart and then put back together in order to make it work. I would do my best to buy those tools that don't require further time, effort and my money to make them work.

Joe nods and agrees, so Bob continues on:

Linux is a dream come true for the creative techs who want to solve problems effectively, quickly and by putting a little of themselves into the work.

But - until I, as a plant operator (example only), can be satisfied that my concerns outlined above are satisfied, then I will be extremely reluctant to purchase open source.


Joe interjects:


And that, of course, is the wisest thing to do. There will be a time, though, when the current tool set is inadequte. It is already quite often not real elegant. The question comes down to a cost v. benefits. Will you, as the plant operator, be willing to give your developers the -best- tools, or the tools that can be made to work. If you workers need to pound a nail, and all you have ever bought are wrenches, do you get them a hammer, or tell them to turn their wrench sideways?


Bob again:

> If Rockwell decided that the next version of RSLogix would not be able
> to export files in AI format, and the exact same day, Red Hat
> announced that the distrobution disks for 6.1 were no longer available
> to download from their web site, who got the shaft harder? As
> integrators upgrade their software, isn't plant 1 being pushed into
> upgrading their programming software against their will? Plant 2
> already has all the legal software purchased that they need to (1),
> and if they can't support it, they can still get support from many
> other locations.
>
> I would think that the person in charge of the software platform would
> be cracking open a new roll of Tums on that day.
>
> Don't get me wrong, I am not trying to cheerlead for Linux. I guess I
> am just looking for an example of how it is better to use
proprietarysoftware
> as a means of insuring continuity. I have seen myself that most new
> software releases insure that file formats are incompatable, thus
> forcing the upgrade. If the techs at my remote plants are a rev
> behind, they cannot look at my stuff.

If this is happening purposely, rather than a needed method of making the application better, then it is clearly wrong.


Joe:


I addressed this further up. Suffice to re-iterate that Logix changes file format as often to more often than MS word. No net gain to the end user, but you do have to upgrade your software. Funny how that happens every time. And all they can tell you each time is "Well, we didn't anticipate well enough to make the last version expandable. oops." Funny they never learn, tho.

By Michael Griffin on 19 February, 2002 - 12:26 pm

My own impression of the reason behind this problem (and it is a serious one) is a bit different from yours. I did some investigation (telephone calls, etc.) for why a certain PLC's software was not able to accept files from versions with trivial differences (no changes which would affect the PLC or the code it received). The conclusion that I reached was that it was due to laziness and stupidity rather than greed and malice.

I spoke to certain people in the company's marketting department, and they
were at least as unhappy about the situation as I was. The story they were receiving from their software developers was that it was all necessary because the PLC used "compiled instead of interpreted code". Since the programming software is dealing with a source code file, this was self evident nonsense. The real reason was more like "I can't be bothered with what customers want, this was easier for me, go away".

I have been getting the impression lately (and not just with this situation) that there has been an influx of programming and software design staff with little or no experience with what customers in industry really need. They've produced some very flashy Windows programs without the functionality or balance of features which existed in their DOS predecessors.
Some of these programs are almost unusable unless you are sitting at a desk with a large monitor and a mouse. I have a hundred tool bars with fancy graphics, but my program is squished down into a tiny corner of my screen when I'm out on the plant floor. Have the people who dream these things up ever used them in real life?
The situation seems to be improving, but I have to wonder why these companies had to learn the same lessons over again which they had apparently forgot from their earlier days.

I found a way of dealing with the file compatability problem on a short term basis though. I was able to export the file in ASCII format, and import it again into the older version. The software had no problems with this - as it obviously shouldn't since it is dealing with identical instructions in either case. So the question arises - why couldn't I do this directly?

--

************************
Michael Griffin
London, Ont. Canada
************************

<snip>
>>I addressed this further up. Suffice to re-iterate that Logix changes file format as often to more often than MS word. No net gain to the end user, but you do have to upgrade your software. Funny how that happens every time. And all they can tell you each time is "Well, we didn't anticipate well enough to make the last version expandable. oops." Funny they never
learn, tho.
<<
<snip>

Not only that (which is annoying enough) but, and I guess this depends on what version of RSL created the ladder file, but an older version of RSL reading a later version file typically causes my computer to crash.

Which prompts me to wonder ... how hard would it be to preface the file with a data block describing which version created it?

That way, RSL would see immediately that it might not be able to digest the data, and give a relevant error message (i.e. - "Look, Tightwad, Upgrade now to RSL vx.xx. The data file was created with RSL vx.xx, and RSL version y.yy you are now using may cause the computer to crash if I read it").

A question comes to mind as well. Has anybody run into the situation where the latest and greatest version cannot read files created with a previous
version?

Bob

Hello,

There is another way to bring all your software packages togather, Citect\SCADA.
It works with tags\address\ very easy to learn and do.

Irl Johnson

By Michael Griffin on 14 February, 2002 - 2:13 pm

On February 13, 2002 11:46 am, Bob Pawley wrote:
<clip>
> With a proprietary system the trouble-shooter knows the fundamental nature
> of the program can not be changed so he is perfectly comfortable standing
> on that knowledge. Not so with an open source system.
> One of the posts indicated that Linux is structured and organized by the
> distributor and the core programs are not touched unless absolutely
> necessary. Who makes this decision, The guy on the site?, His supervisor?
> The president of the company 5,000 miles away? How is this software
> structured by the distributor and never touched, so much different from
> proprietary software?
<clip>

Since you based your comparison on Linux ("open source" is not synonymous with Linux), we'll discuss an example based on that. Linux is an operating system, not an application so we'll compare it to a proprietary operating system such as Windows. I'm not trying to suggest that there is anything wrong with WIndows, but it makes a good contrast.

Firstly, there is nothing to prevent someone from changing some very fundamental features of a system using Windows. Drivers and other such
software can be changed for different ones whether they are proprietary or not. There are also lots of utilities which modify the behaviour of Windows, supposedly to make it more "crash-proof", or faster or other such (usually
imaginary) benefits.

Secondly, Windows comes in different versions with different service packs. There is nothing to prevent someone from installing new service packs whose side effects (and new bugs) have not been tested in your application.

Thirdly, Windows' publisher (Microsoft) changes Windows all the time, and they won't ask your permission (or even tell you) before they do this. It is very unlikely that two supposedly "identical" installations conducted some time apart will in fact use the same software version.

A similar case can be made for most other types of software. Unless you are installing the software off a common set of CDs (which can be contrary to the software licensing), you are not going to have truly indentical systems.

Do you have anything with DOS in it? I believe there are open source versions of DOS around. People can hack away at that. People used to hack DOS even without source code. They used a debugger (included with DOS!) to patch the executable files directly in machine code. People used to publish these hacks in magazines and books, so you didn't even have to figure it out for yourself.

We've got proprietary equipment with special EPROMs containg firmware modified just for us. It's easy to get this when you are dealing with
proprietary systems. You just give the OEM a spec and some money, and they'll do a new EPROM for you. When you order the hardware again, you just specify the EPROM version you want. This can be better (and cheaper) than a completely custom system if there is nothing on the market that does what you need. So there's no guarantees that the firmware is "standard", even if it is burned into EPROM.

Hacking isn't limited to software either. People used to (and probably still do) hot-rod 8032 based systems by installing chips which have a shorter execution cycle. This can upset various critical software timing loops. Do you pry the lid off all your hardware to see if anyone has been doing this?

Regardless of the talk you may hear of people "fixing" or modifying Linux, all except a very small number of people just stick the CD-ROM in their computer and run the software as is.

I have a very good idea of the reasons for keeping equipment to a common standard. But it can in fact be very difficult to do this with proprietary systems. If the manufacturer discontinues the current version (e.g. Windows),
then you cannot (legally) continue copying the old one until you are ready to change.

I was involved in a meeting on Tuesday in which we were discussing a new machine (a standard design) we are considering buying. The machine included a "panel" type PC which ran software written by the machine OEM for MMI, parameter handling, and conducting certain critical process calculations. The operating system is Windows NT4. The machine OEM has spent several years
developing this new product, and they are just beginning to make some significant sales.

One of our people mentioned that Windows NT4 is a discontinued product. Upon hearing this, the machine OEM representative looked shocked, and began cursing something to the effect of "you just get the lastest thing working, and you have to start all over again" (to put it mildly).

I can sympathise with him. They just want to get their new product into the field without having to worry about operating system compatability. They want to keep selling the same thing for years to come. If we buy a machine now, we want to be able to buy *exactly* the same machine again in the future. This part of the machine however, is out of their control.

The operating system is proprietary. However, it isn't proprietary to the machinery OEM - it belongs to someone else. What should this OEM do? They really don't want to get into the software business and start writing their own operating systems.

So how do they get something they can have some control over? I suppose they could use Linux. Nobody is going to cut off their supply of a particular version of that. They can keep using whatever version they like, completely unaffected by anyone's change in sales strategy, corporate merger, divestiture, bankruptcy, or anything else. That sounds pretty close to what the advantages of a proprietary system are supposed to be.::

************************
Michael Griffin
London, Ont. Canada
************************

By Joe Jansen/ENGR/HQ/KEMET/US on 13 February, 2002 - 11:40 am

Bob Pawley wrote:

I don't know about others, I speak only for myself.

I came into this open control and open source discussion later than most with no preconceived ideas other than what I have lived with for the last 30 some years.

It does seem to me that we as an industry have moved from total proprietary systems, to a point where we aren't absolutely required to purchase hardware and software from the same source.

Joe Replies:

I agree. DeviceNet is a good example of this trend, where I can use Omron, InterbusBT, and many other branded I/O components with my AB processor/scanner module.

Bob wrote:

The other extreme that has come about because of Linux causes me to note that there is a definite movement toward systems being as open as possible. This trend will continue regardless of what individuals think.

What I am suggesting is that a totally open system such as Linux - standing by itself - is to much the opposite extreme to have great appeal.

Joe replies:

Could be. However, as I was alluding to in my posting, sometimes you need a group at the far opposite extreme in order to get the mainstream to shift towards where you really want to be.

Bob wrote:

Some boundaries, some anchor is needed so that all concerned have a solid place to stand in order to see what needs to be done or to see what has been done.

Proprietary systems have this solid place upon which everyone, technician to corporate bureaucrat, is comfortable. The fact that this proprietary place is so vast gives me reason to consider a melding of the two extremes.

Joe replies:

This is where I am getting confused. Is it simply their name that gives everyone a "warm-fuzzy" feeling? If RSLogix were released as a Linux app, would that apply? I don't pretend to think that they would open source it, but what if I could buy it, even at the same cost, for Linux?

Or do you feel there is something more than the names of the providers that provides that solid place? Is it the hardware? If LinuxPLC does manage to get some hardware platform, and a system that provides the stability of a PLC with data collection that isn't a PITA, does that provide the footing that management/others seeks?

Could you clarify a bit more for me what you meant at the end of your post? I feel that I -almost- "get it".

Thanks!

--Joe Jansen

> So paraphrasing, let me know if I understand the gist of what you are saying.....
>
> Rockwell, GEFanuc, and the others are completely closed and currently have no
intention of untrenching.
>

I don't think that you can throw all vendors of proprietary systems into the category of being uncooperative in support of Open Systems technology. Rockwell appears not to support the notion of untrenching. However, GE Fanuc and
Schneider Automation have stated their realization that the industrial automation market will, however slowly, move towards open systems. A recent discussion that I had with an executive at GE Fanuc was encouraging. He stated that the proprietary PLC market has reached the point where PLCs are a commodity. GE Fanuc desires to participate in the open systems movement in
order to raise their controllers from the commodity market to becoming a component of an open system. This will allow them to once again differentiate their product based upon its superior performance as an open system component
for specific applications. With respect to Schneider's efforts in this area, they have product available today which can be used to build an open control system and they have the courage to support an open forum discussion on their company website's home page. Schneider has absolutely no control over the postings to their forum as the forum is moderated and managed by an
independent, third party (Control.com). One will get you a hundred that you will never see that coming from Rockwell.

Steve Harr
Control.com

By Curt Wuollet on 10 February, 2002 - 3:08 pm

I mentioned that there were exceptions and I'm certain we differ on our concept of "open". When I tried to get information from GE on their
latest and greatest Ethernet protocol, I got stonewalled. And we're a GE customer.
I'm sure we can agree that there's quite a ways to go on this. I have recognized publicly that Modicon in particular seems to "get it" They have published much of Modbus and all of Modbus/TCP. They won't give us explicit permission to use it in LPLC but they haven't sicced any lawyers on us either. All the "open" stuff I've seen is still bounded by product lines and/or patents. And being "open" only to closed systems like Microsoft products is pretty much an oxymoron. I think we could help them by identifying which areas are most pressing. For my part, protocols are most important. And I simply can't see the downside for letting people use the protocols you _want_ them to use. Linux tools would be next so I can work with their products. At this stage, they don't have to be OSS, but it would solve the XP problem nicely and save everyone a lot of money and grief by eliminating the forced upgrade march and license hassles Microsoft seems bent on enforcing. A Linux distribution could be tailored to actually support the needs of the automation market.
ONE open fieldbus standard would be nice, but I believe they've already nailed the coffin on fieldbus and that will come from the Ethernet Open Systems side and be forced upon them out of pragmatism just like Ethernet.
That will solve many of the intractable hardware problems simply by having ONE thing in common to build upon. I don't see any likely candidates in the new bunch of "proprietary but on Ethernet hardware" products being released every day, but I could be wrong. Perhaps someone will try to steal a march on the competition and open one up. I am almost sure that the successful one won't require custom silicon.

Really I wish they would simply look at their R&D costs and how much all this balkanization costs them verses standardization. If they do that, I'm pretty sure they'll begin to do the right things. The benefits in a commodity market are even more important for them than for the consumers. Most industries have already gone through this. It's pretty hard to sell nuts and bolts that are incompatible, but that doesn't mean they can't be stronger or higher quality. You don't make a lot of money selling standard PC's, but you don't stay in business long selling non-standard ones. Standards with differentiation is where we need to go.

IMHO

Regards

cww

By Dave Lillie on 11 February, 2002 - 2:59 pm

Steve,

We did this 5 years ago on OpenAutomation.com - in fact the user forums were un-moderated and postings were real-time.

Dave Lillie
Program Manager
Rockwell Software Inc.

By Curt Wuollet on 10 February, 2002 - 1:22 pm

Hi Joe

Not exactly, and this isn't a position it's an observation. It's not a decision not to mix it up with the status quo, it's simply not possible to interoperate freely with closed systems until the information and especially the legal barriers are lowered. I do quite a bit of talking to proprietary systems in integrating existing machines and old used stuff. It could hardly be described as easy. If I were to publish the stuff I've done or try to sell it,I'm fairly certain I would have legal problems. Modbus is the only proto I would feel safe with and even there, I can't get clear permission to do so. Individuals or companies who own the equipment can do quite a bit or we on their behalf under their license. Trying to be a go between and solving the problem for all is explicitly prohibited by many, many, licenses. That explains some of the reason why I see problems where many don't see any problem at all. Actually trying to accomplish that mixing and merging would require a legal staff larger than the township I live in and a ton of cash until attitudes change. They (big automation) can come our direction and we'll greet them with open arms but there are a lot of very high hurdles for us even trying to meet them half way. That's why it's wonderful to talk about meeting in the middle, but not very realistic. I'm all ears for real world solutions, because we would like very much to be that neutral go between. I have specifically (see the archives) tried to get quite a few entities to give us legal room to do so and have taken great pains to keep our project absolutely neutral. In a way I'm the perfect person to explain why that's a pipe dream because I know of nobody who has tried harder to provide the vehicle.

Joe

I don't know about others, I speak only for myself.

I came into this open control and open source discussion later than most with no preconceived ideas other than what I have lived with for the last 30 some years.

It does seem to me that we as an industry have moved from total proprietary systems, to a point where we aren't absolutely required to purchase hardware and software from the same source.

The other extreme that has come about because of Linux causes me to note that there is a definite movement toward systems being as open as possible. This trend will continue regardless of what individuals think.

What I am suggesting is that a totally open system such as Linux - standing by itself - is to much the opposite extreme to have great appeal. Some boundaries, some anchor is needed so that all concerned have a solid place to stand in order to see what needs to be done or to see what has been done.

Proprietary systems have this solid place upon which everyone, technician to corporate bureaucrat, is comfortable. The fact that this proprietary place is so vast gives me reason to consider a melding of the two extremes.

Bob Pawley
www.automating-automation.com
250-493-6146

By Hullsiek, William on 5 February, 2002 - 2:21 pm

Personally, the definition works for me. It covers the Foxboro situation where they sell you a Sun (which is open) but you only buy the Sun from Foxboro.

From a user-perspective, vendors can (should) add value by:

1. Testing

You probably can 'charge more' if you test your components with other vendors.
Let your customer know they have a choice.

2. Improving manage-ability of the components.

Have a unified frameworks based on CORBA, Java, SNMP for managing multiple vendor control equipment.

3. Different programming tools / IDE for porting

Would be nice to have CTC state logic running on other equipment.

4. Training courses -- Application instead of vendor.

Imagine if we had training courses organized by application instead of by vendor.
It would really be useful, if we could lower the cost of implementation and ownership for our customers.

- bill hullsiek

By Anand krishnan Iyer on 5 February, 2002 - 2:40 pm

I believe that this is probably the best possible definition of what is practical and what the user should want from an open system.
Anand

By Ralph Mackiewicz on 6 February, 2002 - 4:08 pm

> - adherence to published, freely-usable standards at key interfaces
> (bus, protocol, physical form factor, signal levels, etc.).

If the standard costs $100 to purchase from a standards organization does this preclude its use in your definition? Or does "freely- usable" mean no restrictions on use such as royalties?

> - unbundled support available at a variety of levels from a selection
> of providers.

I am curious as to what "unbundled support" means. I have a preconception that it means that if you buy some software that you must also purchase support. Or would the situation where support is simply optional meet this criteria?

> The whole point of open control is to reduce cost and risk, and
> increase flexibility to respond to change.

I think it is important to clarify what is meant by "cost". There are many elements of cost including purchase price, installation, packaging, support, maintenance, modification/flexibility, productivity/throughput, etc. There is a tendency to focus only on purchase price for cost reductions which makes many kinds of useful and necessary investments look impractical. Or, it incorrectly puts the spotlight on something like free software (for instance) as being the source of the cost reduction which results in disappointment and therefore failure.

> This can only be accomplished by opening each component choice to
> multiple suppliers competing in a free market.

...snip...snip...

> And before anyone says it's impossible, it's already happened in the
> PC world.

Nothing is really impossible, but there are significant differences between the PC market and the IA market that need to be considered. The massive investments that took place in the PC market by hundreds, if not thousands, of companies that enables this interoperability was driven by the returns from a market that is a couple of orders of magnitude larger in size. That is why I don't think analogies with the PC industry are all that relevant. But, I don't think that it is impossible for IA either. All that is really required is an energized user base that understands and buys open technology. Everything else will flow naturally from that.

Regards,

Ralph Mackiewicz
SISCO, Inc.

Ken Crater:
> - adherence to published, freely-usable
> standards at key interfaces(bus, protocol,
> physical form factor, signal levels, etc.).

Ralph Mackiewicz:
If the standard costs $100 to purchase from
a standards organization does this preclude
its use in your definition? Or does "freely-
usable" mean no restrictions on use such as
royalties?

Ken Crater:
The latter. In open-source parlance, this is "free" as in free speech, not free as in "free beer". In other words, a standards org can charge
for the paper the standard is printed on, but the intellectual property content of the standard must be open for free use if it is to meaningfully be called an "open" standard.

Ken:
> - unbundled support available at a variety
> of levels from a selection of providers.

Ralph:
I am curious as to what "unbundled support"
means. I have a preconception that it means
that if you buy some software that you must
also purchase support. Or would the situation
where support is simply optional meet this
criteria?

Ken:
If there is no requirement to pay for support in order to obtain the hardware/software, and the hardware/software is not "opaque", then the
option becomes available to obtain third-party support at the best price/competence levels for your company.

Ken:
> The whole point of open control is to reduce
> cost and risk, and increase flexibility to
> respond to change.

Ralph:
[...] There are many elements of cost including
purchase price, installation, packaging, support,
maintenance, modification/flexibility,
productivity/throughput, etc. [...]

Ken:
True, and it is in the consideration of the full range of these cost elements that open technologies become the most attractive. Openness has its true value in the expansion of options, which can benefit the user throughout the lifecycle of a system. As Ralph points out, the near-term issue revolves around the support infrastructure, which has grown in the computer industry and which we are helping to grow in the controls industry (including on this forum <grin>).

Ken Crater
Control.com Inc.
ken@control.com

By Jeremy Pollard on 7 February, 2002 - 4:52 pm

Hey Ken - theres always free beer in Canada - just have to pay the tax:)

Cheers from:

Jeremy Pollard, CET
jpollard@tsuonline.com
On The Web - http://www.tsuonline.com
PLCopen North America - plcopenna@tsuonline.com www.PLCopen.org
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157

By Hullsiek, William on 8 February, 2002 - 5:18 pm

Suggested improvement to definition of Open Control

One attribute of an Open Standard is the availability of source-code examples, i.e., done under Gnu or University type of sponsorship, hence the popularity and low cost of TCP/IP.

Many vendors offer the IP protocol suite at a nominal charge, because they can take "Open Source" and port to their hardware at a minimal effort. Which is why *nix systems and IP work so well in a commercial environments.

FieldBus and MAP would have been done deals by now, if they had sponsored a University or other organization to develop the software /firmware "prototypes" and place them in the public domain.

- bill hullsiek

By Curt Wuollet on 8 February, 2002 - 5:19 pm

Wiser words were never spoken.

It really helps to make something ubiquitous if you act like you _want_ people to use it. The attitude and impression I get from the fieldbus consortia involves buying memberships, equipment and licenses or they'll sue me for using it. Completely kills _my_ enthusiasm. I would think they would like for us to popularize their systems with MAT/LPLC. It might be a pretty good investment.

Regards

cww

Hi Ken,

A significant local symposium for the 'PC-Based Control' was held in Seoul last fall.
The first topic in the meeting was to define the exact meaning of 'PC-Based Control', since it has been called some different names, such as 'PC-Based Control', Open Control, Softlogix, SoftPLC,
PC Control and ...

If this forum focus on 'PC-Based Control',
I think it is timely forum and my company can share our valuable experiences with PC-Based Control applications.

Thanks...
Key

Hi Key:

Does your company define 'open control' as being based on a PC or virtual hardware, as opposed to other hardware?

Bob Pawley
250-493-6146

I don't think it is possible to define "OPEN" Control as if it was some standard for a protocol. OPEN is a philosophy that embodies vulnerability and innovation. If you have a product that is OPEN, you are vulnerable to lose your customer to another choice. However, if you are the most innovative and provide your customer a high degree of on-going value, vulnerability becomes an asset. Being vulnerable is the juice that drives small or major corporations to soar to new levels.

In most cases the major industrial players don't see themselves, or the market this way at all. In fact the larger you become (mergers & acquisitions) the less vulnerable you are, the more you control the market. Being huge means you can buyout trade publications to dominate advertising, impress decision makers for large accounts with trinkets and might, for example. The technology of automation is complex. Few people understand the full ramifications of a decision one way or another. Those that do are lower down the corporate ladder. Every situation is different, the factors too numerous to list. But size, capacity, installed base, and the ability to invest thousands on entertainment and sales campaigns are a big part of obtaining large orders, and keeping the lid on OPEN innovators.......

Here is a piece I am working on for our next newsletter aXFlash. I spent 8 years of in systems engineering and a about a year in sales/marketing for the #3 automation vendor in the US. This is a candid view from the inside. (Note - Advisory - It contains some promotional statements about our company). Comments or additions are welcome!


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.

Confessions of an Industrial Salesman

Delivering increased value to customers is something rarely discussed inside regional meetings of large industrial vendors. The focus of discussion is usually the volume of orders booked and how to generate more revenue in order to meet the sales targets. The products and sales practices of firms are often designed to maximize revenue "pull" from the customer base.

Proprietary communications, proprietary devices, hardware, and software provide vendors with market protection by being exclusive. They exclude competition from other vendors for expansions, upgrades, spare parts and service. New customers are given very aggressive pricing to secure the facility.

Are these practices "industrial atrocities" and are they short sighted? Do such strategies harm the long-term competitiveness of the very industries they serve?


A seasoned industrial systems salesman chortled "You know in most businesses you give your good customers a break, but in this business once they are locked in you put the screws to them. We low-balled the bid to get the order, now we are trying to get back as much as we can by gouging on the transmitters and spare parts."

Large DCS and PLC supply is a proprietary business - for both hardware and software. Even in today's market that has a healthy supply of inexpensive IT components, the major industrial vendors continue to deliver closed systems
despite claims to the contrary.

After customers purchase a system they find upgrades, expansion, parts and services that are expensive. There isn't much one can do once "locked" in. After millions in software development, training, and hardware there is no easy alternative.

The explosion of information technology, standardized operating systems and networks show promise for change within the industrial community. However, we are seeing very slow movement in terms of inter-operability among devices.

The same is true for networks. There is a large, vendor-biased and fragmented choice for industrial networks, some of which are very expensive to implement. In contrast IT rides on widely used standards, with new technology or enhancements adopted relatively quickly as standard for leaps of functionality.

We are seeing industrial facilities operating in markets that are more challenging than ever. The costs of automation systems and IT are significant in the capital or and maintenance budgets. And automation and IT integration play a key role in how the facility manages operations and how efficient the employees can be.

There is no doubt that the use of IT technology in a comprehensive way for in automation lowers the initial and yearly costs of our systems. Also to replace hardware, in particular PLC or DCS processors and their distributed programs with software executing on IT servers and clients is another way to deliver increased value to automation users. The cost of maintaining automation software on the IT platform is far less than hardware in the industrial environment.

It's clear that solution providers must deliver their absolute best effort to clients for new and on-going business. Above all else, top value or price for functionality to system users should be the goal. These key automation systems and their benefit are vital to the long-term health of end-user companies, and in turn the providers.

(Product X ) is designed from need of the user or customer. It's core development came from customers who were after increased value and reduced complexity. (Product X) replaces hardware with software, optimally uses IT technology, and delivers high-performance, flexibility and reliability.

Cheers,

Paul Jager
CEO
www.mnrcan.com

My thanks for an interesting discussion to all those who are taking part.

Let me try to summarize all of the messages posted so far. You guys let me know where I'm wrong.

The open source software is similar to proprietary software in that nobody changes the OS and/or features, what I call infrastructure, unless given permission from a higher authority (boss for Linux, vendor for proprietary, except the vendor will do the work and charge you for a patch or new version).

Open source, Linux in this case, doesn't make an integrator feel as if they have been unduly or unnecessarily charged for features added after purchase. (I'm not very clear why this is a problem. You as system integrators merely pass this cost on to your clients, if they, your clients, want these extra features. If you want them, at your direct cost, it must be because you think these features will save time and/or effort. When I was in the business, software and hardware were fused, what we purchased for the project would last for years, regardless what the vendor did with that software.)

One vendor's proprietary software does not play well with others. Linux doesn't have this problem, because you can change the infrastructure to accommodate mixing of systems.(This may be my answer to the above question.)

Both, Linux and proprietary software, allow the user unlimited access to the elements that make up the control solutions.

Is this a reasonable summary? If so it appears to me that, other than the comfort level of having direct control over the software, exercised or not, the real problem I have been hearing is a vendor problem, not necessarily a proprietary versus open source problem as such. Except, of course for the run time costs.

Is this a fair statement?

Yes, Bob, that is a very fair statement of the problem. IMHO, the real issue here is not that Linux is _per se_ so wonderful, but that the proprietary vendors have done such a terrible job of providing quality software, hardware, and support that nearly everybody is angry at them, and would walk if a viable alternative presented itself.

There's lots of other, non-core, stuff here, but that's the basis, yes.

Walt Boyes

---------SPITZER AND BOYES, LLC-------------
"Consulting from the engineer
to the distribution channel"

walt@waltboyes.com
21118 SE 278th Place
Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142
--------------------------------------------

By Curt Wuollet on 21 February, 2002 - 3:08 pm

I would hope they get just a little madder and help us provide a viable alternative. We can code as time allows and advocate, but the real key to having a viable alternative is for people to accept that this is to their advantage and get beyond "wait and see" to actually making it happen. It clearly can be done, and the objections about support, momentum, installed base and confidence are all easily and obviously evercome by a vibrant and enthusiastic user community. The critical path to this objective can only be met by folks reading this. Nothing on our part can take the place of this community. With enough push, just a little from a lot of people, no roadblock is insurmountable.

Regards

cww

Are you also thinking that this thread has gone a different direction than Ken might have thought??

Bob

By Greg Goodman on 22 February, 2002 - 1:53 pm

The Control.com website describes them as "The company whose goal is to make "open" a reality for industrial control and automation," so I
imagine that Ken and his colleagues are particularly interested in what A-List participants (i.e. the automation marketplace) have to say about the requirements for acceptance of solutions based on Open Source components.

Greg Goodman
Chiron Consulting

By Curt Wuollet on 20 February, 2002 - 2:59 pm

> Open source, Linux in this case, doesn't make an integrator feel as if
> they have been unduly or unnecessarily charged for features added after
> purchase. (I'm not very clear why this is a problem. You as system
> integrators merely pass this cost on to your clients, if they, your
> clients, want these extra features. If you want them, at your direct cost,
> it must be because you think these features will save time and/or effort.
> When I was in the business, software and hardware were fused, what we
> purchased for the project would last for years, regardless what the vendor
> did with that software.)

Or you can do the work and keep the money yourself and your customer will be happy that you are passing much less cost along to them. Taking the vendor out of the equation should mean more money for the integrator.

> One vendor's proprietary software does not play well with others. Linux
> doesn't have this problem, because you can change the infrastructure to
> accommodate mixing of systems.(This may be my answer to the above
> question.)

And you can change or add those little things that the customer decides they want and it's all billable time.

> Both, Linux and proprietary software, allow the user unlimited access to
> the elements that make up the control solutions.

And the user can potentially add elements or write around those roadblocks that appear. It depends on who user is.

> Is this a reasonable summary? If so it appears to me that, other than the
> comfort level of having direct control over the software, exercised or
> not, the real problem I have been hearing is a vendor problem, not
> necessarily a proprietary versus open source problem as such. Except, of
> course for the run time costs.

Pretty much so, except that the flexibility is worth a lot more. It solves a lot of problems that relate to how the business is done now. And the costs can be dramatically lower as many things that sell bridges adapters, basic modules, etc. can be done in software. And you can simply do more and say yes more often.

> Is this a fair statement?

As I said, It's a much more powerful tool for building solutions.

Regards

cww