Introduction
I recently encountered and resolved an issue at work regarding the PROFINET system redundant communications and I think it worth an article.
At work we have a S7-1500H redundant control system that contains many components that we use in single controller systems, too. The issue that I encountered and resolved was when the S7-1500 redundant controllers switched from its primary controller to its secondary controller, some of the components (PN IO devices) in the PROFINET network stopped updating their process data and retained their last process data exchanged with the primary controller. In other words, these IO devices were “frozen”. Later I resolved the issue by updating these devices’ firmware to make it support the PROFINET S2 redundant communications.
However, I noticed that very little engineers know the PROFINET system redundant communications hence I am writing this article to cover the blind spot.
Fundamentals
With the redundant PLCs like S7-1500H communicating with the IO devices via PROFINET, the network standards can be categorized into 4 types: S1, S2, R1 and R2.
The letter in the name of the types indicates if the IO device has one (S) or two (R) PN interfaces. This interface is also referred to as a NAP (Network Access Point).
The digit in the name of the types indicates the maximum number of communication relationships the IO device’s NAP can support. The communication relationship is also referred to as an AR (Application Relationship).
Knowing the above fundamentals, the 4 types of PROFINET system redundant communications can be described below.
The System Redundant Communications
S1 Communication
S1 system redundant communication is basically no redundancy communication. If the AR is interrupted, the IO device will be lost though the controller is redundant like below.
To connect an IO device that only supports S1 PROFINET communication, we need to rely on a device called Y switch to simply add S2 communication capabilities to the S1 IO device.
The issue that I encountered at work was that the IO devices that I used at work supported only S1 communication hence when the AR is interrupted, it won’t switch to the secondary PLC.
Luckily the IO device had a firmware update and after updating the firmware, it supports S2 communication.
S2 Communication
A S2 IO device can have up to 2 ARs hence when the primary controller is offline, the secondary controller can take over. Note that in the S2 IO device case, the primary AR is active and the secondary AR is reserved which means the redundant switch over takes a bit more time than the R type IO devices. In most of the scenarios, this won’t be a problem though.
R1 and R2 Communication
The R type IO devices have two NAPs. The R1 IO devices can maintain 2 ARs with each NAP supporting one of them.
In the case of R2, 4 ARs are there with each NAP maintaining 2 ARs.
Since in the R type communications there are two NAPs, the communications via each AR runs in real time hence when a failover happens, the recovery time is shorter.
Conclusion
The PROFINET system redundant communications are categorized into 4 types (S1, S2, R1, R2) and differentiated by the number of NAPs and ARs the IO device can maintain. Different types of IO devices can coexist in the same PROFINET network.
It is also important to note that the system redundant communications can run on different network topologies as well as different ethernet redundancy protocols like MRP (Media Redundancy Protocol), HSR (High Availability Seamless Redundancy), etc, as long as the ARs can be maintained.