Enriquecimiento de datos del vehículo a través de sistemas empresariales

Una plataforma de flotas ya conoce mucho sobre el vehículo. Un sistema de pago, la aplicación del proveedor de baterías o un directorio de conductores conocen algo más que puede ser igual de importante. A menudo, estos sistemas no comparten naturalmente lo que saben, por lo que las decisiones se toman sin el contexto completo.

Conectar esas piezas que faltan solía significar desarrollar otra integración. Con IoT Logic, muchas de ellas pueden simplemente formar parte del flujo de datos del vehículo.

Todo un proyecto de integración de datos detrás de unos pocos campos adicionales

Y esas piezas faltantes pueden ser sorprendentemente pequeñas, por ejemplo, un ID de activo almacenado en un ERP, una categoría de servicio asignada por un equipo de operaciones o una referencia de contrato desde un CRM. Ninguna de ellas es particularmente interesante por sí sola, pero cada una puede volverse útil cuando está disponible junto con los datos del vehículo.

Nada de esto suena a un proyecto de integración de datos. Sin embargo, incluso obtener unos pocos valores de un sistema a otro tradicionalmente ha requerido que alguien defina el alcance de la conexión, la construya, la pruebe y la mantenga.

La empresa podría necesitar tres campos adicionales. La respuesta técnica puede terminar siendo otra integración personalizada.

IoT Logic ofrece otra ruta para el enriquecimiento de datos del vehículo. Un sistema externo puede enviar atributos adicionales a un dispositivo que ya se rastrea en la plataforma. Los datos entrantes se asignan al dispositivo correcto y se unen a su flujo de datos existente, donde pueden utilizarse en un procesamiento y automatización posteriores.

El formato de la solicitud y los detalles de autenticación se describen en la documentación técnica. Aquí, veremos qué sucede con los datos una vez que llegan a la plataforma.

Cómo se integra la data externa en el flujo de datos del vehículo

Los datos entrantes primero deben encontrar el vehículo correcto. El sistema externo los envía con un identificador, e IoT Logic usa la asignación configurada para hacer coincidir ese identificador con un dispositivo ya registrado en la plataforma. Los nuevos atributos luego se unen al flujo de datos del dispositivo junto con la telemetría que ya informa.

Nada cambia en el lado del dispositivo. El rastreador continúa reportando como antes, mientras que IoT Logic puede usar los atributos adicionales en cálculos, condiciones, automatizaciones y procesamiento posterior.

Normalmente, un flujo de telemetría comienza con el dispositivo. El rastreador envía un nuevo mensaje y ese mensaje pasa por IoT Logic para su procesamiento. Los eventos en otros sistemas no necesariamente siguen ese ritmo. Un pago puede confirmarse, un estado puede cambiar o un servicio externo puede generar un valor nuevo mientras el vehículo no tiene nada nuevo que reportar.

HTTP Push permite que esos datos ingresen al flujo cuando sucede el evento externo, en lugar de esperar el siguiente mensaje del dispositivo. Por ejemplo, una confirmación de pago puede llegar cuando se aprueba la transacción y formar parte de la lógica que determina qué sucede a continuación.

Enriquecimiento de datos de vehículos en flujos de trabajo reales

Lo que sucede a continuación depende de para qué la flota necesita esos datos adicionales. El estado de un pago puede determinar si un vehículo puede desbloquearse, las condiciones climáticas pueden cambiar cómo se evalúa la telemetría, mientras que los datos de un sistema comercial interno o de una plataforma OEM pueden agregar contexto que el rastreador no proporciona.

Los ejemplos siguientes describen esos escenarios dentro de IoT Logic. Los flujos son ilustrativos en lugar de configuraciones específicas, ya que los atributos, condiciones y acciones exactos dependerán del sistema externo, los dispositivos involucrados y el flujo de trabajo que se esté construyendo.

La confirmación de pago puede convertirse en una acción del vehículo

Considere un operador de movilidad compartida que necesite que el pago y el acceso al vehículo ocurran como un solo proceso. El proveedor de pagos sabe cuándo se ha aprobado una transacción, mientras que la plataforma de flotas sabe qué vehículo el cliente está tratando de usar. Sin una conexión entre ambos, el pago y el control del vehículo siguen siendo flujos de trabajo separados.

El proveedor de pagos puede enviar el estado de la transacción junto con un identificador que lo asocie al vehículo correspondiente. Una vez que ese estado entra en el flujo de datos del vehículo, IoT Logic puede usarlo como parte de la lógica que determina lo que sucede a continuación.

Por ejemplo, un pago confirmado podría permitir que se envíe un comando de desbloqueo al vehículo. Un pago rechazado o inexistente dejaría el vehículo bloqueado. El operador obtiene un único flujo automatizado en lugar de tener que coordinar el sistema de pago y el control del vehículo por separado.

Ejemplo de flujo IoT Logic

Un posible flujo podría verse así:

Proveedor de pagos → HTTP Push → Asignar transacción a vehículo → Verificar estado de pago → Enviar comando de desbloqueo

El sistema externo envía un atributo como payment_status para el vehículo asignado. IoT Logic evalúa el valor y, cuando se cumplen las condiciones necesarias, dirige el mensaje al nodo responsable de enviar el comando al dispositivo.

En un flujo de producción, un operador normalmente agregaría sus propias medidas de seguridad en torno a esa lógica, como verificar la referencia de la transacción, el estado del vehículo u otras condiciones requeridas por el servicio.

Los datos meteorológicos pueden hacer que las reglas del vehículo sean menos rígidas

Las reglas del vehículo a menudo funcionan con umbrales fijos. Eso sirve hasta que las condiciones alrededor del vehículo cambian.

Una flota puede tolerar un cierto patrón de velocidad, frenado o movimiento en una vía seca y querer una respuesta diferente bajo lluvia intensa, hielo o visibilidad reducida. El servicio meteorológico tiene ese contexto, pero el rastreador en sí no necesita medirlo.

Al enriquecer los datos del vehículo con las condiciones actuales de una fuente meteorológica externa, IoT Logic puede incluir ese contexto al evaluar la telemetría del vehículo. El mismo comportamiento del vehículo puede producir resultados diferentes según las condiciones en las que se produzca.

Para un operador, esto abre la puerta a reglas más situacionales sin requerir otra fuente de telemetría desde el propio vehículo.

Ejemplo de flujo IoT Logic

Un flujo ilustrativo podría ser:

Servicio meteorológico → HTTP Push → Asignar condiciones a vehículo → Combinar con telemetría del vehículo → Aplicar lógica específica de la condición → Alerta o acción

El servicio externo podría proporcionar atributos que describan la precipitación, visibilidad, temperatura o condiciones de la vía. IoT Logic puede usar esos valores junto con la telemetría entrante del vehículo en cálculos o lógica condicional.

Por ejemplo, una regla podría aplicar un umbral de velocidad diferente cuando un atributo meteorológico asignado indique condiciones severas. Los umbrales y la respuesta exactos continuarían siendo una decisión del negocio, más que algo prescrito por el propio mecanismo de enriquecimiento.

Los registros empresariales pueden viajar con los datos del vehículo

No todos los casos de uso de enriquecimiento necesitan controlar el vehículo. A veces, la información útil ya está en un sistema empresarial interno, pero demasiado alejada de los datos operativos.

Una empresa puede mantener asignaciones de vehículos, categorías de servicio, referencias de contrato, equipos responsables u otros atributos operativos en su ERP, CRM o aplicación interna. El personal de flotas puede necesitar parte de esa información al revisar la actividad del vehículo o ejecutar procesos automatizados, incluso si no tiene nada que ver con lo que mide el rastreador.

En lugar de reproducir esos registros manualmente en la plataforma de flotas, los valores relevantes pueden enviarse al vehículo asignado. Luego, pasan a estar disponibles junto a su telemetría y pueden participar en el procesamiento, la generación de informes o la entrega de datos a otros sistemas.

Este es el enriquecimiento de datos del vehículo en su forma más discreta. Nada dramático le sucede al vehículo, pero la telemetría se vuelve mucho más útil para las personas y sistemas que la consumen.

Ejemplo de flujo IoT Logic

Un flujo básico podría lucir así:

ERP / CRM / sistema interno → HTTP Push → Asignar atributos empresariales al vehículo → Datos del vehículo enriquecidos → Procesamiento o destino posterior

Por ejemplo, un sistema interno podría enviar un contract_id, service_type u otro atributo operativo asociado con el vehículo. IoT Logic puede conservar ese contexto a medida que los datos del vehículo avanzan por el flujo, lo que permite que la lógica subsiguiente o los sistemas posteriores trabajen tanto con la telemetría como con la información empresarial.

Qué atributos pertenecen al flujo depende de la operación. El objetivo no es copiar todo el registro de CRM o ERP en la plataforma de flotas, sino trasladar los pocos valores que hagan que los datos del vehículo sean más útiles.

Los datos de batería de OEM pueden cubrir lagunas en la telemetría del rastreador

Los datos de batería son un caso ligeramente diferente porque muchos rastreadores ya informan parámetros relacionados con la batería. La diferencia valiosa aparece cuando un fabricante de vehículos eléctricos (OEM) o un sistema de gestión de baterías (BMS) tiene información que el dispositivo telemático instalado no proporciona.

Una plataforma OEM podría exponer información adicional sobre el estado de carga, el estado de salud de la batería, el estado de carga o algún otro parámetro de la batería a través de su propio sistema. Por sí sola, esa información vive separada de la telemetría GPS y operativa del vehículo.

Enviar los valores relevantes al vehículo asignado une ambas fuentes sin cambiar la forma en que el rastreador informa. Las operaciones de flota pueden entonces trabajar con la ubicación, el movimiento y el contexto de la batería adicional en el mismo flujo de datos.

Para una flota de vehículos eléctricos, eso puede ser mucho más útil que tratar el portal OEM y la plataforma de flotas como dos lugares separados para ver qué sucede con el mismo vehículo.

Ejemplo de flujo IoT Logic

Un posible flujo es:

OEM / BMS platform → HTTP Push → Asignar datos al vehículo → Agregar atributos de batería → Combinar con la telemetría del rastreador → Procesamiento, alerta o sistema posterior

Supongamos que el sistema OEM proporciona un parámetro de batería que el rastreador no brinda. Puede enviar ese valor como un atributo adicional para el vehículo asignado. IoT Logic tiene entonces la telemetría nativa del rastreador y los datos de batería suministrados externamente disponibles en el mismo flujo.

A partir de ahí, la flota puede aplicar su propia lógica. Podría dirigir los datos enriquecidos a otro sistema, evaluar una condición relacionada con la batería junto con la actividad del vehículo o usar el parámetro adicional como contexto para una alerta operativa.

En todos estos ejemplos, los datos externos juegan diferentes roles, pero el vehículo sigue siendo el punto que conecta todo. El estado de pago puede conducir a una acción, los datos meteorológicos pueden afectar una regla, los atributos empresariales pueden agregar contexto operativo y los datos OEM pueden cubrir una brecha en la telemetría disponible del rastreador.

En cada caso, los datos externos se asignan a un dispositivo reconocido y se agregan junto con la telemetría que ya reporta. No reemplazan la función de GPS o datos de estado nativos del dispositivo. Esto mantiene el enriquecimiento de datos del vehículo enfocado en agregar el contexto que necesita un flujo de trabajo, mientras el vehículo permanece en el centro del flujo de datos.

Cuando otra fuente de datos ya no significa otra integración

Para los socios e integradores de sistemas, esto cambia una conversación familiar con un cliente. “¿Podemos traer estos datos también a Navixy?” ya no tiene que llevar inmediatamente a “Necesitaremos crear otra integración.”

A veces, una integración personalizada seguirá siendo la respuesta correcta. Pero cuando el sistema externo puede enviar los datos que IoT Logic necesita, una solicitud que antes parecía un proyecto de desarrollo puede estar mucho más cerca de ser una tarea de configuración.

Esto hace que valga la pena considerar incluso ideas de enriquecimiento más pequeñas. La pregunta ya no es sólo si se justifica un nuevo proyecto de integración de datos, sino si agregar ese contexto adicional al flujo de datos del vehículo podría hacer que un flujo de trabajo existente funcione mejor.

¿Quiere ver cómo el enriquecimiento de datos del vehículo podría funcionar para su empresa? Póngase en contacto con nuestro equipo, y lo ayudaremos a explorar su caso de uso y responder sus preguntas.