OPC DA Data Modeling

One of the more interesting parts of my jobs is talking with automation guys (yes – they’re still mostly all guys) around the world. There are a lot of fascinating people doing a lot of fascinating things.
Everything from a guy in Alaska doing pipeline controls to a New Zealander running a dairy farm to a Swede building robots for non-industrial applications.

Everybody has a unique take on their part of the small world we all share. Luckily for me these people are all pretty smart, dedicated to solving problems and really want to learn and do the best job they can. It’s not hard to go all out to help people like that.

Today I talked with a guy about OPC. Now, I’m not an OPC expert but I have studied it for quite a while.

I’ve said for a long time, the number one thing you have to know about data transfer is the representation of your data on the network. If you don’t understand that, you are really operating blind. On a wing and a prayer as they used to say in the early days of aviation.

With EtherNet/IP, DeviceNet and all the other CIP protocols, the data representation is Objects and attributes. Objects simply being how the device vendor organized similar data together in the device. Attributes being the values for each of the data items in those objects.

That’s pretty straightforward but in Modbus RTU and Modbus TCP, it’s even simpler. All the data is just a flat series of 16-bit unsigned register data. There are some different types and function codes to access the different types but it’s still pretty easy to understand.
With our EtherNet/IP to Modbus RTU Data Converter, for example, we have to map the registers the users want from a group of Modbus RTU Slave devices to a set of EtherNet/IP Objects. Not hard, but not for the faint of heart either.
But if you used OPC, how does it model data? It’s not hard just a bit buried in the literature. If you’re a device vendor it takes a bit to dig it out.
Within an OPC structure there are two ways to look at your data. The data is organized in the OPC Server and then there’s how the data is organized for your application. The OPC Server in this context is the component that interfaces to the remote device. It knows not only what all the data items are in the device but how to move data between the device and the internal data tables of the server. It can use any internal storage mechanism it wants for this data depending on the size, complexity and specifics of the data. But to the outside world is provides a folder/item list kind of structure. But this list isn’t what an OPC Client can access. OPC unlike the industrial protocol interfaces that RTA creates allows this data to be organized by a Client for the particulars of this application.

I think that this is pretty cool. A Client device like an HMI can tell the server to create a group of items that it needs fast access to; a group of items that it needs for each page on its screens or a group of items that it will write to for recipe management or something like that.
With this structure a Client device isn’t limited to predefined groups of tags with predefined updates. It can organize it on an as needed basis and change it dynamically when the needs of the application changes.
Pretty powerful stuff. A unique approach for unique applications. Fits well with an international customer base with unique needs and unique approaches to doing business; just like the guys I talk to on a daily basis. Explains why OPC is such an international hit within the industrial automation community.