Die LPWAN-Funktechnik Mioty bietet Skalierbarkeit (massive IoT) und eine bisher unerreichte Zuverlässigkeit. Genügend Potenzial, um zukünftig eine führende Rolle im Bereich der IIoT-Funktechniken zu übernehmen. Doch was muss ein Sensorhersteller tun, um Mioty für seine Produkte nutzen zu können?
Ausgangspunkt für die Entwicklung des softwarebasierten LPWAN-Protokolls Mioty beim Fraunhofer Institut für integrierte Schaltungen (IIS) war das Ziel, die heute noch bestehenden Einschränkungen in der Funkkommunikation im weiten Feld der industriellen IoT-Anwendungen zu überwinden und neue Maßstäbe in Sachen Skalierbarkeit, Zuverlässigkeit, Mobilität, Effizienz und Flexibilität zu setzen. Dreh- und Angelpunkt bei der technischen Umsetzung ist die Telegram Splitting Multiple Access (TSMA) genannte Methode (Bild 1). Gemäß Definition des European Telecommunications Standards Institute (ETSI TS 103 357) werden hierbei die zu übermittelnden Datenpakete auf Endgeräteseite in kleinere Sub-Pakete aufgeteilt. Der Versand erfolgt zu definierten Zeitpunkten auf verschiedenen Frequenzen [1, 2].
Durch die Verwendung mehrerer Algorithmen in der Mioty-Basisstation ist es möglich, mittels der empfangenen Sub-Pakete das vollständige Datenpaket zu rekonstruieren. Im Gegensatz zu anderen LPWAN-Protokollen, die deutlich anfälliger auf auftretende Interferenzen während der Telegrammaussendung reagieren, bietet Mioty durch seine einzigartige Telegramm-Splitting-Methode und die Nutzung verschiedener Algorithmen eine wesentlich höhere Robustheit. Im Idealfall muss eine Mioty-Basisstation nur 50 % des ausgesendeten Datenpakets korrekt empfangen, um die kompletten Daten rekonstruieren zu können. Das Mioty-Protokoll verringert hierdurch die Paketfehlerrate (Packet Error Rate, PER) um ein Vielfaches. Gerade in Zeiten von massiv zunehmendem Funkdatentransfer aufgrund voranschreitender Digitalisierung und der damit einhergehenden wachsenden Anzahl von Interferenzen, bietet diese Technik mit ihrer sehr hohen Zuverlässigkeit einen entscheidenden Vorteil.
Mioty zeichnet sich jedoch nicht nur durch eine außergewöhnlich hohe Zuverlässigkeit aus. Mit einem sehr effizienten Energieeinsatz können mitunter Batterielebensdauern von bis zu 20 Jahren erreicht werden. Außerdem kann die sehr stabile Datenübertragung von rund einer Million Sendern und bis zu 1,5 Millionen Nachrichten pro Tag mit nur einem Empfänger einer Basisstation sichergestellt werden und das im stationären oder mobilen Betrieb bei einer Geschwindigkeit von bis zu 120 km/h. Hunderttausende Sensoren können so über viele Jahre relativ wartungsfrei und energieeffizient betrieben werden. Ein weiteres Plus ist die Möglichkeit der bidirektionalen Kommunikation, sofern diese von der eingesetzten Schaltung unterstützt wird.
All das klingt nach einem flexibel einsetzbaren und vor allem zukunftsorientierten Funkprotokoll für Sensorhersteller. Was aber gilt es konkret zu beachten, wenn ein Mioty-Funksensor entwickelt und verkauft werden soll?
Um einen Sensor Mioty-fähig auszustatten, gilt es je nach Anwendungsfall auf die Details zu achten. Soll z.B. die Sensoranwendung auf demselben Mikrocontroller wie die Kommunikationssoftware eingesetzt werden (Bild 2), ist zu beachten, dass auch die Ressourcen des Mikrocontrollers und dessen Peripherie untereinander geteilt werden müssen. Dies kann unter Umständen bei sehr zeitkritischen Sensoranwendungen ein Nachteil sein. Ebenso ist besonderes Augenmerk auf die Art der Kommunikation zu richten.
Mit Mioty ist zwar eine bidirektionale sowie eine unidirektionale Kommunikation möglich, Entwickler sollten aber berücksichtigen, dass nicht alle Mioty-kompatiblen Funkbausteine, die aktuell auf dem Markt angeboten werden, beide Kommunikationsvarianten unterstützen.
Zunächst ist die Frage zu klären, welche Architektur zur Verbindung mit der Mioty-Funktechnik für die geplante Schaltung die richtige ist. Für Sensorhersteller ergeben sich grundsätzlich drei Optionen:
Um die eigene Schaltung zur Sensorauswertung mit einer Mioty-Funkschnittstelle auszustatten, kann ein fertiges Mioty-Kommunikationsmodul gewählt werden, das die Kommunikation mit dem Mioty-Netzwerk übernimmt (Bild 2 oben und Bild 3). Damit ist es auch möglich, eine bereits bestehende Sensorschaltung, mit genügend Platz im Gehäuse, ohne große Änderungen mit einer Mioty-Funkschnittstelle auszurüsten. Über unterschiedliche Schnittstellen, wie zum Beispiel UART oder SPI, wird dann das Mioty-Kommunikationsmodul mit der Sensorschaltung verbunden.
Fällt die Wahl auf das Kommunikationsmodul, gibt es drei Möglichkeiten:
Der Vorteil dieses Ansatzes liegt vor allem im geringen Entwicklungsaufwand und dem geringen Risiko für Überraschungen bei der Zertifizierung des Gerätes.
Eine Alternative zum Kommunikationsmodul ist die Integration eines dedizierten Mikrocontrollers nebst Funk-Transceiver-IC bzw. eines System-on-Chip, das speziell für die Kommunikation eingesetzt wird. In der Architektur unterscheidet sich der Zwei-Chip-Ansatz nicht von der des Kommunikationsmoduls, jedoch ist diese Variante platz- und kostensparender.
Softwareseitig ist der Zwei-Chip-Ansatz im Vergleich zum Einsatz eines Kommunikationsmoduls gleichermaßen einfach. Jedoch ist der Aufwand hinsichtlich der Schaltung etwas höher, da eine entsprechende Leiterplatte entwickelt werden muss – und es steigt auch der Aufwand für die Produktzertifizierung.
Der am stärksten integrierende Ansatz ist der Einsatz einer Mioty-konformen Schaltung, auf der die Sensoranwendung ausgeführt werden kann. Bei dieser Variante wird lediglich ein Baustein für die Anwendung und die Kommunikationssoftware benötigt (Bild 2, unten). Eine Softwarebibliothek (Bild 4) wird in die eigene Sensor-Firmware integriert. Mit dieser Bibliothek nutzt der Entwickler eine fertige Implementierung des Übertragungsprotokolls und steuert auch den Funk-Transceiver-IC bzw. den Funkteil bei einem System-On-Chip an.
Der Vorteil dieses Ansatzes liegt in den Einsparungen bezüglich der Bauteilkosten sowie im geringsten Platzbedarf der verschiedenen Möglichkeiten. Jedoch sind die Einmalkosten für die Entwicklung bei dieser Variante deutlich höher, denn es muss eine eigene und nicht selten eine produktspezifische Schaltung entwickelt werden.
Ebenso gibt es bei der Integration der Softwarebibliothek für den Mioty-Protokollstapel ein paar Dinge zu beachten, da sich die Sensoranwendung und der Protokollstapel die Ressourcen des Mikrocontrollers teilen. Unter Umständen nutzt die Anwendung die Rechenzeit, die eigentlich der Protokollstapel benötigt, um standardkonform kommunizieren zu können. Dies kann typischerweise durch entsprechende Testtools und auf jeden Fall durch den Hersteller der Softwarebibliothek überprüft werden.
In Summe ist diese Architektur insbesondere für Produkte interessant, die in hohen Stückzahlen gefertigt werden sollen und vor allem möglichst geringe Kosten pro Gerät erfordern.
Neben verschiedenen Mikrocontrollern in Kombination mit Funk-ICs unterstützt Mioty auch System-on-Chips (SoC), bei denen sowohl die Funkschaltung als auch der Mikrocontroller in einem Chip integriert sind. Der wesentliche Vorteil der SoCs liegt in der geringen Baugröße sowie der energieeffizienteren Nutzung des Funkteils.
Mit Blick auf die Schaltung ist es ein besonderes Plus, dass Mioty eine softwarebasierte Kommunikationstechnik ist. Dadurch lassen sich schon jetzt eine Vielzahl der am Markt erhältlichen Funk-ICs für Mioty einsetzen. Eine kleine Auswahl zeigt die Tabelle.
| Hersteller | Funk-IC |
bidirektionale Kommunikation |
|---|---|---|
| Semtech | SX1276 | nein |
| STMicroelectronics | S2-LP | nein |
| Texas Instruments | CC13x0 | ja |
| Texas Instruments | CC13x2 | ja |
| Silicon Labs | Si4463 | nein |
| Silicon Labs | EFR32FG14 | ja |
Klar ist, die Sensor-Firmware wird typischerweise vom Sensorhersteller oder einem Softwaredienstleister entwickelt. Schließlich ist die Firmware das Herzstück, das dem Sensor mit dem Know-how des Herstellers Leben einhaucht. Aber ist es deshalb ratsam, als Sensorhersteller auch die Kommunikationsschnittstellen selbst umzusetzen?
Ein »Für« ist natürlich, dass der Sensorhersteller damit über den eigenen Source Code verfügt. Im selben Atemzug muss allerdings auch der Pflegeaufwand des Source Code als klares »Wider« genannt werden. Selbst wenn die Implementierung eines Protokolls hinsichtlich des Energiebedarfs vollkommen fehlerfrei und absolut effizient sein sollte, muss der Protokollstapel spätestens beim nächsten Update des Kommunikationsstandards angefasst werden. Es gibt daher einige Aspekte, die dafür sprechen, die Implementierung des Protokollstapels Spezialisten zu überlassen – Pflege und Gewährleistung sind dabei nur zwei.
Einen Protokollstapel zu beziehen ist denkbar einfach, hierfür gibt es typischerweise zwei Lizenzmodelle:
Dieses Lizenzierungsmodell ist insbesondere dann interessant, wenn die Stückzahlen nicht sehr hoch sind oder noch nicht klar ist, wie hoch die Stückzahlen tatsächlich ausfallen werden, und ob sich damit eine One-off-Lizenz als sinnvoll erweist. Denn diese Lizenzart kann später auch durch eine One-off-Lizenz ersetzt werden, wenn die Stückzahlen deutlich höher ausfallen, als ursprünglich erwartet.
Zu beachten ist hierbei, dass die Lizenzen für die Softwareimplementierung nicht die nötigen Rechte zur Nutzung der Patente beinhalten, wie im nächsten Kapitel erklärt.
Für die Nutzung und den Verkauf eines Mioty-fähigen Sensors sind Lizenzen für die Nutzung der patentierten Technik nötig. Dies gilt ebenfalls für Mioty-Basisstationen. Sowohl die Lizenzgebühren für die Software als auch für die Technik unterscheiden zwischen der unidirektionalen und der bidirektionalen Variante. Als Sensorhersteller sollte dies schon frühzeitig berücksichtigt werden, da sich sowohl die Lizenzgebühren für die Kommunikationssoftware, also auch für die relevanten Patente unterscheiden.
Der Patent-Pool, der alle für Mioty relevanten Patente umfasst, wird von dem IP-Verwaltungsunternehmen Sisvel International verwaltet, mit Hauptsitz in Luxemburg.
Der Bezug einer Mioty-Techniklizenz ist denkbar einfach:
Alle Details und aktuelle Informationen hierzu sind auf der Website [3] von Sisvel verfügbar. In jedem Fall empfiehlt es sich, auch bei kleinen Unklarheiten mit Sisvel International in Kontakt zu treten, um einen reibungslosen Ablauf der Lizenzierung sicherzustellen.
Ein sehr einfacher Einstieg ist zum Beispiel mit einem CC1312 LaunchPad von Texas Instruments und einer Modem-Firmware von Stackforce möglich. Damit erhält ein Entwickler ein unabhängiges Mioty-Kommunikationsmodul, das über eine serielle Schnittstelle, z.B. USB, gesteuert werden kann. Die eigentliche Sensoranwendung kann auf einem zweiten, beliebigen System entwickelt werden.
Für erste Tests oder zur Entwicklung kann mit einem CLI-Programm (Command Line Interface) von Stackforce das Kommunikationsmodul mit dem CC1312-Mikrocontroller direkt von einem PC aus angesteuert werden
Als Gegenstelle der Mioty-Endknoten wird eine Mioty-Basisstation benötigt. Sie kann von unterschiedlichen Herstellern bezogen werden. Hier gibt es bereits verschiedene Varianten:
Die Basisstationen bieten typischerweise eine Web-Oberfläche, die zur Konfiguration des Netzwerks und für einen Überblick des Mioty-Datenverkehrs dienen kann.
Literatur
[1] Sikora, Dr. A.: Funkprotokoll für Massive IoT – Standard für skalierbare Netzwerke. elektronik.de, 17. September 2020, www.elektroniknet.de/kommunikation/wireless/standard-fuer-skalierbare-netzwerke.178949.html.
[2] Bernhard, J.; Dünkler, R.; Kneißl J. und Otte, L.: Funknetzwerke – Mioty – die Revolution des IoT. elektronik.de, 18. April 2019, www.elektroniknet.de/kommunikation/wireless/mioty-die-revolution-des-iot.164612.html.
[3] Mioty Massive, secure and powerful LPWAN technology, About MIOTY Licensing Platform. Sisvel International, Website, www.sisvel.com/licensing- programs/wireless-communications/ mioty/introduction.
[4] Mioty Stack. Stackforce, Website, www.stackforce.de/mioty-stack.
Der Autor
Patrick Weber
absolvierte sein Studium an der Hochschule Offenburg mit einem Abschluss in Elektrotechnik/ Informationstechnik (B. Eng.) und in Informatik (M. Sc.). Nach dem Studium war er zunächst in der Entwicklungsabteilung bei MSC Technologies tätig, bevor er als Entwicklungsingenieur zu Stackforce wechselte. Inzwischen ist er als Principal Engineer bei Stackforce hauptsächlich für Projektmanagement und Softwarearchitektur verantwortlich, aber auch bei der Entwicklung verschiedener Protokoll-Stacks involviert. Zudem leitet er die Task Force Application Layer, einer Task Force des Technical Committees der Mioty Allianz.
patrick.weber@stackforce.de
