Patrones técnicos reales
Resume situaciones reales de boot project, runtime, persistentes, recetas, tarjetas, memorias, baterías, firmware, descargas parciales y equipos que vuelven con valores antiguos o incompletos.
Diagnóstico de automatización industrial
PLC pierde variables persistentes: separar persistentes, recetas, boot project, runtime, versión, memoria y restauración antes de concluir.
Cuando un PLC pierde variables persistentes, no basta con mirar una alarma o una señal aislada. La guía ayuda a ordenar evidencias, condiciones de aparición, documentación y límites sin convertir el caso en una instrucción operativa.
El error es mirar solo si el controlador está en RUN. En automatización, la continuidad también depende de datos vivos, runtime, archivos auxiliares y persistencia real.
Criterio de la guía
Por qué esta guía puede ayudarte.
Está escrita para ordenar pérdidas de datos retenidos y restauraciones parciales sin publicar proyectos, rutas internas, procedimientos de descarga ni parámetros de producción.
Separación antes que ajuste
Ayuda a separar programa cargado, proyecto guardado, datos retenidos, receta de proceso, runtime HMI, archivos auxiliares y evidencia de la versión realmente activa.
Límites claros
No da instrucciones para descargar proyectos, escribir persistentes, restaurar recetas, modificar runtime, alterar usuarios, tocar certificados ni validar una máquina tras un cambio.
Separación diagnóstica
La primera separación: programa, runtime y datos vivos no son lo mismo.
Una máquina puede parecer recuperada aunque falte una capa que el operador no ve hasta que cambia de receta, reinicia o entra en producción.
Boot project frente a proyecto abierto
Entra cuando el archivo disponible no demuestra qué se ejecuta tras reinicio, qué versión quedó activa o si el arranque carga lo esperado.
Persistentes y datos retenidos
Entra cuando contadores, calibraciones, offsets, parámetros de proceso o valores de aprendizaje vuelven a cero, a un valor viejo o a un estado incoherente.
Recetas y archivos auxiliares
Entra cuando la HMI abre, pero faltan recetas, ficheros, rutas, usuarios, históricos o datos que no viajaban con el programa principal.
Firmware, tarjeta y memoria
Entra cuando una sustitución o actualización permite arrancar, pero cambia compatibilidad, retención, comportamiento de memoria o relación con el hardware.
Cambio reciente documentado
Entra cuando la diferencia aparece justo después de mantenimiento, corte de tensión, batería, descarga, actualización, backup o recuperación desde soporte externo.
Evidencia mínima
Evidencia mínima útil antes de cerrar diagnóstico.
La evidencia útil une estado de arranque, versión activa, datos retenidos, recetas, pantalla, firmware y cambio temporal.
- Equipo afectado: PLC, HMI, IPC, CPU, tarjeta, memoria, runtime, servidor, remota o equipo sustituido.
- Momento de aparición: después de reinicio, corte, batería, descarga, actualización, restauración, sustitución o parada larga.
- Diferencia observable: receta ausente, valor retenido perdido, contador incoherente, calibración antigua, usuario ausente, ruta rota o archivo faltante.
- Relación entre proyecto guardado, programa activo, boot project, runtime HMI, firmware y copia usada para la recuperación.
- Capturas o mensajes de arranque, versiones, alarmas, estado de memoria, fotos de referencias y parte de intervención.
- Alcance funcional: qué modo funciona, qué receta falla, qué datos cambian tras reinicio y qué condición reproduce la pérdida.
Patrones de error
Errores que conviene evitar.
La pérdida de persistencia se agrava cuando se confunde una copia disponible con continuidad real de proceso.
Dar por bueno el RUN
El RUN puede indicar ejecución, pero no garantiza que recetas, persistentes, runtime y dependencias hayan vuelto al estado correcto.
No distinguir archivo de dato vivo
Un proyecto puede estar guardado y aun así no contener los valores reales que la máquina necesitaba para operar como antes.
Ignorar el origen de la copia
Fecha, responsable, equipo exacto, versión y alcance de la copia importan tanto como el nombre del archivo.
Cerrar sin prueba de reinicio
Si el problema aparece tras apagar o cambiar receta, una validación breve puede dejar pendiente justo la capa que falla.
Documentación
Documentación que conviene reunir sin exponer material sensible.
Dentro de Harcki, el caso puede continuar con proyectos, esquemas, capturas, alarmas, versiones, eventos, cambios, historial y documentación validada sin publicar material sensible en la web.
- Inventario de PLC, HMI, IPC, firmware, tarjetas, memoria, runtime y equipos relacionados.
- Relación entre proyecto, boot project, copia histórica, versión activa, cambios recientes y evidencia de verificación.
- Listado de recetas, persistentes, calibraciones, usuarios, certificados, archivos auxiliares, rutas e históricos que pueden quedar fuera de una copia parcial.
- Capturas de pantallas, mensajes, versiones, alarmas, valores incoherentes y fotos de placas sin publicar credenciales ni arquitectura sensible.
- Parte de intervención con qué se tocó, cuándo, por qué, qué quedó funcionando y qué no se pudo comprobar.
Seguridad
Límites de seguridad antes de intervenir.
Los datos retenidos pueden afectar movimiento, calidad, permisos y proceso. Ordenar la evidencia no autoriza cambios desde una guía pública.
- No tratar una pérdida de receta, persistente, calibración, usuario, certificado, runtime o archivo auxiliar como detalle menor si afecta a producción o seguridad.
- No da instrucciones para descargar proyectos, escribir persistentes, restaurar recetas, modificar runtime, alterar usuarios, tocar certificados ni validar una máquina tras un cambio.
- No asumir que una copia histórica es válida para una máquina actual sin contraste de versión, hardware y estado real.
- No usar una guía pública para justificar cambios sobre movimiento, seguridad, parámetros de proceso o continuidad de producción.
- Ante duda de versión, persistencia, safety, acceso seguro o comportamiento inesperado, parar y escalar por el canal responsable.
Harcki
Esta guía ordena el inicio; Harcki permite continuar el caso completo.
Esta guía ayuda a ordenar el diagnóstico de automatización sin publicar proyectos, credenciales, redes privadas ni instrucciones de intervención. Dentro de Harcki, el caso puede continuar con historial, evidencias, documentación validada, decisiones, contexto y memoria técnica compartida.
- 01Continuidad con contexto
Harcki puede vincular proyecto, runtime, persistentes, recetas, firmware y cambios para que el diagnóstico no dependa de un archivo suelto.
- 02Datos vivos como evidencia
Valores retenidos, capturas, alarmas, rutas y partes aportan valor cuando se conectan al equipo real y a la fecha correcta.
- 03Memoria reutilizable
Un patrón de restauración parcial puede ayudar a reconocer la familia del problema sin convertirlo en una receta operativa.
Normativa y límites
Normativa, fabricante y responsable técnico siguen mandando.
Harcki ayuda a ordenar el caso. Las decisiones críticas dependen del profesional responsable y del marco aplicable.
BOE - Real Decreto 1215/1997, equipos de trabajoMarco oficial sobre disposiciones mínimas de seguridad y salud para la utilización de equipos de trabajo.NIST SP 800-82 Rev. 3 - Guide to Operational Technology SecurityGuía pública sobre seguridad OT, sistemas de control industrial, topologías, riesgos y requisitos propios de entornos operativos.
Aviso de lanzamiento
Recibe el aviso cuando Harcki abra su primera fase.
Recibe el aviso para solicitar acceso a Harcki. Dentro de Harcki podrás continuar este diagnóstico con persistentes, recetas, boot project, runtime, documentación validada, evidencias, historial y memoria técnica con límites claros.