PROFIBUS Object Models

I’ve spent a bunch of time over the past month looking harder at the Profibus and Profinet IO Object Models than I ever have before. I think I’ve learned some interesting new facts and confirmed some of my earlier perceptions about those technologies.

One of the things I always said was that these technologies are complex. Siemens has done an incredible job of building protocols that are fast and functional. In fact, if you listen to Carl Henning at one of the Profinet IO seminars, Profinet IO will do everything any factory could ever need including making morning coffee. It’s hard to believe that they’ve built all that functionality into the technology.

But then you look at the size of the code and realize the downside of all that functionality. Five big megabytes plus a huge operating system like a VxWorks or WinCE. That’s a lot of physical resources you have to provide in your embedded device.

Besides size, another huge downside to the ultimate functionality and speed that Profibus and Profinet gives you is incredible complexity. The data representation for both protocols is complex as is the access to the data in a device from a Siemens PLC. Both protocols use a Rack / Slot / Point kind of data representation though in actuality that representation varies a lot from device to device.

The Rack Address is the first identifier of data. That part is pretty straightforward. In Profibus you have a 7-bit address 1-127 while in Profinet you have a TCP/IP address.

Next is the Slot address. All Profibus and Profinet IO devices are modeled as PLC I/O racks. The Slot address is the space in a rack where you can plug into a module.

Modules are another aspect of the data representation. Your device can specify that a slot has a specific module. For example, Slot 2 of your device can be an Analog Input module with four Analog input points, another aspect of the data representation. All four point AI modules are the same providing the identical IO data, diagnostics and analog conversion.

Points and channels are the lowest level of data representation where you identify the specific I/O point.

If all this sounds somewhat confusing and awkward, you’re right. It is! I don’t especially like it but that’s how it works.

If I was to contrast it with the CIP data representation I would say that the CIP representation is much simpler and more straight forward to explain. If I have a device with a combination of Analog and Discrete I/O it is much simpler to organize that I/O as Objects and Attributes instead of the more awkward Rack/Slot/Point representation.

Then there’s the issue of how the PLC accesses your Profibus or Profinet IO device data. Cyclic data is pretty easy. The data exchange with the PLC works just like CIP I/O data exchange. There is a buffer in the PLC that is sent out to the device and a buffer in the device that is transferred to the PLC.

There’s also a way to directly access data in your device from a PLC like a Siemens S7. In an S7 you can setup an instruction witch specifically addresses a Rack/Slot/Point within your device. It’s nearly exactly the same as the block used in a RA PLC to access a specific Object/Instance/Attribute in a CIP device.

It’s all a bit awkward but there are huge numbers of Profibus (and now Profinet IO) devices so it’s good to know.