OPC UA Profiles – What good are they?

Every communication protocol I’ve worked with over the years has a concept of profiles. Profiles are some standard set of features or capabilities that make one manufacturer’s device look like another manufacturer’s device. Users like this – a lot. They can tell you to go shove your device and plug your competitor’s device in without missing a beat. Good for them. Not so great for you, the device manufacturer.

EtherNet/IP and DeviceNet had the most organized profiles. Those profiles specified exactly what the contents of the messages would be for a fairly long list of devices. EtherNet/IP and DeviceNet Motor Drives were the devices that always followed the profile. It made it easy for users to easily switch from Allen–Bradley drives to Yaskawa or ABB drives without changing any PLC code.

Besides the contents of messages, sometimes the profiles included state machines, error states, initialization states and more. Profiles were started for lots of other devices, but there was never any real traction other than for drives. Partly it was because there was a lot of direct competition for drives and there was real value in saying you could use our drive instead of the other guy’s and not change any PLC code. Plus the drive profile was really straightforward: just two bytes in and two bytes out. It was easy to implement. The drive manufacturers all cooperated on the profile. That didn’t happen for many other devices.

When OPC UA was created, the founders also included profiles, but instead of just defining messaging, they defined a whole host of capabilities for a device. There were four profiles, each including all the features of the previous profiles:

Nano Embedded Device Server Profile – Intended for devices with limited resources. It supports only Read/Write Attribute commands and there is no security.

Micro Embedded Device Server Profile – Micro Embedded supports features of the Nano Profile, plus support for subscriptions (publish/subscribe) and at least two sessions.

Embedded Device Server Profile – This profile supports features of the Micro Embedded Profile plus security via the Security Policy and support for the DataChange Subscription Server.

Standard UA Server Profile – The big enchilada. The full featured Profile that defines the set of functionalities you’ll find in a PC based server.

Several years ago, I really believed that these UA profiles would be widely adopted. If nothing else, they would be a shorthand for users to know what they wanted in a server device. Two things have now changed that. One, processors are now more powerful than ever; we are rapidly moving to an era where every device on the factory floor will be a powerful processor with massive flash and RAM resources. Secondly, there is a shakeout of the feature sets that are actually being used.

In many ways, OPC UA was over designed. Simplicity was not at the top of the design objectives. A very sophisticated Type system was created along with complex history and eventing subsystems. These things are software engineering masterpieces. But now, after a few years, there is a settling out of what the market really wants and needs.

I believe OPC UA is moving toward a time where users are going to pick the features they want in an OPC UA device by selecting a little bit of this and a little bit of that. They’ll say, “I want security and Pub Sub (another kind of publisher/subscriber), but not standard publisher/subscriber.” It is going to be more of a long buffet of features than the predefined set of features that were guessed at by the OPC UA designers.