Comprobar una referencia sucesora de CPU de PLC antes de aceptarla

Una comprobación de sucesor compara dos unidades: la CPU de un PLC (autómata programable industrial) instalada en tu armario y la candidata que podría sustituirla. Cambiar una CPU por su sucesor suena simple hasta el primer desajuste de cableado. La comparación corre entre bloques de número de pedido y datos registrados, no entre nombres comerciales ni páginas de catálogo, y cada elemento se escribe como una pareja: lo que tiene la unidad instalada, lo que tiene el sucesor.

Esquema del sistema ampliado

×

Las dos unidades alimentan la misma lista de parejas. Una pareja sin fuente es un supuesto, no una comparación.

Las parejas escritas son el entregable. Una comparación que vive en la cabeza de alguien no se puede revisar, y una decisión de sucesor es justo el tipo de decisión que una segunda persona debería poder comprobar. Las parejas escritas sobreviven además a los cambios de personal, porque las máquinas que funcionan durante décadas sobreviven a las personas que las pusieron en marcha.

Esta sección recorre la comparación en el orden en que aparecen los riesgos: primero el hardware que cambia el trabajo del armario, después el firmware que condiciona el proyecto, y luego las vinculaciones que ninguna placa de características muestra. Una foto de cada unidad junto a su pareja escrita hace la comprobación aún más difícil de discutir. El orden de la lista es también el orden del coste: los cambios de hardware se ven primero, las vinculaciones afloran al final.

Sabe de dónde viene cada lado de la pareja. La unidad instalada la describe tu propio registro: fotos de la placa de características, una lectura de la herramienta de ingeniería y la posición en el rack. El sucesor lo describe la documentación del fabricante: el manual de equipo y los datos técnicos publicados. Una pareja que mezcla un dato medido con uno recordado es más débil de lo que parece, así que marca la fuente en cada línea y mantiene los dos lados distinguibles.

Empieza por los datos que cambian el trabajo del armario: la entrada de alimentación, la etapa de salidas integrada y los recuentos de E/S integradas deciden si el cableado existente sobrevive al cambio. Una CPU 1214C DC/DC/DC (6ES7214-1AG40-0XB0) entrega salidas de transistores de 24 V a sus filas de bornas. Su hermana AC/DC/relé conmuta cargas a través de relés sobre una entrada de alimentación distinta. Así que la comparación real corre entre bloques de número de pedido, no entre nombres comerciales.

Esquema del sistema ampliado

×

Cada línea de hardware termina en una estimación de trabajo, no en un veredicto. Es una comparación funcional, no un diagrama de cableado.

El montaje y la disposición de red pertenecen a la misma lista. Pasar de una CPU compacta 1214C con un puerto PROFINET a una CPU con dos puertos cambia lo que el armario puede conectar sin hardware extra. Pasar a un formato distinto, como una CPU ET 200SP 1510SP-1 PN (6ES7510-1SJ01-0AB0), cambia el riel, los adaptadores de bus y la familia de módulos alrededor de la CPU. Cada diferencia se convierte en trabajo real en el armario, así que cada una recibe una línea.

Una diferencia de montaje que parece menor en una hoja de datos se convierte en un problema de canal de cableado en la práctica. Por eso la lista de hardware va primero: decide si el cambio es una tarde de re-bornado o un cambio de riel y de familia de módulos, y ambas respuestas son desenlaces legítimos de una comparación honesta. Escribe la estimación de trabajo junto a la pareja, porque una estimación que queda en tu cabeza no se puede discutir. La estimación es también donde los dos desenlaces se separan: el re-bornado cabe en una ventana de mantenimiento, mientras que un cambio de riel pertenece a un proyecto.

Aquí es donde un emparejamiento de hardware plausible falla en silencio. Una CPU sucesora puede exigir una versión de firmware más nueva de la que el proyecto existente o el software de ingeniería instalado soporta. La unidad encaja, el cableado encaja, y el proyecto no carga o no compila. Registra el firmware instalado y el requisito del sucesor como datos separados, y contrasta ambos con la versión del proyecto antes de pedir cualquier unidad.

Esquema del sistema ampliado

×

La puerta solo se abre con datos citados en ambos lados. Una suposición de catálogo no cuenta como requisito.

Donde el fabricante publica datos de compatibilidad, cita la fuente publicada en el registro en lugar de fiarte de la semejanza de catálogo. Dos referencias que aparecen juntas en un catálogo no son una declaración de compatibilidad. Una ruta de migración que funcionó para un proyecto no es prueba para el siguiente. La cita también fecha la comprobación, lo que importa porque los datos de compatibilidad cambian a medida que se actualizan los productos.

Una afirmación de compatibilidad sin cita es exactamente el modo de fallo que esta comprobación existe para evitar. Una cita fechada da además al siguiente revisor un punto de partida cuando los datos cambien, lo que es probable, porque las familias sucesoras siguen moviéndose mientras tu proyecto instalado no. Las afirmaciones de compatibilidad envejecen rápido, así que una afirmación sin fecha es una afirmación que no puedes defender.

Registra la versión del software de ingeniería junto a las versiones de firmware, porque la compatibilidad corre en ambas direcciones. Un sucesor que exige una versión de proyecto que no puedes instalar está tan bloqueado como uno cuyo firmware no coincide, y el bloqueo aflora en el puesto de ingeniería y no en el armario. La versión del software instalado se puede leer mientras la máquina funciona, así que pertenece al registro antes de que empiece la comparación.

El programa de control no es la única vinculación que comprobar. El proyecto HMI referencia variables de la CPU. Los variadores de frecuencia y las E/S remotas conectados mantienen relaciones con ella. Una aplicación fail-safe añade a la lista el programa de seguridad y su configuración F. Cada vinculación es un lugar donde un sucesor que parece compatible puede seguir rompiendo la máquina.

Esquema del sistema ampliado

×

Cuatro familias de vinculaciones rodean la CPU. Las ramas son relaciones de proyecto, no cableado de red.

Enumera cada proyecto que habla con la unidad y confirma, para cada uno, cómo se actualizaría o migraría. La lista de dispositivos del registro de red es la lista de comprobación natural aquí, porque cada dispositivo conectado es una vinculación potencial. Cuenta los proyectos HMI por separado de los variadores, porque migran con herramientas distintas. El orden de enumeración sugiere además el orden de restauración, porque las dependencias entre vinculaciones afloran al listarlas.

Un sucesor aceptado sin estas comprobaciones puede parar una máquina por razones que ninguna placa de características muestra. Las vinculaciones son invisibles en la propia unidad; viven en los proyectos a su alrededor, y por eso la enumeración, no la intuición, es la prueba. La enumeración es también lo que te dice cuánto tardaría una restauración si se acepta el sucesor.

Construye la lista de vinculaciones desde el registro de red y no de memoria. La lista de dispositivos conectados, los nombres de los proyectos HMI y las referencias de los variadores ya están capturados en el contexto de red si el armario se documentó antes, y la enumeración es entonces casi burocracia. Donde falta el registro, anota el hueco en lugar de asumir que la vinculación no existe. Una lista vacía asumida es la versión de esta comprobación que falla.

Cierra la comparación con un veredicto explícito por elemento: emparejado, discrepante o sin resolver. Un sucesor con tres elementos emparejados y uno sin resolver no se acepta. Queda pendiente. El registro debe decir qué pruebas resolverían el elemento abierto, para que la decisión no pueda colarse apoyada en sus comprobaciones más fuertes. Pendiente es un desenlace normal, no un fallo del proceso.

Esquema del sistema ampliado

×

Los veredictos son por elemento, no por unidad. Una línea sin resolver mantiene toda la decisión en pendiente.

Mantén el registro de comparación separado de la decisión de pedido. El registro dice qué se comparó y qué se encontró. La decisión dice quién aprobó continuar y cuándo. Mantener ambos separados permite a un revisor distinguir después una discrepancia documentada de una no documentada, y entrega a la siguiente migración sobre la misma máquina un punto de partida que ya existe.

Trata el resultado como condicional hasta que el sucesor se haya contrastado con el proyecto real. Las comparaciones de hardware, firmware y proyecto estrechan el riesgo. No convierten un sucesor en un reemplazo directo demostrado. El registro honesto declara qué se verificó en el papel y qué aún tiene que demostrarse en la máquina, y esa distinción es justo lo que necesita una decisión revisada. Lo que queda por demostrar en la máquina es exactamente la lista que un plan de puesta en marcha debería absorber.

• Compara la entrada de alimentación, la etapa de salidas, las E/S integradas, el montaje y los puertos de red como parejas escritas.
• Contrasta los requisitos de firmware con las versiones del proyecto y del software de ingeniería, con fuentes citadas.
• Lista cada proyecto que habla con la CPU: HMI, variadores, E/S remotas y cualquier programa de seguridad.
• Un elemento sin resolver significa pendiente, no aceptado. Di qué pruebas lo cerrarían.

• nuestra cobertura de PLC y CPU
• la guía de planificación ante una CPU obsoleta
• por qué el contexto de red cambia una sustitución