Software de adquisición de datos de máquina: qué comprar en 2026 (y qué saltar)
El software de adquisición de datos de máquina es la capa entre una línea de producción y cualquier sistema que quiera hacer algo útil con lo que la línea está haciendo. Lee señales de PLCs, sensores, sistemas de visión, MES y, cada vez más, de cámaras apuntando a la máquina, y entonces transforma esas señales en un flujo que una base de datos, un cuadro de mando o un modelo de IA pueda consumir.
La categoría ha pasado de uno o dos players dominantes a cerca de veinte en cinco años. La mitad de ellos resuelve un problema que no existía en 2020. La otra mitad resuelve un problema que los grandes proveedores de MES resolvían y hoy ya no quieren resolver. Este texto es para el responsable de operaciones o de TI que está armando una short list de herramientas y quiere un mapa claro.
Qué hace de verdad un software de adquisición de datos de máquina
En el núcleo, tres cosas. Se conecta a la fuente de datos (PLC, sensor, cámara, MES, ERP, registro tecleado a mano). Normaliza los datos a un formato consistente con marcas de tiempo e información de unidades. Entrega los datos a cualquier sistema que vaya a consumirlos (un historian, un cuadro de mando, una base de datos en la nube, un modelo de IA, la hoja de cálculo Excel de un ingeniero de procesos).
Las diferencias entre proveedores están casi todas en el primer y en el tercer paso. El medio es commodity. Los proveedores compiten en cuántos protocolos hablan nativamente (Siemens S7, Allen-Bradley, Modbus, OPC UA, MQTT, EtherNet/IP, Profinet, más la larga cola de protocolos específicos de marca) y en cuántos consumidores integran (SQL, bases de datos time-series, Snowflake, BigQuery, Azure Data Explorer, Power BI, Grafana, endpoints REST a medida).
Para una fábrica pequeña o mediana, la capa de conexión importa más que la capa de consumo. Para una fábrica grande con una stack analítica ya montada, vale lo contrario.
Las cinco categorías de herramientas en 2026
Cinco cubos cubren la mayor parte del mercado en 2026.
1. Middleware clásico al estilo SCADA
Herramientas nacidas de workflows de historian y SCADA: AVEVA PI, Inductive Automation Ignition, Wonderware/AVEVA System Platform, GE Proficy. Fuertes en datos de PLC de alto volumen, débiles en integraciones modernas en nube y en datos de cámara. Caras (las licencias por tag o por conexión se suman rápido). Fiables. El estándar en petróleo y gas, en la gran química y en la gran manufactura discreta.
Elige si: tienes un parque de PLCs y un historian consolidados desde hace años, la TI de planta los gestiona con tranquilidad y no estás tratando de añadir monitorización por cámara o analítica en nube a corto plazo.
2. Stacks modernas open source
Node-RED + InfluxDB + Grafana, a menudo con Mosquitto para el brokering MQTT. United Manufacturing Hub para un bundle open source más opinado. HiveMQ para MQTT serio. El coste de propiedad es el tiempo de tus ingenieros, no una licencia. El techo es alto y el suelo es bajo (necesitas a alguien que sepa operarlo).
Elige si: tienes un equipo interno cómodo con self-hosting, quieres evitar vendor lock-in y aceptas pagar en horas de ingeniero en vez de dólares de licencia.
3. Plataformas comerciales cloud-native
Tulip, Litmus Edge, HighByte, Cognite, Element, Cumulocity, AVEVA Data Hub. La promesa es la misma para la mayoría: TCO menor que el del middleware SCADA legado, tiempo más corto hasta el primer cuadro de mando, entrega nativa en nube, una historia de TI decente para el procurement. El precio es por dispositivo o por flujo de datos y se suma más rápido de lo que los proveedores te van a decir. UX e integraciones con IA varían mucho entre proveedores.
Elige si: quieres una herramienta moderna, no quieres hacer self-hosting, tienes presupuesto para fees recurrentes por dispositivo y tienes un conjunto claro de fuentes de datos para conectar en hasta doce meses.
4. Sistemas cámara e IA-first
Una categoría más reciente. Herramientas que tratan a la cámara como fuente de datos de primera clase, no como un añadido. La cámara alimenta modelos de visión que cuentan piezas, clasifican defectos y detectan anomalías de proceso, y los eventos resultantes aparecen en la misma tubería que los datos de PLC. Enao Vision está aquí. Otros entrantes incluyen Augmentir, MakinaRocks y diversos plug-ins MES especializados en visión.
Elige si: tu cuello de botella es la visibilidad sobre lo que la línea está haciendo de verdad (no solo lo que el PLC cree que está haciendo) y quieres una herramienta que trate datos de cámara y datos de PLC como pares.
5. Integraciones hechas en casa
Muchas fábricas corren scripts Python que hacen ping a un cliente OPC UA, vuelcan CSVs en una share de red y montan algún informe Power BI encima. No es una categoría de herramientas, es la ausencia de una, pero merece un nombre porque en pequeña escala funciona. Deja de funcionar cuando el script se rompe a las dos de la mañana y nadie sabe arreglarlo.
Elige si: tienes una o dos líneas, un ingeniero que mantiene los scripts y cero presupuesto. Migra a una de las categorías 1 a 4 en cuanto crezca la complejidad o una segunda persona tenga que mantener el sistema.
Dónde se rompe cada categoría
El middleware SCADA clásico se rompe en datos de cámara y en entrega a nube. Añadir un sistema de visión a un servidor PI parece un parche. Sacar los datos a un data warehouse en nube añade costes de licencia y de ingeniería que la mayoría de los equipos subestima.
Las stacks open source modernas se rompen en las personas, no en la tecnología. Corren muy bien mientras un ingeniero específico está en la empresa y dejan de correr cuando ese ingeniero se va. El coste de enseñar la stack al segundo ingeniero casi siempre es mayor que un año de licencias comerciales.
Las plataformas comerciales cloud-native se rompen en la transparencia de precio. El list price rara vez es el precio real, y el precio real crece con el uso de formas que no se ven obvias en el proof of concept. Se rompen también en los casos de borde: el protocolo PLC de la larga cola que el proveedor todavía no soporta, la política de TI local que prohibe egress a nube, la línea que corre en un controlador de 1998 sin puerto Ethernet.
Los sistemas cámara e IA-first se rompen cuando los datos de PLC existentes ya son lo bastante buenos y la cámara solo añade ruido sin valor. Se rompen también cuando la iluminación y el montaje en la línea están mal (el mismo problema de cualquier sistema de visión).
La integración hecha en casa se rompe en la primera semana de vacaciones de la persona que la escribió.
Cómo elegir para una fábrica concreta
Tres preguntas en orden. ¿Qué fuentes de datos necesitas conectar hoy y cuáles vas a necesitar conectar en dieciocho meses? ¿Dónde tienen que aterrizar los datos (un historian, un data warehouse en nube, una herramienta de BI, un modelo de IA)? ¿Quién mantiene el sistema y cuál es la tolerancia de esa persona a la complejidad self-hosted?
Una fábrica con veinte máquinas conectadas por PLC, un historian PI ya instalado y un equipo pequeño de TI probablemente debería extender lo que ya tiene. Una fábrica con cinco líneas, sin historian, con ganas de analítica en nube y disposición a pagar por dispositivo debería mirar la categoría comercial cloud-native. Una fábrica cuyo mayor hueco de visibilidad es lo que pasa en la línea más allá de lo que reporta el PLC debería mirar los sistemas cámara e IA-first. Una fábrica con un ingeniero y una línea está bien con hecho en casa mientras el ingeniero no se vaya de vacaciones.
El error es elegir por reconocimiento de marca en vez de por la respuesta a esas tres preguntas. La respuesta correcta rara vez es la misma que la de la fábrica de al lado.
Costes en 2026
Orden de magnitud aproximado para una fábrica mediana (10-30 máquinas conectadas).
SCADA clásico: 100k-400k EUR inicial más 15-25 por ciento de mantenimiento anual.
Open source moderno: 0 EUR de licencia más 1-2 ingenieros a tiempo completo (es decir, 100k-200k EUR al año de coste cargado).
Comercial cloud-native: 30k-150k EUR al año de suscripción, según el tier por dispositivo o por flujo de datos.
Cámara e IA-first: 5k-20k EUR por línea al año de suscripción, más un coste de setup único del orden de 1-5k por línea por el hardware que corre la cámara.
Hecho en casa: el coste del tiempo de un ingeniero y el riesgo de fallo catastrófico cuando esa persona se va.
Esas franjas son amplias porque los números reales dependen de negociación, volumen y descuentos de fin de trimestre. Trátalo como orientación, no como presupuesto.
Primer de campo: qué hay de verdad dentro de un sistema de adquisición de datos
Un sistema de adquisición de datos funcional en 2026 es una stack, no un producto único. Nombrar las piezas ayuda cuando te sientas delante de un proveedor y la demo pasa por encima de la mitad de ellas.
En la capa de sensores, las entradas son típicamente una mezcla de termopares y RTDs para temperatura, transductores de presión, transductores de vibración, transductores de caudal y transductores de corriente y tensión usados para análisis de potencia. Cada señal de sensor pasa por acondicionamiento (el signal conditioning incluye amplificación, aislamiento y filtrado) y se convierte de analógico a digital con conversores analógico-digitales. El flujo convertido entonces carga un número de serie de la fuente, una marca de tiempo y las unidades de ingeniería, y se entrega a quien vaya a consumirlo.
El hardware DAQ que hace esa conversión viene en tres formas. Data loggers y registradores autónomos que guardan las lecturas en memoria interna para descargarlas después (el workflow más simple de data logging, todavía común en bombas remotas, generadores y equipos HVAC). Hardware DAQ modular sobre un backbone Ethernet o USB que hace streaming a un host (la forma dominante en laboratorios de prueba y en bancadas de I+D). Y front ends de controladores lógicos programables que combinan una pequeña stack DAQ con la lógica de control en el mismo dispositivo (la forma dominante en líneas de producción).
Por encima del hardware queda el software DAQ. Hace tres trabajos que se solapan con lo que hace una herramienta de adquisición de datos de máquina a escala de fábrica. Configura los canales (tasa de muestreo, rango, filtrado). Registra y guarda los datos de proceso (a menudo en un host Linux que también corre el historian). Y muestra las lecturas a los operarios vía gráficos en tiempo real, cuadros de mando y alarmas. La capa de usuario se construye en una variedad de lenguajes de programación: C y C# para stacks legadas, Python y JavaScript para cuadros de mando web modernos, más una larga cola de entornos de scripting de proveedor (LabVIEW, Codesys structured text, Beckhoff TwinCAT).
La razón por la que este primer importa al comprador de la fábrica es que las mismas palabras significan cosas distintas a escalas distintas. Un test engineer en un laboratorio de I+D de baterías que dice “DAQ” normalmente quiere decir un chasis National Instruments PXI con una stack de módulos de entrada analógica y LabVIEW por encima. Un responsable de operaciones en una fábrica de envasado que dice “adquisición de datos de máquina” normalmente quiere decir un trozo de middleware que tira de datos de veinte PLCs y los entrega a un cuadro de mando y a un modelo de IA. Los dos tienen razón, los dos usan las mismas palabras, y los proveedores que venden a los dos segmentos hablan en términos deliberadamente ambiguos. Cuando un vendedor te hable de DAQ, pregúntale si quiere decir la stack sensor-conversor o la capa PLC-cuadro de mando. La respuesta determina si la herramienta te sirve.
Los equipos de control de calidad usan datos de DAQ de forma más agresiva que cualquier otra función. Los datos son la prueba en todo CAPA, toda auditoría de proveedor, toda reclamación de cliente que exige trazabilidad. Una fábrica que hace control de calidad en registros escritos a mano está en una década distinta a una que lo hace en el sistema de adquisición de datos. El paso de uno al otro es lo que este software realmente está vendiendo, incluso cuando se vende como productividad o como visibilidad.
FAQ
¿MQTT es lo mismo que una herramienta de adquisición de datos de máquina? No. MQTT es un protocolo de transporte. Una herramienta de adquisición de datos de máquina típicamente usa MQTT (u OPC UA, o protocolos propietarios) como una de sus capas de transporte. Herramientas y protocolos son cosas distintas.
¿Necesito un historian y una herramienta de adquisición de datos de máquina? En una fábrica pequeña, no. En una fábrica grande con datos de PLC de alto volumen, sí. El historian está optimizado para almacenar y recuperar series temporales en alta cadencia. La herramienta de adquisición está optimizada para llevar los datos hasta ahí y a otros consumidores.
¿Qué es OPC UA y lo necesito? OPC UA es el estándar abierto moderno para el intercambio de datos máquina-a-máquina. La mayoría de las herramientas de adquisición lo hablan. Lo necesitas si tus máquinas lo soportan (la mayoría de PLCs modernos lo soporta). Para máquinas más viejas, se cae de vuelta a los protocolos específicos de marca.
¿Cómo encaja esto con nuestro MES o ERP? La herramienta de adquisición alimenta al MES con datos de máquina en tiempo real. El MES alimenta al ERP con datos de producción agregados. La herramienta de adquisición queda aguas arriba de los dos.
Empieza por el hueco de visibilidad
La herramienta correcta depende del hueco. Si el hueco son cuadros de mando a partir de datos de PLC, ve a comercial cloud-native o open source. Si el hueco es reporting enterprise a partir de un parque grande de máquinas, quédate con la stack clásica y extiéndela. Si el hueco es saber qué está haciendo la línea de verdad más allá de lo que reporta el PLC, empieza por la categoría cámara e IA-first y piensa en el resto después.
Para una mirada más profunda sobre lo que la monitorización por cámara te entrega, mira monitorización de producción por cámara. Para cómo encaja en un programa de visibilidad más amplio, mira sistema de monitorización de producción.
Abre una cuenta gratuita o únete a la comunidad para comparar stacks de adquisición de datos con colegas de otras fábricas.
Únete a la comunidad
Animamos una comunidad de Slack gratuita para builders de fábrica, líderes de mejora continua y gente de operaciones que quiere comparar stacks de adquisición de datos sin rodeos. Únete a la comunidad.
