Intelligente Gasüberwachungsgeräte: Überprüfen, dass ein NB-IoT-Zählerbericht analysiert und bestätigt wurde
Zusammenfassung
Eine Funkübertragung, ein ausgelesener Zählerdatensatz und eine Anwendungsbestätigung sind unterschiedliche Ergebnisse. Song, Wang und Yang beschreiben einen NB-IoT-Gaszähler-Prototypen mit einer Nachricht fester Länge, Sende- und Empfangsprüfungen und einer Server-Testschnittstelle. Dieser Artikel verwendet das veröffentlichte 68-Byte-Layout und den berichteten Programmablauf, um zu erklären, wie ein Käufer diese Ergebnisse unterscheiden kann. Die Feldlängentabelle behält die Werte der Autoren bei, ohne Gerätekennungen oder Netzwerkadressen wiederzugeben. Ein erfolgreicher Prototypenaustausch demonstriert die in diesem Beispiel gezeigten Funktionen. Für die Feldabnahme sind weiterhin Fehlerfälle, Wiederholbarkeit und eine klare Definition der erwarteten Antwort erforderlich.
Hintergrund und Forschungsfrage
Die Fernüberwachung von Gas hängt davon ab, was passiert, nachdem ein Messgerät Daten sendet. Das Modem kann melden, dass ein Sendebefehl abgeschlossen wurde. Der Server kann dann den Frame empfangen, aber seine Länge oder Version ablehnen. Ein Server kann einen Messwert akzeptieren, während eine Antwort verzögert oder verloren geht. Jedes Ergebnis kann zu einer unterschiedlichen Beobachtung am Gerät und an der Anwendung führen. Ein Käufer muss wissen, welches Ereignis ein Lieferant mit erfolgreicher Kommunikation meint.
Song, Wang und Yang beschreiben einen Prototypen mit einem eingebetteten Controller, einem BC95-Kommunikationsmodul und einer serverseitigen Testschnittstelle [1]. Diese Überprüfung folgt der Architektur, der Nachrichtendefinition, dem Programmablauf und dem Testergebnis in dieser Reihenfolge. Die Überprüfung fragt, welche Belege die Arbeit für eine vollständige Transaktion liefert und was ein Abnahmetest zeigen müsste, wenn ein Teil des Austauschs fehlschlägt.
Systemarchitektur und Verantwortlichkeiten
Abbildung 1. Wahrnehmungs-, Netzwerk- und Anwendungsschichten des Prototyps der Autoren. Song, Wang und Yang [1], Original Abbildung 1 (Druck S. 114). Unabhängige englische funktionale Neuzeichnung des veröffentlichten Diagramms.
Abbildung 2. Blockweise Organisation der Messgeräte-Hardware der Autoren. Song, Wang und Yang [1], Original Abbildung 2 (Druck S. 114). Unabhängige englische funktionale Neuzeichnung des veröffentlichten Diagramms.
Abbildung 3. Zwei Reglerpfade, Entkopplungswerte und das 3,9-V-Freigabesignal. Song, Wang und Yang [1], Original Abbildung 3 (Druck S. 114). Englische funktionale Neuzeichnung. Die Bauteilwerte stammen aus dem veröffentlichten Schaltplan. Dies ist keine pin-genaue Verdrahtungszeichnung.
Abbildung 4. Gleichstrommotorantrieb, Schaltzustände und abgetastete Ventilrückmeldung. Song, Wang und Yang [1], Original Abbildung 4 (Druck S. 114). Englische funktionale Neuzeichnung der veröffentlichten Steuerschaltung und der drei Betriebszustände in Abschnitt 2.3. Die Komponentenverdrahtung ist nicht dargestellt.
Abbildung 5. BC95 Stromversorgungs-, Funk-, SIM- und UART-Schaltungen. Song, Wang und Yang [1], Original Abbildung 5 (Druck S. 115). Englische funktionale Neuzeichnung mit aus der Quelle übernommenen Signalnamen und -werten. Sie lässt physische Verdrahtungsdetails weg.
Die Quelle trennt Datenerfassung, Vernetzung und Anwendungsfunktionen. Im Prototyp sammelt und paketiert der Zählercontroller die Messwerte. Das NB-IoT-Modul überträgt und empfängt Nachrichten. Der Server speichert die Zählerdaten und stellt sie zur Anzeige bereit. Die Architektur hilft dabei, die Belege für verschiedene Ereignisse zu lokalisieren. Ein Netzwerkprotokoll kann zeigen, dass ein Frame den Server erreicht hat. Ein Parser-Protokoll kann feststellen, ob die Nachricht interpretiert wurde. Ein Anwendungsdatensatz kann den Zähler und den Zeitpunkt anzeigen, denen ein Messwert zugeordnet wurde.
Der Artikel beschreibt die Einrichtung des Moduls, die Prüfung auf eine SIM und die Prüfung der Signalbedingungen vor dem Senden. Sein Flussdiagramm unterscheidet, ob das Senden erfolgreich war, von der Frage, ob ein Empfangsvorgang erfolgreich war. Es enthält begrenzte Wiederholungsversuche und die Rückkehr in einen Niedrigenergiemodus. Diese Verhaltensweisen machen es nützlich, festzuhalten, welche Phase einen Fehler verursacht hat, anstatt jeden Wiederholungsversuch zu einem einzigen Verbindungsfehler zusammenzufassen.
Nachrichtenformat und Prüfmethode
Abbildung 6. Organisation des KL36-Treibers auf niedriger Ebene. Song, Wang und Yang [1], Originalabbildung 6 (Druckseite 115). Unabhängige englische funktionale Neuziechnung des veröffentlichten Diagramms.
Abbildung 7. BC95-Kommunikationsablauf, wobei separate Wiederholungsentscheidungen für Verbindungsprüfungen und Nachrichtenübertragung beibehalten werden. Song, Wang und Yang [1], Originalabbildung 7 (Druckversion S. 115). Unabhängige englische funktionale Neuzeichnung des veröffentlichten Diagramms.
Abbildung 8. Hauptprogrammentscheidungen, Ereignisauslöser und Ausgabe. Song, Wang und Yang [1], Originalabbildung 8 (Druckversion S. 115). Unabhängige englische funktionale Neuzeichnung des veröffentlichten Diagramms.
Abb. Veranschaulichung der proportionalen Feldlängen basierend auf Song, Wang und Yang [1], Abschnitt 3.2. Feldwerte werden nicht wiedergegeben.
Der Prototyp spezifiziert 68 Bytes in einem Frame. Die Quelle listet die Felder in der unten gezeigten Reihenfolge auf. Die Feldlängen summieren sich zu 68 Bytes. Diese einfache Prüfung ist aus dem Paper reproduzierbar, ohne dass ein Beispiel-Geräteidentifikator, eine Adresse oder ein anderer Bildschirmwert aufgezeichnet wird.
Prototyp-Feld | Länge (Bytes) |
Frame-Header | 2 |
Teilnehmerkennungsfeld | 15 |
Übertragene Daten | 32 |
Zieladressfeld | 15 |
Verifizierungscode-Feld | 2 |
Frame-Trailer | 2 |
Gesamt | 68 |
Tabelle. Englische Transkription des festen Frame-Layouts in Song, Wang und Yang [1], Abschnitt 3.2. Es werden nur Feldbezeichnungen und Längen angezeigt.
Das Papier bezeichnet das Zwei-Byte-Element als Verifizierungscode. Die angegebene Feldbreite definiert nicht, wie der Code berechnet wurde, oder belegt, dass er eine Authentifizierung bietet. Eine Beschaffungsspezifikation sollte daher Nachrichtenintegritätsprüfungen, Geräteidentifikation und alle erforderlichen Sicherheitskontrollen unterscheiden. Sie sollte auch definieren, wie verschiedene Firmware-Versionen identifiziert werden, wenn sich das Feldlayout ändert.
Was das Prototypenergebnis zeigt
Abbildung 9. Prototyp-Verifikationsschnittstelle. Song, Wang und Yang [1], Original Abbildung 9 (Druck S. 116). Anonymisierter englischer Wireframe basierend auf der Publikation. Ursprüngliche Bildschirmwerte, Identifikatoren und Nachrichtenbytes sind ausgelassen.
Der Beispielschnittstellen des Artikels zeigt ein analysiertes Ergebnis und eine Möglichkeit zur Antwort. Das unterstützt die Beschreibung der Autoren eines Prototyps, der Daten senden und analysierte Felder darstellen kann. Die Schnittstelle belegt nicht, dass jeder akzeptierte Datensatz einmal geschrieben wurde, dass Bestätigungen jeder Lesung zugeordnet wurden oder dass der Austausch ein Service-Level-Ziel erreicht hat. Das Paper gibt keine Feldstichprobengröße oder Langzeitverteilung der Erfolgsraten an. Es kann keine Trägerabdeckungszahl oder Batterielebensdauer-Vorhersage liefern.
Ein nützlicher Abnahmetest kann jedem versuchten Bericht eine nachverfolgbare Identität innerhalb des Testprotokolls geben. Das Protokoll kann dann Senden, Empfangen, Parsen, Speichern und Bestätigen getrennt zeigen. Ein gültiger Frame testet den normalen Pfad. Ein Frame mit falscher Länge testet die Zurückweisung am Parser. Ein wiederholter gültiger Frame testet, ob die Anwendung Duplikate erkennen kann. Das Zurückhalten einer Antwort testet, was das Gerät aufzeichnet und wie es in seinen vorgesehenen Betriebszustand zurückkehrt. Dies sind vorgeschlagene Testfälle, keine von den Autoren berichteten Experimente.
Der Unterschied wird deutlicher, wenn der Abnahmeprotokoll drei Uhren unterscheidet. Das Gerät kann festhalten, wann eine Messung abgetastet wurde, der Server kann festhalten, wann ein Frame ankam, und die Anwendung kann festhalten, wann die Nachricht angenommen oder bestätigt wurde. Eine verzögerte Antwort ändert nicht den ursprünglichen Abtastzeitpunkt. Ein Prüfer der Abnahme kann fragen, ob jede Zeit auf derselben Grundlage gemeldet wird und ob der Nachrichtenschlüssel einen erneuten Versuch übersteht. Das Dokument legt diese Uhr- oder Schlüsselkonventionen nicht fest. Sie sind Beispiele für Implementierungsdetails, die vor dem Vergleich von Anbietern vereinbart werden sollten.
Die beabsichtigte Antwort benötigt ebenfalls eine Definition. Eine Bestätigung kann den Empfang, die Akzeptanz durch den Parser, die dauerhafte Speicherung oder die Erfüllung einer Geschäftsregel bedeuten. Wenn die Anforderung die dauerhafte Speicherung ist, sollte die Demonstration sowohl den gespeicherten Datensatz als auch die zurückgegebene Antwort prüfen. Wenn nur die Akzeptanz durch den Parser erforderlich ist, sollte der Nachweis diesen engeren Umfang angeben.
Fazit und Ausblick
Bitten Sie Lieferanten, erfolgreiche Zustellung an der Anwendungsgrenze zu definieren und passende Geräte- und Serveraufzeichnungen bereitzustellen. Die Frame- und Empfangslogik des Prototyps zeigt, warum Modem-Erfolg allein nicht ausreicht. Eine Produktionsbewertung kann die erwartete Aufzeichnungs-, Antwort- und Duplikatrichtlinie festlegen und dann dieselben Kriterien über repräsentative Betriebsbedingungen hinweg prüfen. Folgetests sollten Ergebnisse auf Anwendungsebene messen und die Bedingungen aufzeichnen, anstatt die Leistung aus einem erfolgreichen Beispielbildschirm zu extrapolieren.
Hinweise
Die Feldnamen und Byte-Anzahlen stammen aus dem zitierten Prototyp. Die Wortverifikation bezieht sich auf den Feldnamen der Quelle. Es werden keine Beispielkennungen, persönlichen Daten oder Netzwerkadressen aus der Schnittstelle wiedergegeben.
Referenzen und Bildquellen
[1] Song, H., Wang, Y. und Yang, F. (2019). „基于窄带物联网智能燃气表系统设计与实现“ [Entwurf und Implementierung eines intelligenten Gasmessersystems basierend auf NB-IoT]. 传感器与微系统, 38(3), S. 113–116. Abschnitte 1–4 und Abbildungen 1–9. Schaltungsabbildungen zeigen die relevanten Funktionspfade. Die Testschnittstelle wurde neu gezeichnet, wobei Kennungen und Nutzdaten weggelassen wurden.
https://doi.org/10.13873/J.1000-9787(2019)03-0113-04