Soluciones de IoT industrial

El IoT industrial no comienza conectando un dispositivo a internet. Los sistemas construidos antes de definir qué datos recopilar, con qué frecuencia y qué hacer con ellos, se convierten pronto en un panel abandonado.

Soluciones de IoT industrial

Lo que distingue a un sistema que funciona en campo de uno de oficina es el costo de acceso. Si llegar a un dispositivo requiere vehículo, personal y tiempo, que ese dispositivo sea gestionable a distancia es algo que debe abordarse desde el inicio mismo del diseño.

Al construir la arquitectura, las primeras preguntas que nos hacemos son: qué ocurre si se corta la conexión, cómo se actualiza el software del dispositivo sin visitar el sitio, cómo se detecta una avería desde un punto central. Las respuestas a estas tres preguntas determinan la vida útil del sistema en el terreno.

Los sistemas construidos antes de definir qué datos recopilar y qué hacer con ellos se convierten pronto en un panel abandonado.

¿Somos el interlocutor adecuado?

La mayoría de estas instalaciones logra recopilar datos, pero no logra hacer algo con ellos. Por eso empezamos el trabajo no por el panel, sino por la decisión a la que se vincularán los datos: qué umbral dispara qué acción, quién ejecuta esa acción.

Sí, hablemos

  • Hay un proceso que se gestiona a ojo por falta de medición en el terreno
  • Los datos a recopilar pueden vincularse a una acción: mantenimiento, reabastecimiento, planificación, detención
  • Llegar a los dispositivos requiere vehículo y tiempo; la gestión remota es imprescindible

No, alguien más lo hace mejor

  • Se recopilarán datos, pero aún no está claro qué se hará con ellos
  • La medición ya se realiza y puede obtenerse de un sistema existente
  • El único resultado esperado es un panel de control

Qué hacemos

  • Análisis de campo y determinación de las magnitudes a medir
  • Selección de sensores y hardware de medición
  • Recopilación de datos y software del dispositivo edge
  • Selección de protocolo de comunicación y arquitectura de red
  • Distribución del procesamiento entre el edge y la nube
  • Gestión de dispositivos y actualizaciones de software remotas
  • Paneles de supervisión, umbrales y reglas de alarma
  • Almacenamiento de datos e infraestructura de análisis histórico
  • Instalación en campo y puesta en marcha

Cómo procedemos

01

Análisis de campo

Evaluamos in situ las magnitudes a medir, las condiciones de campo y las posibilidades de alimentación y conexión. La mayoría de las arquitecturas que funcionan en el papel cambian en el terreno.

02

Decisión de arquitectura

Decidimos qué procesamiento se realiza en el dispositivo y cuál de forma centralizada. El costo de conexión y la tolerancia a interrupciones guían esta decisión.

03

Instalación piloto

Instalamos un piloto en un número limitado de sitios y lo ponemos en funcionamiento en condiciones reales. Aquí verificamos la precisión de las mediciones y la estabilidad de las comunicaciones.

04

Despliegue

Extendemos al terreno la estructura validada en el piloto. El procedimiento de instalación y el registro de dispositivos se estandarizan en esta etapa.

05

Supervisión y mantenimiento

Supervisamos el estado de los dispositivos, la continuidad de los datos y el comportamiento de las alarmas. Gestionamos las actualizaciones de software a distancia.

Nuestras decisiones técnicas

  • Enviar cada medición a un punto central genera costos de ancho de banda y almacenamiento. Qué constituye un cambio significativo se determina en el propio dispositivo, y solo se transmiten datos resumidos al centro. Se conserva un historial limitado en el dispositivo para los casos que requieren datos en bruto.
  • Cuando se corta la conexión, el dispositivo sigue midiendo y almacena los datos localmente. Cuando la conexión vuelve, los registros acumulados se envían en orden, de modo que el período de corte no deja un vacío en los datos.
  • El mecanismo de actualización está presente desde la primera versión. En un sistema donde el software no puede actualizarse sin visitar el sitio, cada pequeña corrección exige una visita de campo; con el tiempo, las actualizaciones dejan de hacerse y los dispositivos terminan funcionando con versiones distintas.
  • Cada dispositivo tiene una identidad única. Desde un punto central puede verse dónde está cada dispositivo, qué versión de software ejecuta y cuándo envió sus últimos datos.
  • La ausencia de datos también es una señal. El sistema genera una alarma no solo por superar un umbral, sino también cuando no llegan los datos esperados. Un sensor que se queda en silencio puede pasar desapercibido mucho más tiempo que uno que da una medición errónea.
Soluciones de circuitos electrónicos
Aplicaciones empresariales asistidas por IA