Most of the communication in a PROFINET network flows between Devices and Controllers. Supervisors don’t get much attention because they don’t get involved in production work. However, a PROFINET Supervisor can be a great tool during system commissioning, checkout, and even to troubleshoot when there’s a problem.
PROFINET supervisors operate in a similar role to a PROFIBUS DP Class 2 Master. They can run in a network concurrently with a PROFINET Controller and connect to Devices to read or write parameters and data. They can also operate in a network without an active PROFINET Controller to work with devices that aren’t communicating yet.
Supervisor Data Exchange
Supervisors use a special type of connection, the Supervisor Application Relationship (AR), to communicate with Devices. This Application Relationship can contain information about any one of the submodules plugged in to the device, but doesn’t necessarily have to contain data about the port(s) or interface. A supervisor AR may contain the Real-Time cyclic data from the connected submodules, but it doesn’t have to. And a supervisor may choose to parameterize a connected submodule… but again, it doesn’t have to.
All of this flexibility means that Supervisor connections to Devices can fill a lot of operational gaps. They may be as complex as a Controller connection with a Device, or they may be incredibly simple.
Going Solo without a Controller
Setting up a Supervisor AR with a Device without a controller is pretty easy. The Supervisor sends a request to the Device to open the connection and gives the device a list of all of the types of data it would like to access. Since the Device isn’t really doing anything anyway, it can always give the supervisor access to the data it wants.
Operating Alongside a Controller
Connecting a Supervisor in parallel with a Controller is a little harder. A Controller AR is “more important” than a Supervisor AR. So if there’s a conflict between the connections, the Supervisor AR is going to lose.
For instance, think about a device that has two output submodules. If the Controller is using those two outputs to control a real-world process, it can’t let a Supervisor just swoop in and grab them. When the Controller first made the connection to the device, can set a flag to keep Supervisors from connecting to the device concurrently. This flag is called the “SupervisorTakeoverAllowed” bit and is set in the ARProperties field. And most Controllers are greedy; they will usually set this flag to “FALSE” to keep Supervisors from connecting to the device.
This means that, while it’s possible to use Supervisors alongside Controllers, it’s not a common situation. The way most Controllers are designed usually prohibits this connection. If the Device is locked to keep a Supervisor from connecting, the Implicit or Device Access AR may still be used for data access.
Use Supervisors to make Commissioning and Maintenance Easy
Because a Supervisor can connect to Devices at almost any time, they’re very useful for forcing outputs or reading inputs for machine calibration, testing and check-out. And because they can read acyclic records from connected Devices, they’re also useful for collecting real-time diagnostic and fault information.
Those functions are also useful writing and debugging the application code that runs on top of many PROFINET Controllers. That’s why the engineering system for the controller (Siemens’ TIA Portal, Phoenix Contact’s PCWorx, etc) usually implements some Supervisor functions. But in some cases, it’s easier to use standalone software to suss-out commissioning or runtime bugs.
This article originally appeared as a lesson at PROFINET University