I said I hoped I was wrong about PLC vendors not supporting integrated OPC-UA. That was in my last post and as it turns out, to some extent I was wrong, which is good. Matthias Damm pointed out that at least three PLC vendors are shipping with integrated OPC-UA interfaces, including Beckoff, Bosch Rexroth and B&R.
I did a little searching on Beckhoff, Bosch Rexroth and B&R to find out more about these controllers and found the Beckoff CX8091 controller right away but came away empty handed for the latter two. I'm hoping someone can help point me in the right direction on those two.
According to their website the Beckhoff controller is estimated for market release in the 2nd quarter of 2013. It is programmed using IEC 61131-3 languages and most importantly supports online programming changes. As you can see, they have the OPC-UA logo in the lower middle of their product.
Another poster pointed out that SAP and iTAC (who is iTAC anyway?) have already implemented OPC-UA. As I pointed out in my last post, it's not the software companies that are the problem. Most pure software companies have already adopted. It's the hardware companies that are lagging.
Kudos to the software companies who are now on-board, and kudos to Beckhoff for their new controller, but as I search the web for other hardware, particularly PLCs, with integrated OPC-UA, it is kind of spooky how empty the space is. So if Bosch Rexroth and B&R have it then why can't I find it with a web search? Are they just not promoting it? Someone please shed some light on this.
In my last post I pointed out three firms that provide SDKs for embedded OPC-UA. Matthias points out another provider is Unified Automation which provides a full range of OPC-UA SDKs and development tools for ANSI C, C++, Java and .NET.
All the tools are there, all that's missing is the motivation.
Intro
This blog is dedicated to open, interoperable manufacturing software and the coolest, latest and greatest things I see every day while conducting business under the banner of Inductive Automation.
Hello, my name is Steve Hechtman and I am president of Inductive Automation. During the span of one day there is more excitement, more discovery than I can possibly keep to myself. This blog is, therefore, my outlet. WARNING: This site is highly biased in favor of the most powerful, affordable manufacturing software in the world - Ignition by Inductive Automation!
Imagine OPC-UA Everywhere
I did a little fact checking to find out if there are any PLC controllers available with OPC-UA embedded. As far as I can tell, none are available yet. I found a page for the OPC Technology Summit 2012 which has downloadable presentations from major automation vendors like Rockwell, Siemens, and ABB. Each laid out their OPC-UA adoption roadmap.
How is it these presentations glow about the wonderful virtues of OPC-UA, yet you can't find a PLC with OPC-UA embedded? (Please tell me if I'm wrong, I hope I am.) There's certainly no technological barrier preventing it. There are many OPC-UA development tools available from companies like Prosys OPC and OPC Labs. Embedded Labs even provides OPC-UA on a chip that costs less than five dollars.
Adoption Roadmap
But, there is a glimmer of hope. Each of these manufacturers has put embedded OPC-UA on their adoption roadmap. They say they are going to do it, but not one has said when. This is especially interesting when you consider Inductive Automation and most other pure software companies have had OPC-UA for years now. Works great.
So what's so special about OPC-UA? Secure, simple, cross platform, flexible, standardized. Enough said?
Imagine OPC-UA Everywhere
Imagine a world of 100% OPC-UA. Gets me all excited because it would take the pain out the subject of intercommunication, between devices, between enterprise applications, and between devices and enterprise applications. For example, from the Ignition server running right here on my desktop I can connect to any number of other Ignition servers running on other people's machines in just minutes. And I can connect to Kepware servers running on other machines with similar ease. Now if I only had a few OPC-UA-enabled PLCs to connect to, the world would be beautiful. I won't hold my breath.
Sadly, when I mention this beautiful vision people usually roll their eyes and sigh a wistful sigh. (Try it sometime, it's true.) They know it should be but there's a tacit reality that even though it would be right for end-users and integrators, there's little incentive for PLC vendors to be more open.
Security as an Incentive
However, there's a good reason for hardware vendors to adopt OPC-UA that has nothing to do with openness. It is the one thing they are being beaten up about and that's security. OPC-UA is very, very secure and that solves a lot of their problems. It has built-in encryption and can use certificates to ensure end-points are who they say they are. We wrote our OPC-UA client and server from the ground up (from the specification) which was no easy feat mainly because of all the security involved. And speaking of that, anyone who attempts to create proprietary security schemes based on secrecy is going to be the least secure of all. Encryption and security schemes that are exposed to general public scrutiny (like the OPC-UA specification) will be tested and vulnerabilities exposed so they can be fixed.
I wrote this post because I thought it would be fun to imagine what it would be like if the anarchy of endless communication protocols was gone and we could experience the simple, secure, and standardized beauty of OPC-UA to communicate between all devices and software applications.
How is it these presentations glow about the wonderful virtues of OPC-UA, yet you can't find a PLC with OPC-UA embedded? (Please tell me if I'm wrong, I hope I am.) There's certainly no technological barrier preventing it. There are many OPC-UA development tools available from companies like Prosys OPC and OPC Labs. Embedded Labs even provides OPC-UA on a chip that costs less than five dollars.
Adoption Roadmap
But, there is a glimmer of hope. Each of these manufacturers has put embedded OPC-UA on their adoption roadmap. They say they are going to do it, but not one has said when. This is especially interesting when you consider Inductive Automation and most other pure software companies have had OPC-UA for years now. Works great.
So what's so special about OPC-UA? Secure, simple, cross platform, flexible, standardized. Enough said?
Imagine OPC-UA Everywhere
Imagine a world of 100% OPC-UA. Gets me all excited because it would take the pain out the subject of intercommunication, between devices, between enterprise applications, and between devices and enterprise applications. For example, from the Ignition server running right here on my desktop I can connect to any number of other Ignition servers running on other people's machines in just minutes. And I can connect to Kepware servers running on other machines with similar ease. Now if I only had a few OPC-UA-enabled PLCs to connect to, the world would be beautiful. I won't hold my breath.
Sadly, when I mention this beautiful vision people usually roll their eyes and sigh a wistful sigh. (Try it sometime, it's true.) They know it should be but there's a tacit reality that even though it would be right for end-users and integrators, there's little incentive for PLC vendors to be more open.
Security as an Incentive
However, there's a good reason for hardware vendors to adopt OPC-UA that has nothing to do with openness. It is the one thing they are being beaten up about and that's security. OPC-UA is very, very secure and that solves a lot of their problems. It has built-in encryption and can use certificates to ensure end-points are who they say they are. We wrote our OPC-UA client and server from the ground up (from the specification) which was no easy feat mainly because of all the security involved. And speaking of that, anyone who attempts to create proprietary security schemes based on secrecy is going to be the least secure of all. Encryption and security schemes that are exposed to general public scrutiny (like the OPC-UA specification) will be tested and vulnerabilities exposed so they can be fixed.
I wrote this post because I thought it would be fun to imagine what it would be like if the anarchy of endless communication protocols was gone and we could experience the simple, secure, and standardized beauty of OPC-UA to communicate between all devices and software applications.
Subscribe to:
Posts (Atom)