Aug 19, 2022

“We make redundancy easy to use”

Interview on TwinCAT Controller Redundancy

Published in P&A International 2022, July,, publish-industry Verlag, Germany

Interview conducted by Christian Vilsbeck and Jessica Bischoff, both P&A

A control system failure can have fatal consequences, especially in the process industry. This is precisely why redundant systems should be mandatory in critical processes, although they are often highly sophisticated and expensive to implement. Dr. Henning Mersch, Product Manager TwinCAT at Beckhoff, explains in an interview with P&A how fail-safety can now be maximized very simply with redundant control technology.

Dr. Mersch, haven’t redundancy solutions from Beckhoff been around for many years?

Yes, that’s correct, but until now we were focusing on the fieldbus level. To put it simply, if a cable between the controller and the actual fieldbus elements no longer transmits data correctly due to breakage, mechanical damage, or weak contacts, then we enable redundant communication via EtherCAT using a second cable. Now we are taking things one step further by making our TwinCAT controller itself redundant. If this should fail due to excessively harsh environmental influences, unintentional mechanical stress, or even a technical defect, the second controller can step in seamlessly and take over.

Dr. Henning Mersch, Product Manager TwinCAT at Beckhoff
Dr. Henning Mersch, Product Manager TwinCAT at Beckhoff

Could you outline the functionality of the new TwinCAT Controller Redundancy solution?

Of course, our controller redundancy is based on taking two controllers that run the same program. This means there are symmetrical images on both sides, and these must be executed with absolute synchronicity. Since it is usually impossible to determine exactly when and if a controller will fail, the second controller always has to be ready to take over the process control along with all important current process values. This requires there to be a data connection between the two controllers. It’s a pretty standard requirement across the market and our competitors work on the same basis. Where we differ, however, and what makes our solution so special is that we use a normal Ethernet connection for this, so we don’t need dedicated hardware components for synchronization between controllers, unlike our competitors. The technical progress we have made with our TwinCAT controllers means we already have network connections in the gigabit range on board for real-time synchronization as standard. And then there is the communication of the controller at fieldbus level. To this end, each controller features our CU2508 real-time Ethernet port multiplier, and we also link these with a connecting cable. If the data link between the two controllers fails, we need to make sure that each side can decide whether the other controller has failed or just the data link. We do this further down via this second communication channel between the two CU2508s, thereby offering additional fail-safety. From the port multipliers, it all continues downstream quite normally via EtherCAT, where we can also offer redundancy.

Surely there are special requirements for synchronizing the two controllers via Ethernet? Have you developed your own synchronization protocol here to meet your needs?

Absolutely – this is an independent protocol. It doesn’t have much in common with EtherCAT either, because we have to transfer completely different data there. In this horizontal communication between the two controllers, the process images not only have to be transmitted as quickly as possible, but also provided in highly optimized packages. This is the only way that the other side can also process the data quickly again in real time. To meet this requirement over Ethernet, we had to develop a new synchronization protocol.

Does TwinCAT Controller Redundancy actually have a primary and secondary system, or does the solution handle this automatically?

Customer feedback and our own experience have shown that it makes the most sense for users to determine this for themselves. It starts with the most trivial applications like commissioning the systems, where very different situations can occur in practice. One controller is therefore defined as the primary system in the control operation, making it the active component, while the secondary system acts passively in the background. In process technology, it is also common to make routine switchovers for control purposes – for example, with redundantly designed pumps. And that’s exactly where our controller redundancy comes into play. Users can therefore safely test a critical fault at any time without provoking a deliberate failure.

Is your TwinCAT Controller Redundancy actually completely software-based, or did you have to adapt the controller hardware?

Yes, the solution is an out-and-out software product, which also makes TwinCAT Controller Redundancy extremely appealing in terms of price. But as I mentioned earlier, we use the CU2508 real-time Ethernet port multipliers as additional hardware, which we have had in our range for a long time and so these were not specially developed for this purpose.

So now we can ensure redundancy not only between the controllers, but also right down to field level. But how do the controllers communicate with the higher-level systems in the event of a critical defect?

Our upward communication interface provides a virtual redundancy address with TwinCAT Controller Redundancy. Higher-level systems always use this to communicate automatically with the active system with no indication of whether it is the primary or secondary control. We also offer the possibility of addressing both controllers via their real address. This is necessary in the case of diagnostic programs, for example, if they want to check the status of the redundancy solution. Another new feature is that our TwinCAT controller can also communicate upward via two redundantly designed Ethernet networks using the Parallel Redundancy Protocol (PRP). To this end, two separate network interfaces are used per industrial PC. Users can therefore also implement redundancy above the control level, which is then automatically supported by our controllers.

To finish up, what would you like to say to customers wondering why they should rely on Beckhoff for redundant solutions?

Here at Beckhoff, we still offer a very open interface with our PC-based control and the protection between these two controllers. So rather than having a completely closed redundancy system, we can run customer programs on the controllers without any issues, as is usual with Beckhoff solutions. We are therefore offering something really quite special here that makes redundant control solutions much more suitable for everyday applications with significantly greater usability. At the same time, the state-of-the-art processors in our controllers give them a computing power that far exceeds that offered by our competitors in the field of redundant control.

Further information