In „IoT-Entwicklung – einfach, sicher, schnell. Entwickeln und testen im Studio!“ wurde bereits der Aufbau des Studios beschrieben. Das CODEbed (CODEbed ) wird für die Programmierung der IoT App selbst genutzt, während das TESTbed (TESTbed ) zum Testen der IoT App im Zuge der Programmierung zur Verfügung steht.
Dieser Artikel beschäftigt sich mit den Details für die Entwicklung von IoT-Apps. Sie lernen, mit welcher IoT App Komponente sie am besten starten und welche Punkte es dabei zu beachten gibt. Weiters werden Projekteinstellungen erklärt, die für ein Release von IoT Apps wichtig sind.
DDE als Startpunkt für die IoT App Entwicklung
Nachdem Sie ein neues Projekt im Studio erstellt haben, müssen die einzelnen Komponenten implementiert werden. Doch mit welcher Komponente starten Sie am besten?
IoT-App Komponenten:
- Data Descriptor (DDE): Struktur der Daten (Messdaten, Konfigurationen, etc.)
- Device Logic (DLO): Logik die im Gerät ausgeführt wird
- Portal View (POV): Frontend der IoT-App auf der IoT-Plattform
- Backend Logic (BLO): Logik die auf der IoT-Plattform ausgeführt wird
Der DDE definiert die Struktur der Konfigurationsdaten und der historischen Daten. Diese Struktur wird von den weiteren Komponenten der IoT App (DLO, POV, BLO) zur Interaktion benötigt. Deswegen empfehlen wir immer mit dem DDE zu starten.
Die “DDE Basic Examples Collection” im Studio erklärt die praktische Anwendung des DDE und zeigt die Möglichkeiten und Funktionen des DDE anhand von mehreren Beispielen.
Wichtige Punkte für den Aufbau des DDE
Von der Datenbeschreibung die im DDE (Data structure) erfolgt, hängen die anderen Komponenten der IoT App ab. Deswegen ist schon zu Beginn gut zu überlegen, wie dieser aufgebaut und strukturiert werden soll.
Zudem ist es wichtig, sich zu überlegen, welche Konfigurationsmöglichkeiten einem Anwender für die IoT-App zur Verfügung stehen sollen. Ein Beispiel sind Aufzeichnungs- und Übertragungsintervall oder der Übertragungsmodus. Wenn diese Felder für Anwender konfigurierbar gemacht werden sollen, müssen diese im DDE entsprechend angelegt werden. Eine Erklärung dazu ist unter “Data structure” im Abschnitt “Division of a configuration memory block into individual data fields“ zu finden.
Für Konfigurationen, die häufig verändert werden und Konfigurationen, die selten verändert werden, empfiehlt sich eine Auftrennung in separate Container. Diese Aufteilung der Konfigurationen bringt den Vorteil, dass nicht alle Konfigurationsfelder gleichzeitig auf das Gerät übertragen werden müssen und dadurch Datenvolumen gespart wird.
Ein ähnliches Vorgehen empfehlen wir auch bei den historisch aufgezeichneten Daten. Bei historisch aufgezeichneten Daten bietet es sich an, Messdaten, die miteinander aufgezeichnet werden, in entsprechende Container zu gruppieren. Neben der Reduktion des Datenvolumens, verhindert die Auftrennung in separate Container, dass Messwerte aufgezeichnet werden müssen, die zum Zeitpunkt der Aufzeichnung noch nicht vorhanden sind. Beispielsweise wenn es zwei unterschiedliche Quellen für die Messdaten gibt und diese zu unterschiedlichen Zeiten aufgezeichnet werden sollen.
Die Strukturierung von IoT Apps
Das Studio bietet verschiedene Möglichkeiten ein Projekt zu strukturieren. Das erleichtert vor allem bei größeren Projekten die Wartung.
Im CODEbed ist es möglich für eine DLO/POV/BLO mehrere Dateien anzulegen, um eine IoT App in verschiedene Teile zu trennen. Durch diese Auftrennung wird die IoT App besser strukturiert und das Verständnis der unterschiedlichen Teile der IoT App erleichtert.
Für eine weitere Kapselung der IoT-App-Abschnitte gibt es zu dem die Möglichkeit im CODEbed Ordner anzulegen, sollte es notwendig werden mehrere Dateien in einen Ordner zu gruppieren.
Libraries bieten eine weitere Möglichkeit eine IoT App zu strukturieren und zu vereinfachen, in dem der Code für bestimmte Abschnitte einer IoT App in eine Library ausgelagert wird.
Die Vorteile von Libraries im Überblick
Um den Wartungs- und Entwicklungsaufwand von IoT Apps für Sie möglichst gering zu halten, gibt es Libraries für häufig verwendete Komponenten. Ein einfaches Beispiel ist eine Bibliothek, die ein bestimmtes Kommunikationsprotokoll implementiert wie beispielsweise die Modbus Master Bibliothek.
Durch eine Library befindet sich der Code für eine bestimmte Komponente an einem zentralen Ort und kann dadurch separat von der IoT App gewartet werden. Dies ist speziell dann interessant, wenn die Library für mehrere IoT Apps eingesetzt wird, da Verbesserungen dann direkt in allen IoT Apps verfügbar sind.
Das Studio stellt Libraries für häufig benötigte Funktionen zur Verfügung.
Wichtige Projekteinstellungen für einen IoT-App-Release
Ist die Entwicklung einer IoT App abgeschlossen, ist es notwendig sich Gedanken über den Release der IoT App zu machen. Dabei gibt es einige Dinge zu beachten, damit die IoT App entsprechend auf den Geräten installiert werden kann.
Allgemeine IoT-App-Informationen
Vor einer IoT-App-Veröffentlichung ist es wichtig allgemeine Projektinformationen nochmals zu kontrollieren. Die Informationen Name, Icon, Beschreibung der IoT App sind bei der Installation der IoT App sichtbar.
Wichtig ist es zudem den “Crowd Share“ der IoT App zu überprüfen. Der “Crowd Share” beinhaltet die IoT-Plattform auf denen die IoT App verfügbar sein wird, sobald die Veröffentlichung der IoT App abgeschlossen ist.
IoT App Projekt Owner
Der Projekt “Owner” ist der Besitzer des Projektes. Dieser Name wird auch bei der IoT App im App Center angezeigt. Es empfiehlt sich hier einen Studio Account zu erstellen, der für die Verwaltung und den Release von IoT Apps genutzt wird. So werden IoT Apps von einer zentralen Stelle verwaltet und veröffentlicht.
Es empfiehlt sich, diesen Prozess bereits beim ersten IoT-App-Projekt im Studio zu verfolgen, da dies das Management von IoT Apps im späteren Verlauf erleichtert.
Es ist möglich den Projekt “Owner“ im späteren Verlauf zu ändern. Dies kann nützlich sein, wenn ein Entwickler ein Projekt initial erstellt, aber die IoT App von einem zentralen Account aus veröffentlicht werden soll.
Benötigte Hardware-Plattform und Hardware-/Firmware-Versionen
Sind IoT Apps nur für eine bestimmte Hardware-Plattform geeignet oder benötigen eine bestimmte mindest Hardware-/Firmware-Version, ist es wichtig die Installation der IoT App auf diese Anforderungen zu beschränken.
Diese Beschränkungen werden relevant, wenn ein Anwender eine IoT App auf einem Gerät über die IoT-Plattform installieren möchte. Durch die Beschränkung werden bei der Installation nur mehr IoT Apps angezeigt, die die Anforderungen der IoT App erfüllen. Dies verhindert, dass eine IoT App auf inkompatiblen Geräten von der IoT-Plattform aus installiert werden kann.
Während der Entwicklung der IoT App und der Installation der DLO über das TESTbed, wird diese Beschränkung ignoriert, um eine einfachere Entwicklung auf mehreren Hardware Plattformen zu ermöglichen.
Die Versionsbeschränkungen für Hardware und Firmware geben immer eine Mindestversion an. Neuere Versionen sind dadurch automatisch kompatibel.
Informationen für das Feld “Required HW & FW“
Die rapidM2M Hardware-Plattform, die Hardware-Version der rapidM2M-Hardware-Plattform und die Firmware-Version können über die IoT-Plattform mit der Site Liste abgefragt werden.
Über diese Einstellungen können die Firmware-Version und die Identifikation (rapidM2M-Hardware-Plattform und Hardware-Version) herausgefunden werden.
- Firmware-Version
- rapidM2M-Hardware-Plattform
- Hardware-Version
Fazit
Berücksichtigen Sie das empfohlene Vorgehen und die Struktur bei der Erstellung Ihrer IoT App profitieren Sie von den Management- und Deployfunktionen des Studios und der IoT-Plattform. Mit dem empfohlenen Prozess erstellen Sie Schritt für Schritte Ihre Anwendung – von der ersten Idee zum Release der IoT App.
