New forum topic - Open Control

G

Greg Goodman

>> "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 K Ken Irving > 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 <[email protected]> J Joe Jansen/ENGR/HQ/KEMET/US 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 A Alan Brause 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 A 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 D 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 G Greg Goodman > 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 B Bob Pawley 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 M Michael Griffin 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 ************************ B Bob Pawley 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 G 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 A 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 C 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 D 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 G Greg Schiller 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 G Greg Goodman > 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 M Michael Griffin <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 ************************ B Bob Pawley 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? C 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 G Greg Schiller 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.