Pular para o conteúdo principal

Como o dex-embedded funciona

O gateway (dex-gateway) é um programa único, escrito em Rust, que roda como serviço no MDVR. Ele escuta os relógios por Bluetooth, resolve quem é o operador, guarda tudo localmente e entrega os eventos ao software do parceiro.

relógio ──BLE──▶ dex-gateway ──▶ API local (gRPC) ──▶ software do parceiro
                     │      └──▶ MQTT (opcional)
                     └─────────▶ nuvem Dersalis (incidentes e telemetria)

Quatro decisões de projeto​

1. O Bluetooth só escuta, nunca conecta​

O relógio já transmite, em cada anúncio Bluetooth, tudo que o gateway precisa: jornada, incidente, status. O gateway só observa esses anúncios (scan passivo). Isso evita o custo e a fragilidade de manter uma conexão por dispositivo, e não exige nenhum pareamento.

2. O operador é identificado dentro do equipamento​

O anúncio do relógio traz só um prefixo do identificador do colaborador, que não basta para resolvê-lo sozinho. O gateway baixa da nuvem a lista de colaboradores e monitoramentos da empresa e a mantém em memória; cada evento é resolvido contra essa lista na hora, sem ir à rede.

Por isso o equipamento continua tratando o status do operador mesmo com a conexão caída: só a atualização da lista depende da nuvem. Ela é disparada quando um operador começa a jornada, e não o tempo todo.

3. O seu software recebe eventos já resolvidos​

O seu software nunca vê Bluetooth nem identificadores internos. O contrato é uma API local (gRPC, 127.0.0.1, só acessível de dentro do equipamento) com os campos já resolvidos: a matrícula do operador e o nome do monitoramento. O contrato é versionado: dentro da versão v1 só se acrescentam campos.

Quem não quer compilar uma biblioteca gRPC no equipamento usa o dex-events, que entrega os mesmos eventos como uma linha JSON por evento. Quem prefere um barramento publica por MQTT.

4. Tudo é gravado antes de ser entregue​

Cada evento vai para uma fila local durável (SQLite) assim que é decodificado e resolvido, com eliminação de duplicatas: o relógio repete o mesmo incidente a cada poucos segundos enquanto ele está ativo, e isso vira um único registro, atualizado conforme o incidente evolui.

Essa fila desacopla a captura Bluetooth da API local e do envio à nuvem: uma queda de rede ou um software do parceiro fora do ar não perde nada.

O que fica no equipamento​

  • Jornada do gateway: o contêiner a que incidentes, status e testes de atenção pertencem. O software do parceiro a controla dizendo qual operador acompanhar e quando o turno termina.
  • Retenção: os dados vivem com a jornada. Depois dela, o gateway apaga o que já foi entregue à nuvem e confirmado pelo parceiro, para o armazenamento do equipamento não crescer sem limite.
  • Privacidade: o nome do operador não é armazenado. O resultado do teste de atenção é dado de saúde: só circula pela API local e, se o parceiro ligar a telemetria, pela nuvem, e nunca é escrito em log.

E a nuvem?​

O gateway envia à nuvem Dersalis os incidentes (já identificados) em segundo plano, de forma leve. Há também uma telemetria opcional (posição do veículo, estado do gateway e dos relógios), desligada por padrão. O gateway não depende da nuvem para entregar eventos ao seu software.

Próximos passos​