PROFINET offers many features which allow for custom-tailored architectures and automation applications. An overview of these features can be found in our mandatory and optional features articles. One of these features is “PROFINET Shared Device”, which gives multiple PROFINET IO controllers (PLCs / PACs) access to the same IO device. You are probably thinking why would we want to do that? And, how could that help improve our companies projects? In this article, we’ll explain why Shared Device may be useful in your next automation application.
First, let’s look at how sharing works in principle. You probably use sharing in your daily activities, especially if you are doing file sharing on a server, or between colleagues. The first person to open the file on the server is the owner, who then locks the file, and has access to read and write to the file (save). The second person opening the file only gets an option to open it as ‘read only’ mode. They cannot write since the first owned locked it. However, the second user can still see the contents of the file and read what is there.
With PROFINET, we can take this functionality a step further. Imagine we have a workbook with various spreadsheets. All users can read each spreadsheet, however, only one user (in our case controller) has access to write to their assigned sheet in the workbook. Now we can look closer at how this applies to PROFINET applications.
How does “PROFINET Shared Device” work?
“PROFINET Shared Device” offers the ability for a device to support connections to more than one controller at the same time. This offers flexible architecture of the PROFINET network and advanced automation tasks to be performed.
When configuring a shared device you can set up input and output modules to be exclusive to separate IO controllers or inclusive. It’s probably a good idea for us to explain and take a look at the following diagram. Let’s say we have two IO controllers. One is a standard controller and one is a safety controller (PROFIsafe). We have an IO device with 4 modules, two input modules, and two output modules. IO controller 1 can be set up to exclusively control the first input and output modules (Orange). While IO controller 2 could be set up to control only the second input and output safety modules (Blue). So, as you can see, this is just like file sharing, but now we’re doing it with our device IO data!
IO Controller 1 also sets up the PROFINET interface and network ports on the device (the first big orange slot). In addition, IO Controller 1 handles any diagnostic/process alarms from its modules. For example, module pulled or a fault like a wire break. While IO controller 2 will handle any alarms from its associated modules.
Next is another example, which allows more flexibility. Let’s imagine we own a juice factory. And each controller needs to know the input value for the type of juice in production today. In this case, we can set up shared inputs with two controllers (safety is also possible). Now both IO controller 1 and IO controller 2 can see all the inputs from the device. And each controller has exclusive access to their own output modules. Since both controllers now have access to the recipe, they can act accordingly by sending down the proper output values.
Note that a device which supports sharing must allow for at least two controller connections. But, can support greater than two depending on the device and vendor. We have seen some devices which support four or more connections.
In conclusion, we hope you see the benefit of “PROFINET Shared Device” and how it could help your applications. You can minimize hardware, cabling, cabinet space, allow flexible assignment of multiple IO controllers to the same device, custom tailor architectures, and mix failsafe and standard IO on the same device (for example on a robot controller). It also allows exclusive input/outputs to separate controllers, or even shared inputs between multiple controllers. If you are interested in this feature, your IO vendor may show you how it works with real hardware.