Diseño de Arquitectura

Qué es el diseño de arquitectura de sistemas industriales

El diseño de arquitectura de sistemas industriales es el trabajo de definir, antes de instalar nada, cómo van a encajar entre sí las máquinas, los sensores, las redes, las bases de datos y las aplicaciones de gestión de una planta. No es un documento comercial ni un catálogo de productos: es el plano técnico y funcional que responde a preguntas concretas. Qué dato sale de cada equipo, por qué protocolo viaja, dónde se almacena, quién lo consume y qué decisión de negocio alimenta.

En Captia Technology diseñamos esa arquitectura adaptada a la infraestructura que la empresa ya tiene. Una planta con un PLC Siemens de hace quince años, una báscula con salida serie y un ERP en marcha no parte de cero, y la arquitectura debe reconocerlo. El punto de partida habitual es un diagnóstico operacional que inventaría lo que existe: equipos, versiones, protocolos, hojas de cálculo que hacen de pegamento entre sistemas. Sobre ese inventario se dibuja la solución.

Las capas: OT, datos, aplicación y negocio

Una forma útil de razonar sobre la arquitectura es por capas, cada una con responsabilidades y tecnologías propias:

• Capa OT (operación). PLCs, variadores, sensores, SCADA y HMIs. Aquí mandan los tiempos de ciclo y la fiabilidad: un fallo en esta capa para la línea. Los protocolos típicos son Modbus, PROFINET, EtherNet/IP u OPC UA en equipos más recientes.
• Capa de datos. Captura, normaliza y almacena las señales de planta: gateways, brokers MQTT, historiadores y bases de datos de series temporales. Es la capa que convierte "el registro 40012 del PLC de la envasadora" en "unidades producidas por hora en la línea 2".
• Capa de aplicación. Las herramientas con las que trabaja la gente: MES, cuadros de mando, sistemas de calidad, gestión de mantenimiento. Consumen el dato ya normalizado y lo presentan en el contexto de cada rol.
• Capa de negocio. ERP, planificación, costes y facturación. Cierra el ciclo: la producción real alimenta el ERP y las órdenes del ERP bajan a planta sin transcripciones manuales.

El valor del diseño está en las fronteras entre capas. Definir qué interfaz une la capa OT con la de datos, o la de datos con el ERP, evita el acoplamiento directo entre sistemas que después nadie se atreve a tocar.

Principios de diseño que aplicamos

Cada planta es distinta, pero hay principios que sostienen cualquier arquitectura industrial bien planteada:

Sin rip-and-replace. No proponemos sustituir sistemas que funcionan solo porque son antiguos. Un PLC en producción estable se integra, no se jubila. La arquitectura envuelve lo existente con capas de integración y reserva las sustituciones para cuando haya una razón operativa real: obsolescencia sin repuestos, riesgo de seguridad o un cuello de botella demostrado.

Escalabilidad por etapas. El diseño contempla la planta completa, pero se implanta por fases que caben en el presupuesto y en el calendario de paradas. Empezar por una línea piloto y extender el mismo patrón al resto es más barato y menos arriesgado que un despliegue total de golpe. Ese troceado se ordena después en un roadmap de transformación con prioridades y dependencias explícitas.

Estándares abiertos. Priorizamos OPC UA, MQTT, APIs REST y formatos de datos documentados frente a conectores propietarios. La razón es práctica: una interfaz estándar permite cambiar de proveedor de software sin rehacer la integración, y cualquier técnico puede mantenerla sin depender de un fabricante concreto.

El dato se captura una vez. Si el peso de un palet ya lo lee la báscula, nadie debería teclearlo en el ERP. Cada dato tiene una fuente única y el resto de sistemas lo consumen de ahí. Este principio, simple de enunciar, elimina buena parte de los errores de transcripción y de las discusiones sobre "qué cifra es la buena".

Errores típicos de las arquitecturas fragmentadas

La mayoría de plantas no tienen una arquitectura diseñada: tienen una acumulación de decisiones puntuales. Cada proyecto resolvió su problema con su propia integración, y diez años después el conjunto presenta síntomas reconocibles:

• Islas de datos. El SCADA sabe cuánto se produjo, el ERP sabe cuánto se facturó, y conciliar ambas cifras es un trabajo mensual en Excel.
• Integraciones punto a punto. Cada sistema habla directamente con otros dos o tres. Con cinco sistemas ya hay una maraña donde cambiar uno obliga a retocar todos los demás.
• Dependencia de una persona. La integración crítica la montó alguien que ya no está, no hay documentación y nadie quiere tocarla.
• Doble introducción de datos. Operarios que apuntan en papel lo que una máquina ya registró, y administrativos que lo vuelven a teclear.
• Software infrautilizado. Un MES o un módulo de ERP comprado y configurado a medias, porque nadie diseñó cómo debía recibir los datos de planta.

Ninguno de estos problemas se arregla comprando otra herramienta. Se arreglan rediseñando cómo se conectan las que hay, que es exactamente el objeto de este servicio. Para situar en qué punto está una planta antes de rediseñar nada, puede servir de referencia nuestra guía sobre madurez operacional industrial.

Qué entregamos al final del trabajo

El resultado del diseño de arquitectura es documentación técnica accionable, no una presentación. Los entregables habituales son:

• Diagrama de arquitectura por capas, con todos los sistemas actuales y futuros, sus interfaces y los protocolos de cada conexión.
• Mapa de flujos de datos: qué información se origina en cada punto, con qué frecuencia, hacia dónde viaja y quién la consume.
• Especificación funcional de cada integración, en un nivel de detalle suficiente para que un equipo técnico (nuestro o de terceros) la implemente sin ambigüedad.
• Criterios de selección tecnológica cuando hay que incorporar componentes nuevos, con alternativas comparadas y justificación.
• Propuesta de fases de implantación, con dependencias entre ellas y requisitos previos de cada una.

Esta documentación es propiedad del cliente y es deliberadamente independiente de proveedor: sirve igual si la implantación la hace Captia Technology o cualquier otro equipo. Una arquitectura bien documentada es la diferencia entre digitalizar con criterio y volver a acumular parches durante otra década.