🚀 Introducción: El último filtro antes de la operación
El protocolo de pruebas y puesta en marcha representa la fase crítica que separa un proyecto de automatización de una instalación productiva fiable. No se trata únicamente de "encender y ver si funciona", sino de un proceso metódico y documentado que garantiza que el sistema cumple con las especificaciones de diseño, las normativas de seguridad y las expectativas de rendimiento del cliente. Una ejecución deficiente de esta etapa puede traducirse en paradas no planificadas, riesgos para los operarios, daños materiales y costosos retrabajos. Por el contrario, un protocolo bien estructurado minimiza los riesgos, asegura una transición suave hacia la operación continua y sienta las bases para un mantenimiento eficaz.
En el entorno industrial actual, donde la integración de sistemas ciberfísicos es la norma, las pruebas deben abarcar tanto el mundo físico (sensores, actuadores, cableado) como el lógico (programas de PLC, comunicaciones industriales, interfaces HMI/SCADA). Este capítulo desglosa las fases de validación (FAT, SAT, operativa), los tipos de pruebas funcionales, la utilidad de los checklists y la definición de los criterios de aceptación que conducen al acta de entrega final. Todo ello, con ejemplos prácticos y referencias a las tecnologías que facilitan estas tareas.
Protocolos de Validación Industrial
La puesta en marcha de un sistema industrial no es un evento único, sino un proceso escalonado de validaciones. Cada etapa permite detectar y corregir desviaciones antes de que el coste de reparación sea crítico.
Diagrama de Bloques: Fases de Validación
Esquema de flujo: Las líneas discontinuas representan los lazos de retroalimentación para corrección de errores.
Durante las fases FAT y SAT, todas las desviaciones se recogen en una "Punch List". El sistema no puede avanzar a la siguiente fase hasta que los puntos críticos hayan sido subsanados y firmados por ambas partes.
Comparativa de Fases
| Fase | Entorno | Medio / Pruebas | Objetivo Principal |
|---|---|---|---|
| FAT | Taller del Integrador | Simulación de señales (I/O) y software. | Verificar funcionalidad según diseño. |
| SAT | Planta del Cliente | Conexión a servicios reales (Aire, Vapor, Red). | Verificar integración en el entorno final. |
| Operativa | Línea de Producción | Producción supervisada con producto real. | Validar capacidad y repetibilidad (Cp/Cpk). |
1.- Fases de validación del sistema
La validación se estructura en etapas progresivas que permiten detectar y corregir errores en el momento más adecuado, minimizando el impacto en costes y plazos. Cada fase tiene un objetivo y un entorno específico.
1.1.- Pruebas de aceptación en fábrica (FAT)
El Factory Acceptance Test (FAT) se realiza en las instalaciones del integrador o proveedor, antes de enviar el equipo a planta. En un entorno controlado, se monta el armario de control, se conecta la señalización y, mediante simuladores de campo (entradas digitales/analógicas, cargas ficticias), se verifica la lógica del programa, la respuesta de las protecciones y la comunicación con los sistemas superiores. El cliente puede presenciar estas pruebas y dar su conformidad parcial. Una correcta ejecución del FAT reduce drásticamente los problemas durante la instalación en campo.
Durante el FAT se revisan: cableado interno, etiquetado, parametrización de variadores, funcionamiento del HMI en modo simulación, y la documentación preliminar. Cualquier desviación respecto al diseño debe quedar registrada y corregida antes del embalaje.
1.2.- Pruebas de aceptación en sitio (SAT)
El Site Acceptance Test (SAT) se ejecuta una vez que el sistema está instalado físicamente en su ubicación definitiva y conectado a los servicios auxiliares (alimentación, aire comprimido, red de comunicaciones). El objetivo es verificar la correcta integración con el proceso real: sensores y actuadores reales, interferencias electromagnéticas, distancias de cableado, y comunicaciones con el SCADA o MES. Se prueban los enclavamientos con equipos existentes y se realizan las primeras maniobras en vacío (sin producto) para confirmar la secuencia lógica.
1.3.- Validación operativa
Superado el SAT, se inicia la validación operativa, también llamada marcha en vacío con producto simulado o producción supervisada. Durante un periodo acordado (por ejemplo, 72 horas), el sistema opera en condiciones normales de producción pero con supervisión intensiva. Se monitorizan rendimientos, tiempos de ciclo, consumos, y se evalúa la respuesta ante incidencias menores. Esta fase permite realizar ajustes finos de parámetros (PID, temporizaciones) y confirmar la estabilidad del sistema antes de la aceptación final.
2.- Pruebas funcionales y listas de verificación
Dentro de cada fase de validación, se ejecutan pruebas funcionales específicas que deben cubrir todos los requisitos del sistema. Estas pruebas se diseñan a partir de las especificaciones técnicas y los diagramas de funcionamiento (GRAFCET, diagramas de estados).
2.1.- Tipos de pruebas funcionales
- Arranques y paradas: Verificar secuencias de inicio y parada normal, incluyendo condiciones de seguridad (por ejemplo, imposibilidad de arrancar si una puerta está abierta).
- Respuesta a alarmas y eventos: Forzar fallos (rotura de sensor, sobrecarga motor) y comprobar que el sistema genera la alarma correcta, la muestra en HMI y activa las acciones predefinidas (parada, reducción de velocidad, etc.).
- Pruebas de comunicación: Verificar la integridad de los datos intercambiados entre PLCs, entre PLC y SCADA, y con periferia descentralizada (Profinet, EtherCAT).
- Simulación de fallos de red/alimentación: Cortar la comunicación o la alimentación y comprobar la recuperación automática o manual sin pérdida de datos críticos.
2.2.- Checklist de verificación
Un checklist bien diseñado es la herramienta que garantiza que no se omite ninguna comprobación. Debe ser específico para el proyecto y dividirse en secciones: mecánica, eléctrica, software, seguridad, documentación. Cada ítem debe tener espacio para indicar "Conforme/No conforme", observaciones y la firma del responsable. Ejemplos de ítems:
- Identificación de bornes y cables según norma UNE-EN 60445.
- Sentido de giro de motores comprobado.
- Señales de emergencia verificadas en todos los pulsadores.
- Niveles de presión neumática dentro de rango.
- Backup del programa del PLC guardado en dos ubicaciones.
Protocolo de Puesta en Marcha
Este documento debe ser cumplimentado por el técnico responsable durante la fase SAT o la Validación Operativa. Cada ítem requiere una evidencia física o medida técnica antes de ser marcado como conforme.
Utilice herramientas calibradas para las medidas. Cualquier resultado NOK debe generar automáticamente una entrada en la Punch List y bloquear el avance del protocolo hasta su resolución.
Checklist de Verificación Técnica
| Ítem de Inspección | Método de Prueba | Resultado | Observaciones | Firma |
|---|---|---|---|---|
| Continuidad de tierras | Medición con telurómetro en bornes principales y chasis. | ☐ OK ☐ NOK |
Valor esperado: < 1 Ohm. | ________________ |
| Prueba de enclavamientos | Simulación de apertura de puertas/resguardos en marcha. | ☐ OK ☐ NOK |
Verificar parada inmediata del motor. | ________________ |
| Resistencia de aislamiento | Megóhmetro a 500Vdc entre fases y tierra. | ☐ OK ☐ NOK |
Mínimo aceptable: 1000 Ω/V. | ________________ |
| Paradas de emergencia | Accionamiento físico de todas las setas locales. | ☐ OK ☐ NOK |
Comprobar rearme manual obligatorio. | ________________ |
| Sentido de giro (Motores) | Impulsos cortos (JOG) para verificar rotación. | ☐ OK ☐ NOK |
Cotejar con flecha indicadora. | ________________ |
Declaración de Conformidad
El abajo firmante certifica que los ensayos se han realizado conforme a la normativa vigente y que el sistema se encuentra en condiciones seguras para su operación supervisada.
La norma IEC 62890 para ciclo de vida de sistemas industriales está impulsando el uso de gemelos digitales durante las pruebas FAT. Se realizan pruebas en un entorno virtual idéntico al real, reduciendo el tiempo de validación en campo. También se extiende el uso de drones con cámaras térmicas para inspeccionar instalaciones durante el SAT, detectando puntos calientes en conexiones sin necesidad de contactar. En 2026, los protocolos de prueba deben incluir tests de ciberseguridad (penetration testing) en sistemas conectados.
Durante el SAT, una Raspberry Pi 4 con Node-RED y una base de datos InfluxDB puede actuar como registrador autónomo. Conectada a las salidas analógicas del PLC o a sensores adicionales (temperatura, corriente), registra continuamente las variables durante las 72h de validación operativa. Los datos se visualizan en paneles de Grafana, permitiendo al equipo de puesta en marcha detectar tendencias anómalas (derivas, picos) de forma temprana.
Para verificar rápidamente las entradas del PLC durante el SAT, se puede utilizar un Arduino Due programado como generador de señales. Con un shield de relés, puede simular pulsos de encoders o secuencias de sensores, permitiendo probar la lógica del programa sin necesidad de accionar los elementos físicos (útiles cuando el proceso no puede arrancarse aún). También se usa para medir tiempos de respuesta de actuadores mediante sensores de efecto Hall conectados al Arduino.
Una vez finalizadas las pruebas, es necesario generar un informe completo. Un script en Python que procesa los CSV descargados del PLC (conteniendo eventos y alarmas) y los combina con el checklist rellenado en una hoja de cálculo, puede producir automáticamente un PDF profesional con la librería reportlab. Esto ahorra horas de trabajo y garantiza que el informe incluye todos los anexos requeridos (gráficos, tablas).
3.- Criterios de aceptación y acta de fin de pruebas
El protocolo concluye con la verificación de que se han cumplido los criterios de aceptación, definidos en el pliego de condiciones del proyecto. Estos criterios deben ser medibles y objetivos. Algunos ejemplos típicos:
- Funcionales: Todas las secuencias del GRAFCET se han ejecutado correctamente.
- Rendimiento: El tiempo de ciclo no supera el especificado (ej. 12s ±5%).
- Seguridad: Todas las paradas de emergencia detienen el movimiento en menos de 500ms.
- Documentación: Se han entregado planos as-built, manuales y backup del software.
Cuando se cumplen, se procede a la firma del acta de aceptación (o certificado de puesta en marcha) por parte del cliente y el integrador. Esta fecha marca el inicio del periodo de garantía y la transferencia de responsabilidad. Es crucial que el acta recoja cualquier posible punch-list (lista de tareas menores pendientes) con plazos de resolución acordados.
INTEGRADOR
CLIENTE
Acta de Aceptación Final
Fecha: 17 de febrero de 2026
Ubicación: Planta Industrial Sector A
Proyecto: Automatización Línea 4
Responsable: Ing. Técnico Superior
Mediante el presente documento, las partes abajo firmantes confirman que el sistema ha sido sometido a las pruebas pertinentes y cumple con las especificaciones técnicas requeridas.
Listado de Hitos y Pruebas Superadas
| Fase | Hito de Validación | Estado | Fecha de Cierre |
|---|---|---|---|
| FAT | Simulación de lógica y seguridad en taller. | ✅ Superado | 12/01/2026 |
| SAT | Integración con servicios de planta y señales reales. | ✅ Superado | 05/02/2026 |
| Operativa | Prueba de rendimiento (Cpk > 1.33) en producción. | ✅ Superado | 16/02/2026 |
El sistema se entrega con toda la documentación técnica, esquemas eléctricos actualizados ("As-Built") y manuales de operación. Se acuerda un periodo de garantía de 12 meses a partir de la firma de este acta.
Pendiente únicamente: Entrega de repuestos de sensores inductivos (semana 8).
Por el Integrador:
Fdo: Responsable de Proyecto
Por el Cliente:
Fdo: Director de Planta / Operaciones
| Aspecto | FAT (Fábrica) | SAT (Campo) |
|---|---|---|
| Lugar | Taller del integrador | Planta del cliente |
| Entorno | Simulado (señales ficticias) | Real (conectado a proceso) |
| Objetivo | Verificar lógica, cableado interno, parametrización | Verificar integración, comunicaciones reales, interfaz con operario |
| Duración típica | 1-3 días | 3-10 días (dependiendo de la complejidad) |
| Plataforma | Aplicación en pruebas | Ventaja |
|---|---|---|
| Arduino | Generador de señales, inyector de fallos, medidor de tiempos | Respuesta en tiempo real, fácil de programar para tareas repetitivas |
| Raspberry Pi | Registro de datos, monitorización continua, generación de informes | Capacidad de almacenamiento, conectividad, ejecución de scripts complejos |
Contexto: Durante el FAT de una célula robotizada, todas las pruebas de software funcionan perfectamente con entradas simuladas. Sin embargo, en el SAT, al conectar los sensores reales, el robot no detecta correctamente la posición de las piezas.
Problema: El equipo de puesta en marcha debe identificar la causa más probable.
Pregunta: ¿Cuál es la acción diagnóstica inicial más adecuada?
Contexto: Durante la validación operativa de una línea de envasado, se utiliza una Raspberry Pi con Node-RED para registrar las temperaturas de los variadores. Los datos muestran picos de temperatura de 85°C en uno de ellos, aunque el variador no reporta alarma.
Problema: El equipo sospecha que el sensor de temperatura del variador podría no estar calibrado o que hay un problema de ventilación.
Pregunta: ¿Qué medida debería tomarse antes de continuar con la validación?
Contexto: Un script en Python procesa los logs del PLC durante las 72h de validación y detecta que la alarma "Nivel bajo de aceite" se activa 15 veces, pero siempre se desactiva a los 2 segundos.
Problema: Esta intermitencia podría indicar un falso contacto en el sensor o un problema real de lubricación.
Pregunta: ¿Qué análisis adicional debería hacer el script para ayudar al equipo?
📚 Recursos Técnicos y Normativos 2026
- ISO 230-1:2025 - Código de pruebas para máquinas herramienta (aplicable a automatismos)
- InfoPLC - Plantillas de protocolos FAT/SAT
- Siemens - Herramientas de comisionado digital
- Rockwell - Servicios de puesta en marcha
- PLCopen - Directrices para pruebas funcionales
- Raspberry Pi - Casos de uso en comisionado
- Arduino - Pruebas de campo
- Python - Librerías para adquisición de datos