Unterschiede zu klassischem Development 7 Lektionen für IoT-Softwareentwicklung

Autor / Redakteur: Vincent Ohana * / Stephan Augsten

Das Internet der Dinge, kurz IoT, wächst und gedeiht. Aus diesem Trend hin zu immer mehr vernetzten Produkten ergeben sich einige Änderungen für die Softwareentwicklung. Dieser Beitrag beleuchtet die wichtigsten Unterschiede und sieben Lehren, die sich daraus ziehen lassen.

Firmen zum Thema

Im IoT-Zeitalter stehen Entwickler vor völlig neuen technischen und methodischen Herausforderungen.
Im IoT-Zeitalter stehen Entwickler vor völlig neuen technischen und methodischen Herausforderungen.
(Bild gemeinfrei: Zan Ilic / Unsplash)

27 Milliarden Geräte waren 2017 über das IoT verbunden. Diese Zahl soll bis 2030 auf 125 Milliarden anwachsen. Bereits für 2022 wird erwartet, dass das Geschäft mit IoT-Produkten einen 561 Milliarden US-Dollar-Markt bilden wird.

Vergleicht man IoT-Softwareentwicklung mit klassischen Entwicklungsszenarien, stehen die Entwickler im IoT-Zeitalter allerdings vor neuen technischen und methodischen Herausforderungen. Vor allem die Sicherstellung der Softwarequalität kann schnell zu einer Hürde werden. Falsche Architekturentscheidungen führen zu schwer wartbarer Software und Sicherheitsrisiken. Die Folgen: hohe Kosten und gesunkene Wettbewerbsfähigkeit.

Aber trotz aller Hürden und Herausforderungen sind IoT-Projekte die Lösung für zukunftsfähige Softwareentwicklung und in naher Zukunft wird kein Weg an ihnen vorbeiführen. Concept Reply konnte im Zuge diverser IoT-Projekte eine Reihe wichtiger Erkenntnisse gewinnen, die dabei helfen, diese Herausforderungen zu meistern.

Lektion 1: Sicherheit muss von Anfang an in die Architektur eingeplant werden

Klassische Softwareentwicklung: In der traditionellen Software-Entwicklung hat man häufig noch die Möglichkeit, eine Applikation nachträglich sicher zu machen, indem ein neues Release zur Verfügung gestellt wird. In einer IoT-Umgebung kann es hingegen dazu kommen, dass Devices nicht mehr nachträglich mit einer verbesserten Softwareversion aktualisiert werden können. In dem Fall hat der Nutzer nur die Wahl, mit der Sicherheitslücke zu leben oder das Gerät durch ein neues zu ersetzen.

Development für das IoT: Eine IoT-Umgebung ist extrem komplex, da hier viele Komponenten miteinander kommunizieren und Daten austauschen. Sicherheitslücken sind kurzfristig oft nur Gateway-seitig oder durch ein direktes Beheben der Schwachstelle lösbar. Gleichzeitig bestehen Spezialanforderungen auf Device-Seite (wie etwa spezielle Microcontroller oder ein limitierter Speicher), was dazu führt, dass Fixes nicht schnell verfügbar sind.

Eine Patch-Möglichkeit für Devices muss von Anfang an eingeplant sein – mit Over-the-air-Update-Funktionalität. Aber auch eine Software-Architektur, die bereits so gestaltet ist, dass entsprechende Hürden und Einschränkungen für Zugriffe auf Gateways oder den App-Server existieren, hilft, sollte es zu einem Breach kommen.

Lektion 2: Gerätesimulatoren helfen in frühen Phasen und bei der Testautomatisierung

Klassisch: Egal ob Web-, Smartphone- oder Desktop-Apps, sie alle haben eine Client-Server-Architektur. Auf dem Client läuft das Frontend, auf dem Server das Backend. Während der Client einen lokalen Zustand abbildet und einen Ausschnitt des globalen Zustands wiedergibt, ist der Server in einem globalen Zustand, der durch die Clients verändert werden kann. Somit lassen sich Testvorgänge auf diese geringe Menge an Zuständen und Interaktionen beschränken.

IoT: Zu Frontend auf dem Client und Backend auf dem Server gesellen sich hier die Edge Software auf dem IoT-Gateway, das für die Internetanbindung und leichte Datenverarbeitung verantwortlich ist, sowie die „Thing Software“ auf dem eigentlichen Gerät, etwa einem Sensor. Dadurch steigt die Systemkomplexität.

Die Systemkomplexität ergibt sich unter anderem aus der Menge der Zustände (die abhängig von der physikalischen Umgebung sind) und möglichen Interaktionen, zieht also einen erhöhten Testaufwand nach sich. Da in den frühen Projektphasen die eigentlichen Geräte meist noch nicht verfügbar sind, sind Gerätesimulatoren unverzichtbare Hilfsmittel. Sie helfen unter anderem beim automatisierten Testen in der Cloud, vereinfachen zudem aber auch das Load Testing.

Natürlich können auch schon vorhandene Geräte in die Testautomatisierung eingebunden werden, jedoch erschwert das das Testen in der Cloud – die Geräte befinden sich schließlich in den meisten Fällen hinter einer Firewall im Firmennetz. Daher muss eine komplexe Testinfrastruktur geschaffen werden, die sich von klassischen Testinfrastrukturen unterscheidet.

Ein Beispiel: In einem Kundenprojekt ging es für Concept Reply darum, mittels Ende-zu-Ende-Tests die Korrektheit der Umsetzung von IoT-Softwarefunktionen zu testen, die teils in der Cloud (z.B. langfristige Datenspeicherung und Generierung von Alarmen), teils auf Feldgeräten (z.B. Erfassung von Sensordaten) und teils auf Endgeräten wie Smartphones und Laptops (z.B. Benutzermanagement und Änderung von Einstellungen) laufen.

Die Testabdeckung misst für einen einzelnen oder mehrere Testfälle, welche IoT-Softwarefunktionen Im Rahmen des Tests ausgeführt werden. Die Messung ist schwierig, weil die Funktionen auf unterschiedliche Plattformen verteilt sind. In klassischen Softwareprojekten ist das einfacher, weil es sich um homogene Plattformen handelt.

Lektion 3: Over-the-Air-Update-Funktionalität ist ein Wettbewerbsvorteil

Klassisch: In der klassischen IT installieren Nutzer neue Software in den meisten Fällen selbst – oder sie erhalten eine Information, dass eine neue Version zur Verfügung steht. Der Nutzer entscheidet damit selbst, ob er ein Update durchführen möchte oder nicht. Der Nachteil: wichtige und unter Umständen sicherheitskritische Aktualisierungen können schnell übersehen werden.

IoT: Mit einer steigenden Anzahl an Devices und Geräten eines IoT-Szenarios ist es kaum noch möglich, hier einen Überblick zu behalten und solche Updates manuell durchzuführen. Die sich im Einsatz befindlichen Devices können oft nur noch per Over-the-Air-Update (OTA-Update) auf aktuellem Stand gehalten werden.

Das muss bei Entwicklung von Anfang an – und in Hinblick auf den gesamten Application Lifecycle – mitberücksichtigt werden. Ein Gerät, das Sicherheitslücken aber keinen Update-Mechanismus aufweist, muss entsorgt werden.

Ein weiterer Vorteil: Ein Update-Mechanismus ermöglicht neue Geschäftsmodelle. Während ein Kunde zu Beginn eines Projektes häufig noch gar nicht weiß, welche Funktionen seine Entwicklung in Zukunft alles umsetzen soll, ermöglicht ein integrierter Update-Mechanismus auch den späteren Vertrieb von Softwarefunktionen, die heute noch nicht existieren.

Lektion 4: Fehlerdiagnose erfordert umfassendes Logging von Device bis Cloud!

Klassisch: In einem klassischen IT-Setup existiert im Allgemeinen ein App-Server und gegebenenfalls einige Clients. Logs sind auf beiden Seiten leicht verfügbar, so dass eine Fehlerdiagnose einfach durchzuführen ist.

IoT: In der Welt des IoT sieht das ein bisschen anders aus: Es gibt eine große Anzahl Devices und eventuell dazwischengeschaltete Gateways. Eine Ursachensuche gestaltet sich hier im Fehlerfall um einiges komplexer als in einer klassischen Softwareumgebung. Logs müssen daher gezielt zentral verfügbar gemacht werden, unter anderem auch, da auf Geräteseite unter Umständen Einschränkungen bezüglich des Speicherplatzes bestehen.

Eine zentrale Log-Datenbank (beziehungsweise Syslog-ng) ist eine mögliche Lösung für das Problem der großen Geräteanzahl. Der Batterie-Betrieb ist ein weiteres Problem, das sich dadurch lösen lässt, dass jedes Mal, wenn das Gerät online geht, aktuelle Status-Informationen an die Cloud geschickt werden.

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.

* 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.

(ID:46031280)