Wir sind es nicht mehr gewohnt, Daten zu sparen. Die Bandbreiten wachsen ständig, weshalb heute sauberem HTML-Quellcode oder reinen Textnachrichten kaum mehr Beachtung geschenkt wird. In der Begrenzung der neuen öffentlichen 0G-Netze auf nur wenige Bytes liegt aber enormes Marktpotenzial. Weniger Bytes bedeuten nämlich weniger Energie für die Datenübertragung und weniger Nutzlast kostet auch weniger Geld und schafft zudem im Kommunikationskanal Platz für weitere Teilnehmer. Dies wiederum spart Kosten für die Infrastruktur, sodass man Dienste günstiger anbieten kann. Genau in diesem Low-End-High-Volume-Markt positioniert sich das ultraschmalbandinge 0G-Netz von Sigfox, um all die Dinge an das Internet anbinden zu können, die man bislang nicht anbinden konnte, weil 3G/4G/5G-Breitband zu teuer ist, zu viel Energie benötigt und global auch nicht ohne Roaminggebühren einsetzbar ist.

Stark in weit verteilten Infrastrukturen

Egal ob Microsoft Azure Cloud for Predictive Maintenance, Siemens Mindsphere Cloud oder Cumulocity: Sie alle unterstützen das 0G-Netz von Sigfox und docken an die Sigfox Cloud an, die in Europa von Thales gehostet wird und eine der sichersten Clouds weltweit ist.

© Sigfox Germany

Einen großen Markt für das neue 0G-Netz gibt es deshalb in – vielfach auch grenzüberschreitend verteilten Dingen und Infrastrukturen – von Container- und Ladungsträger-Monitoring-Lösungen über das Smart Metering bis hin zur Überwachung des Betriebs von Pumpstationen in der Wasserversorgung. Der Charme der 0G-Logik für smarte Sensoren und Aktuatoren aller Art liegt bei solchen verteilten Systemen unter anderem in der jahrelang wartungsfreien Netzanbindung, da ein Batteriewechsel nicht erforderlich ist. Letztlich sind sie für OEM nichts anderes, als weltweit verteilte Devices, die es für besseren Kundenservice zentral zu monitoren und managen gilt.

Kleine Nachrichten, großer Nutzen

12 Byte beziehungsweise 96 Bit sind nur ein Teil des gesamten Communication Stacks. Hinzu kommen ein Length Indicator (LI), eine Bidirectional Flag (BF), Repeated Flag (RF), Ein Message Counter (MC) und ein Identifier (ID).

© Sigfox Germany

Hierzu kann Sigfox täglich bis zu 140 Nachrichten von Geräten aller Art an IoT-Clouds senden (Uplink) und vier zum Gerät zurück (Downlink)  für Stellbefehle, Parametrierungen oder Funktionsfreischaltungen. Die Payload der Nachrichten darf jedoch nicht größer als 12 Byte sein. Das ist nicht viel, weshalb die Netzanbindung auch sehr energiesparend und preiswert ist. Mit 12 Byte lassen sich jedoch 2 hoch 96 unterschiedliche Werte darstellen. Das sind 79 Quadrilliarden unterschiedliche Zustände. Zur Verdeutlichung: Eine Quadrialliarde ist eine Zahl mit 27 Nullen vor dem Komma! Mit dieser Vielfalt sollte sich jeder Systemzustand hinreichend präzise beschreiben lassen. Selbst komplexe globale GPS-Koordinaten brauchen nur rund 6 Byte, sodass sich die überwachten Gegenstände bei Bedarf auch noch exakt lokalisieren lassen. Welche Lösungswege gibt es aber, beispielsweise diverse Messwerte zu übertragen, wenn diese in der Summe rein rechnerisch mehr als 12 Byte ausmachen?

Dos and Don‘ts beim Datenpacken

Wenig sinnvoll sind die aktuell verfügbaren Methoden der Datenkomprimierung, da sie bei den ohnehin schon sehr kleinen Datenpaketen kaum Einsparungen erzielen. Der Overhead dieser Algorithmen ist nämlich oft größer, als die Einsparung, die man bei 12 Byte erzielen kann.

Auch macht es keinen Sinn, beispielsweise bei Geodaten nur die kleinen Änderungen in Bezug auf die vorherige Position zu übermitteln, denn geht die Nachricht mit der ersten kompletten Geoinformation dann doch einmal verloren, ist der nachfolgende Datenstrang nicht mehr rekonstruierbar. Bei Systemen, die dann einen alternativen Fallback-Zugriff auf die Quelldaten zulassen würden, wäre dies zwar kein Weltuntergang, doch von Anfang an so zu konzipieren, dass man nicht auf Alternativen zurückgreifen muss, ist sicherlich besser. Deshalb hat es sich in der Nachrichtenaufbereitung für 0G-Netze durchgesetzt, stateless, also ohne Bezug auf frühere Pakete, zu kommunizieren. Auch werden keine Sitzungsinformationen ausgetauscht und/oder verwaltet.

Es ist aber durchaus sinnvoll, Nachrichten, die größer sind, über Splittingverfahren in mehrere Datenübertragungen aufzuteilen und sie in der Cloud wieder zusammenzubauen. Entsprechen die vorhandenen Daten also nicht der 12-Byte-Struktur, lassen sich diese mittels geeigneter Bit- und Bytefolgen erweitern.

Redundanzen vermeiden

Sinnvoll ist es zudem, Redundanzen zu reduzieren und die Entropie zu optimieren, indem etwa in die Nachricht nicht mehr einprogrammiert wird, dass es sich um den Sensor x oder die Maschine y handelt, die hier gerade berichtet. Es ist auch nicht sinnvoll zu senden, welcher Art der übermittelte Wert ist, beispielsweise Temperatur oder Geschwindigkeit. Denn die Devices erhalten schon über die Sigfox-ID eine eindeutige Identifikation in der Cloud, in der die Zuordnung definiert werden kann.

Ein probater Weg ist es auch – anders als bei Ethernet Datenpaketen – keine feste Datenbreite zu nutzen. Stattdessen nutzt man wirklich nur die von den Messwerten benötigte Bittiefe. So reichen für beispielsweise Temperaturwerte von –20 bis 100 °C schon 7 bit (27 = 128). Dadurch lässt sich die Payload des Sigfox-Signals optimal ausnutzen. Auch bei Ja/Nein-Werten lässt sich dieses Prinzip anwenden. Müssen nur die Ein/Aus-Informationen für sechs Eingänge übermittelt werden, müssen diese nicht in einem Byte codiert werden, sondern benötigen bei entsprechendem Regelwerk auch nur 6 bit. So lassen sich also diese Informationen zusammen mit nur 13 bit übertragen. Damit können gegenüber reinen Byte-Werten 3 bit eingespart werden, die sich für weitere Daten nutzen lassen. Zudem kann man die möglichen Messwerte auch in Bereiche segmentieren und so die Daten auf wenige Melde-Cluster anstelle von großen Zahlenwerten mit endlosen Nachkommastellen zu kommunizieren.

Nicht immer die ganze Welt erklären

Es empfiehlt sich zudem, die Geodaten nicht 1:1 zu übertragen, sondern sie logisch in Blöcken zu reduzieren, was Bits spart, da sich der jeweils darzustellende Bereich reduziert. Das kann für Geräte, die etwa Länder beziehungsweise Kontinente nicht verlassen, sinnvoll sein. Weil kommende GNSS-Chips eine erhöhte Genauigkeit durch Auswertung der E5/L5-Signale ermöglichen, können diese Einsparungen dann dort verwendet werden. Auch macht es Sinn, eine spezifische Tabelle mit Zuständen zu erstellen – sinnvollerweise geordnet nach erwarteter Häufigkeit – um so kürzere Bitfolgen selbigen zuzuweisen. Dieses Verfahren nennt man Huffman-Codierung.

Prioritäten setzen!

Reichen all diese Maßnahmen nicht aus, können Nachrichten auch priorisiert werden, um nur die wichtigsten Daten bei Überschreitung eines Schwellenwertes sofort zu übertragen und weitere Daten später zu senden. So können beispielsweise Daten, die weniger kritisch sind, nur wöchentlich oder monatlich übertragen werden, was bei 140 Nachrichten pro Tag immens viel Spielraum lässt, selbst die exotischsten Werte in die Cloud zu übertragen, um über einen etwas längeren Zeitraum alle erforderlichen Informationen zu sammeln. Eine Nachricht „Ich bin aktiv“ kann zudem gänzlich entfallen, wenn weitere Zustandsinformationen regelmäßig übermittelt werden.

Bei komplexen Predictive-Maintenance-Applikationen ist es darüber hinaus ohnehin vonnöten, eine Edge-Analytik umzusetzen, um beispielsweise Schwingungen einer Maschine richtig zu interpretieren. Solche komplexen, teils Gigabyte großen Daten live in Echtzeit in zentrale Clouds zu streamen, ist zumindest für Predictive Maintenance selten sinnvoll beziehungsweise in der Regel nur dann interessant, wenn der KI-Algorithmus des Inferenzsystems weiter in Deep-Learning-Clouds trainiert werden soll. Die Meldung: Die Achse ist jetzt soweit verzogen, dass die CNC-Maschine nicht mehr im Toleranzbereich arbeitet, passt aber problemlos in 12 Byte.

Speicher am Edge nutzen

Manche Kunden nutzen auch lokalen Speicherplatz für ihre Daten, die sie bei Wartungsarbeiten über BLE-Interface auslesen, um über solche komplementären Kanäle dann die vollständigen Datensätze zu sammeln. Bei einfachsten mobilen IoT-Devices, wie beispielsweise Ladungstrackern, ist dann oft die Frage zu klären, wie viel Flashspeicher der eingesetzte Mikrocontroller haben soll, um die Daten vorzuhalten, denn selbiger ist bei MCUs vergleichsweise teuer. Bei komplexeren Embedded Systemen, die ohnehin mit größeren ARM- oder x86-Prozessor betrieben werden, ist diese Speicherfrage in aller Regel jedoch zu vernachlässigen, sodass Walk-by-Lösungen bestehend aus BLE-Interface und Sigfox als primärer Meldekanal für die wichtigsten Usage- und Predictive-Maintenance-Botschaften eine hervorragende Kombination auch für komplexere Devices darstellt.