Appareils de surveillance intelligents du gaz : vérifier qu'un rapport de compteur NB-IoT a été analysé et acquitté

Publié le Aujourd'hui

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é.
Des groupes de compteurs de gaz et de collecteurs envoient des relevés via une station de base NB-IoT et un serveur pour un accès par ordinateur ou téléphone.
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é.
Contrôleur KL36 et modules connectés de mesure, de fuite, tactile, d'alarme, d'alimentation, BC95, de commande de vanne et d'affichage.
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.
P5V alimente les régulateurs TPS70933 et TPS70939 pour le rail 3,3 V du contrôleur et le rail 3,9 V activé du BC95.
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é.
Les commandes d'entraînement sélectionnent le courant direct ou inverse via le moteur P201. AD1 et AD2 sont utilisés pour le retour d'état des vannes.
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.
Circuit fonctionnel BC95 avec VBAT, antenne, signaux SIM et leur réseau de protection, ainsi que les lignes d'émission et de réception.
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é.
Micrologiciel principal KL36, données de communication et modules pour SPI, GPIO, minuterie, tactile, ADC, commande de vanne et affichage liés aux interruptions.
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é.
Organigramme pour l'initialisation du BC95, la connexion réseau, les vérifications SIM et de signal, l'émission, la réception et les décisions de nouvelle tentative.
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é.
Flux principal du programme, de l'éligibilité de la vanne et de la branche d'alarme jusqu'aux déclencheurs par minuterie ou tactile, aux contrôles de transfert BC95 et à l'affichage LCD.
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.
Une trame prototype de 68 octets montrant les tailles de champs publiées de 2, 15, 32, 15, 2 et 2 octets.
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.
Reconstruction en anglais de l'écran de test du prototype avec des zones pour les messages reçus, les champs d'appareil et de compteur, et les commandes de test.
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
Crédit image : Song, Wang et Yang (2019), section 3.2, p. 115 de l'édition imprimée. Visualisation originale des tailles de champs uniquement. https://doi.org/10.13873/J.1000-9787(2019)03-0113-04
Photo de couverture : Département de l'Énergie des États-Unis, archives d'Oak Ridge. Le photographe de la Commission de l'énergie atomique Ed Westcott avec son équipement de cinéma à Oak Ridge. Œuvre du gouvernement des États-Unis, domaine public selon le dossier source. Recadrage éditorial de la photo et mise en page du titre. https://commons.wikimedia.org/wiki/File:Ed_Westcott_with_film_making_Equipment_Oak_Ridge_1960.jpg