AusDataTech

Plans

Qué cubre un piloto de telemetría y qué queda para después

En la página de planes conviene ser concreto: AusDataTech no conecta toda la planta de una vez. La propuesta arranca con un piloto acotado a una línea, y antes de instalar cualquier gateway se define el alcance, los sensores que se van a leer y el objetivo de mantenimiento que se quiere observar. Ese recorte es lo que permite aprender rápido, con bajo riesgo, y recién después evaluar si el esquema se extiende a otras líneas.

Dentro del alcance

El piloto trabaja sobre una línea: se eligen las lecturas de temperatura, vibración, presión o caudal que tengan sentido para el equipo de mantenimiento, se integran los protocolos Modbus y OPC-UA según lo que ya esté instalado en los equipos, y se suman los gateways industriales necesarios para publicar los datos. Las lecturas quedan guardadas en una base de series temporales y se arma el tablero de telemetría ordenado por turno y por máquina, para que el operario de piso y el supervisor miren el mismo dato sin planillas de Excel dando vueltas. Los avisos por mail o Telegram se configuran después, cuando los rangos relevantes ya están acordados con el jefe de planta.

Fuera del alcance

El piloto no cubre la planta completa ni reemplaza al sistema de control existente. Tampoco incluye instrumentación nueva que no esté prevista en la definición inicial, ni la instalación eléctrica de los sensores, ni tareas de mantenimiento correctivo sobre los equipos. Si en la línea hay variadores, PLC o medidores que no exponen sus datos por Modbus u OPC-UA, eso se evalúa aparte: puede requerir hardware adicional o un relevamiento previo antes de decidir si entra o no en esta etapa.

Qué conviene definir antes de empezar

Antes de la primera visita técnica hace falta cerrar tres cosas: qué máquina o conjunto de máquinas se va a monitorear, qué variable concreta interesa seguir y con qué frecuencia, y quién va a recibir los avisos cuando un valor se salga de rango. También ayuda acordar los nombres de los equipos y las unidades de medida desde el inicio, porque eso evita discusiones más adelante sobre qué número es el correcto. Si esos puntos quedan claros, el piloto avanza sin sorpresas; si no, el proyecto se estira y pierde la ventaja de probar acotado.

Los detalles finos del alcance, los sensores incluidos y los criterios de evaluación se acuerdan caso por caso antes de arrancar. No hay condiciones estándar: cada línea tiene su propio punto de partida.

Un caso de telemetría en una línea de producción

Este es un caso de referencia, sin nombre de cliente ni cifras cerradas. Sirve para mostrar cómo se ordena el trabajo cuando una planta tiene sensores dando vueltas y nadie los mira. Lo tomamos como escenario de ejemplo para explicar el recorrido completo: contexto, tarea, límites del proyecto y enfoque aplicado.

Contexto

Una línea con motores, bombas y un tablero de control ya instalado. Los equipos de mantenimiento tomaban lecturas de temperatura, vibración, presión y caudal de forma manual, en planillas separadas por turno. El operario de piso anotaba una cosa, el supervisor otra, y cuando había que revisar un evento pasado los números no coincidían. Los datos existían, pero no había una estructura común que los juntara.

Tarea

Armar un tablero de telemetría que reuniera esas lecturas en un solo lugar, ordenadas por turno y por máquina, con avisos por mail o Telegram cuando un valor se saliera de rango. La condición era no frenar la producción ni reemplazar los equipos existentes: había que leer lo que ya estaba instalado.

Restricciones del recorte

  • Una sola línea como alcance inicial, sin extender el monitoreo a otras áreas.
  • Los protocolos disponibles en planta eran Modbus y OPC-UA, según el equipo.
  • Los umbrales de aviso debían definirlos el equipo de mantenimiento y el jefe de planta, no imponerse desde afuera.
  • La base de datos de series temporales tenía que convivir con el sistema de gestión ya en uso.

Enfoque

Primero se acordó la clave de datos: qué se mide, en qué unidad, con qué frecuencia y bajo qué nombre de máquina. Después se integraron los gateways industriales para traducir Modbus y OPC-UA a un mismo bus, y se volcó todo a la base de series temporales. El tablero se armó con vistas por turno y por máquina, con gráficos de líneas y gauges de planta para los valores numéricos. Los avisos se configuraron con umbrales por equipo e histéresis, para que no sonaran por oscilaciones normales del proceso.

Qué se espera de un piloto así

El objetivo práctico es que el operario de piso y el supervisor miren el mismo dato sin planillas de Excel dando vueltas. Recién después de esa instancia tiene sentido evaluar si el esquema se extiende a otras líneas. No hay plazos ni cantidades de sensores definidos de antemano: eso se acota con cada equipo antes de arrancar.

Qué se arma en una prueba piloto de telemetría

No se trata de conectar toda la planta de una vez. El punto de partida es una línea, con alcance, sensores y objetivo de mantenimiento acordados antes de extender el esquema. Así el equipo de mantenimiento y el jefe de planta ven resultados sobre algo concreto y no sobre una promesa.

Relevamiento de sensores y protocolos

Se define qué lecturas entran al tablero: temperatura, vibración, presión o caudal, según lo que ya esté instrumentado en la línea. En el mismo paso se revisa qué equipos hablan Modbus, cuáles exponen OPC-UA y si hace falta un gateway industrial que traduzca uno hacia el otro.

Tablero de telemetría por turno y por máquina

Las lecturas se agrupan con una clave común: turno, máquina y línea. El operario de piso y el supervisor consultan el mismo dato, sin planillas de Excel paralelas ni versiones que no coinciden. Los valores numéricos se muestran en tipografía monoespaciada para que se lean rápido.

Base de series temporales con retención definida

Se acuerda qué se guarda crudo y qué se resume por hora, porque no todo valor necesita la misma resolución con el paso del tiempo. Esa decisión afecta el costo de almacenamiento y la velocidad con la que después se comparan períodos de producción.

Avisos según los rangos que el equipo considere relevantes

Los umbrales se configuran por equipo, no con un valor único para toda la planta. La vibración de un motor en arranque no se parece a la de uno en régimen, y esa diferencia importa al momento de definir cuándo vale la pena avisar.

Criterio para escalar a otras líneas

Terminado el piloto se evalúa si conviene replicar el esquema. La decisión se apoya en lo que se vio durante la prueba, no en una proyección. Si el recorte inicial fue acotado, esa evaluación es más simple y menos costosa.

Cómo trabaja el equipo por dentro

Un tablero de telemetría no se arma de una sola vez ni de un día para el otro. Antes de conectar un solo gateway hay un recorrido interno que ordena qué se mide, cómo se agrupa y quién revisa el resultado. Este es el proceso que seguimos cuando llega un pedido de monitoreo para una línea de planta.

  1. Recepción del pedido

    El punto de partida es una conversación concreta: qué línea preocupa, qué sensores ya están instalados y qué se quiere ver distinto. Registramos el equipo, el protocolo disponible en cada controlador y el tipo de lectura que hoy nadie consulta. Si hay planillas de Excel circulando entre turnos, pedimos verlas, porque suelen mostrar dónde está el desacuerdo real entre operario y supervisor.

  2. Planificación del alcance

    Con el relevamiento en mano definimos el recorte: una línea, un conjunto acotado de variables de temperatura, vibración, presión o caudal, y un objetivo de mantenimiento explícito. Ahí se decide qué se lee por Modbus y qué conviene exponer por OPC-UA, cómo se nombran las máquinas y cómo se agrupan las lecturas por turno. La planificación también fija qué se guarda crudo en la base de series temporales y qué se resume.

  3. Ejecución de la integración

    Montamos el gateway industrial, configuramos las lecturas y las publicamos en la base de series temporales. El tablero se arma después, cuando los datos ya llegan ordenados y con nombres que el equipo reconoce. En esta etapa trabajamos junto al personal de planta para validar que cada valor corresponda a la máquina correcta y no a una etiqueta heredada de un plano viejo.

  4. Verificación en piso

    Antes de dar por cerrado el armado, contrastamos lo que muestra el tablero con lo que se ve en la línea. Revisamos rangos, unidades y ventanas de tiempo, y ajustamos los umbrales que disparan avisos por mail o Telegram. Si un valor oscila de forma normal durante el arranque, lo dejamos documentado para que no genere alertas repetidas que nadie va a mirar.

  5. Entrega y traspaso

    La entrega incluye el tablero funcionando, la estructura de datos acordada y una explicación de cómo se leen las lecturas por turno y por máquina. El traspaso es al equipo de mantenimiento y al jefe de planta, que quedan con el mismo dato a la vista. Recién después se evalúa si tiene sentido extender el esquema a otras líneas.

El proceso no promete resultados numéricos ni plazos cerrados: cada línea tiene su propio punto de partida y su propio conjunto de sensores. Lo que sí se sostiene es el orden de los pasos, porque saltarse la planificación es la forma más rápida de terminar con otra planilla de Excel dando vueltas.

Uso de cookies

Usamos cookies para recordar tus preferencias y mejorar tu experiencia en el sitio. Puedes aceptar todas, rechazarlas o elegir qué permitir. Si quieres más detalles, revisa nuestra política de privacidad.