What Is a Shared Device in PROFINET?

Back to Blog

Ownership Splits at the Submodule Level

In an ordinary PROFINET setup, one controller establishes an application relation to a device and owns all of its submodules. A shared device breaks that assumption: the device presents its submodules, and the engineering configuration assigns each submodule to a specific controller. Controller A might own the digital output submodules while controller B owns a subset of inputs. Each controller sees only its own submodules as owned and exchanges cyclic data with just those, while the others appear as not-owned from its perspective.

This works because PROFINET addressing already reaches down to the submodule inside a slot, the same granularity a GSDML file describes. The device supports more than one simultaneous application relation, one per owning controller, and internally arbitrates which controller drives which output. Inputs can be read by more than one controller; outputs must have exactly one owner to avoid two controllers commanding the same actuator.

Where Shared Devices Earn Their Keep

The classic case is functional safety. A single I/O device can carry both standard submodules owned by the automation PLC and safety submodules owned by a separate PROFIsafe-capable safety controller, so one physical rack serves both the control and the safety application. That reduces hardware and wiring while keeping the two applications logically independent, which is why shared device and the device's GSDML description are often discussed together.

Another case is a line divided between two machine controllers that must each read a shared set of sensors near the boundary. Rather than duplicate the sensors or run signals between panels, both controllers subscribe as owners of the input submodules they need. The design constraint to remember is the output rule: shared inputs are fine for multiple readers, but any output submodule must be owned by exactly one controller so there is never contention over a physical command.

Configuring a Shared Device Without Surprises

The feature stands or falls on configuration discipline, because two engineering projects now describe one physical rack. Both projects must agree exactly on the device's identity and layout - the device name and the slot and subslot arrangement of modules and submodules - and each project then marks the submodules it owns while declaring the rest shared or unused. Any drift between the two views, such as one project holding an outdated rack layout after a hardware change, produces faults that look like random communication errors and burn troubleshooting hours on the wrong layer.

A sequence that keeps the two projects honest:

1. Document the full slot and subslot layout of the device once, and make that document the single source of truth for both teams.
2. Assign every output submodule exactly one owner on paper before touching either project.
3. Confirm in the GSDML and the vendor manual that the device supports the number of simultaneous application relations you need.
4. Configure each controller's project with its owned submodules and the agreed view of the rest.
5. Bring both controllers online and verify each shows its submodules owned and healthy before wiring logic to them.
6. Repeat the paper exercise for every later hardware change, because a module added by one team is a fault source for the other.

Failure Behavior: When One Controller Drops

Each owning controller maintains its own application relation to the device, and those ARs live and die independently. If one controller loses its connection, only its submodules are affected: its outputs go to their configured substitute-value behavior, its inputs stop updating on that controller, and the other controller continues exchanging data with its own submodules undisturbed. That independence is the feature's core promise, and it is worth proving deliberately during commissioning by stopping each controller in turn and watching what the surviving one actually sees.

Diagnostics follow the same split. Alarms and channel diagnostics for a submodule are delivered to the controller that owns it, so each team troubleshoots its own I/O without wading through the other application's faults. The corollary is that device-level problems, such as a failing power supply in the shared rack, surface in both projects at once - if both controllers alarm on the same device simultaneously, look for a common physical cause rather than two coincidences.

When Shared Device Is the Wrong Tool

Not every case of two controllers needing the same data calls for a shared device. If the second controller only needs a handful of values rather than raw I/O ownership, controller-to-controller communication - one PLC exposing data for the other to consume - is simpler and does not require the device to support multiple application relations at all. If the device does not declare shared-device capability in its GSDML, duplicating a sensor or adding a small remote I/O station for the second application is often cheaper and cleaner than replacing the device to gain the feature.

And if the temptation is for two controllers to command the same actuator, the answer is to redesign the ownership, not to fight the output rule. Give the output to one controller and pass the other's request across as a signal, so exactly one application arbitrates the physical command. The case where shared device remains clearly the right call is the standard-plus-safety split, where PROFIsafe submodules belong to the safety controller and everything else to the automation PLC in one rack.

Frequently Asked Questions