Embedded Files
Pruebas FAT - SAT - CAT
Pruebas FAT - SAT - CAT
Validaste el equipo en fábrica. ¿Pero validaste el sistema en planta?
Validaste el equipo en fábrica. ¿Pero validaste el sistema en planta?
La mayoría de los proyectos industriales fallan en la integración, no en el hardware. Y eso suele evidenciarse — muchas veces tarde — durante la puesta en marcha (PEM).
Tras más de dos décadas en sistemas de control en minería, he visto equipos perfectos en fábrica generar retrasos, disputas y ajustes no presupuestados en sitio. La causa es recurrente: confundir la aceptación del equipo con la del sistema.
FAT y SAT no son lo mismo
Pruebas FAT
La FAT (Factory Acceptence Test), verifica el cumplimiento contractual en condiciones controladas: interlocks, HMI/SCADA, I/O y potencia.
Pruebas SAT
La SAT (Site Acceptence Test), enfrenta el sistema a la realidad: ruido eléctrico, variaciones de red, integración con sistemas existentes y condiciones no simuladas.
Tratarlas como equivalentes es un riesgo contractual crítico.
Lo que debería cubrir un plan de pruebas. No basta con abrir y cerrar válvulas. Un buen plan incluye:
Fallos de comunicación HMI–RTU y tiempos reales de alarma
Respuesta a cortes de energía y reinicio automático
Validación de interlocks cableados vs. software (LOCAL vs. REMOTO)
Medición de latencia en redes industriales críticas
Desde 2024, la ciberseguridad ya no es opcional. Con el aumento de ataques a sistemas industriales, IEC 62443 y pruebas Cyber FAT/SAT (vulnerabilidades y pentesting) son parte del estándar en proyectos serios. Este es el momento adecuado, antes de producción.
El documento más subestimado: Punch List
No es una lista informal, sino una herramienta de control que registra cada desviación con responsable y prioridad.
Clave: debe iniciarse en pre-diseño, no en comisionamiento.
La lección
El éxito no es que el equipo funcione, sino que funcione integrado en la planta, con trazabilidad, desviaciones documentadas y base para mantenimiento.
Si no está definido en el protocolo — qué se acepta, cómo y con qué criterio — es un riesgo contractual.
Pruebas CAT
Había una ingeniería aprobada. Un FAT firmado. Confianza total.
Y aun así, el sistema falló — en el primer evento operacional real, semanas después del SAT.
La pregunta correcta no era qué salió mal en planta. Era qué no se validó antes.
En proyectos de DCS / SCADA / PLC, el foco está en el FAT y el SAT. Pero hay una etapa que se ejecuta mal en casi todos los proyectos: el CAT.
El CAT (Configuration Acceptance Test), no verifica hardware ni señales reales. Valida algo más profundo: que la lógica del sistema esté correctamente ensamblada.
Lógica de control — secuencias, interlocks, permissives.
Estados operacionales — Auto, Manual, Falla, Mantenimiento.
Filosofía de alarmas — prioridades, delays, coherencia.
Navegación HMI — que ayude al operador a decidir, no a perderse.
Eso no lo verifica ningún FAT. Solo lo valida el CAT.
El problema: la mayoría de los CAT que he visto en terreno son checklists.
Sin escenarios operacionales. Sin condiciones de borde. Sin nadie preguntando qué pasa si el interlock A falla mientras el estado B está activo.
Solo señales revisadas y un sello de "conforme".
Resultado: sistemas que pasan FAT ✔ — sistemas que fallan en el primer evento real ✗.
No por hardware. Por una configuración que nadie validó en serio.
Cuando el sistema falla en operación, el instinto es buscar el problema en planta.
Pero nació mucho antes. En un CAT que duró la mitad del tiempo asignado y no ejecutó un solo escenario de estrés.
El CAT no es un trámite. Es donde los errores estructurales cuestan poco.
Antes de que cuesten paradas, tiempo... y credibilidad.
¿Cómo gestionan la transición FAT–SAT en sus proyectos? ¿Dónde suelen aparecer los mayores problemas?
👉 ¿Tu CAT valida de verdad — o solo documenta que alguien revisó algo?
Si necesitas apoyo para lograr una buena identificación, háblanos estamos disponibles para ayudarte.
gerencia@decordoba.cl
Page updated
Report abuse