IoT-Entwicklungsplattform beschleunigt LPWAN-Implementierung

Der LPWAN-IoT-Entwicklungsprozess folgt tendenziell einer stets gleichen Herangehensweise; sie beginnt auf Kundenseite mit einer Konzeptidee für ein Gerät, das zur Erfassung bestimmter Nutzdaten Verwendung finden kann. Jedoch ist in den meisten Fällen nicht klar, welche Art von Daten zu erfassen sind, oder inwiefern diese Daten im Rahmen der Prozessoptimierung hilfreich sind, um den Kunden wiederum Geld zu sparen. Daher erfordert der Entwicklungsprozess bei der Implementierung von Flex-Sketch-to-Scale-Diensten oder bei der Umsetzung eines Produktkonzepts von der Ideenfindung bis zur Industrialisierung ein gewisses Maß an Wiederholungen.

Bild 1: Eine für die industrielle Umsetzung geeignete LPWAN-Lösung muss bezüglich Kosten, Abmessungen, mechanischer Eigenschaften oder Batteriegröße optimiert sein. Flex

Zuerst erfolgt die Anfertigung eines Prototyps, um zu beweisen, dass die Konzeptidee funktioniert. Dann gilt es, diese in einem kleinen oder mittleren Versuchsaufbau im Feldeinsatz zu testen, um herauszufinden, ob sie erwartungsgemäß funktioniert und ob die gesammelten Daten die richtigen sind, ob die Erfassung auf der richtigen Frequenz erfolgt oder ob die Menge der gesammelten Daten ausreichend ist. Um all diese Variablen zu bestimmen, könnte es erforderlich sein, den Prototypen zu modifizieren oder neu zu gestalten. Eine für die industrielle Umsetzung geeignete Lösung muss bezüglich Kosten, Abmessungen, mechanischer Eigenschaften oder Batteriegröße optimiert sein (Bild 1).

Schnelles Prototyping

Der Bau eines schnellen Prototyps sollte eine einfache und kostengünstige Aufgabe sein, indem einfach eine der vielen offenen und generischen Entwicklungsplattformen zum Einsatz kommt, die heute auf dem Markt erhältlich sind. Der Anschluss der erforderlichen Sensoren und des ausgewählten LPWAN-Interface-Shields an ein Entwicklungsboard vom Typ Arduino oder Raspberry Pi sollte ausreichen, um zu zeigen, dass die IoT-Idee funktioniert, zumindest auf dem Labortisch. Eine Garantie, dass eine integrierte Lösung einschließlich Gehäuse und Batterie auf die gleiche Weise oder mit der gleichen Leistung funktioniert, ist dies jedoch noch nicht. Außerdem ist es unmöglich, den tatsächlichen Stromverbrauch des Endgeräts abzuschätzen.

Doch selbst wenn ein auf dieser Basis gebauter Prototyp gut genug ist, um zum nächsten Schritt des Entwicklungsprozesses überzugehen, also einem Versuch im kleinen oder mittleren Maßstab: Wie gelingt es mehrere Zehner- oder sogar Hundertermengen dieser Prototypen im Feld einzusetzen und zu testen? Bereits geringfügig unterschiedliches Verhalten in den einzelnen Instanzen des Prototyps und die gesammelten Ergebnisse weichen von denen eines integrierten Gerätes ab – ganz zu schweigen von dem Aufwand, die Prototypen mit Kabeln und separaten Batterien auszustatten, sofern diese an einem bestimmten Ort oder einer Maschine zu platzieren sind.

Warum es für einige Lösungen eine gute Idee ist, die Hardware von Grund auf neu zu entwickeln, zeigt der Beitrag auf der nächsten Seite.

LPWAN-Hardwarelösungen entwickeln

Eine weitere Möglichkeit für Kunden besteht darin, von Grund auf eine Hardwarelösung neu zu entwickeln, die eigenen Bedürfnissen entspricht – einschließlich Art und Anzahl der Sensoren, der zu verwendenden LPWAN-Technologie, der Batteriegröße, der Mechanik und des industriellen Designs. Dabei handelt es sich um eine neue Produktentwicklung, die wahrscheinlich ein Jahr Entwicklungszeit und mehrere Hunderttausend Dollar in elektronischen, mechanischen und industriellen Designs, Validierungs-, Test- und Zertifizierungskosten erfordert. Der Kunde müsste etwa sechs Monate warten, um einige Prototypen zu erhalten, damit er mit der Arbeit an der IoT-Anwendung beginnen kann.

Mit einer generischen Entwicklungsplattform zum Start der IoT-Anwendungsentwicklung lässt sich etwas Zeit sparen. Wenn die Neuentwicklung jedoch nicht genau auf der gleichen Architektur der Entwicklungsplatine basiert, ist ein Portierungsaufwand für die Anwendung unvermeidlich. Schließlich sind nach dem Probetest einige Anpassungen und Neukonzeptionen der Hardware erforderlich, um die während des Probetests gewonnenen Erkenntnisse zur Optimierung von Leistung und Stromverbrauch umzusetzen. Es kann sogar vorkommen, dass die ursprünglich gewählte LPWAN-Technologie nicht den Erwartungen entspricht und ein größeres Re-Design mit anschließendem Feldtest notwendig wird, was Entwicklungszeit und Kosten weiter in die Höhe treibt. Flex hat erkannt, dass dieser Mangel an geeigneter Hardware eines der Probleme ist, das die Einführung von IoT-Lösungen verlangsamt, und hat das iENBL entwickelt, um zu einer Lösung beizutragen.

Die IoT-Entwicklungsplattform im Detail

Bild 2: iENBL ist eine IoT-Entwicklungsplattform, die in ein robustes IP65-Zweischalen-Gehäuse mit Fokus auf Low-Power-Wide-Area-Networks eingebettet ist. Flex

iENBL (Bild 2) ist eine IoT-Entwicklungsplattform, die in ein robustes IP65-Zweischalen-Gehäuse mit Fokus auf Low-Power-Wide-Area-Networks eingebettet ist. In einer hochintegrierten Lösung vereint iENBL einen leistungsstarken ARM-Cortex-M4-Mikrocontroller mit 512 MByte Speicher mit den in den meisten IoT-Anwendungsideen benötigten Sensoren, die Kurzstrecken-Kommunikationslösungen Wi-Fi und BLE, einige Aktoren und die erwähnten LPWAN-Technologien. Version 1 konzentriert sich auf die nicht lizenzierten LPWAN-Lösungen LoRa und Sigfox, Version 2 auf die lizenzierten Ausführungen LTE-CatM und NB-IoT. Das in dem iENBL enthaltene Mikrofon und der SD-Kartensteckplatz ermöglichen es, Geräuschdaten in Anwendungen der vorrausschauenden Instandhaltung (Predictive Maintenance) aufzuzeichnen und zu verwenden (Bild x).

Jeder der mitgelieferten Sensoren ist in der Lage, die Datenaufzeichnung durchzuführen. Falls die IoT-Anwendung einen Sensor benötigt, der nicht im Gerät enthalten ist, lässt sich das iENBL erweitern. Es genügt, die benötigten Sensoren an die dafür vorgesehenen Sensoranschlüsse im jeweiligen Erweiterungsport anzuschließen. Der Erweiterungsport dient auch zur Programmierung des Gerätes über eine JTAG-Programmierschnittstelle, obwohl das iENBL auch die Möglichkeit bietet, neue Firmware über den USB-Anschluss herunterzuladen, welcher auch den mitgelieferten 1320 mAh starken Akku auflädt. Bild x zeigt die iENBL-Abmessungen: 65 mm × 97 mm × 26 mm.

Das Asset Tracking ist eine der anspruchsvollsten IoT-Anwendungen, was auch die iENBL-Entwickler berücksichtigen. Die aus diesem Grund integrierte GNSS-Einheit macht in Kombination mit dem Beschleunigungssensor, dem Drucksensor, den WiFi- und BLE-Schnittstellen sowie den Geolokalisierungsfähigkeiten der LPWAN-Technologien das iENBL zu einer geeigneten Plattform für die Entwicklung und den Test von Asset-Tracking-IoT-Anwendungen. Die GNSS-Einheit sorgt für eine genaue Position im Freien, während der LPWAN grobe Positionsinformationen sowohl im Freien als auch im Innenbereich liefert. Die Wi-Fi-Schnittstelle erlaubt den Zugriff auf immer präzisere Wi-Fi-Standortdatenbanken wie die von Google oder Here, wodurch die Möglichkeit zur Standortbestimmung im Innenbereich besteht. Um das BLE-Gerät im Innenbereich einzusetzen, bedarf es einer BLE-Beacon-Infrastruktur. Eine Energiesparoption bietet der Beschleunigungssensor, indem erst das Erkennen einer Bewegung zu einer Aktualisierung der Positionsinformation führt. Außerdem kann der Drucksensor zur Bereitstellung der Höheninformation beitragen.

Auf der nächsten Seite stellt der Beitrag die iENBL-Entwicklungsplattform im Detail vor.

Zwei Versionen

Version 1 des iENBL unterstützt sowohl LoRa als auch Sigfox, die im unlizenzierten ISM-Band arbeiten. Um beide Lösungen in das Gerät zu integrieren, sind zwei verschiedene RF-Frontends notwendig, da LoRa einen der LoRa-Transceiver der Semtech benötigt (zum Beispiel den SX1276), während die Sigfox-FW-Implementierung mit mehreren FSK-Transceivern arbeitet. Es existieren zwei Varianten, deren Antennen optimal auf die europäischen (868 MHz) und die US-amerikanischen Frequenzen (915 MHz) abgestimmt sind.

Version 2 von iENBL konzentriert sich auf die lizenzierten LPWAN-Technologien LTE-CatM und NB-IoT. Anders als bei Version 1 gibt es hier nicht nur eine einzige mögliche Implementierung. Obwohl das 3GPP eine Gruppe von Bändern definiert hat, die offiziell zum Einsatz von LTE-CatM und NB-IoT geeignet sind, erwerben einige Carrier landesweite Breitbandspektren in Frequenzbändern außerhalb dieses Bereichs. Diese unterstützen die bestehenden NB-IoT/Cat-M-Module nicht oder sie benötigen eine spezifische Kanalisierung für Sondereinsätze in industriellen Privatnetzen von Smart Cities.

Die erste Variante (v2.a) verwendet das Quectel-Modul BG96, das den Qualcomm-MDM9206-Chipsatz enthält, der Cat-M/NB-IoT und 2G-Fallback-Kompatibilität unterstützt (Bild 3). Diese iENBL-Variante umfasst die LTE-Bänder B1, B2, B3, B4, B5, B8, B12, B13, B18, B19, B20, B26, B28 in FDD und das Band B39 in TDD nur für Cat-M. In 2G unterstützt es EGPRS: 850/900/1800/1800/1900 MHz.

Die zweite Version (v2b) basiert auf dem Chipsatz GDM7243i von GCT. Dieses Design unterstützt die erweiterten Bänder B71 und B7/B38 für Cat-M/NB-IoT, aber auch Sigfox und eine zusätzliche BLE-Schnittstelle. Sigfox- und BLE-Funktionen sind bereits in den GDM7243i-Chip integriert. Die Sigfox-Schnittstelle kann sehr kleine Nachrichten senden und so die Energie des viel leistungshungrigeren NB-IoT-Modems sparen oder eine grobe Geolokalisierung durchführen, ohne die GNSS-Einheit oder das NB-IoT-Modem dabei aufwecken zu müssen. Außerdem kann die BLE-Schnittstelle sehr nützlich sein, wenn ein FW-Update erforderlich ist und die NB-IoT-Datenrate an einem bestimmten Ort (zum Beispiel unter der Erde oder im Edge-Bereich der Zelle) verfügbar ist.

Bild 3: Die erste Variante (v2.a) verwendet das Quectel-Modul BG96, das den Qualcomm-MDM9206-Chipsatz enthält, der Cat-M/NB-IoT und 2G-Fallback-Kompatibilität unterstützt. Flex

Variante v2c demonstriert den Betrieb eines SiP (System in Package), das Flex in Zusammenarbeit mit Altair Semiconductors entwickelt hat. Dieses SiP integriert das ALT1250-Cat-M/NB-IoT-Basismodem und das ALT-1910-RF-Frontend, das alle Bänder von 700 MHz bis 2,2 GHz in nur einer Artikelnummer unterstützt, mit einem ARM-Cortex-M4-Mikrocontroller und einer Sony-GNSS-Einheit in einem Formfaktor von 10 × 10 × 1 mm³ (Bild 3). Dieses SiP soll die Cat-M/NB-IoT-Konnektivität in IoT-Geräten mit reduziertem Formfaktor wie in Wearables, medizinischen Geräten oder Personal Trackern ermöglichen.

Zusammenfassung

LPWAN-Technologien eröffnen ein neues Spektrum an Geschäftsmöglichkeiten im IoT-Bereich, aber die Auswahl und Einführung einer neuen Funktechnologie ist ein langsamer Prozess, der umfangreiche Feldtests neuer Entwicklungen und Ideen erfordert. Tests im Feld setzen oft die Entwicklung eines Prototyps voraus. Dies kann ein teurer und zeitaufwendiger Prozess sein und ist in der Regel ein Bremsklotz, da das potenzielle Geschäft und der ROI dieser Idee unklar sind, bis endlich die Ergebnisse einer mittelgroßen Studie vorliegen. Allerdings ist dies nicht mit den traditionellen, auf dem Markt erhältlichen Arduino-Evaluierungsboards erreichbar, lediglich ergänzt um einige Sensoren und ein LPWAN-Connectivity-Shield. Diese Lösung ist geeignet, um eine Idee in einem Testaufbau zu evaluieren, doch sie ist noch nicht dafür ausgelegt, in einem Feldtesteinsatz einen Proof-of-Concept durchzuführen. Außerdem sind sie im kleinen und mittleren Maßstab nicht reproduzierbar. Dies hat die Entwicklung neuer IoT-Anwendungen und die Einführung von LPWAN-Technologien verlangsamt – zumindest bislang. Die Lösung dieses Problems ist eine integrierte Entwicklungsplattform mit LPWAN-Anbindung und den für die meisten IoT-Anwendungen erforderlichen Sensoren.

(aok/na)