There’s a discussion I seem to be having about once a week on implementing OPC UA (Unified Architecture). The people on my side of the world, automation, seem to think that UA is just another protocol like DeviceNet, Modbus TCP, EtherNet/IP or Profinet IO. That’s silly but I don’t blame them for thinking that.
In Automation, all those protocols are basically alike. There is a block of Outputs that move from some controller to some end device; a PLC sending speed command to a Drive. There are some Inputs coming from the target device to the controller; a valve block sending valve status bits to the PLC. The specifics vary but all the standard automation protocols have this sort of functionality. I/O moves from here to there at some cyclic rate.
And that’s why all the automation guys want to put OPC UA in that I/O box. They are thinking that it’s just another one of these protocols with a new twist to it.
Just yesterday, Vince, one of our newest engineers asked me about implement UA for a project I just assigned to him. We were discussing it and he says “UA has an Object Model just like DeviceNet”. And I go “Only if you would say a Ruth’s Chris Steak is just like a white castle burger”.
What Vince doesn’t understand is that UA is more of an IT protocol than an automation protocol. Before starting an implementation you have to wrap your mind around the fact that UA exists to move non-control data to some server in a very open, extremely secure and highly organized way. It doesn’t exist to move I/O data to a controller.
The key to understanding this is that UA servers a different but complementary purpose than those automation protocols Vince was thinking about. Once you get past that, you can start to think about implementing OPC UA.
If you’re a device developer implementing a UA stack, Step 1 is identifying the data you want to make available to UA Clients like databases, quality tools, energy management systems and more. If this is a Drive that is connected to a controller over Profinet IO or EtherNet/IP, you don’t want to duplicate all the information that is going to the PLC. Current Drive status (run/stop/faulted) and speed are already over there in that environment and available to process controllers and HMIs.
Instead you probably want to think about the data that a maintenance guy might need (run time, number cycles), the data the plant IT people might want (last time the drive profile changed), the data the group concerned with monitoring energy might need (current KW and KW month-to-date) or the data mechanical guys might want to see (a torque profile). It’s very different way of looking at a plant floor device.
Once you get there, you will need to start thinking about the OPC UA functionality you want to build into your device. Here is a not at all comprehensive OPC UA implementation checklist:
1. Address Space – How does the data that you defined interrelate? Is there a hierarchy? How much access do you want to give to the user to customize the address space? Can they add or delete nodes or will it be fixed? What Attributes are read only and which ones are writeable?
2. Views of the address space – will different users have different views of your device? Will the maintenance guy want to access a different subset of information than the energy manager?
3. What alarms will each of these users require?
4. What level of security is required? If your device is going to be accessed over the Internet, you will probably need security? Do you need 128 or 256 bit security? Can your hardware support 256 bit security? What security models does your Client support?
5. What Transport mappings and data encodings should you support? There will be some Clients that will only use .net. If you aren’t using something like embedded windows, you may not be able to talk to those kinds of devices.
6. What Events will you make available for notification?
7. What UA Services must be supported? What Services should you support?
8. Do you want to implement the Historical functionality where the device manages history data? I’d guess that few devices will implement this.
9. How will your device support device discovery under UA?
10. Do you want to support Methods? Methods are essentially vendor specific functionality. A calibration process might be a Method?
Once you have all this information, next you need to identify the profile for the device that most closely matches your functionality. And, then check with your client devices to make sure they can support that profile. It’s not for the faint hearted. There’s a reason the trailblazers take the arrows and right now, UA is trailblazing kind of stuff.