DCS redundancy issues

Put it this way: redundant controllers all have a status indicator light, specifically used to indicate whether the current CPU is in the primary role or the secondary role. What you should focus on is how to ensure data synchronization without any loss during the primary/secondary switchover, so as not to affect the entire system.

The normal operating mode is one in which the system is working properly, while the alternate mode is when it is in standby; this can be seen from the indicator lights on the cards. If the CPU in use fails, operation will switch to the backup card. In daily use, it is also possible to switch the controller from the server. If there’s anything else you don’t understand, feel free to ask

That’s exactly what I mean! Does the main card transfer data to the backup card in every operation cycle? Otherwise, how can data consistency be ensured during switching?

This post was last edited by humker on 2016-2-21 at 15:15. Different DCS systems have roughly the same mechanisms, with only minor differences. Both controllers retrieve real-time IO data from the IO bus simultaneously; only the primary controller can issue commands. During the switch between primary and backup controllers, commands are generally not executed, or they are executed in a buffer area of sorts. In other words, each controller has a common buffer area that is normally invisible; it exists only during controller switching to ensure the continued functionality of the DCS. It plays a role in hard switching (or manual switching). So here comes the question: if the primary controller fails suddenly and stops working, the backup controller’s buffer area will continue to execute commands until it assumes the role of the primary controller. If the primary and secondary controllers are switched manually, then a command is sent to the cache area in advance, instructing it to take over the tasks of the primary controller during the switching process, while waiting for the secondary controller to become ready. However, since the switch-over time for primary/secondary DCS systems is usually in the range of a few milliseconds to a dozen milliseconds, in most cases the controller stops executing output commands and ceases to perform logical operations during the switch-over process. After all, DCS is not ESD, so there isn’t such an urgent requirement for timeliness. If a critical event occurs within a few milliseconds or a dozen milliseconds and lasts only for that short time, then one can only blame their own bad luck.

Has everyone seen a dedicated cable or optical fiber connecting the main controller and the backup controller? This cable is used for switching between the main controller and the backup controller; without it, switching is not possible. In fact, it involves the watchdog signals of each of the primary and backup controllers. Under normal conditions, both controllers collect input data; when the watchdog signal from the primary controller is triggered, the backup controller takes over, and the output signal is switched from the primary controller to the backup controller

In DCS systems, CPU redundancy usually operates in a primary and backup configuration; when the primary card fails, operation automatically switches to the backup card. This switch-over is done automatically, but there is a certain time required for such a switch. If the timing of this manual switch-over is not managed properly, it can easily lead to system shutdown.

Switching takes time! Who was responsible for handling things during that period? Still, the time for this transition is the blank period

Since it is a disturbance-free switch, it certainly isn’t a period of inactivity; as for which component is responsible for data processing during that time, I’m not really sure

Two CPUs, one primary and one secondary. Use indicator lights to distinguish them separately. In actual operation, both CPUs perform calculations based on the configuration, but only the CPU on the control side outputs the actual results. It’s as if both CPUs are working, performing the same tasks; it’s not the case that one CPU stays idle just because it serves as a backup. There are many situations in which the main CPU switches to the backup CPU, such as when the network connection to the main CPU is lost, or when there is a hardware failure in the main CPU, etc. As for any differences in data or timing during switching, they do not exist; each manufacturer possesses synchronization techniques, and these are considered technical secrets of each company. It is not possible to tell you what techniques their CPUs use to eliminate such differences in data and timing. They will only tell you that our CPU switches without any disruption and does not affect the system. Now, CPU redundancy technology is quite widespread, and domestic manufacturers also perform well in this area. If there is suspicion that the system is experiencing disturbances during switching, this can be observed through trends. Check whether there are steps in the PID output, etc.