Elige cómo quieres explorar esta guía:
Recepción y Análisis de Documentación
Fase 1 de 10 — El punto de partida de todo proyecto
Todo proyecto de automatización comienza con la recepción de la documentación de ingeniería. El ingeniero de automatización debe analizar, comprender y validar estos documentos antes de dar un solo paso. Es el momento de hacer preguntas, detectar incoherencias y establecer el alcance real del trabajo.
Inputs
- FDS (Functional Design Specification) o URS
- P&ID (Piping & Instrumentation Diagram)
- Listado de equipos con especificaciones
- Listado de I/O preliminar
- Narrativas de proceso y diagramas de flujo
- Cause & Effect Matrix (si existe)
Outputs
- Documentación revisada y comentada
- Lista de RFIs (Requests for Information)
- Estimación inicial de alcance y horas
- Matriz de trazabilidad requisitos
- Informe de viabilidad técnica
Consejos y Buenas Prácticas
- Solicita siempre la última revisión de cada documento — verifica el control de revisiones.
- Compara el P&ID con el FDS: cada instrumento del P&ID debe tener su descripción en el FDS.
- Identifica lagunas y ambigüedades ahora, no durante la programación.
- Usa una checklist de recepción documental para no olvidar nada.
- Documenta cada RFI con número, fecha y responsable de respuesta.
Problemas Comunes
- El FDS está incompleto o usa terminología ambigua.
- El P&ID no coincide con la última versión del FDS.
- Faltan especificaciones de equipos críticos (variadores, válvulas proporcionales).
- Cambios de proceso después de la entrega de documentación sin control de cambios formal.
- El cliente asume que "sobreentendemos" requisitos no escritos.
Nota de campo
En un proyecto real, dedica al menos 2 horas a leer el FDS sin interrupciones. Marca con colores: verde = claro, amarillo = duda, rojo = falta info. Después de la primera lectura, tendrás una lista de RFIs que te ahorrará semanas de retrabajo.
Checklist de entregables:
- FDS revisado y comentado
- P&ID verificado vs FDS
- Lista de RFIs enviada
- Matriz de trazabilidad creada
- Alcance estimado y aprobado
- Reunión kick-off realizada
Especificación de Software (SDS)
Fase 2 de 10 — Traducir el proceso a lógica de control
Con la documentación analizada, el ingeniero de automatización elabora la Especificación de Diseño de Software (SDS). Este documento es el puente entre lo que el proceso necesita y lo que el programa va a hacer. Aquí se definen narrativas de control, diagramas de estados, matrices de interlocks, listas de alarmas y lazos PID.
Inputs
- FDS revisado y validado
- P&ID con comentarios
- Datasheets de equipos
- Respuestas a RFIs
- Normativa aplicable (IEC 62443, GAMP5…)
Outputs
- SDS (Software Design Specification)
- Narrativas de control por equipo/área
- Matriz de interlocks (proceso y seguridad)
- Lista de alarmas con prioridades (ISA-18.2)
- Definición de lazos PID, set-points y rangos
- Recetas batch si aplica (ISA-88)
Consejos y Buenas Prácticas
- Define convenciones de nomenclatura desde el día uno (ISA-5.1 para tags).
- Usa plantillas estándar: una narrativa de control bien formateada ahorra horas de programación.
- Obtén la aprobación formal (firma) del SDS antes de empezar a programar.
- Clasifica las alarmas según ISA-18.2: no todo es "High Priority".
- Incluye diagramas de estado (state machines) para secuencias complejas.
Problemas Comunes
- Scope creep: "ya que estás, ¿puedes añadir también…?" sin control de cambios.
- Secuencias de arranque/parada no definidas o incompletas.
- Falta de análisis de modos de fallo (¿qué pasa si el sensor falla?).
- Prioridades de alarma definidas sin racionalización formal.
Listado de I/O y Diseño Eléctrico
Fase 3 de 10 — Donde el software se encuentra con el hardware
Esta fase es crítica porque conecta el mundo del software con el hardware real. El listado de I/O define cada señal que entrará o saldrá del PLC: tipo de señal, rango de ingeniería, asignación de rack/slot/canal, número de cable y bornero. La coordinación con el equipo de diseño eléctrico es fundamental para que los paneles, el cableado y la arquitectura de control encajen perfectamente.
Inputs
- SDS aprobado
- Datasheets de instrumentos y equipos
- Esquemas eléctricos (borrador)
- Topología de red propuesta
- Estándar de nomenclatura de tags
Outputs
- Listado de I/O final (tag, tipo, rango, rack/slot/canal)
- BOM de hardware PLC (CPUs, módulos, fuentes, racks)
- Asignación de direcciones de red
- Esquema de arquitectura de control
- Especificación de reservas de I/O (10-15%)
Consejos y Buenas Prácticas
- Usa una base de datos o Excel estructurado para el I/O list — evita archivos desorganizados.
- Verifica cada tipo de señal: 4-20 mA, 0-10 V, NPN/PNP, contacto seco, PT100, termopar…
- Planifica un 10-15% de reserva de I/O — siempre se añaden señales durante la puesta en marcha.
- Identifica los equipos de largo plazo de entrega (lead time) y pídelos cuanto antes.
- Coordina con eléctricos la distribución de paneles y la separación de potencia/señal.
Problemas Comunes
- Tipo de señal mal especificado (tensión en lugar de corriente, o viceversa).
- I/O insuficiente: no se reservó espacio y ahora hay que añadir módulos.
- Incompatibilidad de módulos con el tipo de CPU seleccionada.
- Cambios en el I/O list después de que los paneles ya están fabricados.
- Errores en la numeración de cables que no se detectan hasta la puesta en marcha.
Instrumentación y Configuración de Equipos
Fase 4 de 10 — Preparar el campo antes de programar
Antes de que el código PLC tenga sentido real, cada instrumento y equipo de campo debe estar correctamente configurado. Esto incluye transmisores, caudalímetros, variadores de frecuencia, válvulas inteligentes, switches de red y cualquier dispositivo que interactúe con el sistema de control. La configuración incorrecta de un solo instrumento puede provocar horas de depuración durante la puesta en marcha.
Inputs
- Listado de I/O finalizado
- Datasheets de instrumentos y drives
- Diseño de topología de red
- Estándares de parametrización del cliente
Outputs
- Instrumentos configurados (rango, damping, comunicación)
- Listado de parámetros de variadores
- Diagrama de red con direcciones IP/nodos
- Configuraciones HART/Profibus PA/IO-Link
- Documentación de calibración
Consejos y Buenas Prácticas
- Documenta todos los cambios de parámetros respecto a los valores de fábrica.
- Guarda una copia de seguridad de la configuración original (factory defaults) de cada drive.
- Usa direccionamiento IP estructurado: un esquema coherente ahorra problemas.
- En variadores: configura primero los parámetros de motor antes que los de control.
- Verifica la comunicación de cada instrumento antes del montaje definitivo en campo.
Problemas Comunes
- Rango incorrecto en transmisores (0-10 bar cuando el proceso trabaja a 0-6 bar).
- Conflictos de direccionamiento en buses de campo (Profibus, Modbus).
- Parámetros de variador que provocan disparo por sobrecorriente en el primer arranque.
- Switches de red con configuración por defecto que genera tormentas de broadcast.
Programación de PLC
Fase 5 de 10 — El corazón de la automatización
Aquí es donde todo el trabajo previo toma forma como lógica ejecutable. El ingeniero desarrolla el programa de PLC siguiendo las narrativas del SDS, utilizando los estándares IEC 61131-3 y las mejores prácticas de la industria. Se programan bloques de control de motores, válvulas, lazos PID, secuencias, interlocks, comunicaciones y diagnósticos. Es fundamental usar librerías reutilizables, estructurar bien el código y documentarlo adecuadamente.
Inputs
- SDS aprobado con narrativas de control
- Listado de I/O con asignaciones finales
- Configuración de hardware PLC
- Librería de bloques estándar (si existe)
- Estándares de programación del cliente/empresa
Outputs
- Programa de PLC completo (FBD/LAD/ST/SFC)
- Tablas de símbolos / definiciones de tags
- Documentación de bloques funcionales
- Resultados de simulación offline
- Código versionado y bajo control de cambios
Plataformas habituales:
Consejos y Buenas Prácticas
- Usa programación estructurada: librerías de FBs reutilizables, UDTs, tipos de datos propios.
- Implementa un manejo de errores robusto: qué hace el sistema si un sensor falla.
- Usa control de versiones (Git + TIA Portal Openness, L5X export, etc.).
- Comenta el código: cada bloque debe explicar su propósito, no solo su funcionamiento.
- Estándares IEC 61131-3: elige el lenguaje adecuado para cada tarea (SFC para secuencias, ST para cálculos, FBD para lógica combinacional).
Problemas Comunes
- Tiempo de ciclo (scan time) que excede los requisitos por programación ineficiente.
- Conflictos de tipos de datos entre módulos.
- Timers/contadores mal inicializados que causan comportamientos erráticos al arrancar.
- "Reinventar la rueda" en lugar de usar bloques de librería probados.
- Falta de manejo de estados transitorios (¿qué pasa durante el primer scan?).
Nota de campo
Antes de escribir una sola línea de código, crea la estructura completa del proyecto: carpetas, FBs vacíos, UDTs y symbol tables. Es como los cimientos de una casa. Si empiezas a programar sin estructura, acabarás con código espagueti que nadie podrá mantener.
Checklist de entregables:
- Programa PLC completo
- Tablas de símbolos documentadas
- FBs estándar probados
- Simulación offline OK
- Código bajo control de versiones
- Documentación de bloques
Desarrollo de HMI
Fase 6 de 10 — La ventana del operador al proceso
La HMI es la interfaz entre el operador y el proceso. Un buen diseño de HMI mejora la eficiencia operativa, reduce errores humanos y facilita la detección de anomalías. Se diseñan pantallas de sinópticos, detalle de equipos, gestión de alarmas, trending histórico y navegación intuitiva, siguiendo los principios de la norma ISA-101 y las directrices de High Performance HMI.
Inputs
- SDS — sección de HMI
- P&ID (base para sinópticos)
- Lista de alarmas racionalizada
- Requisitos operativos del cliente
- Guía de estilo corporativa (si existe)
Outputs
- Pantallas HMI completas (overview, detalle, alarmas, trends)
- Configuración de alarmas y eventos
- Estructura de navegación documentada
- Guía de operator training
- Scripts de pantalla y animaciones
Plataformas habituales:
Consejos y Buenas Prácticas
- Fondos en escala de grises: reserva los colores brillantes para estados anómalos.
- Minimiza las animaciones innecesarias: distraen y consumen recursos.
- Diseña para el flujo de trabajo del operador, no para "que quede bonito".
- Implementa una jerarquía clara: Overview → Área → Detalle de equipo.
- ISA-18.2: gestiona las alarmas correctamente para evitar alarm flooding.
Problemas Comunes
- Demasiada información en una sola pantalla (information overload).
- Código de colores inconsistente entre pantallas.
- Alarmas mal gestionadas: avalanchas de alarmas que el operador ignora.
- Navegación lenta o confusa entre pantallas.
- No consultar a los operadores reales durante el diseño.
SCADA y Sistemas de Registro
Fase 7 de 10 — Visión global y registro de datos
En instalaciones de mayor envergadura, el sistema SCADA proporciona supervisión centralizada de múltiples PLCs y áreas. El sistema de registro almacena datos históricos de proceso para análisis, reporting y cumplimiento normativo. Configurar correctamente la arquitectura cliente-servidor, las comunicaciones OPC UA/DA, la redundancia y las políticas de almacenamiento es fundamental para un sistema robusto.
Inputs
- Requisitos SCADA del SDS
- Lista de tags a historizar
- Requisitos de almacenamiento y retención
- Plantillas de informes (KPIs, batch reports)
- Arquitectura de servidores
Outputs
- Sistema SCADA configurado y operativo
- Sistema de registro recopilando datos
- Informes y dashboards
- Acceso web/móvil configurado
- Documentación de arquitectura
Plataformas y herramientas:
Consejos y Buenas Prácticas
- Planifica la jerarquía de tags con visión de futuro — es difícil reestructurar después.
- Define políticas de retención de datos claras (¿cuánto tiempo se guardan los datos?).
- Optimiza las tasas de polling: no todo necesita actualizarse cada 100 ms.
- Implementa redundancia en servidores críticos (SCADA, servidor de registro).
- Usa OPC UA siempre que sea posible — es el futuro de las comunicaciones industriales.
Problemas Comunes
- Cuellos de botella en comunicaciones por exceso de tags o polling demasiado rápido.
- Disco lleno por no planificar la capacidad de almacenamiento del sistema de registro.
- Compresión de datos excesiva que pierde información relevante.
- Problemas de licencias en sistemas distribuidos (nodos, tags, connections).
- IT que bloquea puertos o rompe la comunicación OPC sin avisar.
Pruebas FAT (Factory Acceptance Test)
Fase 8 de 10 — Validar antes de ir a planta
El FAT es la oportunidad de verificar que todo funciona correctamente antes de llegar a la planta. Se monta un entorno de simulación donde se prueban todas las secuencias, interlocks, alarmas, comunicaciones y modos de fallo. El cliente presencia las pruebas y firma su conformidad. Un FAT bien ejecutado reduce drásticamente los problemas en la puesta en marcha real.
Inputs
- Programa de PLC completo
- Aplicación HMI/SCADA completa
- Protocolo de FAT (documento de pruebas)
- Entorno de simulación (PLCSim, emuladores)
- Criterios de aceptación
Outputs
- Informe de FAT firmado (pass/fail por prueba)
- Punch list (incidencias pendientes)
- Evidencias: capturas de pantalla, vídeos
- Software listo para desplegar en planta
- Lista de acciones correctivas si las hay
Consejos y Buenas Prácticas
- Prepara el entorno de simulación con antelación — no el día antes del FAT.
- Documenta cada test con capturas de pantalla y descripción paso a paso.
- El cliente debe firmar cada sección del FAT, no solo el documento final.
- Incluye pruebas de fallo: pérdida de comunicación, fallo de sensor, corte de alimentación.
- Graba en vídeo las secuencias críticas como evidencia adicional.
Problemas Comunes
- Simulación incompleta: no se pueden probar todas las condiciones reales en oficina.
- Cambios de última hora que invalidan pruebas ya realizadas.
- El entorno FAT no refleja la configuración real de planta (versiones de firmware, redes).
- Presión de plazos que reduce la cobertura de pruebas.
- Falta de definición clara de criterios de aceptación (¿qué es "OK"?).
Nota de campo
Prepara una tabla de pruebas con estado (pendiente / en curso / pass / fail / N/A) y proyéctala en pantalla durante el FAT. El cliente ve el progreso en tiempo real, se siente involucrado y el proceso de firma es mucho más fluido.
Checklist de entregables:
- Protocolo FAT firmado
- Capturas y vídeos
- Punch list documentado
- Pruebas I/O completas
- Pruebas de secuencias OK
- Software listo para planta
Puesta en Marcha (SAT — Site Acceptance Test)
Fase 9 de 10 — La prueba de fuego
La puesta en marcha es donde todo el trabajo de oficina se pone a prueba con la realidad. Se divide en sub-fases: pre-comisionado (inspección de paneles, verificación punto a punto), comisionado en frío (sistemas energizados sin proceso) y comisionado en caliente (proceso real en marcha). La coordinación con montadores, electricistas, operadores y responsables de seguridad es constante y exigente.
Inputs
- Hardware instalado en planta
- Software aprobado en FAT
- Plan de comisionado con cronograma
- Protocolos de loop check
- Permisos de trabajo y LOTO
Outputs
- Sistema comisionado y operativo
- Informe de SAT firmado
- Loop checks completados y documentados
- Lazos PID sintonizados con proceso real
- Punch list de pendientes post-SAT
- Documentación as-built actualizada
Consejos y Buenas Prácticas
- Haz reuniones diarias de seguimiento cortas para coordinar con todos los gremios.
- Ten siempre a mano el portátil de programación, cables, adaptadores y herramientas básicas.
- Loop check metódico: sigue un orden lógico (panel → campo → PLC → HMI) y documenta todo.
- Los lazos PID necesitan sintonización con el proceso real, no con valores teóricos.
- Lleva un registro diario de incidencias y resoluciones — es tu evidencia de trabajo.
- Anticipa problemas de acceso a la planta (permisos, horarios, seguridad).
Problemas Comunes
- Errores de cableado descubiertos durante el loop check (cables cruzados, bornes sueltos).
- Instrumentos con fallo o rango incorrecto descubiertos en campo.
- "Ya que estás aquí, ¿puedes hacer también esto otro?" — scope creep en planta.
- El proceso se comporta distinto a lo esperado (tiempos, caudales, temperaturas).
- Problemas de comunicación en un entorno industrial ruidoso (EMI, distancias).
- Conflictos de planificación con otros gremios (¿quién tiene acceso al panel ahora?).
Nota de campo
La mochila del comisionador: portátil cargado + cargador, cables Ethernet (2 min.), cable USB-serial, adaptador Profibus, cinta aislante, destornilladores plano/estrella, linterna frontal, cargador de móvil, EPIs y una libreta. Si llegas a planta sin alguno de estos, perderás medio día buscándolo.
Checklist de entregables:
- Loop checks completos
- Informe SAT firmado
- PIDs sintonizados
- Alarmas ajustadas
- Punch list actualizado
- Documentación as-built
Validación y Entrega
Fase 10 de 10 — Cerrar el proyecto correctamente
La fase final asegura que el sistema cumple con todos los requisitos, está debidamente documentado y se entrega al equipo de producción y mantenimiento. En industrias reguladas (farmacéutica, alimentaria), esto incluye la validación formal (IQ/OQ/PQ según GAMP5). La formación a operadores y mantenimiento, y la entrega de documentación as-built completa, son esenciales para el éxito a largo plazo del proyecto.
Inputs
- Resultados de SAT
- Protocolos de validación (IQ/OQ/PQ)
- Datos de rendimiento del proceso
- Feedback de operaciones
- Requisitos normativos (GMP, FDA, etc.)
Outputs
- Informes de validación firmados
- Documentación as-built completa
- SOPs (Procedimientos Operativos Estándar)
- Registros de formación
- Lista de repuestos recomendados
- Contrato de mantenimiento/soporte
- Acta de entrega y aceptación final
Consejos y Buenas Prácticas
- La documentación as-built debe reflejar el estado real del sistema, no el diseño original.
- Forma a los operadores con el proceso real, no solo con presentaciones.
- Entrega procedimientos de mantenimiento claros: qué hacer si falla X componente.
- Deja una lista de contactos para soporte técnico post-entrega.
- Realiza una reunión de lecciones aprendidas con todo el equipo.
Problemas Comunes
- Documentación no actualizada con los últimos cambios de la puesta en marcha.
- Formación insuficiente: los operadores no se sienten cómodos con el sistema.
- Desviaciones de validación que requieren investigación y acciones correctivas.
- Resistencia al cambio por parte del personal de producción.
- Pendientes de la punch list que se arrastran semanas/meses.