Unterschiede zu klassischem Development

7 Lektionen für IoT-Softwareentwicklung

| Autor / Redakteur: Vincent Ohana * / Stephan Augsten

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)

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.

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.

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
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.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

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