Lessons Learned - Software-Entwicklung im IoT-Zeitalter

Das Internet der Dinge ist längst real. 27 Milliarden Geräte waren 2017 über das IoT (Internet of Things) 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. Aus diesem Trend hin zu immer mehr vernetzten Produkten, ergeben sich einige Änderungen für die Softwareentwicklung. Vergleicht man IoT-Softwareentwicklung mit klassischen Entwicklungsszenarien, stehen die Entwickler im IoT-Zeitalter vor neuen technischen und methodischen Herausforderungen, die auf den ersten Blick jedoch nur schwer zu erkennen sind. 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 bereits in vielen IoT-Projekten seine Kompetenz unter Beweis stellen und hat dadurch eine Reihe wichtiger Erkenntnisse gewonnen, die dabei helfen, diese Herausforderungen zu meistern.

  • strip-0

    Lesson 1: Am Anfang steht die Sicherheitsplanung

    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 Updatemöglichkeit für Geräte muss von Anfang an eingeplant sein – mit Over-the-air-Updatefunktionalitä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.

  • Lesson 2: Gerätesimulatoren als Hilfsmittel Ihrer Wahl

    Neben das Frontend auf dem Client und das Backend auf dem Server tritt 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. Diese Systemkomplexität zieht 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 Infrastrukturen unterscheidet.

    strip-1
  • strip-2

    Lesson 3: Nicht ohne OTA-Update-Funktionalität

    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 der Entwicklung von Anfang an – und in Hinblick auf den gesamten Application Lifecycle – berücksichtigt werden, da ein Gerät, das Sicherheitslücken aber keinen Update-Mechanismus aufweist, entsorgt werden muss. Ein weiterer Vorteil: 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.

  • Lesson 4: Logging von Device bis Cloud

    Eine Ursachensuche gestaltet sich bei einer großen Anzahl Devices und eventuell dazwischengeschalteten Gateways 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 Deviceseite unter Umständen Einschränkungen bezüglich des Platzes 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 dadurch gelöst werden kann, dass jedes Mal, wenn das Gerät online geht, aktuelle Status-Informationen an die Cloud geschickt werden.

    strip-3
  • strip-4

    Lesson 5: IoT verlangt agile Methoden

    Die vielbesprochene 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; ein Fehler, da sie für den langfristigen Erfolg der Lösungen ausschlaggebend 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 gerade in den frühen Phasen der anzustrebende Business Impact schwer einzuschätzen ist, ist es wichtig auf einen agilen Ansatz zu bauen. 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.

  • Lesson 6: Cloud Native als Vorteil für die Time-To-Market

    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 können so konzipiert werden, dass sie auf verschiedenen Cloud-Umgebungen laufen können. Das macht den Kunden unabhängig vom Cloud-Anbieter.

    strip-5
  • strip-6

    Lesson 7: Eingebettete Komponenten nicht isoliert entwickeln.

    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-Komponente 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?

Mehr dazu

Lesen im vollständigen Whitepaper die ausführliche Gegenüberstellung der klassischen und IoT Software-Entwicklungsszenarien inklusive Best-Practice-Beispielen.

Mit einem kompetenten Entwicklungspartner wie Concept Reply an Ihrer Seite, schaffen Sie es, Ihre IoT-Projekte strukturiert anzugehen und optimal umzusetzen: die Softwarequalität wird gesteigert, Iterationen werden vermieden, (Weiter-)Entwicklungskosten werden gesenkt, die Kundenzufriedenheit wird gesteigert und Wartungskosten werden reduziert. www.concept-reply.de