Bessere IoT-Software durch Rückmeldungen aus dem Feld

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Linutronix GmbH

Percepio AB c/o SynerLeap

Um Software für IoT-Geräte effizient verbessern zu können ist es nötig, dass Entwickler sinnvolles Feedback aus deren Praxisbetrieb erhalten. Nur so können Fehler sofort erkannt und direkt behoben werden.

Wir können uns nie sicher sein, dass Software frei von Fehlern ist. Entwicklerteams erzeugen im Schnitt bei der Entwicklung alle 1000 Codezeilen ungefähr 120 Fehler. Etwa 5% davon, also 6 Bugs pro 1000 Codezeilen, entziehen sich allen Aufdeckungsversuchen. Diese Fehler sind deshalb auch noch im finalen Produkt enthalten, das an den Kunden ausgeliefert wird. Auch wenn die genauen Zahlen variieren können, haben wir es hier mit einem grundlegenden Problem der Softwareentwicklung zu tun, das bereits seit den Anfangstagen der Computertechnik bekannt ist.

Wie aber kann es sein, dass immer noch keine Abhilfe geschaffen wurde, obwohl Entwicklungswerkzeuge, Programmiersprachen und Prozesse über 50 Jahre hinweg stetig verbessert wurden? Hierfür gibt es viele Gründe, aber einer der zentralen Faktoren ist, dass die Komplexität der Applikationen schneller zunimmt als unsere Fähigkeit, diese komplexen Anwendungen auch zu verifizieren. Die Software-Qualitätssicherung wird also ständig schwieriger.

Kein Code ist jemals vollkommen fehlerfrei

Bei den meisten softwarebasierten Produkten ist es praktisch unmöglich, jedes Einsatzszenario und alle Wege, die der Code nehmen kann, zu prüfen – dafür sind es einfach zu viele. Selbst wenn man mehr Zeit und Geld in das Verifizieren investiert wird man niemals garantieren, alle Bugs gefunden zu haben. Nicht zuletzt davon ist das Zeit- und Geldbudget stets begrenzt.

Selbst wenn man seinen Code nach den anerkannten Regeln der Technik prüft, kommt die echte Nagelprobe erst dann, wenn Tausende Anwender ihr Produkt im täglichen Gebrauch nutzen. Oft machen sich dann Probleme auf eine Art und Weise bemerkbar, die die Entwickler niemals erwartet und entsprechend nicht getestet hatten. In diesen Größenordnungen arbeiten die Gesetze der Wahrscheinlichkeit gegen sie. Selbst, wenn nur noch wenige Bugs vorhanden sind, wird es wahrscheinlich doch einige Anwender geben, die auf diese Fehler stoßen.

Im besten Fall benachrichtigen diese Anwender den Entwickler und geben ihm so viele Informationen, dass er den Fehler reproduzieren und beseitigen kann. Wahrscheinlicher ist es aber insbesondere bei Consumer-Produkten so, dass die Anwender das Gerät einfach neu starten und weitermachen. Handelt es sich um einen ernsten Fehler, der wiederholt auftritt, geben die Benutzer möglicherweise negative Bewertungen ab und meiden die Produkte in Zukunft.

Eine unlängst durchgeführte Erhebung des Marktforschungsunternehmens VDC Research ergab, dass die untersuchten Embedded-Entwicklungsprojekte während des ersten Jahres nach Markteinführung im Durchschnitt 79 Patches benötigten. Bei vielen dürfte es sich dabei um Bugfixes gehandelt haben. Insgesamt ist es also an der Tagesordnung, dass Endanwender über längere Zeit mit Bugs konfrontiert werden.

Darüber hinaus verursacht die Behebung der Bugs und das Einspielen der Patches laut dem VDC Report durchschnittlich Kosten von mehr als 5.000 US-$ pro Bug. Wir sprechen hier also für jedes Projekt von Support-Aufwendungen von mehreren tausend Dollar allein im ersten Jahr!

Fehlerüberwachung an Geräten im Praxiseinsatz

IoT-Geräte, also Geräte mit Konnektivität, bieten uns die Gelegenheit, unsere Denkweise über die Embedded-Entwicklung grundlegend zu ändern. Natürlich behält der gewohnte Zyklus aus Codieren, Prüfen und Debuggen seine bisherige Bedeutung. Weil wir aber wissen, dass es einige Fehler bis in das finale, an den Kunden ausgelieferte Produkt schaffen, können wir die Konnektivität doch dafür nutzen, dass die Geräte etwaige Fehler vorher an uns melden.

Sobald ein Fehler in der Geräte-Firmware auftritt, kann über die bestehende Netzwerkverbindung eine Meldung an das Entwicklungs-Team gegeben werden – zusammen mit relevanten Diagnoseinformationen, die den Entwicklern das Lokalisieren des Bugs erleichtern. Unter anderem kann es sich dabei um Software-Traces und Logs handeln, die Auskunft über die zurückliegenden Aktivitäten des Systems geben. Neben dem reinen Fehlercode wird damit also auch der Kontext des Fehlers übermittelt. Diese Informationen lassen sich anschließend in einem Tool für die visuelle Trace-Diagnose (z.B. mit Percepio Tracealyzer) analysieren.

Ist der Fehler behoben, kann die aktualisierte Firmware als Over-the-Air-Update (OTA) publiziert werden. Dies ist wesentlich schneller und zuverlässiger, als die Kunden zu einer manuellen Aktualisierung ihrer Geräte-Firmware aufzufordern.

Dies schafft zwischen dem im Einsatz befindlichen Code und den Entwicklern eine Rückkopplungsschleife, die zügige, iterative Verbesserungen möglich macht. Dieses Verfahren, ist in Mobil- und Cloud-Anwendungen schon lange als fester Bestandteil des DevOps-Gedankens etabliert (siehe Bild 1). Mit der Einführung geschützter cloud-basierter IoT-Plattformen wie etwa AWS IoT Core oder Microsoft Azure IoT ist dies auch für die Embedded-Entwicklung zu einem realistischen Modell geworden.

Diese direkte Rückmeldung und detaillierte Diagnose erlaubt es dem Entwickler, die Behebung von Fehlern und die Auslieferung aktualisierter Firmware zu beschleunigen. Aus kaufmännischer Sicht bewirkt die Verfügbarkeit detaillierterer Informationen, dass weniger Arbeitsstunden pro Bug aufgewendet werden müssen. Unter Umständen können wegen der direkten Rückmeldung kurz nach Produkteinführung mehr Bugfixes erkannt werden als bisher, aber langfristig werden es weniger sein.

Noch wichtiger ist, dass weniger Endanwender von den Bugs betroffen sein werden, was die Kundenzufriedenheit verbessert. Denn unentdeckte Fehler manifestieren sich nicht sofort bei allen Endanwendern, sondern führen meist nur unter bestimmten Umständen zu Problemen – sonst wären sie je bereits vorher entdeckt worden. Hinzu kommt, dass nicht alle Endanwender gleichzeitig beginnen, das Produkt zu nutzen. Dies gibt dem Entwickler Zeit zu reagieren, bevor zu viele Anwender den Bug zu spüren bekommen. Die „Time-to-Repair”, hier die Zeit zwischen dem ersten Auftreten eines Fehlers und dem Einspielen der reparierten Firmware, ist also sehr wichtig.

Es geht nicht nur um Softwarefehler

Das geschilderte Verfahren ermöglicht eine Verkürzung der Time-to-Repair auf Tage oder gar Stunden, während es sonst Wochen, Monate oder sogar Jahre waren. Je schneller man reagiert, umso weniger Endanwender werden von dem Problem betroffen sein. Wenn man sehr schnell ist, bemerkt nur eine Handvoll früher Nutzer (oder Field Tester) das Problem, bis man dann die aktualisierte Firmware herausgibt.

Das beschriebene Konzept eignet sich zum Melden aller bedeutsamen Vorkommnisse, die sich per Software detektieren lassen. Dies können sowohl Fehler infolge von Bugs (fehlgeschlagene Assertions, Abstürze usw.) als auch Bedienungsprobleme (abgestürzte Setup-Assistenten usw.) oder Hardwareprobleme sein (etwa wenn ein Sensor einen außerhalb des erwarteten Bereichs liegenden Messwert meldet). Die Meldungen können zudem zeitbasiert (zum Beispiel einmal täglich) erfolgen, was unter anderem sinnvoll ist, um Statistiken zur Nutzung eines Geräts und Performance-Daten (Batterielebensdauer, Speichernutzung usw.) zu erfassen.

Im Fall von Hardwareproblemen kann die direkte Rückmeldung den Produktionsingenieuren die Chance bieten, das Problem bereits in einer sehr frühen Phase zu beheben, damit weniger fehlerhafte Produkte zur Auslieferung gelangen. Die übertragenen Diagnoseinformationen können überdies Aufschluss darüber geben, ob das Problem tatsächlich in dem Code liegt oder in einem externen Bauteil. Im letzteren Fall hat man mit den detaillierten Informationen über den Fehler wesentlich bessere Argumente für die Diskussionen mit dem Bauteilzulieferer.

Rückmeldung von Fehlern: Was wird benötigt?

Das hier vorgestellte Fehlermeldungs-Konzept setzt voraus, dass ein geschützter Kommunikationskanal zurück zu den Entwicklern existiert. Diesen Kanal richtig abzusichern, ist eine komplizierte Sache, aber zum Glück ist die neue Generation von IoT-Cloud-Plattformen wie etwa AWS IoT Core und Microsoft Azure IoT von Grund auf sicher, wobei bewährte Lösungen wie etwa TLS und X.509-Zertifikate zum Einsatz kommen. Gestützt auf die eingebauten Fähigkeiten der Plattformen für die gesicherte Kommunikation und OTA-Updates, lässt sich das geschilderte Konzept umsetzen, ohne dass Sicherheitslücken entstehen.

Fehler lassen sich mit Software-Assertions und Fehlerbehandlungen wie etwa Hardware-Exception-Handlern und Callback-Funktionen aufspüren. Im Normalfall ist diese Art der Fehlerbehandlung im Code bereits vorhanden, um das Debugging zu vereinfachen. Unter der Annahme, dass im Gerät schon eine Fehlermeldungs-Bibliothek existiert, lässt sich der bestehende Fehlerbehandlungs-Code einfach so erweitern, dass auch Fehler in bereits im Einsatz befindlichen Geräten gemeldet werden.

Bei der Meldung von Fehlern lassen sich die Diagnoseinformationen auf mindestens zwei Arten bereitstellen:

• Direkte Symptome des Fehlers, also Fehlercodes und Fehlermeldungen, möglicherweise ergänzt durch weitere Angaben über den Fehlerzustand, wie etwa vom Applikationsentwickler ausgewählte globale Zustandsvariablen und Performance-Zähler.

• Software-Tracing und Applikations-Logging stellen eine Zeitleiste mit den Software-Ereignissen zur Verfügung, die dem Fehler vorausgingen. Dies hilft, den Kontext des Fehlers zu verstehen und zu erkennen, wie sich der Fehler reproduzieren lässt, wenn ein detaillierteres Debugging erforderlich sein sollte. Hierfür ist die fortlaufende Aufzeichnung der relevanten Software-Ereignisse nötig.

Die Lösung sollte als permanenter Bestandteil des Systems betrachtet werden und mindestens für die Dauer der Systemtestphase aktiviert sein. Natürlich führt dies zu einem gewissen Mehraufwand von meist ein paar Prozent CPU-Zeit und wenigen KB im RAM und ROM, aber dafür ist die Fehlerbenachrichtigung stets präsent.

Für die Entgegennahme und Organisation der Fehlerbenachrichtigungen wird ein Dienst benötigt, der entweder auf einem lokalen Server angesiedelt sein oder von einem Cloud-Service-Provider gehostet werden kann. Dieser Dienst muss die Entwickler benachrichtigen, wenn neue Probleme gefunden wurden, und entsprechende Diagnoseinformationen bereitstellen. Außerdem muss dieser Dienst unbedingt so intelligent sein, dass er Duplikate bereits gemeldeter Probleme erkennt. So vermeidet man, von zahllosen Meldungen ein und desselben Problems überschwemmt zu werden. Schließlich muss der Dienst auch zuverlässig und geschützt sein und sich auf große Bestände ausgelieferter Geräte skalieren lassen. Hervorzuheben ist, dass das Sammeln von Diagnoseinformationen in der Regel nicht der DSGVO unterliegt, solange die Daten nicht (z.B. über Benutzernamen bzw. Email- oder IP-Adresse) einer bestimmten Person zugeordnet werden können. Solange die Meldungen also anonym erfolgen, gibt es keine Probleme.

Das hier beschriebene Konzept zur Meldung von Fehlern in Geräten im Praxiseinsatz ist inzwischen unter dem Namen Percepio DevAlert (vormals Device Firmware Monitor) als kommerzieller Dienst verfügbar. DevAlert ist ein voll gemanagter Cloud-Dienst zum Erfassen und Koordinieren von Fehlermeldungen („Alerts”) aus dem DevAlert Target Agent, einer in die Gerätefirmware eingebundenen Softwarebibliothek.

Zu DevAlert gehört auch Percepio Tracealyzer, eine Desktop-Applikation für die visuelle Trace-Diagnose. Tracealyzer ist ein fortschrittliches Werkzeug, das schon seit mehr als einem Jahrzehnt in der aktiven Entwicklung eingesetzt wird und Software-Ereignisse auf einer visuellen Zeitleiste darstellt. Man kann sich Tracealyzer wie eine Zeitlupenkamera vorstellen, die Einblick in die internen Abläufe einer Applikation bietet und es dabei durch Erhöhen des Vergrößerungsfaktors möglich macht, die „Verdächtigen” (die laufenden Threads) zu identifizieren und ihre Aktionen zu untersuchen.

Wird Tracealyzer für DevAlert-Fehlerreports verwendet, zeigt es die Ereignisse, die einem Fehler vorangegangen sind, und liefert damit den Kontext (vgl. Bild 2). Es ist so wesentlich leichter, den Fehler zu reproduzieren und den Bug zu beheben. Der in der Cloud angesiedelte Teil von DevAlert speichert sämtliche eintreffenden Fehlerreports (Alerts) mitsamt den zugehörigen Metadaten und Symptomen. Diese Informationen lassen sich zu einem späteren Zeitpunkt durchsuchen, um die Alerts nach Typ, Firmwareversion usw. zu ordnen. Außerdem geht es hier um die Einordnung der Alerts und ihre Zuordnung zu „Problemen“ mit denselben Symptomen. Werden für einen Fehler viele Alerts erzeugt, führt nur der erste Alert zu einer Benachrichtigung an die Entwickler. Ohne dieses Feature ließe sich DevAlert nicht für eine große Zahl von Geräten nutzen, da man sonst Gefahr liefe, in einer übergroßen Anzahl Fehlermeldungen zu ertrinken.

Ein Eckpfeiler der DevOps-Philosophie

Das Internet of Things, die Kombination aus Embedded-Geräten und dem Internet, bietet enorme Chancen für die gesamte Embedded-Branche. IoT-Plattformen wie Microsoft Azure IoT und AWS IoT Core helfen dabei, das Deployment, die Skalierung, die Sicherheit und eine Vielzahl weiterer Probleme zu koordinieren.

Die DevOps-Philosophie, die sich bei der Entwicklung von Cloud- und Mobil-Apps als sehr erfolgreich erwiesen hat, kann sich auch hier beweisen, dank der Fähigkeit zur Überwachung von im Einsatz befindlichen Geräten. Was hierfür bislang fehlte, waren einfache Lösungen zur Überwachung von im Einsatz befindlichen IoT-Geräten mit Unterstützung für die Trace-Diagnose.

Percepio DevAlert wurde genau mit dem Zweck entwickelt, diese Lücke zu füllen, den Regelkreis zu schließen und den Entwicklern von IoT-Geräten die Möglichkeit zu geben, sich das erfolgreiche DevOps-Konzept zunutze zu machen. Es gibt Percepio DevAlert inzwischen für IoT-Anwendungen unter AWS IoT Core und FreeRTOS.

Dieser Beitrag ist erschienen in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 7/2020 (Download PDF)

* Johan Kraft ist Gründer und CEO von Percepio AB in Västerås, Schweden.

(ID:46369484)