It seems my goal to get everyone talking about OPC is having an effect. It’s got Nick over at ProSoft blogging about OPC and how fits into their products. What’s even better are the comments that it inspired. OPC and blogging. Truly Making Connections.
We’ll leave aside his comments on my penchant for Star Wars (the fact that I have a Darth Vadar head and a LEGO Slave I (complete with Han Solo in carbonite) on my desk is just a strange coincidence). What really got my attention are some of the OPC conversations it sparked. It has reaffirmed for me that blogs do reach people, and has shed a new light on how some folks out there perceive OPC.
I’ll forgive Nick for using the definition of OPC as OLE for Process Control. The OPC Foundation has officially stopped using that acronym as the specifications have grown beyond the COM based implementations (OLE) and are used in many places outside of Process Control (it’s used in HVAC, ODBC, RFID and anything else you can think up an acronym for). The term OPC is no longer an acronym for anything. At one meeting we bandied around a few suggestions; Openness – Productivity – Connectivity, Open Performance Connections, Old Programmers Club. Nothing really sounded right. So OPC is just OPC. Open connectivity via open standards. We just didn’t have a splashy ad campaign about it.
Of course I’ve also heard it call Oh Please Connect or Ongoing Pain and Concern. It’s these folks I really want to connect with. Many things are a frustrating experience at first without a little guidance and understanding. Who among use hasn’t tried to assemble IKEA furniture and wondered what the hell the little bubble guy is trying to tell you?
Oh well it saves IKEA money on having to translate their user manuals into a billion languages. The difference is, if our customers don’t understand, we lose money. And they lose out on OPC. There are quite a few misconceptions about OPC floating about. Gary Mintchell had a few thoughts regarding some blog ‘rants’ on OPC. Let’s see if I can help clear the air on some other stuff. Let’s start by saying what OPC is not. OPC is not a protocol. It is not Microsoft’s attempt at re-branding DDE. It is not a particular vendor’s product. It was never meant to be a magical ActiveX control for VB programmers. And probably most importantly, it is not the silver bullet that will solve absolutely every communication problem that exists.
We live in the real world here (we can’t all skip around in Oz), and I’ve been involved on both sides of the continuum; writing and selling OPC products, as well as designing, installing and supporting OPC products. For any of the project engineers out there, I don’t have to tell you that when it’s your neck on the block, you want to have faith in the solution you are implementing. With that said, most times I have found that OPC is the right answer (or at least not a bad answer when you look at the benefits you gain in standardizing your communication network). That doesn’t mean OPC is always free of installation headaches, but that’s a whole kettle of fish for another post.
The vision of OPC is to be the standard, interoperable interface from the shop floor to the top floor through the enterprise of multi-vendor systems. That covers a whole lot of data repositories, systems and vendors. OPC has become the standard because quite frankly it does a good job. It may not be the solution every time, but it should always be the first avenue to consider. If you choose not to go with OPC, be sure you know why you made that decision. The following are all too often the wrong reasons:
- Fear of the Unknown or Complexity – If you take the custom interface route instead you will likely learn the true meaning of complex and the unknown.
- Uninformed Technical Reasons - Get the real facts from a vendor you trust. “I read somewhere OPC is slow” is neither true, nor a good reason.
- Anti-Microsoft Bias – We all love to hate Bill and his monopoly, but that won’t make it go away. OPC does not automatically rule out Linux or other non-Windows platforms.
- Poor Experiences with a Vendor or Product. – OPC specifications are standard. Vendors and their product implementations are not. All restaurants serve food, that doesn’t make them all equal.
It all boils down to having some understanding of what OPC is, what it can do, what some of the pit falls are, and how to solve them. So how do you do that? Read a blog. Take some training. Better yet join me next week in Koln and find out about it one-on-one. (Oh and read the instructions, assuming it has words).
That does give me an idea, maybe I should get new business cards made up, and randomly scatter them around the place. Whadda think? Pictures seem to work for the Swedes.