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.
16 comments:
Hi Steve
You hoped that you are wrong and you are :-)
There are at least three PLC vendors shipping PLCs with integrated OPC UA interfaces. The vendors are Beckhoff, Bosch Rexroth and B&R.
Unified Automation provides a full range of OPC UA SDKs and development tools for ANSI C, C++, JAVA and .NET. The ANSI C version is especially targeted to embedded systems like PLCs that want to provide all major OPC UA features. There will be more PLC vendors with integrated OPC UA servers based on this ANSI C SDK.
But I agree that we are still waiting for vendors like Siemens and Rockwell.
Matthias
Thank you Matthias. I was wrong and I love it! It's happening.
Please continue breathing even reality is better as you might thought: PLC vendors organized in PLCopen organisation agreed to expose their information modell in a semantc indentical way to outside world via OPC-UA. Today PLCopen define standardized Functionblocks to communicate device-to-device but also up to MES layer via UA-methode calls. PLC's aill also become UA client - Beckhoff already demoed public.
SAP, iTAC and other MES already implemented UA and customers already connected MES via UA down into embedded PLC controllers. Now PLC's will do method calls out of PLC's to UA-servers in MES.
UA in field device and sensor: Company Harting is enabling their RFID readers with UA-Servers. And the smallest UA-Server profile has 10kb footprint to be integrated into sensor level...
Siemens and Rockwell also provide UA for their PLC's - not embedded but anyway available.
It's not a dream - it's reality. Please continue breathing
Cheers
Stefan
Thanks Stefan. More going on than I realized. I'm going to research this area more.
One of the biggest challenges of OPC UA is the security. I have seen several implementations now and nobody is using the security features.
I audited installations at my company and visited a few non-related (just to see if we're alone). My conclusion is simple: Security is the Achilles Heel of OPC UA.
For example, people are not using Windows Authentication (even locally). This is bypassed with the certificates. Also, no one is connecting to the Domain controller. Worse, with all the marketing hype around the wonderful security features for OPC UA, people don't even realize their problem.
People are using OPC UA as a way to work around security. In the end, if we do have OPC UA everywhere, it will be a completely insecure platform. No thanks, we figured out DCOM (yes, I mean it) and we're sticking with it.
Andrew Field
Hi Matthias,
please also take into account the joint development with Phoenix/Siemens for the Tiger Chip, which supports OPC-UA, the smallest one as we call it. See http://www.iosb.fraunhofer.de/servlet/is/32564/, unfortunately in German.
If someone leaves their car keys in the ignition, does it mean all cars are insecure?
Our experience doesn't align with yours. Our support department reports UA security is almost always turned on. In fact, it is turned on by default in our products and Kepware's products.
OPC-UA security is actually a no brainer to implement.
Being able to lock a car does not make it "secure". It is simply a security layer. I break the windows and I am in your car.
OPC UA technology has been out since 2009... and still there are nowhere near the number of applications we had for OPC Classic in 2000 (when OPC Classic was 4 years old). And OPC UA has benefited from marketing efforts never seen before in OPC.
You must not ignore the market. There's a reason for the dearth of OPC UA applications...
steve, I don't understand the delay with opc ua either.
We are connecting using opc ua.
we didn't have to worry about security because opc ua does it all for us.
OPC ua was really easy and everything works. everyone can connect now from any computer.
Steve,
Great post. I've been asking my friends at Rockwell for the last 5 years when they will offer OPC UA in the controller. I just get that deer-in-the-headlights stare.
Maybe we should just do all of our control with an arduino connected to raspberry pi running OPC UA. (don't tell my Rockwell friends that I suggested this ;.)
Hey! That sounds like a fun project!
What a great post. I am struggling to convince management and other colleagues to move away from IEC104, mod bus, etc. to OPC-UA, which offers not only safe and easy communication, but also a whole modelling concept.
Hi Steve
You are so right. The only reason for Siemens, ABB and others not to jump on the OPC-UA wagon is the large amount of money they make on their old obsolete solutions. I am struggling to get this protocol adapted and mostly stopped by the lack of hardware vendor support.
It is obvious that all of us are very reluctant to replace the old good stuff as long as it works and fits our needs. Hence we need something special to make additional effort to break the natural reluctance. Talking about acceptance of OPC UA we usually focused on uniqueness and remarkable features with the goal of sending the message: “OPC UA is the best interoperability standard - it is much better than other classic solutions ever available” to the community. Additionally, we are sending (circulating) this message over and over to other members of our close OPC UA community. This way we are fighting against reluctance using comparison and concluding that if something is better it will replace the old stuff soon. By this approach we are making two mistakes:
- compare something without a measure clearly defined in advance -to be useful it could be obvious for all and must yield unique results in all circumstances.
- comparing incomparable things, for example the OPC UA with OPC Classic, because from the technical point of view the OPC Classic is not the protocol at all - it is an instruction of how to use a selected operating system to transfer process data over the network rather, but OPC UA is the protocol and additionally technology making interoperability possible.
In the past, there was a lot of problems solved using money to overcome the reluctance. OPC UA as a technology, in my opinion, is not going to replace "something", but it has been designed to make "something" possible, something that could be used to create new value measured using money.
OPC UA is not just communication protocol - it is integration technology and to look in the future, on the grounds of my personal experience I am trying to imagine new unexplored yet fields of potential applications of the OPC UA. It is obvious that their number is uncountable; therefore a selection key of these new areas must be applied. It seems that the word “ENABLER” seems to be most appropriate to flag the technology, solution, application, model, approach, etc. that OPC UA makes possible. To make my dreaming more useful for others, my first attempt is to prepare a series of short articles (a catalog) on new application scopes where OPC UA could be recognized as a prerequisite. All of them have a common title pattern “OPC UA Makes Possible”. (read full story: http://wp.me/p3MGZj-1l).
Most of them can be recognized as building blocks of a smart-manufacturing concept. Today, to be in fashion, we must provide smart solutions, and finally almost everything is smart. We have smart-cars, smart-grids, smart-buildings, and smart-cities. Therefore we must ask, if it is only a buzzword. If not what distinguish smart-manufacturing and regular-manufacturing. It could be also your homework, but my simplified answer is as follows:
- Recognizable building blocks - for example your new make and pack machine must expose in the OPC UA address space metadata that can be used by a predictive asset management system (PAM) to minimize maintenance cost and improve availability, i.e. save yours company money - a lot of money, so it is not just a toy,
- Cloudy environment - as above your machine must be exposed to the PAM, and in this case you need selective availability as the PAM is maintained by IT department and you must protect your machine against ignorant.
- Global solutions - today manufacturing plants are frequently a more or less autonomous part of a global organization – they are like clouds on the corporate sky, so to provide macro optimization you need global communication measures to communicate them with each other and make collaboration possible.
Do you think you can meet requirements of the above mentioned solutions using OPC Classic?! Do you think we are talking not only about idea but also about money that improves IRR/ROI significantly.
To get more follow me on mpostol.wordpress.com
Mariusz
I deleted the Nov 30th comment since it was substantially the same as this later comment by Mariusz. I assumed the later post was the one he intended to post.
Post a Comment