Intelligente Gasüberwachungsgeräte: Überprüfen, ob ein NB-IoT-Zählerbericht geparst und bestätigt wurde

Veröffentlicht am Heute

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.
Gruppen von Gaszählern und Datensammlern senden Messwerte über eine NB-IoT-Basisstation und einen Server für den Zugriff per Computer oder Telefon.
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.
KL36-Controller und angeschlossene Mess-, Leck-, Touch-, Alarm-, Stromversorgungs-, BC95-, Ventilantriebs- und Anzeigemodule.
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.
P5V versorgt die Regler TPS70933 und TPS70939 für die 3,3-V-Controller-Schiene und die aktivierte 3,9-V-BC95-Schiene.
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.
Die Ansteuerbefehle wählen den Vorwärts- oder Rückwärtsstrom durch Motor P201. AD1 und AD2 werden für die Ventilzustandsrückmeldung verwendet.
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.
BC95-Funktionsschaltung mit VBAT, Antenne, SIM-Signalen und deren Schutznetzwerk sowie Sende- und Empfangsleitungen.
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.
KL36-Hauptfirmware, Kommunikationsdaten und Module für SPI, GPIO, Timer, Touch, ADC, Ventilantrieb und Anzeige, verknüpft mit Interrupts.
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.
Flussdiagramm für BC95-Initialisierung, Netzwerkverbindung, SIM- und Signalprüfungen, Übertragung, Empfang und Wiederholungsentscheidungen.
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.
Hauptprogrammablauf von der Ventilberechtigung und dem Alarmzweig über Timer- oder Touch-Auslöser, BC95-Übertragungsprüfungen und LCD-Anzeige.
Abb. Veranschaulichung der proportionalen Feldlängen basierend auf Song, Wang und Yang [1], Abschnitt 3.2. Feldwerte werden nicht wiedergegeben.
Ein 68-Byte-Prototyprahmen, der veröffentlichte Feldgrößen von 2, 15, 32, 15, 2 und 2 Bytes zeigt.
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.
Englische Rekonstruktion des Prototyp-Testbildschirms mit Bereichen für empfangene Nachrichten, Geräte- und Messgerätfelder sowie Teststeuerungen.
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
Bildnachweis: Song, Wang und Yang (2019), Abschnitt 3.2, Druckseite 115. Ursprüngliche Visualisierung nur der Feldgrößen. https://doi.org/10.13873/J.1000-9787(2019)03-0113-04
Titelbild: U.S. Department of Energy, Oak Ridge Archiv. Fotograf Ed Westcott von der Atomic Energy Commission mit seiner Filmausrüstung in Oak Ridge. Arbeit der U.S.-Regierung, gemeinfrei gemäß der Quellaufzeichnung. Redaktioneller Bildausschnitt und Titellayout. https://commons.wikimedia.org/wiki/File:Ed_Westcott_with_film_making_Equipment_Oak_Ridge_1960.jpg