Ein Angebot von

7 Lektionen für IoT-Softwareentwicklung

| Autor / Redakteur: Vincent Ohana * / Stephan Augsten

Customer Experience kommt in Form der Bedienfreundlichkeit auch in IoT-Geräten zum Tragen.
Customer Experience kommt in Form der Bedienfreundlichkeit auch in IoT-Geräten zum Tragen. (Bild gemeinfrei: TheDigitalArtist / Pixabay)

Lektion 5: Agile Methoden bieten die notwendige Flexibilität für IoT-Innovationen

Klassisch: Die klassische Software-Entwicklung nach dem V- oder Wasserfall-Modell ist unflexibel und träge. Hier werden Anforderungen und Features bereits vor der Entwicklung festgelegt. Wenn die finale Spezifikationsreife erlangt ist, geht es in die Umsetzung genau dieser spezifizierten Anforderungen. Änderungen oder Erweiterungen sind in diesem Modell in der Implementierungsphase nicht vorgesehen.

Dies bedeutet wiederum, dass Innovationen nicht kurzfristig in die Entwicklung mit aufgenommen werden können. Es gibt wenig Raum für kurzfristige Anpassungen. Bei länger andauernden Entwicklungsprojekten ist die Software nach ihrer Fertigstellung in manchen Fällen bereits veraltet, da sich Prozesse oder Anforderungen in der Zwischenzeit geändert haben.

IoT: Die vielbesprochen Customer Experience ist nicht nur im Frontend – sprich in Apps und Webseiten – ein entscheidendes Kriterium für den Erfolg, sie kommt in Form von Bedienfreundlichkeit auch in Geräten zum Tragen. Die Bedienfreundlichkeit spielt für viele Kunden initial noch keine Rolle, was ein Fehler ist, da sie für den langfristigen Erfolg der Lösungen wichtig ist.

Bereits bei der Entwicklung sollte beachtet werden, wie beispielsweise der Einrichtungsprozess eines IoT Gateways aussehen soll. Da gerade IoT-Projekte häufig Innovationsprojekte sind, ist es ein vorrangiges Ziel der Kunden damit einen Business Impact zu erzielen – etwa mit der Senkung der Wartungskosten oder dem Vertrieb von Softwarefunktionen im Allgemeinen.

Da sich der anzustrebende Business Impact gerade in den frühen Phasen schwer einschätzen lässt, ist es wichtig auf einen agilen Ansatz zu setzen. Der Business Case kann dadurch parallel entwickelt werden. Die Herausforderung ist es dann nur noch, den Fokus zu behalten und sich nicht in unnötigen Features zu verlieren.

Lektion 6: Cloud Native verbessert Time-To-Market, Kubernetes bietet Flexibilität

Klassisch: In einer klassischen Architektur gibt es keinen IoT Hub, der in der Regel aus einem Message Broker, Message Buffer (falls Geräte nicht online sind), Device Shadow (für die Speicherung des Gerätezustands), Device Provisioning (für die Anbindung neuer IoT-Geräte an das Backend) und dem Device Management (für die Verwaltung bestehender Geräte, z.B. Firmware Update) besteht.

IoT: Cloud Native IoT Hubs haben die notwendigen Funktionalitäten standardmäßig und Out-of-the-Box integriert und können daher mit wenig Aufwand eingerichtet werden. Auch ein Hochskalieren auf große Gerätezahlen ist relativ einfach umzusetzen. Auch SDKs, die für viele Gerätesoftwareversionen angeboten werden, helfen dabei, die Softwareentwicklung zu beschleunigen.

Die Alternative zu Cloud Native IoT Hubs sind eigenentwickelte IoT Hubs (auf Basis von Kubernetes, Open-Source-Produkten und Individualsoftware). Eigenentwickelte IoT Hubs lassen sich so konzipieren, dass sie auf verschiedenen Cloud-Umgebungen (z.B. AWS oder Azure) laufen können. Das macht den Kunden unabhängig von Cloud-Anbieter.

Damit stehen Kunden vor vielen Fragen: Lösen wir alles On-Premises, Off-Premises oder gar Cloud Native? Sollten Open-Source-Tools zum Einsatz kommen oder lieber proprietäre Softwarelösungen?

Das gilt es abzuwägen:

On-Premises bietet geringe Latenz bei gleichzeitig extrem hohen Datenraten (Vorsicht jedoch: diese führen natürlich zu höheren Verbindungskosten). Eine On-Premises-Lösung kann als einzelnes IoT Gateway oder als Cluster in einem Datencenter umgesetzt werden und für die einzelnen IoT Gateways gibt es bestehende Frameworks (z.B. AWS Greengrass, Azure IoT Edge SDK, Eclipse Kura, Node RED und viele mehr).

Ein Standard hat sich jedoch noch nicht durchgesetzt und hier mischen vor allem auch Hardwareanbieter aus dem industriellen Umfeld mit. Ihre Lösungen berücksichtigen auch gleich die für ihr Umfeld relevanten Anforderungen, wie etwa Robustheit (z.B. Schock- oder Temperaturbeständigkeit). Dazu muss im Feld Sicherheit garantiert sein (TPM Stores sind ein guter Ansatz zur Speicherung von Zertifikaten im Feld)

Off-Premises stehen gleichzeitig Cloud-Native-Dienste wie AWS Lambda, AWS DynamoDB oder Azure IoT Hub zur Verfügung.

Cloud-Native-Lösungen vereinfachen die Arbeit der Entwickler und der Betreiber und verkürzt den Time-to-Market, Cloud Native vergrößert aber auch die Abhängigkeit zu einem Cloud Provider, hybride Strategien sind ein interessanter Mittelweg (Teile in Cloud Native, andere Teile in Docker, etc.).

Cloud-Native-Dienste lassen sich prinzipiell auch durch Open-Source-Produkte ersetzen (z.B. Kafka statt AWS Kinesis). Cloud Native bietet darüber hinaus ein umfassendes Sicherheitskonzept. So können beispielsweise AWS-Lambda-Funktionen nur auf freigegebene SQL-Tabellen zugreifen – ein solches Sicherheitskonzept mit Open Source abzubilden, gestaltet sich meist eher aufwändig.

Ein Beispiel: Bei einem seiner Kunden aus dem Bereich industrielle Automatisierung, setzte Concept Reply ein Kubernetes-Cluster für die Ausführung und Bereitstellung der Backendfunktionen ein. Das Cluster benötigt eine reservierte Rechen- und Speicherleistung – unabhängig davon, ob die Backendfunktionen benutzt werden oder nicht.

Diese reservierte Leistung verursacht automatisch Betriebskosten, welche bei Cloud-Native-Lösungen nicht anfallen. Cloud Native ist daher in frühen Phasen interessant, wenn die Produkte noch wenig genutzt werden und bietet sich darüber hinaus an, wenn die Nutzung zeitlich stark schwankt, also keine gleichmäßige Auslastung über den Tag hinweg zu erwarten ist.

Lektion 7: Eingebettete Komponenten sollten nicht isoliert entwickelt werden

Klassisch: In der klassischen Entwicklung von Embedded-Komponenten wird die Hardware für eine vorab bekannte Funktion entwickelt. Daher ist es sinnvoll nach dem Prinzip: „So sehr spezifiziert wie möglich, so wenig wie nötig“ vorzugehen. Soll eine Plattform durch zukünftige Features erweitert oder aktualisiert werden, stößt dieses Vorgehen an seine Grenzen, da neue Features gegebenenfalls höhere Anforderungen an die Hardware haben.

IoT: Im Konflikt stehen hier Themen wie: Energieeffizienz, Verfügbarkeit und Leistung. Ein Beispiel: Die Anforderung, eine hohe Reichweite abdecken zu können, erfordert gegebenenfalls eine starke Sendeleistung des Devices, kann aber aufgrund des hohen Strombedarfs nur zeitweise aufrechterhalten werden.

Die Dimensionierung einer Hardware-Komponenten erfolgt jedoch nach spezifischen Anforderungen, die wenig Platz für die benötigte Flexibilität lassen um allen oben genannten Kriterien (Energieeffizienz, Verfügbarkeit und Leistung) gerecht zu werden. Daher ist Planung im Vorfeld wichtig. Die wichtigsten Fragen hierbei: Können Anforderungen auch zukünftig mit der geplanten Hardware umgesetzt werden und wie viel Flexibilität ist dafür notwendig?

Der Nutzen

Werden IoT-Projekte richtig und mit einem kompetenten Entwicklungspartner an der Seite angegangen, wird die Softwarequalität gesteigert, Iterationen vermieden, (Weiter-) Entwicklungskosten gesenkt, Kundenzufriedenheit gesteigert und Wartungskosten reduziert.

4 Tipps für den Start in das Internet of Things

4 Tipps für den Start in das Internet of Things

05.10.18 - Das Internet of Things (IoT) eröffnet Unternehmen die Möglichkeit, neue datenbasierte Geschäftsmodelle zu entwickeln. Allerdings tun sich viele Unternehmen bei der Umsetzung von IoT-Projekten noch schwer. Mehr Mut ist gefragt. Die folgenden vier Tipps helfen beim Start. lesen

Connectivity im IIoT – Welcher Konnektivitätsstandard passt zu welcher Anwendung?

Connectivity im IIoT – Welcher Konnektivitätsstandard passt zu welcher Anwendung?

09.08.18 - Für IIoT-Anwendungen existieren diverse Konnektivitäts-Standards zur Kommunikation via Internet, die eigene Vor- und Nachteile bieten. Mittels 5 Fragen lässt sich die jeweils passendste Technologie leicht finden. lesen

Drei Geschäftsmodelle für Embedded Software im Internet of Things

Drei Geschäftsmodelle für Embedded Software im Internet of Things

26.03.18 - Im Rahmen ihrer IoT-Strategie stellen viele Hersteller ihr Geschäftsmodell um: vom einmaligen Hardwareverkauf auf wiederkehrende Umsätze durch digitale Angebote. Software-Updates, neue Features sowie Premium-Funktionen und Abo- und Pay-per-Use-Modelle spielen damit eine größere Rolle. Voraussetzung für diese Transformation ist die richtige Strategie, die mit Embedded Software Gewinn erzielt. lesen

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

* Vincent Ohana ist Partner der Concept Reply GmbH. Reply ist auf die Entwicklung und Einführung von Lösungen auf Basis neuer Kommunikationskanäle und digitaler Medien spezialisiert. Das Unternehmen unterstützt bei Geschäftsmodellen, die auf den neuen Paradigmen wie Big Data, Cloud-Computing, Digitalen Medien und dem Internet der Dinge basieren. Zu den von Reply angebotenen Services gehören: Beratung, Systemintegration und Digital Services.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46028003 / IoT)