|
|
Applications -
Automation Business -
Communications -
Engineering Practices -
HMI -
Information Resources -
LinuxPLC Project -
Motion Control -
Open Control -
PCs in Automation -
Plant Networking -
PLCs -
Programming Languages -
Process Control -
Sensors -
Software
Re: New forum topic - Open Control
Feb 13, 2002 2:21 pm, by Michael Griffin
Text :
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
************************
Reply
Re: New forum topic - Open Control
Feb 14, 2002 12:17 pm, by Dale Witman
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
Reply
Re: New forum topic - Open Control
Feb 17, 2002 12:33 pm, by Curt Wuollet
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
Reply
Re: New forum topic - Open Control
Feb 17, 2002 12:35 pm, by Dale Witman
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
Reply
Re: New forum topic - Open Control
Feb 20, 2002 2:55 pm, by Michael Griffin
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
************************
Reply
Re: New forum topic - Open Control
Feb 19, 2002 11:32 am, by Curt Wuollet
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
Reply
Re: New forum topic - Open Control
Feb 15, 2002 10:20 am, by Alex Pavloff
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
Reply
Re: New forum topic - Open Control
Feb 14, 2002 12:12 pm, by Alex Pavloff
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
Reply
Re: New forum topic - Open Control
Feb 15, 2002 9:45 am, by Greg Goodman
> 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
Reply
|
