Aller au contenu principal

Comment fonctionne dex-embedded

La passerelle (dex-gateway) est un programme unique, écrit en Rust, qui s'exécute comme service sur le MDVR. Elle écoute les montres par Bluetooth, détermine qui est l'opérateur, conserve tout localement et remet les événements au logiciel du partenaire.

montre ──BLE──▶ dex-gateway ──▶ API locale (gRPC) ──▶ logiciel du partenaire
                     │      └──▶ MQTT (optionnel)
                     └─────────▶ cloud Dersalis (incidents et télémétrie)

Quatre décisions de conception​

1. Le Bluetooth écoute seulement, ne se connecte jamais​

La montre transmet déjà, dans chaque annonce Bluetooth, tout ce dont la passerelle a besoin : service, incident, état. La passerelle ne fait qu'observer ces annonces (scan passif). Cela évite le coût et la fragilité d'une connexion par appareil, et n'exige aucun appairage.

2. L'opérateur est identifié à l'intérieur de l'équipement​

L'annonce de la montre ne porte qu'un préfixe de l'identifiant du collaborateur, insuffisant pour le résoudre seul. La passerelle télécharge depuis le cloud la liste des collaborateurs et des surveillances de l'entreprise et la garde en mémoire ; chaque événement est résolu par rapport à cette liste sur-le-champ, sans passer par le réseau.

C'est pourquoi l'équipement continue de traiter l'état de l'opérateur même sans connexion : seule la mise à jour de la liste dépend du cloud. Elle est déclenchée lorsqu'un opérateur commence son service, et non en permanence.

3. Votre logiciel reçoit des événements déjà résolus​

Votre logiciel ne voit jamais de Bluetooth ni d'identifiants internes. Le contrat est une API locale (gRPC, 127.0.0.1, accessible uniquement depuis l'équipement) avec des champs déjà résolus : le matricule de l'opérateur et le nom de la surveillance. Le contrat est versionné : dans la version v1, on n'ajoute que des champs.

Qui ne veut pas compiler une bibliothèque gRPC sur l'équipement utilise dex-events, qui fournit les mêmes événements sous forme d'une ligne JSON par événement. Qui préfère un bus publie par MQTT.

4. Tout est enregistré avant d'être remis​

Chaque événement entre dans une file locale durable (SQLite) dès qu'il est décodé et résolu, avec dédoublonnage : la montre répète le même incident toutes les quelques secondes tant qu'il est actif, et cela devient un seul enregistrement, mis à jour au fil de l'évolution de l'incident.

Cette file découple la capture Bluetooth de l'API locale et de l'envoi au cloud : une coupure réseau ou un logiciel partenaire hors service ne fait rien perdre.

Ce qui reste sur l'équipement​

  • Service de la passerelle : le conteneur auquel appartiennent incidents, états et tests d'attention. Le logiciel du partenaire le pilote en indiquant quel opérateur suivre et quand le service se termine.
  • Rétention : les données vivent avec le service. Ensuite, la passerelle supprime ce qui a été remis au cloud et confirmé par le partenaire, pour que le stockage de l'équipement ne croisse pas sans limite.
  • Confidentialité : le nom de l'opérateur n'est pas conservé. Le résultat du test d'attention est une donnée de santé : il ne circule que par l'API locale et, si le partenaire active la télémétrie, par le cloud, et n'est jamais écrit dans les journaux.

Et le cloud ?​

La passerelle envoie au cloud Dersalis les incidents (déjà identifiés) en arrière-plan, de façon légère. Il existe aussi une télémétrie optionnelle (position du véhicule, état de la passerelle et des montres), désactivée par défaut. La passerelle ne dépend pas du cloud pour remettre les événements à votre logiciel.

Prochaines étapes​