Planificación ante una CPU de PLC obsoleta: qué documentar primero

Oyes que una referencia de un PLC (autómata programable industrial) está obsoleta y el instinto es pedir algo, lo que sea, antes de que desaparezca. Retén ese impulso diez minutos. Comprueba el estado de obsolescencia contra la información publicada actual del fabricante, no contra la memoria ni el recuerdo de un compañero. Los fabricantes mueven las referencias por fases de ciclo de vida, y un estado que era actual en la última auditoría puede haber cambiado desde entonces.

Esquema del sistema ampliado

×

El camino fuerte pasa por la fuente publicada y entra en el registro con una fecha. Las afirmaciones débiles apuntan de vuelta a la misma fuente para confirmarse.

El estado también puede diferir por región y por canal. Una referencia que se comercializa como repuesto en un mercado puede estar agotada en otro, y un listado de distribuidor no es la misma prueba que un anuncio de ciclo de vida del fabricante. Registra qué fuente dijo qué, y cuándo. Una nota de estado sin fecha no se puede fiar un año después, porque la referencia puede haberse movido otra vez. Un listado de distribuidor puede estar actualizado y aun así no probar nada sobre la retirada, porque el stock de comercio y el estado de ciclo de vida son datos distintos.

La comprobación lleva minutos, y ancla todo el plan a una fuente fechada y citable. La fuente que registras hoy es la que vuelves a consultar cuando se revisa el plan, y por eso la cita pertenece al registro de planificación y no al buzón de alguien. Registra también la ruta de consulta, para que la siguiente persona pueda repetir la comprobación sin preguntar cómo la encontraste.

Los fabricantes suelen mover una referencia por fases con nombre: un periodo activo, un anuncio de retirada publicado, una fecha final de entrega y después una cola de soporte de duración variable. La fase en la que está tu referencia decide cuánto tiempo tiene el plan, así que registra el nombre de la fase y su fecha en lugar de solo la palabra obsoleto. Un anuncio fechado hace dos años y otro publicado el mes pasado describen márgenes de tiempo muy distintos para la misma referencia.

Registra la referencia exacta, la revisión y el estado del firmware mientras la unidad sigue en marcha. Una CPU obsoleta que funciona es en sí misma una prueba, y desaparece el día que falla. Cada dato que se podía leer de la unidad en marcha, como la versión de firmware que informa la herramienta de ingeniería, se vuelve irrecuperable después. Ese es el argumento más fuerte para documentar pronto y no cuando la máquina se para.

Esquema del sistema ampliado

×

Las tres capturas comparten una fecha límite: el día que la unidad falla. Las flechas muestran qué depende de que la unidad siga en marcha.

Anota si existe una copia de seguridad del proyecto y dónde está guardada, y después verifica que la copia se pueda leer en lugar de asumirlo. Sin una copia utilizable, cada ruta de recuperación se complica: un intercambio equivalente se convierte en una reconstrucción, y una migración en un esfuerzo de reprogramación. Ese dato pertenece al registro de planificación, porque cambia el coste y el tiempo de cada ruta de la lista.

Las fotos de la placa de características hechas ahora no cuestan nada y responden a preguntas que ningún listado de repuestos puede responder. Captura la composición del rack y la lista de dispositivos de red de la misma manera, porque la planificación de obsolescencia cubre todo lo ligado a la CPU, no solo la CPU. La misma foto también ancla las posiciones de ranura que citarás en cada comparación posterior.

Si máquinas o líneas hermanas comparten la referencia, captúralas también, aunque sea brevemente. Una línea por máquina, con su propia ubicación de armario y su estado, convierte el registro de planificación de una nota de unidad única en una vista de flota. Una vista de flota cambia la economía: un repuesto compartido se defiende mejor, una migración toca más unidades y la urgencia de un fallo cualquiera se mide contra el número de unidades que siguen funcionando.

Describe lo que hace la máquina y lo que un fallo de CPU detiene realmente: una máquina, una célula entera o una función con implicación de seguridad. Esta declaración de riesgo determina cuánta urgencia merece cada ruta de recuperación y quién tiene que participar en la decisión. Una CPU que para una de cinco líneas idénticas es un problema de planificación distinto al de una unidad de fuente única que detiene una sección entera de la planta.

Esquema del sistema ampliado

×

Dos entradas dimensionan el riesgo: el radio de impacto de un fallo y el número de vinculaciones que tocaría una migración.

Pregunta a quienes operan la máquina, no solo a quienes la mantienen, porque el paro se siente de forma distinta en cada lado. La vista de operación suele sacar a la luz soluciones provisionales y opciones de línea hermana que una vista puramente técnica pierde, y esas opciones cambian qué ruta merece la inversión. La vista de operación suele cambiar el plazo tanto como la lista de prioridades.

Captura el contexto circundante de la misma manera: la composición del rack, la lista de dispositivos de red y los proyectos HMI que referencian la CPU. El esfuerzo de migración crece con todo lo ligado a la CPU. Una comparación de sucesores para una CPU con tres proyectos conectados es un trabajo distinto al de una sin ninguno.

La implicación de seguridad pertenece a la declaración de riesgo en su propia línea. Una aplicación fail-safe cambia quién debe participar, qué rutas de recuperación son discutibles y cuánta revalidación lleva una migración. Trata esa línea como una instrucción de encaminamiento para el plan, no como un adjetivo. Una declaración de riesgo que lista la implicación de seguridad como un dato más entre varios esconde el único dato que reconfigura el resto. La estimación de esfuerzo es también lo que hace a la ruta de migración comparable con las demás.

Lista las rutas candidatas sin comprometerte con ninguna: conseguir una unidad equivalente, una pista de reparación o intercambio, y una migración a una familia actual. Cada ruta necesita pruebas distintas. El suministro se apoya en la referencia exacta y la revisión; la reparación se apoya en el historial de averías y las fotos; la migración se apoya en los registros de proyecto y de red. La lista de rutas te dice qué huecos cerrar antes que ningún otro.

Esquema del sistema ampliado

×

Cada ruta nombra sus propias necesidades de prueba. Los huecos, no la preferencia, deciden qué cerrar después.

Escribir las rutas expone opciones que nadie consideró, como tomar prestado runtime de una línea hermana mientras se consigue una unidad. Cada vinculación que captures ahora es un desconocido menos durante una migración futura. La lista también evita que un momento de presión reduzca las opciones al proveedor que devuelve antes la llamada.

Mantén la etapa de pruebas separada de la etapa de decisión. Una referencia documentada, una declaración de riesgo y una lista de rutas permiten que una decisión revisada ocurra más tarde sin repetir el trabajo del armario. También evitan que un apagón fuerce la decisión. Una lista de rutas revisada después de cada evento sigue siendo corta; una revisada años después llega como arqueología.

Dale a la lista de rutas una cadencia de revisión ligada a eventos reales y no solo al calendario. Revísala cuando cambie el estado de retirada, cuando falle una unidad hermana o cuando se dé el próximo servicio a la máquina, y registra qué cambió la revisión. Una lista de rutas que nunca se revisa se desactualiza en silencio, y la primera decisión forzada llega contra una lista que nadie ha comprobado en años.

El stock, el plazo de entrega y el coste de migración siguen siendo preguntas abiertas hasta que una fuente los confirme, así que mantén esos campos explícitos y fuera del plan las afirmaciones sin fecha. El registro debe declarar qué se sabe, qué se asume y qué aún necesita un presupuesto o una confirmación de proveedor. Una decisión revisada necesita esa separación. Cada campo puede llevar su propia fecha, así que la columna de lo conocido se puede comprobar línea a línea.

Esquema del sistema ampliado

×

La división en tres es lo que hace revisable el registro. Una decisión puede sopesarlo sin volver a deducir la historia.

El plan funciona exactamente como se pretende cuando la máquina falla y la respuesta parte de un registro completado en lugar de una improvisación. Esa es la prueba de todo el ejercicio: el apagón se convierte en el momento en que el plan rinde, no en el momento en que se fuerza una decisión. Esa diferencia solo se ve si el plan dice lo que pretendía lograr.

Un plan que marca sus propios huecos se puede entregar a otra persona. La siguiente persona ve qué campos son datos, cuáles son supuestos y qué rutas nunca se evaluaron. Esa calidad de entrega, más que cualquier dato aislado del registro, es lo que mantiene vivo el plan durante los años que una CPU obsoleta puede seguir funcionando.

• Verifica la obsolescencia contra publicaciones actuales del fabricante y registra la fuente y la fecha.
• Captura la referencia, el firmware, el estado de la copia de seguridad y el riesgo de la máquina mientras la unidad sigue en marcha.
• Lista las rutas de suministro, reparación o intercambio y migración, y cierra después los huecos de prueba que cada una necesita.
• El stock y el plazo de entrega siguen abiertos hasta que una fuente los confirme.

• la sección de PLC y CPU de Ardkor
• cómo comparar una referencia sucesora
• pruebas para reparar frente a sustituir