MatrikonOPC OPC Exchange


Open Standards and Paying-to-Play

Posted on May 4th, 2008 by Eric Murphy

The ongoing discussion on ‘Is OPC really considered an open standard if you have to pay for the specifications’ has recently gathered steam again on the forums and other sites.  I posted on this topic last summer and the same arguments and counter arguments are still going around.  Most center on two points; definition of an open standard and definition of nominal fee.  As I’ve said in the past, these are really the wrong things to be focusing on, since there really is no one, accepted definition by everyone.   Wikipedia’s got a good explanation of the various open standard definitions.   The one thing that most agree on is that open means available to everyone without discrimination and does not use a ‘pay-to-use’ or royalty model.

Where things are a bit gray is that some definitions of open do allow ‘pay-to-produce’ fees, and what are acceptable fees to charge.  Some folks argue that not everyone can afford the set fees, so therefore are being discriminated against.  A grad student or one-main integrator shop has a different view of ‘nominal’ than a multi-million dollar global vendor.  No method is perfect.  Even the WC3 which is ‘open to everyone’ and ‘free to access and use’ has its critics.  So, I say these arguments can’t really be won since everyone finds a definition that supports their view.  The reason the OPC Foundation now requires membership to access the specs is an attempt at improving the overall quality and interoperability of OPC products.  I’m all for a debate on the topic.  But let’s talk about the real topic. The question that should be asked is ‘Does a pay-to-produce model improve overall quality?’  

Personally, I don’t know.  What I do know is that the OPC specifications used to be available for free download and there where many interoperability problems.  The message coming from a lot of end users was:  “We don’t what more OPC products, we want better OPC products.”   The stance the OPC Foundation has taken is if you plan to develop OPC products, it requires membership which comes with access to the specifications and the associated code base and tools to help ensure a solid quality baseline.

In the early days of ‘classic’ OPC there were many client applications built on the OPC technology by non-members that did not measure up to expected quality and had many interoperability problems.  The argument that ‘more eyes are better’ and having an Open Source model will create a more reliable infrastructure doesn’t seem to be supported by OPC history.  Take the Automation wrapper and server sample code for example.  The code was freely available, yet it didn’t evolve over time.  Many people just took the sample code and released products; good, bad or ugly.   This became one of the biggest contributing factors to OPC interoperability problems.  It was only after the OPC Foundation took back ownership and provided dedicated support for the wrappers did all the fixes get integrated.  Why?  Maybe it’s because the majority of the OPC community is vendors, users and integrators whose core competence is Industrial Automation. Does it work for something like Linux because of the sheer volume of developers in their community?  Now that the scope of OPC UA extends beyond just the Microsoft platform does that mean there is a much larger pool of developers waiting to contribute?  It doesn’t seem to me that the team of volunteers working on the specifications and code has suddenly grown exponentially.

The OPC Foundation’s solution to the problem was to set the bar so only those individuals and companies that are committed to developing OPC products have access to the tools to do so.   Membership signifies commitment.  Adoption without verified interoperability is not adoption at all.  I suppose that OPC could move to a ‘Brand Licensing’ model such as Bluetooth uses.  The specifications are free to view by anyone, however only the Adopter Members are allowed to develop commercial products and use the brand name.  (Of course the other side of that is, what good is looking at a specification if you aren’t developing a product with it?  If I am a company developing a new headset or hand held peripheral am I really going to say “Well, we need a communication protocol to connect with all the PCs, phones and Blackberries on the market.  Let’s take a good look at the technical details of the Bluetooth protocol and see if we want to go with that or roll our own?”  Just my $0.02)

Is demanding membership to access the OPC specifications the right solution?  Someone like IEC would say yes, where XML would say no.  The important thing is what do you say?  As Randy pointed out on the forum “OPC is a member driven organization and if members believe that the specs should be made available for free then these members need to make their feelings known”.  I’ll make it easy for everyone.  Post a comment that answers these questions:

  • Are you an OPC member?
  •  Does ‘pay-to-play’ mean better quality products? (i.e. member products are built on reference code, interoperability tested and certified.)
  •  Do you agree with the current policy of ‘pay-to-view’?
  • Why/Why not?

11 Responses to “Open Standards and Paying-to-Play”

  1. Ildar Says:

    >Do you agree with the current policy of ‘pay-to-view’?

    No. This policy disallow non-developers to understand what is what in new releases of OPC (e.i. UA).
    Even if organization is member of OPC, this doesn’t means that any employee (like process engineer) can understand good or bad points of upcoming standards. Now we should trust to “professional interpreter”.
    IMHO OPC DA prior to 3 acquired its success due to the openness of specifications and youthful entuziazm of developers.

  2. Adriel Michaud Says:

    Having some sort of bar on admission will improve quality. If someone is not willing to pay a few bucks to get the specs, how likely will they be to scrimp on proper implementation, QA, and support? Experience has shown, likely!

    Go back a few years and remember what websites were like. HTML compliance was terrible, and website developers had to build multiple versions of sites for different browsers. Heck, my bank website STILL demands that I use IE6.0 only! Try writing your own HTML-compliant web browser and see which webpages show up correctly. Now try changing the stakes from “I can’t see this recipe for blueberry muffins” to “I can’t access critical plant data”.

  3. Mike Dillamore Says:

    There’s no doubt in my mind that OPC DA would not have become the success that it is without the openness that OPC Foundation originally gave it. That openness fostered a great community spirit and led to huge amounts of innovation in the DA space.

    OPC UA needs to prove itself all over again, in a world where SOAP-style web services are already very unfashionable. There is every chance it will become another CORBA unless it is given the same chance as OPC DA had.

    Adriel Michaud’s comment is interesting. Does he really believe HTML would have become universal in the way it has, if it had been a restricted specification?

    OPC Foundation can ensure product quality with its current approach, but this is likely to be at the cost of failing to dominate the field. Eric Murphy has already posted about the challenges posed by other emergent standards - see http://blog.matrikonopc.com/index.php/opc-web-service-standards-and-keeping-your-eye-on-the-ball/

    Also, we shouldn’t underestimate the importance attached by many IT managers to openness of specifications. Why would they allow OPC to run over their networks when they can’t get access to the standards which document the protocols?

    Let’s stop debating this question ad nauseam - let’s just do the right thing and open up the specs to give them a fair chance. Product quality can surely be achieved with a combination of certification and good marketing.

  4. Brian Says:

    The restriction should be moved from the specs and sample code to product certification. Requiring payment before the information can be accessed, for the purpose of protecting against inferior software, is like Microsoft charging for Win32/.NET documentation in an effort to reduce bad quality in Windows apps. Newsflash: having access to documentation does not many anyone a better developer (someone can have the OPC specs and sample code and still write lousy software!), while restricting access to documentation potentially keeps quality developers and their products off the playing field. If Microsoft tried what the OPC foundation is trying, you can bet thousands of Windows developers would switch to Mac and Linux in the blink of an eye.

    Yes, there are uncountable examples of bad quality Windows applications. So what??? Customers who want quality make their purchase decisions on things like the reputation of the company and/or Certification of the software and/or reviews of the software, not on if the original developer paid money to Microsoft for API documentation. If developers want more customers, they pay for Windows Logo Certification, which tests for UI, functionality and performance standards. Low-quality uncertified apps don’t tarnish the reputation of the core technologies they used, they tarnish the reputation of the developer.

    Another thing wrong with the current policy: ANY janitor at ABB or TV salesman from Hitatchi, with no development experience, has full access to the specs and sample code just because they have an email address from a corporate member. Does that mean their software will therefore be of a higher quality than mine? I think not. University members have access to the specs as well (that’s what it says in the member benefits .pdf, anyway), which means any student/staff/faculty/alumni from University members can freely access the specs, regardless of their “commitment” to OPC let alone any association with software development or engineering. On the other hand, people like me with many years of professional software development experience and an large interest in OPC are locked out simply because our current employers are not members. Perhaps I should sweet-talk a receptionist at any corporate/charter member company, or pay $20 to a poor Art History student at the University of Illinois to download the specs for me? I wouldn’t do that, my point is only to illustrate that the claim that the current policy is in place for “quality protection” and commitment testing simply doesn’t hold water.

    So my suggestion is: 1. open the specs and sample code to everyone, 2. charge a membership fee for things like voting, input, event attendance, etc. and 3. charge a fee (or combine with #2) for product OPC logo certification. 4. Promote only certified software on the official site and in official catalogs, etc.

    I will continue to try and learn/develop OPC software regardless of whether the specs and sample code are made freely available or not. And there are many others like me - thus, withholding information can actually have the opposite effect from what the current policy is intended to create. If the OPC foundation was *really* interested in protecting quality and determining commitment, having an email address that can get by OPC’s download security system, or $2,500 cash lying around to purchase a membership for themselves, should not be the determining factor in who is viewed as a competent developer of quality software.

  5. Andrew Holt Says:

    Pay to play ? No, pay to certify yes. You should allow open source implementations, however in order to be granted some interoperability certificate, that testing would be carry a cost.

    Pay to view ? No, the specifications should be available to the widest possible audience. Not all the smart people work in your (or any other) discipline. People who do not work directly with automation but have broad knowledge of XML, SOA and SOAP would have constructive criticism to offer, but they would not pay for a spec.

  6. Martin Boers Says:

    Eric asks: “What good is looking at a specification if you aren’t developing a product with it?”

    In my experience, there are many, many small manufacturing/process companies, researchers, students and hobbyists who would find the OPC specs extremely useful but will never develop a *commercial* product based on these specs. At present, the only option for these types is to purchase something - either the OPC Specs or a commercial product - for their entirely non-commercial applications.

    If the only application of OPC was in the development of commercial products, then a nominal fee for the specs would be mostly harmless. However, there are a huge number of non-commercial applications that will now never be written by researchers, students, hobbyists and small companies because of the cost involved.

    The Bluetooth licencing model as described by Eric DOES allow such non-commercial apps to be developed, with a fee only applicable if/when the developer commercialises their product.

    Let be honest - the OPC Foundation is a business just like yours and mine, and they earn a nice bit of money from OPC membership fees. So of course it’s not surprising that there will be resistance to any change until someone can demonstrate that an alternative licencing model is at least as lucrative for the OPC Foundation as the current system.

  7. Brian Says:

    Yes we are an OPC member.

    I think paying for the Wrapper, OPC.NET API and examples and the fast response to any questions I post is certainly worth it.

    I don’t agree with the pay-to-view policy, I think that everyone should have access to view the specifications.

    If they want to write there own server then go ahead and do it. Most OPC client applications like ActivEssentials 5.x highly recommend that the OPC server being connected to is a compliance 2.05a or 3.0 server.

  8. Ryan Weaving Says:

    I was an OPC member. I think that the OPC UA specs should be open and accessible to all. Having read the UA specs I see the potential of UA. Having open specs will help with adoption. OPC DA was limited because it was built on COM / DCOM, but the UA doesn’t suffer from this, because it is built on open specs XML, SOAP, TLS, HTTP, WS-Trust, etc…. The OPC foundation should take the approach of certification to help solve the software quality issue.

  9. eric.murphy Says:

    Wow. Don’t hold back. Let me know what you really think :)
    A lot of great responses and well put together arguments. It’s clear people are passionate about their OPC specs!

    I asked. You answered. Let’s see what happens.

    Stay tuned.

  10. Amir Says:

    thank you , thank you man!
    could you please introduce me a really open and free opc which i could use instead of opcnetapi.dll in my client side of my program to read data from a wincc opc server??? i’ll be more thankful for that ;-)
    be happy

  11. eric.murphy Says:

    Amir,

    If you are looking for something quick and dirty, you could use the OPC Automation Wrapper dll which comes with most OPC products (even free downloads). There are many examples out on the web that use this wrapper in VB or Delphi code. I would not recommend the wrapper if you are building a client for an industrial application since it offers limited error handling capabilities.

    If you are looking for free other OPC client source code you can check out http://www.opcconnect.com/source.php#freesource. Again if you are looking at developing something for use in an industrial setting, you need to review the code carefully. There is a lot of variability in any free code. What you are paying for in commercial products is usually more robust error handling, reliability and ease of use.

    Good Luck.

Leave a Reply

For spam filtering purposes, please copy the number 6315 to the field below: