Integração de dados telemáticos com HTTP Push no IoT Logic

Em diferentes setores, as aplicações telemáticas muitas vezes precisam de mais contexto do que os dados do veículo e do dispositivo podem fornecer sozinhos. Por exemplo, pode ser necessário combinar a quilometragem com os registros da última manutenção de um sistema de manutenção. Há várias maneiras de reunir esses dados, e a escolha afeta a quantidade de código, infraestrutura e manutenção contínua necessária para a integração.

O enriquecimento via HTTP Push, adicionado recentemente ao IoT Logic da Navixy, oferece uma forma direta de incorporar dados externos ao processamento telemático. Vamos analisar mais de perto como ele funciona, o que é possível criar com ele e o que muda do ponto de vista da integração.

Então, o que é o enriquecimento via HTTP Push?

O enriquecimento via HTTP Push permite que um sistema externo envie dados diretamente ao Navixy IoT Logic, um ambiente low-code para processar e transformar dados telemáticos provenientes de dispositivos IoT e sistemas OEM.

O sistema externo envia uma solicitação HTTP com seus dados. Um mapeamento configurado associa os dados recebidos ao rastreador correspondente e disponibiliza os atributos para processamento no IoT Logic.

A telemetria do rastreador e os dados externos chegam de forma independente.

Digamos que um rastreador reporte:

hardware_mileage = 197450

enquanto um sistema de manutenção de frotas envia a quilometragem registrada na última manutenção:

{
  "vehicle_ref": "VEH-318",
  "odometer_at_service": 182300
}

Agora, os dois valores estão disponíveis no IoT Logic. Um fluxo pode calcular que o veículo percorreu 15.150 quilômetros desde a manutenção registrada e usar o resultado no processamento posterior.

O sistema de manutenção não se torna outra fonte de telemetria. Ele fornece as informações que possui, enquanto o rastreador continua reportando dados do veículo de forma independente.

O que os dados externos acrescentam a um fluxo telemático

Incorporar um valor externo ao IoT Logic é útil quando esse valor pode alterar o que o fluxo calcula, decide ou faz. Dois cenários mostram isso particularmente bem.

Para uma visão mais ampla das aplicações de negócio dessa abordagem, consulte nosso artigo sobre enriquecimento de dados de veículos.

Criar condições a partir de duas fontes de dados

Algumas regras operacionais precisam tanto de telemetria quanto de informações existentes em outros sistemas.

Digamos que um rastreador reporte que um veículo refrigerado entrou na geocerca de um depósito, enquanto um sistema externo fornece:

inspection_required = true

O IoT Logic pode avaliar as duas informações e usar o resultado para acionar a próxima etapa do fluxo de trabalho.

O mesmo padrão pode combinar localização, movimento, quilometragem, leituras de sensores ou outros dados telemáticos com permissões, atribuições, informações de manutenção, status operacionais e outros atributos externos.

A aplicação externa fornece o contexto que possui. O IoT Logic aplica esse contexto junto com os dados do rastreador, de modo que nenhum dos dois sistemas precise conter sozinho toda a regra operacional.

Acionar uma ação do lado da telemática a partir de outro sistema

Os dados externos também podem iniciar um fluxo de trabalho na outra direção.

Uma aplicação pode saber que algo precisa acontecer com um veículo, mas não ter um canal de comunicação direto com o rastreador. Por exemplo, outro sistema poderia enviar:

immobilization_requested = true

A solicitação pode entrar no IoT Logic por meio do HTTP Push. O fluxo pode avaliar quaisquer condições adicionais e, quando a configuração do fluxo e os recursos do rastreador permitirem, iniciar a ação correspondente no dispositivo.

A aplicação externa não precisa implementar por conta própria a camada de comunicação com o dispositivo. Ela fornece a solicitação no nível da lógica de negócio, enquanto a Navixy cuida da comunicação do lado da telemática.

Para desenvolvedores de soluções, isso cria uma separação útil. Uma aplicação voltada ao cliente pode participar de fluxos de trabalho relacionados a dispositivos sem precisar implementar também os protocolos dos rastreadores e a entrega de comandos.

Mapeamento de identificadores externos para rastreadores

O sistema de origem não precisa identificar um ativo da mesma forma que a Navixy. Um sistema de manutenção de frotas, por exemplo, pode já utilizar suas próprias referências de veículos:

VEH-318
VEH-319
VEH-320

Ao configurar o enriquecimento via HTTP Push, um parâmetro adequado dos dados recebidos pode ser usado como chave primária para mapear esses valores aos rastreadores:

VEH-318 → rastreador 12345
VEH-319 → rastreador 12346
VEH-320 → rastreador 12347

Assim, o sistema de manutenção pode continuar enviando um payload com base em seu próprio identificador:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

O IoT Logic usa o mapeamento configurado para vehicle_ref para associar os dados recebidos ao rastreador correspondente. Isso mantém a tradução dos identificadores no limite da integração, em vez de exigir que a aplicação de origem adote IDs de rastreadores ou outro identificador específico da Navixy.

Da infraestrutura de integração à lógica de negócio

Antes do enriquecimento via HTTP Push, os dados externos de negócio não podiam ser incorporados diretamente ao IoT Logic dessa forma. Para isso, poderia ser necessário um componente de integração entre a aplicação externa e o processamento telemático.

Mesmo um serviço relativamente simples pode precisar receber um payload, identificar o ativo, preparar os dados e encaminhá-los. O código é apenas uma parte do trabalho. O serviço também precisa ser implantado, hospedado, protegido, monitorado, atualizado, diagnosticado, documentado e mantido.

O HTTP Push transfere essa parte da integração para o IoT Logic. O sistema externo envia os dados, os mapeamentos configurados os associam aos rastreadores e o fluxo define o que acontece em seguida.

Em uma solução na qual um componente personalizado existiria principalmente para receber dados externos e conectá-los ao processamento telemático, o HTTP Push pode eliminar completamente um componente de infraestrutura. Para um TSP ou integrador que implanta soluções semelhantes para vários clientes, isso também significa um serviço a menos para implantar e manter em cada implementação.

Isso não elimina o trabalho de engenharia de integração. A estratégia de identificadores, os mapeamentos, os esquemas de atributos, as credenciais, os testes e o gerenciamento do ciclo de vida continuam importantes. O que muda é onde grande parte desse trabalho acontece: na configuração e na lógica de negócio, em vez de em outro serviço de software e em sua infraestrutura de suporte.

HTTP Push e outros mecanismos de integração da Navixy

HTTP Push, Navixy Generic Protocol e a API da Navixy têm funções diferentes.

Mecanismo	Função
Enriquecimento via HTTP Push	Incorporar atributos externos ao IoT Logic e associá-los a um rastreador existente para processamento junto com sua telemetria
Navixy Generic Protocol	Conectar uma fonte que atua como uma fonte telemática independente e fornece sua própria telemetria
API da Navixy	Criar, ler, atualizar e excluir entidades e configurações compatíveis da Navixy

A diferença entre HTTP Push e NGP é particularmente importante.

Com o NGP, o sistema conectado é a fonte de telemetria. Com o HTTP Push, a telemetria do rastreador já chega de forma independente, enquanto outro sistema fornece informações adicionais relacionadas a esse rastreador.

Essa diferença também estabelece um limite técnico. Os principais atributos de posicionamento, como coordenadas, velocidade, direção, número de satélites e HDOP, não podem ser sobrescritos por meio do enriquecimento via HTTP Push. Se outro sistema for a fonte real dessas medições, ele deve ser conectado como uma fonte de telemetria, em vez de ser tratado como uma fonte de enriquecimento.

A API da Navixy tem outra finalidade. Ela fornece operações CRUD programáticas para entidades e configurações compatíveis da plataforma, em vez de servir como uma entrada alternativa para processar dados externos arbitrários em um fluxo do IoT Logic.

Código de integração personalizado ainda pode ser necessário em casos excepcionais nos quais os mecanismos disponíveis na plataforma não atendam aos requisitos da integração. No entanto, ele não deveria ser necessário simplesmente porque um sistema de terceiros possui dados que precisam participar do processamento no IoT Logic.

A configuração ainda exige engenharia

Transferir a camada de transporte e mapeamento para a configuração não elimina o contrato de integração.

Considere um mapeamento como este:

VEH-318 → rastreador 12345

Se o rastreador for substituído ou o identificador externo mudar, o mapeamento também precisará ser alterado. Por isso, identificadores estáveis se tornam cada vez mais importantes à medida que a implantação cresce.

Os nomes e tipos dos atributos exigem a mesma disciplina. Nomes como:

maintenance_due
maintenance_work_order
odometer_at_service

são mais fáceis de manter do que campos genéricos como status, id ou value. E, se um fluxo espera:

{
  "maintenance_due": true
}

alterar o valor para "yes" muda o contrato da lógica que consome esses dados.

O HTTP Push usa uma chave de API, portanto a aplicação que envia os dados também precisa proteger essa credencial como um segredo de integração.

Durante a implementação inicial, o Data Stream Analyzer pode ajudar a verificar se o identificador, o mapeamento, os atributos e o processamento subsequente esperados chegam corretamente ao fluxo.

Para implantações maiores, o ciclo de vida dos mapeamentos, o tratamento de falhas, os limites de solicitações, o gerenciamento de credenciais e o monitoramento devem ser considerados antes da implementação. Quando a documentação atual não especificar um determinado limite ou comportamento, verifique-o para a implantação em questão em vez de projetar a solução com base em uma suposição.

Configuração do enriquecimento via HTTP Push

O enriquecimento via HTTP Push é configurado no nó Data Source do IoT Logic.

Selecione os rastreadores que devem receber os dados externos e configure o HTTP Push como fonte de dados de software. Depois que o fluxo for salvo, o IoT Logic fornece a URL do HTTP Push usada pela aplicação externa. As solicitações são autenticadas com uma chave de API.

Em seguida, escolha o parâmetro recebido que será usado como chave primária e configure seus mapeamentos para os rastreadores correspondentes:

VEH-318 → rastreador 12345
VEH-319 → rastreador 12346
VEH-320 → rastreador 12347

A aplicação externa pode então enviar:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

O IoT Logic resolve VEH-318 por meio do mapeamento configurado e disponibiliza os atributos enviados para processamento junto com os dados que chegam de forma independente do rastreador.

Para consultar os campos exatos de configuração e os requisitos atuais do HTTP Push, consulte a documentação sobre enriquecimento via HTTP Push.

O contexto externo passa a fazer parte da lógica telemática

O HTTP Push fornece aos dados externos de negócio uma entrada direta no IoT Logic. Esses dados podem participar de condições junto com a telemetria do rastreador ou iniciar fluxos de trabalho que continuam do lado da telemática.

Para integradores e desenvolvedores de soluções, isso também pode eliminar uma infraestrutura cuja única função seria incorporar esses atributos externos ao processamento telemático. O trabalho de engenharia permanece concentrado nos mapeamentos, nas condições e nas ações que tornam úteis os dados combinados.

Tem um cenário que combina dados externos com telemetria? Entre em contato com nossa equipe para conversar sobre como implementá-lo com o IoT Logic.