Tester la capacité et la reconnexion d’une passerelle BLE multicapteur
La réponse à « Combien de capteurs BLE une passerelle peut-elle gérer ? » doit préciser la charge de travail. Dix capteurs envoyant un rapport par minute posent un autre problème que dix appareils émettant des rafales toutes les 20 millisecondes. Une spécification de capacité défendable identifie les limites radio et logicielles, démontre la fraîcheur des données à la charge requise et mesure la reprise lorsque plusieurs capteurs disparaissent simultanément.
Choisir entre collecte connectée et collecte par annonces
Une passerelle GATT connectée maintient des liaisons, s’abonne à des caractéristiques et peut envoyer des commandes de configuration. Un collecteur d’annonces écoute des rapports sans connexion. Bluetooth Mesh utilise encore un autre modèle de communication et de provisionnement. Ces architectures ont des propriétés différentes de découverte, de livraison et de sécurité ; leurs nombres de nœuds ne sont pas interchangeables.
Commencez par inventorier les appareils : protocole et révision du firmware, format des rapports, fréquence d’échantillonnage, longueur des rafales, possibilité de connexion, exigences d’appairage et âge maximal des données. Décidez si les échantillons historiques manquants doivent être récupérés ou si la mesure la plus récente suffit. Pour la collecte par annonces, l’application doit aussi définir l’authenticité, la suppression des doublons et la protection contre le rejeu lorsque le déploiement l’exige.
La cas livré de passerelle Wi-Fi et Bluetooth ESP32 présente des orientations Wi-Fi et SIG Mesh distinctes. Elle apporte un contexte architectural utile, mais ne fournit aucune mesure de capacité de capteurs GATT connectés. Une passerelle GATT nécessite sa propre validation des terminaux et de la charge.
Séparer les limites de connexion de la capacité exploitable
Vérifiez la puce exacte, le firmware du contrôleur, la pile hôte, la version du SDK et la configuration de compilation. Les objets de connexion de l’hôte, les liaisons du contrôleur, les tampons ACL, le stockage des associations de sécurité et les files applicatives imposent des limites différentes. Augmenter un paramètre ne supprime pas les autres limites.
Comme exemple précisément lié à une version, le guide multiconnexion ESP32 d’Espressif pour ESP-IDF v6.0.3 indique neuf connexions simultanées pour ESP-NimBLE et ESP-Bluedroid, avec les paramètres hôte correspondants et un paramètre contrôleur concordant. Il s’agit d’un plafond d’implémentation, pas d’un nombre de capteurs garanti pour toute charge ou toute puce de la famille ESP32. Zephyr expose également CONFIG_BT_MAX_CONN. Vérifiez la documentation de la version réellement utilisée. Sources : guide multiconnexion Espressif et documentation du shell GAP de Zephyr.
Sur une passerelle Linux, ajouter de la RAM ou un processeur plus rapide ne démontre pas une limite supérieure du contrôleur radio. Notez le modèle du contrôleur USB/UART, son firmware, le noyau et la version de BlueZ. Gardez les callbacks de notification courts : validez et mettez les données en file, puis effectuez les écritures en base et les tâches de liaison montante en dehors du chemin de callback Bluetooth.
Établir un budget de trafic avec une marge mesurée
Calculez d’abord les octets applicatifs. Par exemple, huit capteurs produisant chacun un enregistrement de 16 octets à 5 Hz génèrent 640 octets par seconde avant les surcharges protocolaires. Ce calcul ne prédit pas le débit radio. Les échanges de paquets, événements de connexion vides, accusés de réception, retransmissions, balayages et opérations de planification consomment du temps supplémentaire.
Une première estimation utile consiste à additionner, pour chaque liaison, le temps d’occupation radio estimé d’un événement divisé par son intervalle de connexion. Gardez une marge pour le balayage, la reconnexion et la coexistence avec la liaison montante. Cette estimation n’est ni une garantie d’ordonnancement Bluetooth ni un substitut aux mesures : chevauchement d’événements, politique du contrôleur et arrivées en rafales peuvent provoquer des échecs malgré un budget moyen confortable.
Mesurez l’intervalle de connexion négocié, la latence du périphérique, le délai de supervision, le PHY, la MTU ATT et la longueur des données de la couche liaison. Une MTU ATT plus grande ne garantit ni un paquet de couche liaison plus long ni davantage de paquets à chaque événement. Allonger l’intervalle peut faciliter la planification, mais dégrader la latence ou augmenter le besoin de tampon pour les rafales. Ajustez les paramètres selon un objectif de fraîcheur, pas selon un réglage générique de « débit maximal ».
Faire de la reconnexion une machine à états bornée
Suivez indépendamment chaque capteur à travers la découverte, la connexion, la sécurité, la résolution des services, l’abonnement et le transfert. « Connecté » n’est pas l’état prêt. Un critère de disponibilité utile est la réception du premier échantillon applicatif valide et correctement identifié après l’abonnement.
DISCOVER -> CONNECT -> SECURE -> RESOLVE -> SUBSCRIBE -> STREAM
failure -> RELEASE_RESOURCES -> BACKOFF -> DISCOVER
# Illustrative full-jitter backoff, seconds:
delay = random_uniform(0, min(60, 2 ** min(attempt, 6)))
# Reset attempt after a defined healthy-stream interval.
# Limit simultaneous connection/setup attempts globally.Les durées ci-dessus sont des exemples de conception, pas des paramètres imposés par BLE. Donnez à chaque état un délai maximal, un chemin d’annulation et un code de cause. Borner les tentatives pour les défauts nécessitant une intervention, comme un protocole incompatible ou des échecs d’authentification répétés, permet d’afficher un défaut exploitable au lieu de réessayer indéfiniment à pleine vitesse.
Après une déconnexion, libérez correctement les handles et inscriptions de callbacks obsolètes, annulez les tâches dépassées, puis rétablissez la sécurité et les abonnements nécessaires. Préservez une identité durable grâce aux mécanismes de liaison de sécurité et de confidentialité pris en charge ou à un identifiant applicatif authentifié ; ne considérez pas chaque adresse privée renouvelée comme un nouveau capteur permanent. Sous BlueZ, utilisez l’interface de notification prise en charge et traitez ses erreurs documentées. Voir l’API GATT de BlueZ.
Utilisez des identifiants de démarrage et des séquences d’échantillons pour distinguer redémarrages, lacunes et doublons. Ne conservez durablement que l’état nécessaire au contrat de reprise du produit. Un redémarrage de la passerelle pendant le transfert d’un arriéré ne doit pas requalifier silencieusement d’anciens échantillons en mesures en direct.
Tester concurrence et pannes pendant que toutes les liaisons travaillent
Dans une conception à radio partagée, la collecte BLE et le trafic Wi-Fi se disputent les ressources radio. Espressif documente une coexistence fondée sur les priorités et un ordonnancement qui varie avec l’état Wi-Fi. Testez une liaison montante stable, mais aussi les balayages et reconnexions Wi-Fi ; une connexion calme sur banc ne couvre pas ces conditions. Consultez le guide de coexistence ESP32, puis son équivalent pour le SDK et la puce retenus.
Utilisez le boîtier de production, la position d’antenne et l’alimentation prévus. Faites varier le nombre de capteurs et les fréquences de rapport pris en charge, puis répétez à la limite d’exploitation visée avec une atténuation contrôlée ou une implantation représentative. Le RSSI seul n’est pas un critère de réussite. Conservez un groupe témoin à signal fort pour distinguer les problèmes de file ou de processeur des problèmes radio.
| Scénario | Injection | Observation requise |
|---|---|---|
| Capacité stable | Augmenter les capteurs actifs et la fréquence des rapports jusqu’à la limite annoncée | Fraîcheur par capteur, taux de livraison unique, pic de file et évolution CPU/mémoire |
| Rafale synchronisée | Faire émettre tous les capteurs ensemble | Latence aux percentiles élevés, comportement de débordement et équité |
| Défaillance d’un nœud | Éloigner un capteur hors de portée ou le redémarrer électriquement | Temps de détection et de reprise ; autres nœuds toujours conformes |
| Tempête de reconnexions | Redémarrer tous les capteurs ou la passerelle | Premier et dernier flux rétablis, concurrence d’initialisation et répartition des tentatives |
| Concurrence de liaison montante | Balayage Wi-Fi, reconnexion et transfert continu | Lacunes BLE et reprise avec des files bornées |
| Coupure de liaison montante | Bloquer le serveur ou le chemin réseau | Limite de conservation, alarme de débordement et comptage des retransmissions historiques |
| Versions mixtes et sécurité | Combiner révisions compatibles et identifiants rejetés | État correct par appareil sans priver les pairs sains de ressources |
| Fonctionnement prolongé | Répéter les pannes pendant une durée couvrant les cycles requis | Aucune fuite de ressources, aucun état bloqué ni perte inexpliquée |
Définir l’acceptation à partir des données exploitables
Fixez les seuils de réussite avant les essais. Une spécification illustrative pourrait imposer un 99e percentile d’âge des échantillons inférieur à deux secondes, un taux défini de livraison d’échantillons uniques et le rétablissement de tous les capteurs joignables dans une fenêtre convenue. Ce sont des exemples d’exigences, pas des résultats observés. Un capteur lent produisant une mesure par minute nécessite un autre objectif de fraîcheur.
Définissez le dénominateur : les échantillons attendus pendant la fenêtre de mesure, ceux conservés par le capteur et ceux admissibles à la transmission sont des quantités différentes. Comptez les doublons séparément des échantillons uniques livrés. Précisez l’effet des périodes hors ligne connues sur l’objectif. Incluez le taux de réussite au premier essai et le comportement du nœud le moins bien servi, afin qu’une moyenne globale ne masque pas un capteur privé de ressources.
Mesurez l’âge d’un échantillon depuis son horodatage d’acquisition seulement si les horloges sont synchronisées ou si leur décalage et leur dérive sont bornés. Sinon, indiquez séparément le délai entre réception par la passerelle et liaison montante, et signalez l’âge de bout en bout comme inconnu. Utilisez une horloge monotone pour les durées locales et enregistrez toute la chronologie : défaut, détection, connexion, abonnement et premier échantillon valide.
Diagnostiquer la couche réellement en défaut
- Les liaisons sont connectées, mais aucune donnée n’arrive : vérifiez la résolution des services, l’abonnement, les permissions et la production de données du capteur.
- Seuls les nombres élevés de capteurs échouent : examinez les limites du contrôleur, l’épuisement des tampons, l’ordonnancement des événements et la concurrence globale d’initialisation.
- La panne suit l’activité montante : comparez les traces de coexistence Wi-Fi, la durée des callbacks et la croissance des files.
- Un capteur défectueux ralentit tous les autres : examinez les verrous partagés, les tentatives sérielles non bornées et l’équité des files.
- La reconnexion ne fonctionne qu’après redémarrage : recherchez les objets de connexion non libérés, les callbacks obsolètes et les états sans sortie sur expiration.
Un dossier de projet utile comprend des exemplaires de capteurs, les révisions du firmware, les profils de trafic, la topologie, le comportement de la liaison montante et des critères d’acceptation chiffrés. Le service d’intégration de passerelles d’Obeita permet de cadrer ce travail. Le livrable doit décrire une enveloppe de capacité versionnée et un rapport de reprise pour la configuration retenue, étayés par les journaux. Pour le contexte architectural, consultez le cas livré de passerelle Wi-Fi et Bluetooth ESP32 associé. Les exemples chiffrés et le plan d’essai présentés ici ne sont pas des résultats mesurés sur ce cas.
