Der 12-Byte-Guide: Was passt in eine Sigfox-Nachricht?

In der Begrenzung der neuen öffentlichen 0G-Netze auf nur wenige Bytes pro Nachricht 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 im Kommunikationskanal zudem 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 verbraucht und global auch nicht ohne Roaminggebühren einsetzbar ist.

Einen großen Markt für das neue 0G-Netz gibt es deshalb in – vielfach auch grenzüberschreitend –verteilten Dingen und Infrastrukturen aller Art – von Container- und Ladungsträger-Monitoring-Lösungen über das Smart-Metering bis hin zur Überwachung des Betriebs von Pumpstationen in der Wasserversorgung oder den Verbleib von Assets aller Art auf dem Betriebsgelände. 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. Man kann das Netz aber genausogut auch für das Benutzungstracking und die Zustandsüberwachung für die vorausschauende Wartung komplexerer Geräte-, Maschinen und Anlagen mit Stromanschluss einsetzen. Letztlich sind sie für OEM nämlich nichts anderes, als weltweit verteilte Devices, die es für besseren Kundenservice zentral zu monitoren und managen gilt.

Hierzu kann Sigfox täglich bis zu 140 Nachrichten von Geräten aller Art an IoT-Clouds senden (Uplink) und 4 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 kann man 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 eigentlich jeder Systemzustand hinreichend präzise beschreiben lassen. Selbst komplexe globale GPS-Koordinaten brauchen nur rund 6 Byte, sodass man die überwachten Gegenstände bei Bedarf auch noch exakt lokalisieren kann. Welche Lösungswege gibt es aber, beispielsweise diverse Messwerte zu übertragen, wenn diese in der Summe rein rechnerisch mehr als 12 Byte ausmachen?

1. 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.
2. 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.
3. 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, kann man diese mit geeigneten Bit- und Bytefolgen erweitern.

Sinnvoll ist es zudem, Redundanzen zu reduzieren und die Entropie zu optimieren, indem man in die Nachricht nicht mehr einprogrammiert, dass es sich um den Sensor x oder die Maschine y handelt, die hier gerade berichtet oder welcher Art der übermittelte Wert ist, beispielsweise Temperatur oder Geschwindigkeit. Die Devices erhalten nämlich schon über die Sigfox-ID eine eineindeutige Identifikation in der Cloud, in der die Zuordnung definiert werden kann.

Ein probater Weg ist es auch – anders als bei Ethernet Datenpaketen – keine festen 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 natürlich anwenden.

Müssen nur die Ein/Aus-Informationen für 6 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. Man spart also gegenüber reinen Byte-Werten 3 bit ein, die für weitere Daten genutzt werden können. Zudem kann man die möglichen Messwerte auch in Bereiche segmentieren und so die Daten auf wenige Meldecluster anstelle große Zahlenwerte mit endlosen Nachkommastellen zu kommunizieren.

Es empfiehlt sich zudem, die Geodaten nicht 1:1 zu übertagen, 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 z.B. Länder bzw. Kontinente nicht verlassen, sinnvoll sein. Weil kommende GNSS-Chips eine erhöhte Genauigkeit durch Auswertung der E5/L5 Signale ermöglichen, können diese Einsparung dann dort verwendet werden.

Natürlich macht es auch Sinn, eine spezifische Tabelle mit Zuständen zu erstellen – sinnvollerweise geordnet nach erwarteter Häufigkeit – umso kürzere Bitfolgen selbigen zuzuweisen. Dieses Verfahren nennt man übrigens Huffman-Kodierung.

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 dann 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 dann alle erforderlichen Informationen zu sammeln. Eine Nachricht „Ich bin aktiv“ kann zudem gänzlich eingespart werden, wenn man weitere Zustandsinformationen regelmäßig übermittelt.

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.

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, 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 mit zum Beispiel BLE zusammen mit Sigfox als primärer Meldekanal für die wichtigsten Usage- und Predictive Maintenance Botschaften eine hervorragende Kombination auch für komplexere Devices darstellt.

All diese Maßnahmen sind für die meisten Embedded Systeme Entwickler im Geräte-, Maschinen- und Anlagenbauer keine Hexerei, denn sie haben ohnehin hinreichend Logik und Rechenpower in ihren Lösungen implementiert, weshalb es für sie auch keine Hürde darstellen sollte, in eine Logik zur Komprimierung der Daten auf die wesentlichen 12 Byte zu investieren.
Manch einer mag sich aber fragen, warum er das tun sollte, wenn er eine zehn- oder hunderttausende Euro teure Maschine verkauft, die er ohnehin schon für Softwareupdates an das Netz anbinden muss. Dieser Einwand ist sicherlich berechtigt. Nimmt man aber die Maschine nur dann ans Breitbandnetz, wenn es wirklich notwendig ist, reduziert man neben den Kosten für eine ständige Datenverbindung auch die Angriffsfläche für Spionage und Sabotage aus dem Internet. Zudem kann man das 0G-Netz auch als Fallback nutzen, wenn das Festnetz- oder Mobilfunknetz ausfällt, im Katastrophenfall überlastet ist oder von Saboteuren über Jammer gestört wird.

Eine 0G-Anbindung kann zudem auch als probates Mittel für Resets im Rahmen des Out-of-Band Managements dienen. Der französische Hersteller von Homeentertainment-Plattformen Free hat es vorgemacht: Er nutzt das 0G-Netz von Sigfox bereits in seiner All-in-One Konsole Freebox Delta für 10 Gigabit Internet, Telefonie, Fernsehen, Ton und Haussteuerung, um die Verfügbarkeit des Systems zu erhöhen. Warum das 0G-Netz also nicht auch für industrielle Systemüberwachungs- und Predictive Maintenance Applikationen nutzen, die in der Regel für die operative Zustandsüberwachung nur ein paar Meldedaten erfordern?

Eine hohe Störsicherheit und EMI-Festigkeit sowie ein hohes Linkbudget zum Funken auch durch den Stahlbeton so mancher Fabrikhalle ist auf jeden Fall gegeben. Insofern könnte man Sigfox auch zum Standard für die Zustandsüberwachung machen und komplementär nur dann das Breitbandinternet zuschalten, wenn Updates gefahren werden sollen oder Datensätze zum Trainieren neuer KI-Algorithmen gezogen werden sollen. Sowohl sicherer als auch energieeffizienter wäre das auf jeden Fall. Sollten OEM weitere Fragen haben, wie sie ihre Daten in 12 Bytes gepackt bekommen, steht das Münchener Büro von Sigfox Germany gerne Rede und Antwort. Es hat im Rahmen des OEM-Supports schon zahlreiche Projekte begleitet und reicht diesen großen Erfahrungsschatz auch gerne weiter.
Alexander Lehmann