Prototypen für den IoT: Sicherstellen, dass kleine Geräte in der großen Welt Funktionieren
Der Bau von Prototypen als Teil des Entwicklungsprozesses erlaubt dem Entwickler, Hände anzulegen, um eventuelle Fehler früh im Prozess zu finden. Dabei kann man auch neue Ideen entdecken und Funktionen einbauen, die am Anfang vielleicht nicht aufgekommen wären.
von Kim Rowe, RoweBots, Ltd.
„Dieses Ding, an dem wir basteln—wird es wirklich funktionieren, wie wir uns vorstellen?“ Das ist natürlich bei jedem großen Projekt die unausgesprochene Angst. „Na, wir sind uns relativ sicher.“ Das ist mindestens die beste—auch oft unausgesprochene—Antwort, die man erwarten kann, ohne einige konkrete Prüfungsmaßnahmen zu nehmen, die versichern, dass das Projekt in der gehofften Richtung läuft. Wie wir aus der Werbung wissen, ist die Welt allerhand mit graphischen Simulationssystemen gesegnet, die den Fortschritt von Entwicklungsprojekten simulieren und prüfen können. Obwohl solche Werkzeuge enorm hilfreich und nützlich sind, besteht die Tatsache, dass die meisten Projekte darauf gerichtet sind, ein wirkliches „Ding“ zu produzieren. Das bedeutet ein Stück Software oder Hardware oder irgendein elektromechanisches System, das in der wirklichen Welt Platz einnimmt. Bevor so etwas in die Produktion geht, um hoffentlich Umsatz zu produzieren, wollen wir ein funktionierendes Modell haben—einen Prototyp. Dieser Prototyp mag nicht schön aussehen, an ihm mögen überall Drähte anhängen, aber bevor wir es zur Produktion schicken, wollen wir ein Ding haben, das funktioniert,
Was das eigentlich ist, das einen passenden Prototyp darstellt, kann je nach der Art des Zielsystems unterschiedlich sein. Es könnte hauptsächlich Software sein. Es könnte aus einer einzelnen Leiterplatte mit kleiner Anzeige und blinzelnden Lichtern bestehen. Es könnte andererseits ein sehr großes elektromechanisches System sein, das mit funktionierenden Einheiten über das Web verteilt ist und auch eine ausführliche grafische Benutzeroberfläche hat. Für den Internet of Things sind die Fragen des Prototypens über Netzwerken echt und unterschiedlich. Es bleibt aber dir Frage, „Wird das funktionieren?“ Kann es mit der nötigen Energieversorgung in ein kleines Packet passen und noch die erzeugte Hitze ableiten? Was niemand erleben will, sind die Pannen, die im letzten Augenblick auftauchen, die die Einführung eines Produkts verhindern können.
Hieraus könnte man schließen, dass es für den Bau eines Prototyps, keine formelle Regeln gibt. Es gibt aber vielleicht eine Regel: Man will auf jeden Fall den Bau von mehreren Prototypen vermeiden, die nötig wären, um Designfehler zu korrigieren oder Abänderungen zu machen. Das bedeutet, dass ein Prototyp irgendwie zugänglich und auch modular sein sollte. Es sollte relativ leicht sein, Testleitungen zu verbinden und kritische Komponenten auszutauschen. Das kann man sich für große elektromechanische Systeme ziemlich leicht, aber für ein kleines Embedded-Gerät wahrscheinlich nicht so leicht vorstellen.
Es könnte aber auch viel schwieriger sein, für ein großes Maschinensystem, das eine Menge verschiedener Komponenten hat, auf einer einzigen Stelle ein Prototyp zu bauen. In diesem Fall könnte es besser sein, für die einzelnen Komponenten, Prototypen zu bauen und ihre einzelne Funktionalität zu prüfen. Dann müsste man ihre Interaktion testen. Können sie ohne Daten- und Protokollkonversion und ohne Störung miteinander kommunizieren? Heutzutage ist es sehr wahrscheinlich, dass die einzelnen Komponenten eines großen elektromechanischen Systems selber aus Embedded-Geräten bestehen. Von diesen sind einige einfach Teile einer größeren Komponente, die gekauft wurde, um in das System integriert zu werden. Andere, zusammen mit dem Hauptkontrollsystem, können wichtige Teiles des Entwicklungsprozesses sein.
Prototypen für den IoT
Prototypen für den Internet of Things bauen bedeutet für den Entwickler Fluch und Segen. Auf der einen Seite kann das System buchstäblich den Globus umspannen und auf Ebenen von winzigen Sensoren bis zu großen Maschinen arbeiten. Auf der anderen Seite gibt es unzählige kleine Geräte, die quasi-unabhängig sind, die aber auch fehlerlos funktionieren müssen. Diese sind über lokale Netzwerke mit ihren eigenen Gateway-Computern verbunden, die dann mit dem Internet verbinden und weiter zu Cloud-Servern in Datenzentren. Die erste Frage ist wohl, „Was ist in diesem Kontext eigentlich ein Prototyp?“ Das Internet und mit ihm der IoT ist offensichtlich ein Produkt der Evolution und diese Evolution geht weiter. Auf dieser Ebene von einem „Prototyp“ zu reden wäre bedeutungslos. Aber jedes zusätzliche Gerät und Funktion—von Sensor bis zu Cloud-Server—wird durch die Prototypstufe gehen müssen, um zu bestätigen, dass es im Kontext des Ganzen fehlerlos funktioniert. In den meisten Fällen, kann man es am Anfang als ein riesiges Software-Projekt vorstellen, das von kleineren aber sehr detaillierten Hardware/Software-Projekten gefolgt wird (Abbildung 1).
1: Für das IoT gibt es drei Ebenen von Prototypen. Auf der Cloud-Ebene ist es meistens Softwareentwickelung und Protokollprüfung. Auf der Gateway-Ebene gibt es mehr anwendungsorientierte Software- und Benutzeroberfläche- Entwickelung. Für die Geräte am Rande werden starke Prototypen gebaut und zwar für die Auswertung von Software/Hardware-Funktionalität, Kommunikation, Sicherheit, Energieverbrauch, Wärmeabfuhr und mehr.
Wenn man das System über die einzelnen eingesetzten Geräte hinaus betrachtet—und das heißt Gateway-Computer sowie Internet/Cloud-Elemente—konzentrieren sich die Fragen meistens auf Software. In vielen Fällen sind die Gateway-Geräte etwas Anderes als normale PCs sind aber auch meistens für ihre eigenartige Funktionalität gekauft und nicht vom IoT-Entwickler gebaut. Das bedeutet, dass hier das Prototypen auch meistens Software ist.
Diese Software muss in erster Linie versichern können, dass die Daten, die von und zu den verteilten Geräten übermittelt werden, korrekt sind und weiter, dass die Daten, die mit der Cloud und ihren Servern geteilt werden, auch für die Internet-Übermittelung richtig konvertiert und formatiert werden. Aber zusätzlich werden die Gateway-Geräte auch verwendet, gewisse Arten von Analyse auszuführen und Entscheidungen zu machen, die als Befehle an die verteilten Geräte schnell zurückgeschickt werden. Solche Interaktionen müssen zuerst als Prototypen gebaut und getestet werden—für Kommunikation und auch für die Funktionalität ihrer einzelnen Geräte.
Anwendungen, die auf Gateway-Geräten laufen, sind mit zwei verschiedenen Netzwerken und mit deren Protokollen und Datenformaten verbunden. Zu diesen gehören natürlich das Internet und auch ein lokales Netzwerk, wie, z.B., Wi-Fi, 6LoWPAN, LoRa und Bluetooth. Protokollkonversion ist eine entscheidende Funktion, die für Genauigkeit ausführlich getestet werden muss. Zusätzlich sind diese Gateway-Geräte mit der Funktionalität der Geräte, mit denen sie kommunizieren, auch eng verbunden. Das bedeutet, dass ein gründliches Verständnis und Überprüfung dieser Funktionalität vom Standpunkt des Gateway-Geräts auch unbedingt nötig sind.
Das Gateway-Gerät bietet eine funktionelle Brücke aber es kann auch andere, Fragen geben, wie zum Beispiel eine graphische Benutzeroberfläche (GIU). In vielen Fällen kann das Gateway-Gerät ein GUI anzeigen oder mit einem, das auf einem Smartphone oder Tablette läuft, die von einem Fabrikmanager oder einem Sporttrainer getragen wird, verbinden. Solch ein GUI erlaubt einen gewissen Grad von Eingreifen auf der näheren Gateway-Ebene, ohne zur Cloud-Server-Ebene greifen zu müssen. Diese müssen auch getestet werden, um sicherzustellen, dass sie die anderen Funktionen nicht beeinträchtigen.
Die Hauptfragen für Prototypen auf den Gateway- und Cloud-Ebenen befassen sich also mitSoftware. Und das fordert ausführliche Prüfung der spezifischen Anwendungen auf beiden Ebenen. Dazu kommt auch die ausführliche Verifizierung der Daten während Protokollkonversion und Übermittelung von Gerät zu Gateway-Anwendung und weiter zum Server auf dem Internet. Auch die Befehle, die von beiden Ebenen zum Gerät zurückfließen müssen verifiziert werden. Das Testen des Daten- und Befehl- Austausches zwischen Gerät und Gateway geht am besten, wenn es mit einem Gerätprototyp ausgeführt wird. Sonst müsste man das mit simulierten Daten machen.
Neue Geräte zum System hinzufügen
Das Prototypen eines neuen Geräts, das in ein etabliertes Netzwerk einpassen soll, ist vielleicht die häufigste Prototyparbeit im IoT. Es fordert den Bau eines neuen Geräts, das über das lokale Netzwerk mit dem Internet verbunden wird, und die Verifizierung seiner Interaktion—entweder direkt oder indirekt—mit anderen Geräten, um irgendeine Aufgabe zu erfüllen. Es ist viel weniger „abstrakt“ als auf den anderen Ebenen, denn, zusätzlich zu Software. bringt es auch die Probleme von Größe, Gewicht, Energieverbrauch und Hitze mit sich.
Normalerweise ist der erste Schritt, einen Prozessor auszusuchen, der mit den Funktionsbedürfnissen des Geräts passt. Viel besser ist es, eine Prozessorfamilie auszusuchen, die Softwarekompatibilität über verschiedene (größere oder kleinere) Versionen des Produkts unterstützen kann. Es ist ebenso wichtig, dass man ein Embedded-Betriebssystem wählt, das mit der Prozessorfamilie passt. Noch günstiger wäre es, ein Betriebssystem zu finden, das mit anderen Prozessorfamilien arbeitet, für den Fall, dass das Projekt geändert wird. Dadurch kann man vermeiden, dass die schon gemachte Softwareentwicklung völlig aufgegeben wird. Die Wahl eines RTOS/Prozessor-Paars ist die erste Entscheidung für eine Entwicklungsplattform, die endlich ein komplettes Produkt wird (Abbildung 2).
2: Diese Bretter sind das STM32F4 (l) und das STM32F7 (r) von STMicrosystems und tragen einen 32-Bit Mikrokontroller mit ARM Prozessor. Sie werden von RoweBots angeboten und bieten Entwicklungsplattformen zusammen mit dem Unison-RTOS und Treibern für eine ganze Menge Sensoren, Peripheriegeräte und Kommunikationsalternative.
Zum Glück für den heutigen Entwickler sind die Halbleiterhersteller noch einen Schritt weitergegangen. Sie bieten Evaluierungsbretter, die zusammen mit ihren Prozessoren auch eine Auswahl von Peripheriegeräten tragen, die einen schnellen Start an die Evaluierung und Entwicklung ermöglichen. Noch besser gibt es eine Nummer Partnerschaften zwischen Halbleiter- und RTOS-Herstellern, durch die Entwicklungsbausätze angeboten werden, die mit RTOS, Treibern und Kommunikationsprotokollen geliefert werden. Solche Bausätze auszunutzen bedeutet eine erhebliche Verkürzung der Markteinführungszeit.
Zusätzlich zu den Peripheriegeräten, die auf dem Evaluierungsbrett geliefert werden, ist es wichtig, dass der RTOSverkäufer weitere Unterstützung bietet. Das bedeutet natürlich Treiber für die Komponente auf dem Brett. aber auch eine Auswahl von vorgeprüften Treibern und anderen Software-Komponenten, die in das fertige RTOS-Image leicht integriert werden können. Der Gebrauch von Open-source ist ein weiterer Vorteil, indem er dem Entwickler ermöglicht, Code von außen hereinzubringen und das eigene schon verwendete Code—entweder direkt oder mit Verbesserungen—wieder zu gebrauchen, ohne ganz neu anfangen zu müssen. Eine reiche Auswahl an Komponenten bedeutet nicht nur Treiber, sondern auch Protokolle für verdrahtete und drahtlose Kommunikation, Dateisystem, Sicherheit, grafische Benutzeroberfläche und mehr. Mit einem derartigen Arsenal sollte es möglich sein, einen völlig funktionierenden (wenn auch nicht gerade schön aussehenden) Prototyp zusammenzustellen. Und davon wird es leichtfallen, Veränderungen zu machen und das Endprodukt zu schöpfen. Die Daten und Kommunikation des Geräts mit dem größeren System sollten hinauf bis zur Cloud getestet werden, um sicherzustellen, dass der Weg klar und sicher ist.
Die letzte und vielleicht schwierigste Phase des Prototypens kommt gegen das Ende, wo man genaue Schätzungen für die Energieverwendung und Hitzeableitung bestimmen will, um auf das endgültige Gehäuse zu entscheiden. Dafür muss man die Hitze messen, die vom Prototyp in seiner jetzigen Form ausgegeben wird, und dann entscheiden, wie diese Hitze vom endgültigen Gehäuse abzuleiten ist. Für kleine Geräte, wie Smartphone und tragbare Geräte, kann das eine große Herausforderung darstellen, um zur richtigen Kombination von Form und Größe zu gelangen, die auch eine Batterie akzeptieren muss. Es gibt eine Zahl RTOSverkäufer, die auf einer einzelnen Vertragsbasis mit diesen Problemen helfen können.
In einigen Fällen, oft wenn es auf das Gehäuse ankommt, kann es nützlich sein, Prototypen an ein Testteam oder auch an bestimmte Kunden zu verteilen, um Rückmeldung und Ideen für Optimierung zu bekommen. Das Ziel ist, sich immer in der Richtung des optimalen Designs zu bewegen. Der Bau und Gebrauch von einem Prototyp können den Entwicklern helfen, Ideen zu haben, an die sie am Beginn eines Projekts nicht gedacht hätten. Dadurch können sie auch Hindernisse entdecken, die am Anfang nicht vorgesehen waren. Die Begegnung mit der realen Welt ist der letzte Test—und den will man vor der Produkteinführung bestehen.