Un proyecto de automatización se entrega con un juego de documentos que va de la especificación al as built: alcance, P&ID, lista de E/S, planos eléctricos, descripción funcional, programas con versión, protocolos FAT y SAT, manuales y registro de cambios. Esa documentación es lo que permite operar, mantener y auditar la planta.
Para qué sirve la documentación
Un sistema de automatización que funciona pero no está documentado es un riesgo. Quien lo opera no sabe por qué una secuencia se detiene, quien lo mantiene no encuentra el sensor en el plano, el nuevo integrador reescribe lo que ya existía y el auditor no puede comprobar nada. La documentación cumple cuatro funciones: operar con seguridad, mantener con rapidez, modificar con control y demostrar el cumplimiento ante un cliente o un auditor.
Los proveedores de una cadena de suministro cada vez más piden evidencia completa por proyecto: qué se diseñó, quién lo aprobó, qué se probó y con qué resultado. Esa trazabilidad se construye durante el proyecto; reconstruirla al final es caro y rara vez fiel.
El juego de documentos, por fase
| Fase | Documento | Contenido esencial |
|---|---|---|
| Definición | Alcance y especificación de requisitos | Qué hace el sistema, límites de suministro, normas, ambiente |
| Definición | Matriz de responsabilidades | Quién entrega, aprueba y prueba cada parte |
| Ingeniería básica | P&ID y diagramas de bloques | Equipos, lazos, instrumentos, enclavamientos |
| Ingeniería básica | Unifilar y balance de cargas | Alimentación, protecciones, potencias |
| Ingeniería de detalle | Lista de E/S y de instrumentos | Cada señal con tag, tipo, rango, ubicación y descripción |
| Ingeniería de detalle | Planos eléctricos de potencia y control | Esquemas, borneras, cableado, numeración |
| Ingeniería de detalle | Arquitectura de red y plan de direcciones | Switches, zonas, direcciones, protocolos |
| Ingeniería de detalle | Descripción funcional | Modos, secuencias, alarmas, estados seguros |
| Software | Programas fuente y configuraciones | Versión, comentarios, lista de tags, parámetros de variadores |
| Pruebas | Protocolos y registros FAT y SAT | Casos, criterios de aceptación y resultados firmados |
| Entrega | As built y manuales | Planos finales, manuales de operación y mantenimiento |
| Operación | Registro de cambios y respaldos | Qué cambió, quién lo aprobó, copia versionada |
La gestión de documentos requiere además un esquema de codificación y de revisión: cada documento con código, título, revisión, fecha, autor y aprobador, y una lista maestra que indique cuál es la revisión vigente. Los cambios de obra se registran con un formato de solicitud de cambio, que se aprueba antes de ejecutarlo y se cierra al actualizar todos los documentos afectados. Sin ese control, coexisten tres versiones del mismo plano y nadie sabe cuál manda.
Los símbolos y la identificación de los planos siguen la convención adoptada para el proyecto. La guía de diagramas de unifilar de una planta muestra cómo se presenta la parte de potencia.
La lista de E/S como columna vertebral
La lista de entradas y salidas es el documento que más se reutiliza. De ella salen las tarjetas del PLC, los planos de borneras, las pantallas del SCADA, los puntos a probar en el FAT y el SAT y la lista de alarmas. Cada fila lleva como mínimo: etiqueta (tag) única, descripción, tipo de señal, rango y unidad, ubicación física, tablero y borne, equipo al que pertenece, estado seguro ante falla y comentarios. Una convención de nombres coherente evita traducciones entre planos y programa.
Además de la lista, la numeración de borneras y de cables debe ser única y trazable: un cable lleva un identificador que aparece en el plano de cada extremo, en la lista de cables y en la etiqueta física. Cuando una señal falla a las tres de la mañana, quien llega al tablero debe poder seguirla desde el sensor hasta la tarjeta sin abrir el programa.
Una práctica útil es que el nombre del tag sea el mismo en el plano, en la lista, en el PLC y en el SCADA. Cuando cambia uno, cambian todos, y por eso se maneja bajo control de cambios.
Descripción funcional: antes de programar
Es el documento que más discusiones evita si se hace bien. Redacta, para cada unidad o equipo:
- Modos de operación: manual, automático, local, remoto, mantenimiento.
- Condiciones de arranque y de parada normal y de emergencia.
- Secuencias paso a paso, con tiempos de supervisión.
- Enclavamientos y permisivos, indicando cuáles son de seguridad.
- Alarmas, con su prioridad y la acción esperada del operador.
- Comportamiento ante falla de energía, de comunicación o de un instrumento.
Un buen test: dos ingenieros que no participaron en la redacción deben llegar a la misma lógica leyéndola. Las secuencias complejas se complementan con un diagrama de estados o un diagrama funcional. Para las funciones de seguridad hay una documentación adicional, explicada en la guía de seguridad funcional, SIL y PL.
Pruebas de aceptación: FAT y SAT
Los protocolos se escriben antes de la prueba y se acuerdan con el cliente. Cada caso lleva: objetivo, condición inicial, acción, resultado esperado y espacio para el resultado real, la firma y la fecha. Las desviaciones se registran con su acción correctiva y su cierre.
La FAT prueba lo que se puede probar sin la planta: lógica con señales simuladas, comunicaciones, pantallas, alarmas y fallos forzados. La SAT prueba la instalación real: cada lazo desde el campo, el sentido de giro, los límites de carrera, los tiempos reales y la integración con otros sistemas. Las guías de normas para puesta en servicio, FAT y SAT y de niveles de comisionamiento amplían el marco, y el dossier de puesta en servicio describe cómo se arma el paquete final. Si hay requisitos de ciberseguridad, se añaden las pruebas de ciberseguridad en FAT y SAT.
As built, manuales y entrega
El as built refleja lo realmente instalado y programado, no lo proyectado. Incluye planos corregidos, lista de E/S final, programas con la versión cargada en cada controlador, configuraciones de variadores, relés y switches, y el plan de direcciones. A eso se agregan manuales de operación y de mantenimiento, listas de repuestos recomendados, certificados de calibración y de pruebas, y las garantías.
El formato debe ser editable y legible a largo plazo: el programa fuente en el formato del fabricante, los planos en un formato editable además del PDF, y una copia del software de configuración con la versión usada.
Ejemplo numérico ilustrativo
Datos inventados para mostrar el efecto de una documentación coherente.
Una línea de procesamiento tiene 420 señales: 180 entradas digitales, 120 salidas digitales, 80 entradas analógicas y 40 salidas analógicas. Si el FAT verifica cada señal en promedio en 3 minutos, son 21 horas de prueba. En el SAT, con la comprobación en campo, 8 minutos por señal sumarían 56 horas. Con una lista de E/S depurada y el protocolo generado de ella, la duración se acerca a esas cifras. Sin una lista confiable, cada diferencia entre plano y programa se resuelve en el sitio, con tiempos de varios minutos extra por señal en un 10 % de los puntos, que significan unas 6 a 8 horas adicionales de equipo parado.
La documentación se paga en la puesta en servicio.
Gestión de cambios después de la entrega
La documentación se degrada si no se mantiene. Cada modificación posterior, como una señal nueva, un cambio de ajuste o un reemplazo de equipo, sigue el mismo ciclo: solicitud, evaluación de impacto, aprobación, ejecución, prueba y actualización de planos, lista de E/S y programas. Se conserva una copia versionada de cada programa y configuración, con la fecha y el responsable, y se prueba periódicamente que el respaldo se puede restaurar. Esa disciplina es lo que permite volver a un estado conocido después de una falla o de un cambio equivocado.
Errores frecuentes
- Programar antes de acordar la descripción funcional.
- Cambios en obra que no vuelven a los planos ni a la lista de E/S.
- Entregar solo el programa compilado, sin fuente ni comentarios.
- Varias versiones del programa sin saber cuál está en el controlador.
- Protocolos de prueba redactados el mismo día de la prueba.
- Resultados sin firma, sin fecha o sin referencia al equipo de medida usado.
- Falta de respaldos de configuraciones de variadores, relés y switches.
- Documentos sin código ni revisión, imposibles de auditar.
Lista de verificación de entrega
- Alcance y requisitos firmados.
- P&ID, unifilares y planos eléctricos con revisión final.
- Lista de E/S e instrumentos consistente con planos y programa.
- Arquitectura y plan de direcciones de red.
- Descripción funcional aprobada.
- Programas fuente y configuraciones con versión, y copia en un lugar seguro.
- Protocolos FAT y SAT firmados, con desviaciones cerradas.
- As built, manuales y listas de repuestos.
- Capacitación registrada.
- Procedimiento de gestión de cambios y respaldos entregado.
Cómo apoyamos
Elaboramos la ingeniería y la documentación dentro de nuestro servicio de diseño de ingeniería y estudios, y preparamos y ejecutamos los protocolos en pruebas y puesta en servicio, con un paquete trazable para auditorías de clientes. Le cotizamos según el alcance de su proyecto. Cómo evaluar si un proyecto conviene, con valor presente y relación beneficio-costo, está en análisis costo-beneficio de un proyecto AMI.
Guías relacionadas
- Dossier de puesta en servicio
- Normas para puesta en servicio, FAT y SAT
- Niveles de comisionamiento
- Diagrama unifilar de una planta
- Relé sin ajustes documentados
- PLC y automatización de subestaciones
- Diagramas eléctricos industriales: símbolos IEC y NEMA
- Diagramas P&ID e identificación de instrumentos
- Mantenimiento predictivo de motores y variadores
- Análisis costo-beneficio de un proyecto AMI
Referencias
- IEC 61131-3, Programmable controllers: programming languages (organización del programa).
- ISA-5.1, Instrumentation symbols and identification (identificación de lazos y tags).
- IEC 61082 e IEC 81346, preparación de documentos y designación de referencia (visión general).
- Práctica común de FAT y SAT en proyectos de automatización.
Preguntas frecuentes
¿Qué documento define lo que el sistema debe hacer?
La descripción funcional, que redacta el comportamiento del control: modos de operación, secuencias, enclavamientos, alarmas y estados seguros. Debe acordarse antes de programar, porque es la base de las pruebas y de la aceptación.
¿Qué diferencia hay entre FAT y SAT?
La prueba de aceptación en fábrica (FAT) se hace antes del envío, con el sistema montado y simulando el proceso. La prueba de aceptación en sitio (SAT) se hace ya instalado, con el proceso real y las interfaces definitivas. Ambas siguen un protocolo aprobado de antemano.
¿Cuándo se entrega el as built?
Al cerrar el proyecto, después de la puesta en servicio, con todos los cambios hechos en obra reflejados en planos, lista de E/S, programas y configuraciones. Entregar el diseño original como si fuera el as built es una causa frecuente de problemas posteriores.
¿Quién es dueño del código del PLC?
Lo debe definir el contrato. Conviene exigir la entrega del programa fuente, con comentarios, versión y las claves o permisos necesarios, y no solo del programa compilado. Sin esos elementos el propietario depende del integrador para cualquier modificación.