Control.com - Nerds in Control

Simply put, what are the legal terms of the OPC UA specification--how can you practically obtain it and use it?

First, will it be an open specification once released or it must be purchased?

And second, what are the terms its use? What if someone develops an independent implementation (not using code from the OPC Foundation)? Is it possible to write GPLed code based on these specifications and freely distribute it? What about the redistribution of the specifications themselves?

That's a really great question! In short, I don't know and would recommend that you ask here:
http://www.opcfoundation.org/forum/

My understanding has always been that the specification is open, but not necessarily free. That is, they want you to join the foundation to get access to the full written spec, sample code, etc. It's also been my understanding that it's a specification standard not a license agreement. In other words your software can be proprietary, GPL, LGPL, whatever, and is subject to your license agreement and has nothing to do with the OPC foundation. You just happened to write code that conforms to their standard OPC client/server/whatever. They aren't going around asking for royalties, your code, etc. I haven't seen the license for their sample code, but have been under the impression that you can do what you want with it.

I'm not a lawyer, nor a representative of the OPC Foundation. This is how I've always assumed that they work. I also don't know if UA is different than their other specs.

Please update this thread if you find out more. I'll post to the OPC Foundation forum if I don't hear back from you.

----
Nathan Boeger
http://www.inductiveautomation.com
"Total SCADA Freedom"

As the president and executive director of the OPC Foundation, we're currently working on defining the licensing and business model associated with the deliverables from OPC with respect to the OPC Unified Architecture.

In the beginning of OPC, allowed anyone to be able to download the OPC specifications, and corresponding OPC components and to be able to build an OPC application. Essentially mayhem broke loose. We ended up with many companies that built products or simple applications that were far from the expectations are end-users hangout with respect to reliability and quality.

The OPC Foundation members designed, developed and architected products and then certified invalidated interoperability of their products through the OPC Foundation certification programs.

The result was we started to reevaluate what we were doing and made a decision on the behalf of the interest of reliability and quality, to not allow nonmembers access to the OPC specifications and corresponding deliverables, because we would have no ability to make sure that those companies that were not members of the foundation to develop and distribute products that met and exceeded the expectations of both a foundation and the end-user community.

I have still been willing to provide specifications to companies that are not members of the OPC Foundation on request, with the expectation that they sign a memorandum of understanding essentially to develop quality products that exceed the expectation of the end-user community.

It is in the interest of OPC, and the OPC Foundation membership to make sure that products and services based on the OPC technology are the most reliable and best of breed interoperable products.

With the OPC Unified Architecture, we are actually providing significant technology that ultimately will be maintained through an open-source initiative. We are currently working on the corresponding business plan, that will allow nonmembers of the OPC Foundation to be able to access the OPC specifications, and the binary deliverables, and be able to redistribute the binaries with their corresponding products freely with no licensing restrictions.

We potentially will also make the source available to nonmembers, as well as to the OPC Foundation members with a royalty-free license treating it as an open source project.

For those companies wishing formal maintenance and support and a rigorous product development methodology, the open source will be maintained through a subscription arrangement that is part of the current business plan that is being developed.

Feel free to contact me directly with any questions or suggestions you may have about our planned open-source program. (thomas.burke @ opcfoundation.org)

The foundation will continue to provide an enhanced certification program that really will be the validation and interoperability mechanism to make sure that products developed that use the OPC technology far exceed the expectations of the end-user community.

My vision of interoperability is to make sure that we provide the best-of-breed technology that is end-user driven, and that these specifications are worth far more than the paper they are printed on. In addition it is the responsibility of OPC to provide product quality deliverables that facilitate vendor and end-user successful adoption of the OPC technology.

I am not sure who asked this question initially but this does give me the opportunity to communicate and brainstorm back the OPC thoughts. For more information about the OPC Foundation membership and deliverables and the open source project associated with OPC UA, please go to http://www.OPCFoundation.org.

Best regards,

Tom

Thanks Tom! That was really informative. I should have recommended that he email you in the first place.

----
Nathan Boeger
http://www.inductiveautomation.com
Total SCADA Freedom

Thank you for the answers, that was comprehensive.

My question was purely for information and I, personally, am far from being able to start an open source project now. :)

Striving for high quality is a good thing and membership model makes some sense. An independant open source project should be able to apply for membership as an non-profit organization (as long as there is an formal organization and it is a non-profit one) for an acceptable fee (as I can see). If the OPC Foundation itself distributes some open source code, that's even better. Validation, of course, is a must, given the fees are not prohibitive for non-corporative members.

Thank you again for the answers. I hope that the new model will prove to be both more open and providing higher quality.

Best regards.

In reply to Thomas J. Burke: It is good to hear that your organisation wishes to operate in a more "open" fashion. At present though, it seems that even things like the supposedly "freely available" brochure type material (at least that I saw) requires registering with your organisation.

If you are trying to be more "open" with regards to OPC UA while still controlling vendor quality, then I would suggest that you control the vendors through the use of trademark rather than trying to control access to information. That is, let people download the specs freely, but restrict use of the "OPC" trademark and any associated logos to implementations which pass approved conformance tests.

This lets everyone see the specs, but if they wish to distribute software based on it they can't call it "OPC" without your organisation's permission. This approach by the way is used by a number of free software distributions, such as the Firefox web browser or Red Hat Linux, so this is not a new idea.

Hiding the specs is just "security by obscurity". It doesn't prevent anyone from reverse engineering the protocol. Trying to prevent people from reverse engineering a protocol sent in clear ASCII sounds like an exercise in futility. Quality standards is something that is best handled by trademark and logo licensing.

It appears that OPC UA is a WS flavoured SOAP protocol. I imagine that this is intended strictly for ERP integration, as SOAP is fairly slow. People using OPC UA for ERP integration are going to want detailed information on the protocol, and they are going to want it right away when they need it (i.e. when it's not working, not when you get around to sending them a copy).

WS SOAP seems to be a very poorly specified standard. People use it, but it can be very difficult to get working and the protocol is not very robust. Getting two systems using different SOAP toolkits, or even different revisions of the same toolkit, talking to each other can take a lot of low level debugging of messages. I think you will need to provide samples for each type of message and reply (including http headers and XML documents) as part of the specification so that some sort of common standard can be set for what an OPC UA system is supposed to accept. It is fairly common for the SOAP to need tweaking to get two systems to talk to each other.

The "enterprise software" industry is fairly large and well established with many specialised vendors and armies of consultants. They are not likely going to be willing to change their systems to accomodate the automation vendors. This means that the OPC Foundation has to be flexible to accomodate them if OPC UA is to be a success. This includes being forthcoming with the information to make it work.

You said "We potentially will also make the source available to nonmembers, as well as to the OPC Foundation members with a royalty-free license treating it as an open source project." I would suggest using something like an LGPL license on it which requires distributors to supply the source code for this library if they use it. This way you are not likely to get multiple private versions of the source slowly diverging from one another, gradually introducing interoperability problems (as you get with permissive licenses like MIT/BSD). With a GPL/LGPL type license, useful fixes and changes which happen downstream tend to get fed back upstream which tends to keep everyone in sync.

If you actually do intend to release source code, then I would suggest that you decide on the licensing terms as soon as possible, rather than leaving that issue until later. People who have decided to open source existing code bases often find that they have included third party code with incompatible licenses, or they have code for which they cannot determine the origin. They then end up spending considerable time and effort tracking the origin of, and often replacing existing code.

I agree with Michael, if I'm doing feasibility on a project and run into the club mentality, I need a very compelling reason to continue. I just don't
like the feel of this model. And someone can
write and sell crap whether they are a member
or not. And I especially don't like legal
encumbrance when I'm writing something
I don't seek to make money with or on
speculation that I might be the winning bid.
OPC isn't a big problem for me because it's
so MS centric as to be useless with anything
else anyway. But there are too many of these
clubs that want you to pay to play and then
purport to be Open and inclusive. It's these
nagging gotchas that ensures the scheme will
never become ubiquitous or even popular.

Regards
cww

In reply to Curt Wuollet: From what I can see, OPC UA is a new version of OPC that doesn't depend on Microsoft COM/DCOM. Instead, it uses SOAP (I assume the WS version). It appears that it is intended to allow connection to ERP systems, presumably for things like production reporting, recipe management, maintenance reporting, etc.

It appears as if the OPC people realised that the dependency on COM/DCOM was a mistake. Unfortunately, the solution they settled on was SOAP. SOAP is one of those things that looks like a good idea when you see it on one of those spiffy diagrams in a presentation, but turns out to be a disaster in practice.

SOAP started out as a fairly simple idea for sending simple messages in XML tunneled through http and could be described in a 3 page specification. After the major IT vendors got ahold of it (Microsoft, with IBM and Sun, but mainly Microsoft), it bloated out into a monstrosity. Large parts of the protocol are undefined, interoperability is largely a myth, speed is a major problem (it's about 3 orders of magnitude slower than something like CORBA), the specification is changing constantly, and the error messages are singularly unhelpful in resolving problems.

If you want a good explanation in layman's terms of the problems with SOAP, I strongly recommend the following:

http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-st ands-for-simple/

WS SOAP is used by a lot of "enterprise" software vendors to glue otherwise incompatible systems together. They need detailed specs though because they usually have to re-write one end or the other (or both) to get them to work together (unless both ends happen to be using the same model and version of tool kit, which usually only lasts until the next software upgrade). People doing these sorts of systems are used to this though, and they don't mind because they're charging a very high hourly rate to do it.

The good news is that as long as you are doing something really simple (which is all that 99% of people actually want to do with it), then you can often just throw the spec in the garbage. If you are creating a client system that just has to send some data to a web service somewhere, then get the guy who did the server end to send you some samples of the messages that he expects, and samples of the replies he gives back. You will usually find that that all except a few bytes of the message never changes. This means you can just paste a sample message string into your program and manipulate it with a normal string library to give the server exactly what it wants, instead of spending days poking at the server while guessing what it will accept. Add in a http client library and you can POST away.

I haven't seen the spec for OPC UA (it's still a secret apparently), but it's possible that the above will work if you have to do something simple with it for a custom system that you create. It's very likely that even with a good detailed OPC UA spec you'd still have to do this anyway because of SOAP problems.

Unless of course, they happen to be using *binary XML*. Because we all know that binary protocols are uncool, so we create the message in XML, which we then encode into binary in our own extra special proprietary binary XML encoder which nobody else can work with ...

P.S. If you ever need to create your own web service from scratch for some project you are working on, there are simpler protocols than WS SOAP. You might want to look at XML-RPC, which is what SOAP was before Microsoft got involved in it. The whole thing can be described in 2 or 3 pages. There are also things like REST, JSON, etc.

Hi Michael,

In other words, they have repeated their mistake of basing something for automation on something almost singularly unsuitable for automation. Almost any automation system I've seen, which includes some pretty large ones, could communicate everything of interest with a very simple lightweight protocol. They are, after all, largely binary animals, and even the DCS behemoths with a plethora of loops and subsystems still handle what, in comparison to general computing, is an extremely small live data set. That set could be communicated in a very few frames. The problem, I think, is that we are subject to protocols developed by the purveyors of bloat, to solve all of their unrelated problems and needs, when all parties, even said purveyors, would be better served by a protocol developed by those to whom 16k of RAM is still significant. It's like having your mail delivered by a Euclid Earthmover. Yes, your mail gets through, but the method becomes a far larger consideration than the content. It's as if the people who run the Obfusticated C Code contest held one to find the least efficient. most obfusticated, most inscrutable way to deliver a few bytes of data. And ISA granted a present and future monopoly for automation to the winner. I am at a loss for words to describe how idiotic that is from my somewhat objective viewpoint. But, I apologize to those who might be offended and think that is a rational way to go forward. It would be far easier for today's omnipresent bloatware to pick the bits out of such a format than to doom all automation device software to start by incorporating a dead elephant.

Regards
cww

In reply to Curt Wuollet: I think the OPC UA is intended to allow interfacing with things like SAP or Maximo. It would be totally unsuitable as a replacement for something like Modbus/TCP. In other words, it isn't something you would use *in* automation. It's something you would use to connect *outside* of the automation world.

The people doing things in the target market (ERP) want to communicate through web services (at least for now). The fact that the OPC Foundation is doing this shows that they are at least listening. How closely they are listening remains to be seen.

The problem in the web services area is that a lot of people doing web service communications believed the WS SOAP nonsense. Now no Power Point presentation is complete without it. I don't happen to believe though that anything based on WS SOAP is going to have a long and happy life. Many software developers who actually have to use it are very disillusioned with it, and that attitude is starting to filter upwards to customers. Within a few years, I expect something else to be the "next big thing".

The question is whether the people in the OPC Foundation realise what a mess WS SOAP is in practice. If it has sunk in, then they will concentrate on providing an open specification so that people can use it as a guideline when integrating systems.

I had my introduction to WS SOAP the hard way. I implemented it in a project connecting a set of machines to a third party's server. It's not a protocol in the way that Modbus is a protocol. It's just an overly complex way of creating your own application specific protocol based on http and xml. To be quite honest, I didn't see what value the WS SOAP "specification" added to the process. It just added a lot of excess ASCII baggage to the messages that did absolutely nothing of any use to anyone.

If you are just playing with SOAP tool kits, this isn't obvious. If you are trying to interoperate between different systems though (which is the whole point of the exercise), you discover what a mess it is. You have no hope of getting anything to work with real world systems if you are basing it off the WS SOAP spec. You have to tune your messages to what the other end will actually accept.

I suspect that in the end, the OPC Foundation's will create an OPC UA tool kit that won't talk to anything except another OPC UA tool kit. In which case, I would have to wonder what the point of the whole exercise was.

Yes, but it's not particularly good at interfacing with SAP or Maximo either. Kinda like a bladeless knife without a handle. Like BOB it's just another wacky idea the MS shops will eventually see through and abandon on the pile of such things. But in the meantime they will stick a bunch of innocent users with it. OPC is just part of the plan to have every automation system dependent on a PC running Windows. You can't collect without a toll booth.

Regards

cww