Problema de redundancia en DCS

Dicho de otra manera: todos los controladores redundantes cuentan con una luz indicadora de estado, cuya función es indicar si el CPU actual está en modo principal o en modo de respaldo. Lo que debería prestar atención es cómo lograr una sincronización de los datos sin pérdidas durante el cambio entre el servidor principal y el secundario, de modo que no se afecte todo el sistema.

El estado de funcionamiento normal es uno en el que el equipo está en uso, mientras que otro está en modo de reserva; esto se puede ver a través de las luces indicadoras del cartucho. Si el CPU en uso sufre una falla, la operación se transferirá al cartucho de reserva. También es posible cambiar el controlador desde el servidor en el transcurso de las actividades diarias. Si hay algo más que no entienda, puede seguir preguntando

¡Eso es exactamente lo que quiero decir! ¿La tarjeta principal transfiere datos a la tarjeta de respaldo en cada ciclo de operación? De lo contrario, ¿cómo se garantiza la consistencia de los datos al hacer el cambio?

Este mensaje fue editado por última vez por humker el 21-2-2016 a las 15:15. Los diferentes DCS tienen mecanismos similares, aunque existen algunas diferencias. Ambos controladores obtienen en tiempo real los datos provenientes de la bus de E/S. Solo el controlador principal puede enviar instrucciones. Durante el cambio de controlador principal a secundario, la mayoría de las instrucciones no se ejecutan, o bien se ejecutan en una especie de área de almacenamiento temporal. Es decir, cada controlador cuenta con un área de almacenamiento común; esta área suele estar “inactiva” en condiciones normales, pero se activa durante el cambio de controlador, con el fin de mantener la disponibilidad del DCS. Esto es importante durante un cambio forzado (o manual) de controlador. Entonces surge la pregunta: ¿qué pasa si el controlador principal falla de repente? En ese caso, el controlador secundario seguirá ejecutando las instrucciones hasta que asuma el papel del controlador principal. Y si se realiza el cambio manual entre el controlador principal y el secundario, entonces se envía una instrucción previamente al área de caché, indicándole que asuma las tareas del controlador principal durante el proceso de cambio, mientras se espera a que el controlador secundario esté listo para funcionar. Sin embargo, dado que el tiempo necesario para realizar el cambio entre los modos principal y de respaldo en la mayoría de los sistemas DCS es de unos pocos milisegundos, en la mayoría de las instalaciones, durante dicho proceso de cambio, el controlador deja de ejecutar las órdenes de salida y cesa cualquier operación lógica. Después de todo, DCS no es ESD; no se exigen tan altos niveles de eficacia. Si ocurre algún evento crítico durante unos pocos milisegundos o una decena de milisegundos, y ese evento dura solo unos instantes, entonces uno solo puede culpar a su mala suerte.

¿Han visto si existe un cable especial o de fibra óptica entre el controlador principal y el controlador de respaldo? Este cable sirve para realizar la conmutación entre el controlador principal y el de respaldo. Sin este cable, no es posible realizar dicha conmutación. En realidad, se trata de las señales de perro guardián de cada uno de los controladores principal y de respaldo. En condiciones normales, ambos controladores recopilan los datos de entrada. Cuando se activa la señal de perro guardián del controlador principal, el controlador de respaldo entra en funcionamiento, y las señales de salida pasan del controlador principal al controlador de respaldo

En los DCS, la redundancia de la CPU suele ser de un chip activo y otro de respaldo. Cuando el chip principal falla, se pasa automáticamente al chip de respaldo para que continúe funcionando. Este cambio se realiza de forma automática, pero debe haber un tiempo determinado para realizar dicho cambio. Si ese tiempo no se controla adecuadamente, puede causar que la planta deje de funcionar.

El cambio lleva tiempo ¿Quién se encargó de manejar todo eso durante ese tiempo? El tiempo de transición sigue siendo un período en blanco

Dado que se trata de un cambio sin interrupciones, seguramente no se trata de un período de tiempo en blanco. No puedo decir con certeza qué tarjeta será la encargada de procesar los datos durante ese tiempo

Dos CPUs, una principal y otra de respaldo. Se distinguen con luces indicadoras. En el funcionamiento real, ambos CPUs realizan cálculos según la configuración, pero solo el CPU del lado controlador genera el resultado final. Es como si ambos CPUs estuvieran trabajando, realizando la misma tarea. No es que uno de los CPUs funcione como respaldo y se quede inactivo. Hay muchas situaciones en las que el CPU principal pasa a ser el de respaldo: por ejemplo, cuando se interrumpe la conexión de red del CPU principal, o cuando hay un fallo en su hardware, etc. En cuanto a las diferencias de datos y de tiempo que se producen al hacer el cambio, estas no existen. Cada fabricante cuenta con técnicas de sincronización propias; esto constituye un secreto técnico de cada empresa. Por lo tanto, es imposible que te digan qué técnicas utilizan sus CPUs para compensar esas diferencias de datos y de tiempo. Solo te dirán que el cambio de CPU en nuestro sistema se hace de manera sin interrupciones, y que no afecta al sistema en absoluto. Actualmente, la tecnología de redundancia en los CPU ya está muy extendida, y los fabricantes nacionales también lo hacen bien. Si se sospecha que el sistema propio presenta perturbaciones al cambiar de modo, se puede observar mediante las tendencias. Verifique si en la salida del PID existen saltos, etc.

Todo esto lo sé, pero ¿qué se siente realmente al hacer el cambio? ？ ？

En resumen, al hacer el cambio no se siente nada, ni por parte de quien opera el sistema ni por parte de nadie más; ninguna operación se ve afectada. Solo habrá información de alerta relacionada en las alarmas del sistema, y nada más. Si los problemas como las fluctuaciones del sistema se deben a cambios en la CPU, entonces puede acudir al fabricante.