Dispositifs intelligents de surveillance du gaz : vérifier qu'un rapport de compteur NB-IoT a été analysé et acquitté
Résumé
Une transmission radio, un relevé de compteur analysé et un accusé de réception d'application sont des résultats différents. Song, Wang et Yang décrivent un prototype de compteur de gaz NB-IoT avec un message de longueur fixe, des contrôles d'émission et de réception, et une interface de test serveur. Cet article utilise la disposition publiée de 68 octets et le flux de programme rapporté pour expliquer comment un acheteur peut distinguer ces résultats. Le tableau des longueurs de champs conserve les valeurs des auteurs sans reproduire les identifiants d'appareil ni les adresses réseau. Un échange réussi de prototype démontre les fonctions présentées dans cet exemple. L'acceptation sur le terrain nécessite encore des cas de défaillance, la répétabilité et une définition claire de la réponse attendue.
Contexte et question de recherche
La surveillance à distance du gaz dépend de ce qui se passe après qu'un compteur envoie des données. Le modem peut signaler qu'une commande d'envoi a été exécutée. Le serveur peut ensuite recevoir la trame mais rejeter sa longueur ou sa version. Un serveur peut accepter une lecture tandis qu'une réponse est retardée ou perdue. Chaque résultat peut produire une observation différente au niveau de l'appareil et au niveau de l'application. Un acheteur doit savoir quel événement un fournisseur désigne par communication réussie.
Song, Wang et Yang décrivent un prototype doté d'un contrôleur embarqué, d'un module de communication BC95 et d'une interface de test côté serveur [1]. Cette analyse suit l'architecture, la définition des messages, le flux du programme et le résultat des tests dans cet ordre. L'analyse demande quelles preuves l'article fournit pour une transaction complète et ce qu'un test d'acceptation devrait démontrer lorsqu'une partie de l'échange échoue.
Architecture du système et responsabilités
Figure 1. Couches de perception, de réseau et d'application du prototype des auteurs. Song, Wang et Yang [1], Figure 1 originale (p. 114 de l'édition imprimée). Redessin fonctionnel indépendant en anglais du diagramme publié.
Figure 2. Organisation au niveau des blocs du matériel du compteur des auteurs. Song, Wang et Yang [1], Figure 2 originale (p. 114 de l'édition imprimée). Redessin fonctionnel indépendant en anglais du diagramme publié.
Figure 3. Deux chemins de régulateur, valeurs de découplage et signal d'activation de 3,9 V. Song, Wang et Yang [1], Figure 3 originale (p. 114 de l'édition imprimée). Redessin fonctionnel en anglais. Les valeurs des composants proviennent du schéma publié. Il ne s'agit pas d'un schéma de câblage broche par broche.
Figure 4. Entraînement du moteur à courant continu, états de commutation et retour d'information échantillonné de la vanne. Song, Wang et Yang [1], figure 4 originale (p. 114 de l'édition imprimée). Redessin fonctionnel en anglais du circuit de commande publié et des trois états de fonctionnement de la section 2.3. Le câblage des composants n'est pas représenté.
Figure 5. Circuits d'alimentation, radio, SIM et UART du BC95. Song, Wang et Yang [1], figure 5 originale (p. 115 de l'édition imprimée). Redessin fonctionnel en anglais avec les noms de signaux et les valeurs transcrits depuis la source. Il omet les détails de câblage physique.
La source sépare les fonctions d'acquisition de données, de mise en réseau et d'application. Dans le prototype, le contrôleur de compteur collecte et emballe les relevés. Le module NB-IoT transmet et reçoit les messages. Le serveur stocke et expose les données du compteur pour affichage. L'architecture aide à localiser les preuves pour différents événements. Un journal réseau peut montrer qu'une trame a atteint le serveur. Un journal d'analyseur peut identifier si le message a été interprété. Un enregistrement d'application peut montrer le compteur et l'heure auxquels un relevé a été attribué.
L'article décrit la configuration du module, la vérification de la présence d'une SIM et le contrôle des conditions de signal avant l'envoi. Son organigramme distingue la réussite de l'envoi de la réussite d'une opération de réception. Il inclut des chemins de nouvelle tentative limités et un retour à un mode basse consommation. Ces comportements le rendent utile pour enregistrer l'étape ayant provoqué un échec, au lieu de réduire chaque nouvelle tentative à une simple erreur de connexion.
Format des messages et méthode de vérification
Figure 6. Organisation du pilote de bas niveau KL36. Song, Wang et Yang [1], figure 6 originale (p. 115 de l'édition imprimée). Redessin fonctionnel indépendant en anglais du diagramme publié.
Figure 7. Flux de communication BC95, conservant des décisions de nouvelle tentative distinctes pour les vérifications de connexion et le transfert de messages. Song, Wang et Yang [1], figure 7 originale (p. 115 de l'édition imprimée). Redessin fonctionnel indépendant en anglais du diagramme publié.
Figure 8. Décisions du programme principal, déclencheurs d'événements et sortie. Song, Wang et Yang [1], figure 8 originale (p. 115 de l'édition imprimée). Redessin fonctionnel indépendant en anglais du diagramme publié.
Figure. Illustration proportionnelle de la longueur des champs d'après Song, Wang et Yang [1], section 3.2. Les valeurs des champs ne sont pas reproduites.
Le prototype spécifie 68 octets dans une trame. La source liste les champs dans l'ordre indiqué ci-dessous. La somme des longueurs des champs est de 68 octets. Cette vérification simple est reproductible à partir de l'article sans enregistrer d'identifiant d'appareil, d'adresse ou toute autre valeur d'écran d'exemple.
Champ du prototype | Longueur (octets) |
En-tête de trame | 2 |
Champ identifiant d'abonné | 15 |
Données transmises | 32 |
Champ adresse de destination | 15 |
Champ du code de vérification | 2 |
Bande-annonce | 2 |
Total | 68 |
Tableau. Transcription anglaise de la disposition de trame fixe dans Song, Wang et Yang [1], section 3.2. Seuls les libellés de champs et les longueurs sont indiqués.
L'article appelle l'élément de deux octets un code de vérification. La largeur de champ indiquée ne définit pas comment le code a été calculé ni ne démontre qu'il assure une authentification. Une spécification d'approvisionnement devrait donc distinguer les contrôles d'intégrité des messages, l'identification des dispositifs et tout contrôle de sécurité requis. Elle devrait également définir comment les différentes versions de firmware sont identifiées si la disposition des champs change.
Ce que montre le résultat du prototype
Figure 9. Interface de vérification du prototype. Song, Wang et Yang [1], figure 9 originale (p. 116 de l'édition imprimée). Maquette filaire en anglais anonymisée d'après la publication. Les valeurs d'écran, identifiants et octets de message d'origine sont omis.
L'interface d'exemple de l'article affiche un résultat analysé et une possibilité de réponse. Cela étaye la description par les auteurs d'un prototype capable d'envoyer des données et de présenter les champs analysés. L'interface n'établit pas que chaque enregistrement accepté a été écrit une seule fois, que les accusés de réception ont été associés à chaque lecture, ni que l'échange a atteint un objectif de niveau de service. L'article ne fournit ni taille d'échantillon par champ ni distribution à long terme des taux de réussite. Il ne peut fournir ni chiffre de couverture de l'opérateur ni prévision d'autonomie de la batterie.
Un test d'acceptation utile peut donner à chaque rapport tenté une identité traçable au sein du dossier de test. Le journal peut alors montrer séparément l'envoi, la réception, l'analyse, le stockage et l'accusé de réception. Une trame valide teste le chemin ordinaire. Une trame de longueur incorrecte teste le rejet au niveau de l'analyseur. Une trame valide répétée teste si l'application peut identifier les doublons. Retenir une réponse teste ce que l'appareil enregistre et comment il revient à son état de fonctionnement prévu. Il s'agit de cas de test proposés, et non d'expériences rapportées par les auteurs.
La différence devient plus claire si le procès-verbal de réception distingue trois horloges. L'appareil peut enregistrer le moment où une mesure a été échantillonnée, le serveur peut enregistrer le moment où une trame est arrivée, et l'application peut enregistrer le moment où le message a été accepté ou acquitté. Une réponse différée ne modifie pas l'heure d'échantillonnage d'origine. Un examinateur de la réception peut demander si chaque heure est rapportée sur la même base et si la clé du message survit à une nouvelle tentative. Le document ne précise pas ces conventions d'horloge ou de clé. Ce sont des exemples de détails de mise en œuvre à convenir avant de comparer des fournisseurs.
La réponse attendue nécessite également une définition. Un accusé de réception peut signifier la réception, l'acceptation par l'analyseur, le stockage durable ou l'achèvement d'une règle métier. Si l'exigence est le stockage durable, la démonstration doit vérifier l'enregistrement stocké ainsi que la réponse renvoyée. Si seule l'acceptation par l'analyseur est requise, les preuves doivent indiquer ce périmètre plus restreint.
Conclusion et perspectives
Demandez aux fournisseurs de définir la livraison réussie à la frontière de l'application et de fournir des enregistrements correspondants de l'appareil et du serveur. La logique de trame et de réception du prototype montre pourquoi le succès du modem seul est insuffisant. Une évaluation en production peut spécifier l'enregistrement attendu, la politique de réponse et de doublon, puis appliquer les mêmes critères sur des conditions de fonctionnement représentatives. Les tests de suivi doivent mesurer les résultats au niveau de l'application et enregistrer les conditions, plutôt que d'extrapoler les performances à partir d'un écran d'exemple réussi.
Notes
Les noms de champs et les nombres d'octets proviennent du prototype cité. La vérification de mot fait référence au nom de champ de la source. Aucun identifiant d'exemple, détail personnel ou adresse réseau de l'interface n'est reproduit.
Références et sources des images
[1] Song, H., Wang, Y. et Yang, F. (2019). « 基于窄带物联网智能燃气表系统设计与实现 » [Conception et mise en œuvre d'un système de compteur de gaz intelligent basé sur le NB-IoT]. 传感器与微系统, 38(3), pp. 113–116. Sections 1 à 4 et figures 1 à 9. Les figures de circuit montrent les chemins fonctionnels pertinents. L'interface de test a été redessinée en omettant les identifiants et les données de charge utile.
https://doi.org/10.13873/J.1000-9787(2019)03-0113-04