Qué registrar antes de recuperar una CPU de seguridad del PLC

Una CPU fail-safe de un PLC (autómata programable industrial), normalmente escrita F-CPU, ejecuta dos programas a la vez: el programa de control normal y un programa de seguridad separado que el runtime del fabricante mantiene aislado de él. Sacas una CPU, lees la familia y el número, y todo parece estándar. Después la máquina se niega a aceptar un programa de seguridad. Esa es la trampa fail-safe.

Esquema del sistema ampliado

×

La separación es funcional, no física: los dos programas se ejecutan en la misma unidad, pero el lado de seguridad queda aislado por el runtime.

Siemens distribuye variantes fail-safe dentro de las familias S7-1200F y S7-1500F, y la marca F aparece en el número de pedido y en la etiqueta de la carcasa. El hardware no anuncia la diferencia por sí solo, así que la marca es lo primero que hay que comprobar y lo primero que hay que registrar. Un carácter extra en el número de pedido separa una unidad que acepta un proyecto de seguridad de otra que no puede.

Los dos programas permanecen separados por diseño. El programa de seguridad se ejecuta bajo sus propias reglas de runtime, y el programa estándar no puede modificarlo. Ese aislamiento es la razón por la que una CPU estándar no puede simplemente cargarse con un proyecto de seguridad, y por la que la condición F da forma a cada pregunta de recuperación que viene después.

Puedes detectar la marca F sin abrir nada. En los números de pedido de Siemens la capacidad fail-safe aparece en la propia referencia, y la etiqueta de la carcasa lleva también la marca. La herramienta de ingeniería la muestra igualmente, una vez que la unidad está en la red. Lo que no puedes hacer es deducirla del comportamiento de la máquina, porque una CPU estándar puede ejecutar el mismo proceso hasta el momento en que alguien intenta cargar un proyecto de seguridad. La marca es un dato impreso, así que trátala como tal y léela.

La marca cambia lo que una referencia equivalente tiene que incluir. Dos CPU que comparten el número base pueden diferir en si aceptan un programa de seguridad, y esa capacidad está ligada a la unidad concreta y a su configuración. Por eso la condición F pertenece a la primera línea de tu registro, antes de la revisión o de las fotos.

Esquema del sistema ampliado

×

El número base abre la puerta, pero el registro F decide qué puede pasar por ella. Es una comprobación funcional, no de cableado.

El programa de seguridad y su configuración F, los ajustes que ligan la función de seguridad a la unidad, son parte de la identidad de una segunda manera. Una unidad con el número de pedido correcto puede seguir negándose a ejecutar un proyecto de seguridad si la configuración no coincide con lo que el proyecto espera. Ningún valor de la placa de características demuestra que una sustitución aceptará el proyecto. Esa prueba hay que registrarla, nunca asumirla. La lista de módulos F protege además la revisión de una segunda trampa: una CPU de sustitución que parece completa en el papel mientras el conjunto configurado a su alrededor sigue sin registrarse.

Los módulos de E/S fail-safe conectados, los módulos F, pertenecen al mismo conjunto configurado. Una F-CPU y sus F-IO se configuran juntas en el proyecto, y un cambio en cualquier miembro de ese conjunto puede exigir revalidar el programa de seguridad. Así que la pregunta de emparejamiento nunca se detiene en la CPU; se extiende a cada módulo F a su alrededor. La distinción es invisible desde fuera del armario, y por eso la marca impresa lleva tanto peso.

Para una solicitud, la consecuencia práctica es el alcance. Di que la CPU trabaja en una aplicación fail-safe incluso cuando tu pregunta va solo sobre la CPU, porque el revisor no puede saber si los módulos F a su alrededor forman parte de la pregunta hasta que lo digas. Un revisor que se entera de los módulos F a mitad de la revisión tiene que reabrir la admisión, y las referencias de módulos F que listaste antes se convierten en la razón de que la revisión no tuviera que hacerlo.

Captura el número de pedido completo con su marca F, la versión del firmware tal como está impresa y la generación de hardware. Fotografía la placa de características y cualquier rotulado de seguridad del armario, incluidas señales o documentos que nombren la función de seguridad que sirve la CPU. Las fotos conservan el texto exacto, y las etiquetas de seguridad parafraseadas pierden su sentido en un registro. Dos fuentes de etiqueta para la misma unidad son normales, y cada una fotografiada es un detalle menos reconstruido de memoria.

Esquema del sistema ampliado

×

Cuatro grupos de registro alimentan el paquete. Cada uno responde a una pregunta que el revisor tendría que hacer dos veces.

Lista los módulos F conectados con sus propias referencias. Nombra cada módulo F, su posición de ranura o estación y su número de pedido completo, de la misma manera en que registraste la propia CPU. Dónde están los módulos importa, porque la pregunta de revalidación sigue al cableado.

Si existe una copia de seguridad del proyecto, registra la versión del programa de seguridad y dónde está guardada, junto a la versión del programa estándar. Las dos versiones pueden diferir, y un revisor necesita ambas para juzgar qué ejecutaría realmente una unidad restaurada. Si no existe copia, escribe ese hecho en el registro, porque cambia cada ruta de recuperación que venga después. La ubicación de almacenamiento importa tanto como la versión; una copia que nadie encuentra se comporta como una copia perdida.

El rotulado de seguridad merece una pasada deliberada. Busca señales de advertencia en la puerta del armario, bolsas de documentación y cualquier placa que nombre la función de seguridad que sirve la CPU, y fotografía lo que encuentres. Esos elementos llevan el texto con el que trabajan los revisores de seguridad, y una paráfrasis en tus notas no puede reproducirlo. Si nada está rotulado, registra esa ausencia como un hecho, porque le dice al revisor cuánto del contexto de seguridad está sin documentar.

Fecha cada entrada y mantén el paquete factual. Las opiniones sobre qué causó probablemente una avería, o sobre lo que un proveedor podría tener en el estante, no pertenecen junto a los datos medidos. La fecha es lo que convierte una afirmación en un registro, porque un dato sin fecha no se puede contrastar con nada.

Esquema del sistema ampliado

×

La confianza viene de tres campos por línea. Los huecos declarados son parte de la prueba, no un fallo del registro.

Un paquete fechado y con fuentes permite a la siguiente persona verificar cada línea en lugar de deducirla otra vez. Cada valor debe llevar su fuente: placa de características, herramienta de ingeniería o archivo de proyecto. Cuando dos fuentes discrepan, registra ambas lecturas en lugar de promediarlas, y deja que la revisión resuelva el conflicto.

La misma disciplina se aplica a los huecos. Un estado de firmware desconocido o una copia de seguridad ausente son datos sobre el registro, y declararlos abiertamente es una prueba más fuerte que adivinar. Los huecos también le dicen al revisor qué pasos de identificación repetir primero.

Cuando dos fuentes discrepan, registra ambas lecturas con sus fuentes y fechas, y deja el juicio a la revisión. Un valor de firmware de la herramienta de ingeniería y otro distinto de una lista de repuestos es un hallazgo normal en una planta que envejece, y elegir uno en silencio convierte tu registro en una afirmación. Dos lecturas registradas son pruebas; una lectura elegida es una opinión. El revisor resuelve el conflicto una vez, con las fuentes delante, en lugar de descubrirlo dos veces.

Una CPU fail-safe no es solo una cuestión de intercambio equivalente. El trabajo de seguridad pertenece al personal cualificado bajo las normas que se aplican a la máquina, y ninguna entrada de catálogo, hoja de datos ni afirmación de proveedor cambia eso. El paquete de pruebas es una entrada para ese trabajo, no un sustituto.

Esquema del sistema ampliado

×

El paquete termina donde empieza la cualificación de seguridad. Las flechas muestran la entrega de preguntas, no la entrega del trabajo.

Registra lo que sabes y declara lo que no sabes, y luego deriva las preguntas del programa de seguridad a las personas responsables de la máquina. Un registro que lista sus huecos abiertamente resulta más útil a un revisor que uno que los tapa. Donde exista un hueco, di quién lo cerraría normalmente y qué herramienta necesitaría.

Trata la compatibilidad y los resultados como preguntas abiertas en la solicitud. Si una sustitución concreta acepta el proyecto de seguridad existente, y si una reparación puede conservar la configuración F, son decisiones de la revisión con las personas responsables, apoyadas en tus pruebas. La incertidumbre aquí es normal, y declararla es lo que mantiene honesta una recuperación de seguridad.

• Captura el número de pedido con su marca F, la versión del firmware y la generación de hardware.
• Lista cada módulo de E/S fail-safe conectado con su propia referencia y posición.
• Registra las dos versiones de programa, o declara con claridad que no existe copia de seguridad.
• El trabajo del programa de seguridad corresponde al personal cualificado. Anota ese límite en la solicitud.

• la página de categoría de las CPU de PLC
• la guía de los campos de la placa de características
• el paquete de pruebas para una solicitud de PLC