PROFINET System Redundancy: S2 and R1

Back to Blog

System Redundancy Versus Media Redundancy

It is easy to conflate the two, but they solve different failures. Media redundancy, such as a ring healed by the Media Redundancy Protocol, protects against a broken cable or a failed switch in the network path. It does nothing about the controller. System redundancy protects against the controller itself failing, by arranging that a backup controller can take over the IO exchange. A robust design often uses both: a ring for the cabling and system redundancy for the CPUs.

System redundancy works at the application-relation level. A redundancy-capable device holds relations that let a backup controller step in for the primary. During a switchover the device continues exchanging data with the newly active controller rather than dropping its connection and re-establishing from scratch, which is what would otherwise cause an IO outage. The redundancy class describes how much of the interface and path is duplicated to achieve this.

What S2 and R1 Duplicate

An S2 device has a single network interface but maintains application relations to both controllers of a redundant pair, one active and one backup. When the active controller fails, the backup becomes primary and the device carries on over its existing single interface, because it already had the standby relation in place. S2 covers controller redundancy economically, using one device port, and is a common choice where the concern is CPU failover rather than a duplicated network to the device.

R1 goes further by duplicating the device's interface and its path, so the device connects through two independent interfaces to the redundant system. This protects not only against controller failure but against the loss of one interface or path to the device, giving redundancy of the connection itself. R1 costs more hardware and design effort and is chosen where the availability requirement justifies duplicating the device-side path, similar in spirit to broader controller redundancy strategies. The right class depends on which failures the process cannot tolerate.

S2 and R1 at a Glance

The classes are easiest to compare side by side. The table deliberately avoids vendor-specific behavior - switchover characteristics, configuration limits, and supported device counts are per the controller and device documentation for the specific products involved.

Aspect	S2	R1
Device network interfaces used	One	Two
Application relations held	To both controllers via one interface	To both controllers via separate interfaces
Survives controller failure	Yes	Yes
Survives loss of one device-side path	No	Yes
Relative hardware and engineering cost	Lower	Higher

Reading the table bottom-up is how most selection conversations actually go: the cost row rules R1 out unless the availability rows rule it back in. The middle rows carry the technical content - what is duplicated, and therefore which failures the process survives without an interruption. Keeping that framing explicit in a design review stops the discussion drifting into redundancy for its own sake.

When Each Class Wins

S2 wins in the broad middle of applications: a redundant controller pair added to an otherwise conventional PROFINET network, where the failure being engineered out is the CPU, and a network-path failure is acceptable to cover with media redundancy and repair procedures instead. It uses standard single-port device wiring, keeps the network design familiar to the site's maintenance team, and the device market offers far more S2-capable products than R1-capable ones - which matters a great deal the moment the IO list includes third-party devices rather than a single-vendor lineup.

R1 wins where the process cannot tolerate losing the path to the device either: continuously running processes where a single cable, connector, or interface module failure would force a shutdown even with both CPUs healthy. Duplicating the device-side path buys that coverage at the price of doubled interfaces, a more complex network design, and a shorter list of eligible devices. A practical pattern is mixing the classes within one system - R1 or otherwise hardened connections for the IO the process truly cannot lose, S2 for everything else - with the split driven by the site's failure-consequence analysis rather than by a blanket rule applied to the whole IO list.

Commissioning and Failover Testing

System redundancy only counts once the failover has been demonstrated, so commissioning should include deliberately failing things. Verify first that every device intended to ride through a switchover actually declares system redundancy support in its device description file - a standard device on a redundant controller pair does not gain redundancy, it just reconnects after an outage. Then, in a controlled window agreed with operations: fail the primary controller under representative load and observe IO behavior; restore it and verify the return path; and where R1 is in play, pull each device-side path separately and confirm the other carries the exchange without interruption.

Watch the diagnostics as closely as the process values. A switchover that succeeds mechanically but floods the alarm system with communication diagnostics will do exactly that at the worst possible moment in production. Note which alarms a clean failover raises, decide which are informative and which are noise, and tune accordingly before handover. Finally, document the observed switchover behavior for the operations team, because their instinct on seeing a controller-failure alarm is to expect an outage - knowing that IO rode through it changes how they respond. Any timing figures in that document should be observations from your own test, framed per the vendor's documentation, not promises borrowed from a datasheet summary.

Frequently Asked Questions