FAT y SAT: diferencias y alcance de las pruebas de un sistema de automatización

FAT y SAT identifican pruebas de aceptación realizadas en etapas y entornos diferentes de un proyecto de automatización. Su utilidad depende de que las partes acuerden qué requisitos van a comprobar y qué evidencia permitirá aceptar el sistema. El nombre de la prueba no define por sí solo su alcance.

FAT: aceptación en fábrica

La prueba de aceptación en fábrica se realiza antes de la entrega en sitio, en el entorno acordado para esa etapa. Permite evaluar el sistema contra requisitos definidos con los equipos y las condiciones disponibles. Cuando se utilizan simulaciones, su alcance y sus límites deben quedar identificados.

Como propuesta de organización, conviene indicar versiones de programa, configuración y documentos utilizados. Una prueba realizada sobre una versión distinta de la que se entrega necesita una evaluación de los cambios; no debe suponerse que cubre automáticamente toda modificación posterior.

SAT: aceptación en sitio

La prueba de aceptación en sitio evalúa los requisitos acordados en el lugar de instalación. El plan debe distinguir qué se verificará con las condiciones reales disponibles y qué permanece pendiente. Una FAT satisfactoria no demuestra por sí sola que la instalación y la integración en sitio cumplan todo el alcance.

La síntesis pública de IEC 62381:2024 contempla FAT, FIT, SAT y SIT y vincula estas actividades con la especificación aplicable. También destaca el acuerdo de alcance y responsabilidades. Las pruebas de integración pueden constituir actividades diferenciadas; no deben darse por incluidas sin revisar el plan del proyecto.

Prepare criterios que se puedan comprobar

Antes de ejecutar una prueba, acuerde requisito, condición inicial, acción, resultado esperado y evidencia. Esta es una estructura documental original para el artículo, no una reproducción de las listas de IEC. La aplicación de requisitos detallados de la norma exige consultar el texto autorizado.

Ejemplo hipotético: se solicita que una pantalla presente una variable con la unidad acordada. El registro identifica la señal utilizada, la versión probada, la indicación esperada y el resultado observado. Ese ensayo no demuestra por sí solo exactitud del instrumento, desempeño de toda una secuencia ni cumplimiento de seguridad.

Registre desvíos y condiciones de cierre

Una prueba necesita resultados y responsables, no solamente casillas marcadas. Registre incidencias, correcciones, repetición necesaria y pendientes aceptados por las partes. Deje claro qué parte quedó comprobada y qué condición impidió completar un ensayo.

Las simulaciones y cambios que puedan afectar salidas, alarmas o equipos requieren condiciones seguras y autorización de la planta. El artículo explica planificación y evidencia de aceptación; no habilita la puesta en marcha ni sustituye la evaluación de funciones de seguridad.

La aceptación comienza con requisitos revisables

Una prueba necesita un requisito suficientemente claro para comparar lo esperado con lo observado. Expresiones como «el sistema debe funcionar bien» dejan abierta la interpretación. El proyecto debería convertir sus necesidades en condiciones comprobables y acordar qué evidencia servirá para cada una.

La síntesis pública de IEC 62381:2024 vincula las pruebas con la especificación aplicable. El desarrollo que sigue es una propuesta original de organización: identificar requisitos, preparar registros y distinguir los límites de cada etapa. No reproduce tablas de la norma ni atribuye cláusulas cuyo texto íntegro no se consultó.

Si una función todavía no está definida, registre el pendiente antes de preparar su aceptación. Una prueba no debería utilizarse para resolver informalmente decisiones de diseño que requieren acuerdo. El resultado esperado debe quedar establecido antes de observar el resultado real.

Qué información necesita el plan de FAT

El plan puede identificar sistema, componentes disponibles, versiones y documentos de referencia. También conviene señalar qué entradas o condiciones se simularán y cuáles se representarán con equipos reales. Esa separación permite interpretar los resultados con el alcance que efectivamente se evaluó.

Ejemplo hipotético: una función de visualización se prueba utilizando una señal simulada. El registro puede comprobar que la pantalla interpreta esa entrada según el requisito acordado. No demuestra por sí solo el comportamiento del sensor frente al proceso ni el estado de una instalación todavía no realizada.

La propuesta es vincular cada prueba con su requisito y declarar la condición representada. Si una parte no está disponible en esa etapa, indique qué evidencia queda pendiente y dónde se prevé obtenerla. No convierta una casilla «no probado» en aceptación implícita.

Qué cambia al preparar la SAT

La revisión en sitio debe reconocer el sistema realmente instalado y los requisitos que se evaluarán allí. Algunos elementos utilizados en fábrica pueden haberse sustituido o configurado de otra forma. Antes de utilizar resultados anteriores como antecedente, identifique esas diferencias.

El plan debería distinguir condiciones reales disponibles y condiciones que todavía necesitan simulación. Estar físicamente en planta no convierte todas las pruebas en evaluaciones del proceso completo. El registro tiene que conservar la condición utilizada y sus límites.

Para una planta en Paraguay, también conviene coordinar responsables, disponibilidad de equipos y ventanas autorizadas de trabajo. Estas decisiones organizativas no modifican el criterio técnico de aceptación. Si una restricción impide ejecutar una prueba, registre el impedimento y el tratamiento acordado.

Construya un registro que explique el resultado

Una estructura original puede incluir identificación de prueba, requisito, versión, condición inicial, acción prevista, resultado esperado, resultado observado y evidencia. Añada responsable y estado de cierre. La finalidad es que otra persona comprenda qué se comprobó sin depender de quien estuvo presente.

La acción debe describirse con el detalle necesario para revisar su alcance, sin sustituir procedimientos técnicos de intervención. Cuando la prueba pueda afectar el proceso, el plan debe remitir a las condiciones autorizadas y a la evaluación correspondiente. Este artículo no propone forzar salidas ni anular protecciones.

La evidencia puede ser un registro de variables, una captura identificada o un informe, según lo acordado. Un archivo sin fecha, versión o contexto puede resultar insuficiente para vincularlo a una prueba. La propuesta documental es conservar esa relación en el mismo registro o mediante una referencia inequívoca.

Ejemplo hipotético de aceptación de una pantalla

Supongamos que el requisito establece mostrar una variable de presión con unidad definida. La prueba identifica la entrada utilizada, el valor esperado y la pantalla examinada. También conserva la versión de configuración. Si se emplea una señal simulada, lo declara.

Si la lectura presenta la unidad equivocada, el registro describe la observación y remite a la corrección necesaria. Después de corregir, la repetición documenta la nueva versión y el resultado. La evidencia anterior se conserva como antecedente, en lugar de sustituirse por una captura final sin historia del desvío.

Ese ensayo tiene un alcance acotado. No acredita exactitud de la presión de proceso ni funcionamiento de todas las alarmas o secuencias asociadas. Si existen otros requisitos, necesitan sus pruebas o evidencias correspondientes. El ejemplo no representa un sistema o trabajo real de TECNICAT.

Pruebe comportamientos de falla solo dentro de un plan aprobado

NIST SP 800-82 Rev. 3 destaca que disponibilidad, tiempos y consecuencias físicas son consideraciones relevantes en OT. Al preparar aceptación, conviene revisar qué comportamientos ante falla se requieren y cómo se comprobarán sin introducir condiciones no evaluadas.

Como preguntas de planificación, pueden considerarse pérdida de comunicación, indisponibilidad de una interfaz o recuperación de un componente cuando formen parte del alcance. El plan debe definir qué funciones se esperan y qué condiciones permitirán comprobarlas. El artículo no indica desconectar equipos durante la operación.

Tampoco el nombre FAT o SAT acredita una función de seguridad. Si el proyecto incluye protecciones, sus requisitos y validación necesitan el tratamiento específico que corresponda. Las pruebas generales de aceptación no deben presentarse como sustitución de esa evaluación.

Gestione desvíos con criterio y responsables

Una observación debería identificar requisito afectado, resultado, evidencia y acción prevista. Las partes deben acordar qué impide aceptar y qué pendiente puede tener un tratamiento documentado. Este artículo no propone una clasificación universal ni autoriza cerrar incidencias por su nombre.

Si una corrección modifica una parte compartida por varias funciones, el responsable deberá evaluar qué otras pruebas requieren revisión o repetición. La cantidad necesaria depende del efecto del cambio. Repetir solo la pantalla donde se observó el problema puede dejar sin examinar otras relaciones afectadas.

Conserve la aprobación del cierre junto con la evidencia obtenida. «Corregido» describe una acción declarada; el registro de comprobación permite entender qué se evaluó después. Los pendientes aceptados deben conservar condiciones y responsables, sin ocultarse en un resultado global.

Vincule las pruebas con la versión entregada

La entrega debería identificar programa, configuraciones y documentos a los que corresponden los resultados. Si cambió la versión después de una prueba, registre el cambio y su evaluación. Un informe satisfactorio sobre una versión anterior requiere ese análisis antes de utilizarse como respaldo de la nueva.

También es útil separar aceptación técnica, pendientes contractuales y autorización de operación, según el acuerdo del proyecto. Una firma en un registro de ensayo tiene el significado que las partes hayan definido; no debe interpretarse automáticamente como autorización de puesta en marcha.

Para solicitar una revisión del alcance, reúna especificaciones, registros previstos, versiones y condiciones de ejecución. Esa información permite discutir qué puede comprobar cada etapa y qué permanece pendiente. La aceptación queda así asociada al sistema evaluado y a evidencia identificable.

Acuerde el alcance del proyecto

Para un sistema de una planta en Paraguay, presente requisitos, documentos y etapas previstas a Ingeniería y Proyectos y Automatización Industrial de TECNICAT. Puede ampliar su lectura en Ingeniería y proyectos. La aceptación debe quedar ligada al sistema y a la versión efectivamente probados.

Fuentes técnicas

• IEC — International Electrotechnical Commission. IEC 62381:2024 — Automation systems in the process industry — FAT, SAT and SIT. Edición 3.0, publicada el 30 de julio de 2024. Modelo/alcance: Sin modelo; aceptación de sistemas. Apartado: Resumen público y Product detail; no se accedió al texto íntegro de pago. Consulta: 2026-10-02.
• NIST — National Institute of Standards and Technology. Guide to Operational Technology (OT) Security — NIST SP 800-82 Rev. 3. Edición final, septiembre de 2023; Rev. 4 en borrador público al consultar, no sustituye esta final. Modelo/alcance: Sin modelo; arquitectura OT. Apartado: §2.3, pp. 10–12; §2.3.2 SCADA Systems; §2.3.4 PLC-Based Topologies; glosario HMI/PLC; §6.2.4.2–6.2.4.3, pp. 111–113 (PDF 128–130), configuración y respaldos. Consulta: 2026-10-02.