Localización de activos con autorreparación: cómo la automatización redujo las intervenciones de campo en un 80%

Los rastreadores rara vez fallan todos a la vez. Con mayor frecuencia, continúan enviando informes mientras pierden gradualmente la calidad de datos de la cual dependen las operaciones de la flota. Este estudio de caso muestra cómo una terminal de contenedores automatizó la recuperación de dispositivos con la plantilla Device Health Check en Navixy IoT Logic, reduciendo un 80% el trabajo manual de recuperación, y cómo el mismo enfoque puede evolucionar hasta convertirse en un marco mucho más completo de supervisión de la salud de los dispositivos.

Cuando los rastreadores siguen en línea pero dejan de ser confiables

En telemática, en línea no siempre significa saludable. Un rastreador puede continuar enviando datos mientras pierde progresivamente la capacidad de proporcionar posicionamiento fiable, informar un suministro de energía estable o comunicarse consistentemente. Los despachadores siguen viendo el vehículo. Los equipos de mantenimiento siguen recibiendo la telemetría. Sin embargo, tarde o temprano alguien debe responder a una pregunta familiar: ¿Este rastreador simplemente necesita reiniciarse o existe un problema de hardware real detrás de los síntomas?

Responder esa pregunta manualmente para cada dispositivo sospechoso se convierte rápidamente en trabajo rutinario en flotas grandes. El desafío no es que los rastreadores se comporten de forma anómala de vez en cuando; eso sucede en todas las implementaciones. El desafío es reconocer esas situaciones de manera constante y responder antes de que se conviertan en tickets de soporte o en visitas de campo innecesarias.

La automatización cambia ese proceso. La telemetría entrante puede evaluarse de forma continua, los dispositivos con problemas pueden identificarse automáticamente y el primer paso de recuperación puede ejecutarse sin esperar la intervención humana. Luego, los técnicos se ocupan de los casos que la automatización no puede resolver, que normalmente son aquellos donde su experiencia aporta mayor valor.

Learn more about ready-made automations with IoT Logic:

• Automated idling response
• Driver access control

Automatización de la salud del dispositivo sin empezar desde cero

Crear este tipo de flujo de trabajo no es particularmente difícil. Sin embargo, es repetitivo. Cada implementación necesita recibir telemetría, evaluar la salud del dispositivo, decidir si se requiere recuperación, ejecutar la acción adecuada y continuar procesando.

La plantilla Device Health Check en Navixy IoT Logic ya proporciona ese flujo de trabajo. En lugar de diseñar la lógica desde cero, los ingenieros pueden adaptar las condiciones de salud y las acciones de recuperación para que coincidan con sus dispositivos y entorno operativo.

A grandes rasgos, el flujo de trabajo sigue siendo el mismo independientemente de la flota:

1. Recibir la telemetría entrante.
2. Evaluar las condiciones de salud configuradas.
3. Continuar el procesamiento normal si el dispositivo está sano.
4. Ejecutar las acciones de recuperación configuradas si no lo está.

La plantilla está diseñada para adaptarse, no para desplegarse sin cambios. Diferentes flotas experimentan diferentes modos de falla, utilizan distinto hardware y definen “saludable” de forma diferente. El flujo de trabajo se mantiene igual mientras que el modelo de salud evoluciona.

Caso de estudio: adaptar la plantilla para vehículos de una terminal portuaria

Una terminal de contenedores de tamaño mediano operaba una flota mixta de tractores de terminal, reach stackers, manipuladores de contenedores, montacargas y vehículos de servicio.

La flota utilizaba rastreadores GPS Teltonika con capacidad de supervisión de alimentación externa, telemetría configurable, integración CAN y ejecución remota de comandos. Aunque este caso se centra en el hardware de Teltonika, el enfoque general se aplica a cualquier rastreador que admita administración remota.

La implementación abarcó vehículos con alimentación continua que reportan telemetría de forma ininterrumpida y pueden recibir comandos remotos. Los rastreadores de activos con batería que operan en modo de sueño profundo requieren una estrategia de supervisión diferente.

El desafío operativo

El equipo de mantenimiento se encontraba repetidamente con el mismo patrón. Un rastreador parecía comportarse de forma inusual. Seguía en línea, pero algo no funcionaba correctamente. La recepción GNSS se degradaba entre las pilas de contenedores. La energía externa se volvía inestable después del servicio. A veces el rastreador simplemente dejaba de producir datos de posicionamiento confiables mientras seguía conectado a la plataforma.

Cada caso seguía esencialmente el mismo proceso. Alguien revisaba la telemetría, decidía si valía la pena intentar un reinicio remoto, enviaba el comando y luego comprobaba si el dispositivo volvía a funcionar con normalidad o si era necesario realizar una inspección física.

Ninguno de estos incidentes justificaba por sí mismo un proyecto de software. Sin embargo, en conjunto, representaban un flujo constante de trabajo de mantenimiento rutinario que consumía tiempo de ingeniería sin aportar mucho valor.

Empezar con la plantilla estándar de Device Health Check

En lugar de crear un flujo de trabajo personalizado, el equipo comenzó con la plantilla estándar Device Health Check incluida en Navixy IoT Logic.

Desde el primer momento, la plantilla evalúa cuatro condiciones básicas de salud:

latitude != null &&
longitude != null &&
satellites >= 4 &&
board_voltage >= 11.5

Si la expresión se evalúa como TRUE, la telemetría continúa por la ruta de procesamiento normal.

Si se evalúa como FALSE, la telemetría aún se reenvía, mientras que el flujo de trabajo también ejecuta la acción de recuperación configurada. La plantilla estándar incluye acciones de reinicio para dispositivos Teltonika (cpureset) y Jimi/Concox (RESET#), lo que le permite admitir diferentes familias de hardware desde el principio.

Dado que la flota de la terminal consistía exclusivamente en dispositivos Teltonika, el equipo simplemente eliminó el nodo de reinicio Jimi y mantuvo la acción de recuperación de Teltonika.

La verificación de salud en sí requirió solo tres ajustes. El parámetro genérico board_voltage se sustituyó por el atributo específico de Teltonika external_voltage. El umbral de satélites aumentó de cuatro a cinco. Finalmente, el equipo agregó una condición HDOP para mejorar la validación GNSS en un entorno donde las grúas, las pilas de contenedores y mucho acero hacen que la recepción satelital, como bien saben los ingenieros portuarios, sea algo impredecible.

La condición de salud resultante fue:

external_voltage >= 11.5 &&
latitude != null &&
longitude != null &&
satellites >= 5 &&
(hdop == null || hdop < 2.5)

Todo lo demás se mantuvo sin cambios.

¿Cuál fue el resultado?

La prueba piloto de 90 días redujo las intervenciones manuales de recuperación de rastreadores aproximadamente en un 80%. Más importante aún, cambió el propio flujo de trabajo de mantenimiento. Los dispositivos que cumplían los criterios de recuperación predefinidos se reiniciaban automáticamente, a menudo antes de que alguien notara el problema. Los equipos de mantenimiento solo intervenían cuando la recuperación automatizada fallaba o cuando las condiciones de salud sugerían un problema de hardware en lugar de un fallo temporal de software.

Las solicitudes rutinarias de reinicio prácticamente desaparecieron. Los técnicos dedicaron menos tiempo a revisar telemetría que finalmente conducía a la misma acción de recuperación, mientras que las visitas de campo se centraron cada vez más en fallas reales de hardware, como antenas dañadas, cableado inestable o problemas de energía. La automatización no eliminó el trabajo de mantenimiento, sino solo aquel que no requería criterio humano.

La implementación descrita arriba es intencionadamente sencilla y, para muchas flotas, ese nivel de automatización es suficiente para brindar un valor inmediato.

Sin embargo, las terminales portuarias están entre los entornos más exigentes para los dispositivos telemáticos. Al observar más de cerca esas condiciones de operación, surgen oportunidades de construir modelos de salud de los dispositivos mucho más completos, sin dejar de usar el mismo flujo de trabajo subyacente.

Diseñar un modelo de salud de dispositivo más completo

Como se mencionó, el caso de estudio anterior demuestra una implementación deliberadamente simple. Con solo unos pocos ajustes en las condiciones de salud predeterminadas, la terminal automatizó una parte importante del trabajo de recuperación rutinario.

Esto lleva de forma natural a la siguiente pregunta. Si se obtiene tanto valor al supervisar cuatro o cinco parámetros, ¿qué sucede cuando el modelo de salud refleja el entorno operativo con más detalle?

Las terminales portuarias proporcionan un buen ejemplo.

Los vehículos pasan sus jornadas entre pilas de contenedores, grúas, almacenes y grandes estructuras de acero. Las condiciones GNSS cambian constantemente. El cableado está expuesto a vibraciones. Se producen interrupciones de energía durante el mantenimiento. La comunicación CAN puede desaparecer aunque el rastreador en sí continúe en línea.

Ninguna de estas situaciones indica necesariamente que el rastreador esté dañado. Sin embargo, en conjunto, proporcionan una imagen mucho más completa de la salud del dispositivo que la que ofrecen únicamente la latitud, la longitud, la cantidad de satélites y el voltaje. En lugar de rediseñar el flujo de trabajo, los ingenieros simplemente amplían el modelo de salud.

Una implementación típica evalúa cuatro grupos de parámetros:

Health area	Typical parameters
GNSS	Satellite count, HDOP, fix validity, age of last valid position
Power	External voltage, backup battery, ignition state, voltage stability
Communication	Signal quality, reconnect count, packet frequency, time since last communication
Vehicle interface	CAN availability, freshness of engine data, digital inputs

Estos grupos no representan un estándar universal, sino una forma práctica de describir los aspectos del comportamiento del dispositivo que son relevantes para este tipo de flota.

Construir la lógica de salud

Una vez que la telemetría necesaria está disponible, existen dos formas comunes de diseñar la verificación de salud.

Un enfoque define cómo luce un rastreador saludable.

El nodo If-then simplemente evalúa si la telemetría entrante coincide con las condiciones de operación esperadas.

Por ejemplo:

external_voltage >= 11.5 &&
communication_status == "stable" &&
gnss_quality == "good" &&
can_available == true

Si la expresión se evalúa como TRUE, el flujo de trabajo continúa con normalidad.

Si se evalúa como FALSE, el rastreador ha salido de su estado operativo esperado y la rama de recuperación entra en acción.

El segundo enfoque parte de la dirección opuesta.

En lugar de describir el comportamiento saludable, describe patrones de falla específicos que deben desencadenar una acción.

Por ejemplo:

external_voltage >= 11.5 &&
communication_status == "stable" &&
gnss_quality == "poor" &&
gnss_bad_duration_min > 10

Aquí, el rastreador todavía tiene energía y permanece conectado, pero la calidad GNSS ha sido deficiente el tiempo suficiente para sugerir que el subsistema de posicionamiento necesita atención.

En la práctica, ambos enfoques funcionan bien en conjunto.

La verificación de salud primero responde a una pregunta simple:

"¿Está el rastreador sano?"

Si la respuesta es no, reglas adicionales determinan la causa y seleccionan la acción de recuperación más adecuada. Mantener estas dos decisiones por separado hace que el flujo de trabajo sea más fácil de entender y más sencillo de ampliar a medida que surgen nuevos patrones de falla.

Cuando la telemetría no es suficiente

Diseñar el modelo de salud a menudo revela otra realidad.

Los parámetros que se desean no siempre son los que el rastreador proporciona.

Algunos dispositivos reportan la cantidad de satélites pero no ofrecen un indicador significativo de la calidad del posicionamiento. Otros proporcionan el voltaje pero no indican si el suministro de energía ha sido estable. Un tercer rastreador puede exponer cada marca de tiempo de comunicación, pero nunca informar que la conexión se ha vuelto poco confiable.

Aquí es donde el nodo Initiate Attribute resulta útil.

En lugar de construir expresiones cada vez más complejas dentro de la verificación de salud en sí, los ingenieros pueden crear atributos operativos de nivel superior antes de que Device Health Check evalúe la telemetría.

El flujo de trabajo se convierte en:

Incoming telemetry
        │
        ▼
Initiate Attribute
(create operational attributes)
        │
        ▼
Device Health Check
        │
        ▼
Recovery actions

Piense en el nodo Initiate Attribute como una capa de traducción.

La telemetría en bruto describe lo que el rastreador reporta.

Los atributos operativos describen lo que significan esas mediciones.

Ejemplo: derivar la calidad GNSS

Suponga que el rastreador informa:

• latitude, • longitude, • satellite count, • HDOP.

En lugar de evaluar los cuatro valores en todo el flujo de trabajo, el nodo Initiate Attribute puede combinarlos en un solo atributo:

gnss_quality

Por ejemplo:

Input telemetry	Derived value
Missing coordinates	Poor
Satellite count below 5	Poor
HDOP ≥ 4	Poor
HDOP between 2.5 and 4	Degraded
Otherwise	Good

La verificación de salud ahora evalúa:

gnss_quality == "good"

en lugar de interpretar varios valores de telemetría cada vez que llega un mensaje.

El mismo principio se aplica a la calidad de la comunicación, la estabilidad de la alimentación, la disponibilidad CAN o cualquier otro indicador operativo. Una vez que existen estos atributos, la lógica de salud se vuelve más fácil de leer, mantener y adaptar cuando cambia la definición de un rastreador “saludable”.

Esa es una distinción importante.

El flujo de trabajo no se vuelve más complicado.

La comprensión de la salud del dispositivo se vuelve más sofisticada, mientras que el flujo de trabajo en sí permanece casi sin cambios.

Una forma diferente de pensar en la salud del dispositivo

El resultado más interesante de este proyecto no es solo la reducción del 80% en el trabajo de recuperación manual. Es el cambio de preguntar si un rastreador está en línea a preguntar si sus datos siguen siendo confiables.

Esa distinción importa porque la telemática moderna respalda la operación de despacho, mantenimiento, cumplimiento, análisis de utilización y planificación operativa. Un dispositivo conectado puede continuar informando mientras gradualmente produce datos incompletos o poco fiables. Desde la perspectiva de la plataforma, está en línea. Desde la perspectiva operativa, ya ha comenzado a fallar.

La supervisión de la salud del dispositivo cambia esa conversación. En lugar de reaccionar cuando alguien detecta un problema, los operadores definen qué significa “saludable” para su flota, monitorean esas condiciones de manera continua y automatizan la primera respuesta cuando un rastreador se sale de esos parámetros. La plantilla Device Health Check ofrece un punto de partida práctico para ese enfoque. A medida que evolucionan los requisitos, el modelo de salud se vuelve más sofisticado mientras que el flujo de trabajo subyacente sigue resultando familiar.

La lección más amplia va mucho más allá de las terminales portuarias. Cada flota tiene su propia definición de un dispositivo saludable porque cada flota depende de datos diferentes para mantener sus operaciones en funcionamiento eficiente. La tecnología continuará evolucionando, pero el principio sigue siendo el mismo. Mejores decisiones operativas comienzan con telemetría confiable, y la telemetría confiable comienza con comprender la salud del dispositivo.

Si está explorando la supervisión automatizada de la salud de los dispositivos para su flota, contáctenos para analizar su caso de uso y descubrir cómo este enfoque podría integrarse en sus flujos de trabajo de telemática.