Firmware-Feedback in der Praxis dank Software-Tracing und Cloud-Anbindung

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Percepio AB c/o SynerLeap

Treten bei einem bereits ausgelieferten Gerät Software-Fehler auf, müssen diese umgehend ausgemerzt werden, ehe Gefährdungen entstehen. Automatische Alerts und Software-Tracing helfen hier weiter.

Software-Tracing ist ein wichtiges Werkzeug in der Toolbox eines jeden Embedded-Systems-Entwicklers, insbesondere in Kombination mit einer hochentwickelten Visualisierung. Embedded Systems weisen meist viele zyklische Muster auf, bei denen sich dieselbe Sequenz ständig wiederholt. Beim Debuggen geht es oft darum, die Anomalien oder Abweichungen vom normalen zyklischen Verhalten aufzuspüren – also die Stellen, wo etwas Ungewöhnliches passiert ist. Das Software-Tracing an sich ist aber lediglich eine Form der Datenerfassung.

Dabei gleicht die Suche nach einem Problem in einer Ansammlung textlicher oder numerischer Protokolldaten buchstäblich der Suche nach der Nadel im Heuhaufen. Aber mit der passenden Visualisierung verwandelt sich die Suche in einen Erkennungsprozess visueller Muster, etwas, wozu das menschliche Gehirn besonders gut geeignet ist. Interaktive Diagramme zur Veranschaulichung von Ausführungsdauer, Antwortzeiten, Aufgabenwechseln oder der Kommunikation zwischen Tasks – all dies ermöglicht es dem Entwickler, schnell Anomalien bei der Ausführung seiner Firmware zu erkennen, um dort anschließend tiefer nach der Fehlerursache zu graben.

Bildergalerie

Tools für die visuelle Spurensuche gibt es seit mindestens einem Jahrzehnt und sie haben sich für die Entwicklung und Fehlersuche im Labor als nützlich erwiesen. Da heute immer mehr Embedded-Entwickler ihre Software um eine Cloud-Komponente für die sichere Anbindung an das Internet der Dinge (IoT) erweitern, liegt die Überlegung nahe, den Einsatz von Software-Tracing-Tools auch auf die Geräte im Feld auszuweiten, um so Probleme in der realen Anwendung zu erfassen, die während der Tests übersehen wurden. Schließlich erfordert Software-Tracing keine zusätzliche Hardware und ein vernetztes IoT-Gerät kann Diagnosedaten ebenso selbstverständlich hochladen wie reguläre Anwendungsdaten. Auf diese Weise können Entwickler schnell auf verbleibende Software-Fehler aufmerksam gemacht werden, die im realen Betrieb Probleme verursachen. Gleichzeitig erhalten sie zudem auch eine detaillierte Diagnose, die ihnen hilft, die Ursache zu verstehen.

In dem beschriebenen Szenario lässt sich das Software-Tracing mit einem virtuellen Flugschreiber vergleichen, wie er beispielsweise in Flugzeugen zur Aufklärung von Unfällen zum Einsatz kommt. Es ist ein integrierter Teil des Produkts, der permanent aufzeichnet und im Falle eines Problems wichtige Informationen liefert. Aber im Gegensatz zur Black Box im Flugzeug handelt es sich hier um eine Softwarelösung, die für die Erkennung von Softwareproblemen konzipiert ist.

Percepio DevAlert ist eine solche Lösung für die Erkennung von Softwarefehlern in IoT-Geräten. DevAlert besteht dabei aus drei Teilen: dem DevAlert Firmware Monitor (DFM) – eine kleine Bibliothek, die der Firmware hinzugefügt wird, um die Softwarebeobachtung und die Aktivierung von Alerts zu ermöglichen; dem Tracealyzer – ein Tool für die visuelle Trace-Diagnose sowie dem DevAlert Cloud-Service. Letzterer ist für die Kategorisierung und Speicherung von Alerts, die Benachrichtigung von Entwicklern, das Herausfiltern von doppelten Meldungen und vieles mehr zuständig.

Die erste Version von DevAlert läuft auf AWS von Amazon und ist für RTOS-Anwendungen mit AWS IoT Core vorgesehen. Die Lösung kann aber in Zukunft auch für andere Cloud-Plattformen angepasst werden.

Software-Tracing und Cloud-Konnektivität

Software-Tracing im Entwicklungslabor und das Aufspüren von Software-Fehlern in der Feldpraxis sind jedoch zwei verschiedene Dinge. Wer heute visuelle Trace-Diagnostik im Labor einsetzt und dies auf das Feld ausweiten will, muss einige Aspekte berücksichtigen.

Im Vergleich zu einer direkten physischen USB- oder Ethernet-Verbindung hat eine Cloud-Verbindung neben einer begrenzten Bandbreite auch viel längere Reaktionszeiten. Das Hochladen von 5 KByte an Daten kann über eine drahtlose Schnittstelle beispielsweise Dutzende oder sogar Hunderte von Millisekunden dauern. Bei dem hier beschriebenen Ansatz werden Trace-Daten jedoch nicht kontinuierlich gesendet, sondern nur, sobald ein Alert ausgelöst wird und dann handelt es sich auch jeweils nur um eine kleine Datenmenge zur Erfassung der jüngsten Ereignisse. Alerts beschränken sich auf außerordentliche und wichtige Ereignisse, beispielsweise wenn ein Fehler im Anwendungscode entdeckt wurde, wie z.B. eine fehlgeschlagene Zustandsprüfung, ein harter Fehler oder ein Watchdog-Reset.

Bei der Verwendung von DevAlert haben Firmware-Entwickler die volle Kontrolle darüber, welche Software-Ereignisse im Gerät verfolgt und unter welchen Umständen Alerts erzeugt werden sollen.

Jedes mit dem Internet vernetzte Gerät muss sicher sein. Es ist daher wichtig, dass eine Lösung wie DevAlert keine neuen Sicherheitsschwachstellen oder Angriffsvektoren einführt. DevAlert nutzt daher bereits bestehende, sichere Cloud-Verbindungen von AWS und anderen führenden IoT-/Cloud-Anbietern von verifizierten SDKs für die Cloud-Konnektivität, die bewährte Sicherheitsverfahren garantieren, z.B. Geräteauthentifizierung mit X.509-Zertifikaten und verschlüsselte Kommunikation mit TLS. Auf diese Weise ist die Übermittlung von DevAlert-Traces genauso sicher wie die regulärer IoT-Anwendungsdaten. Sicherheitserhöhend kommt hinzu, dass die Kommunikation bei DevAlert immer nur in eine Richtung geht; nie werden eingehende Nachrichten abgehört.

Bei diesem Ansatz werden die Alerts also auf dasselbe Cloud-Konto hochgeladen, das vom Gerät bereits standardmäßig verwendet wird, und zwar mit demselben Sicherheitsniveau. Einmal in der Cloud angelangt, wird ein kleiner Teil der Daten dem DevAlert Cloud-Service zur Verfügung gestellt. Die eigentlichen Tracing-Daten, die als sensible Informationen betrachtet werden können, gehören nicht dazu und verbleiben im Cloud-Konto des Geräts.

Die Betriebskosten für die Übermittlung von Alert-Meldungen an ein Cloud-Konto sind in der Regel gering, obwohl sie natürlich letztendlich vom Datenvolumen abhängen. Aber solange kein Problem konstatiert wird, werden auch keine Alerts gesendet. Im Allgemeinen berechnen Cloud-Anbieter auch sehr wenig für das Senden und Speichern gelegentlicher Meldungen. Die meisten IoT-Anwendungen erzeugen sehr viel mehr Daten, was sich in der Preisgestaltung der IoT-/Cloud-Dienste widerspiegelt. Beispielsweise kostet das Senden von 1 Million MQTT-Nachrichten an AWS IoT Core 1 US-$.

Der Großteil der Nachrichtenverarbeitung erfolgt im von Percepio gehosteten und vollständig verwalteten DevAlert Cloud-Service. Nur die anfängliche Verarbeitung erfolgt im Cloud-Account des Geräteentwicklers, wodurch die Cloud-Kosten für DevAlert niedrig bleiben und die Integration vereinfacht wird.

Das Versenden von Over-the-Air-Updates zur Behebung gemeldeter Fehler kann jedoch erheblich kostspieliger sein, da hier viel größere Datenmengen an alle betroffenen Geräte gesendet werden müssen. In einem Preisbeispiel von AWS belaufen sich die Kosten für die Aktualisierung einer Flotte von 600.000 Geräten auf 1.275 US-$. Dies ist aber nicht sehr teuer im Verhältnis zu den Kosten, die entstehen, wenn ein Fehler nicht behoben wird:Unzufriedene Kunden, schlechte Produktbewertungen, weniger Verkäufe oder sogar Unfälle und rechtliche Konsequenzen.

Es hat erhebliche Vorteile, wenn IoT-Geräte bei Software-Problemen „nach Hause telefonieren“ können. Aufgrund der unmittelbaren Fehlerbenachrichtigungen und detaillierten Diagnosen entsteht eine Feedbackschleife zwischen Entwicklern und dem Firmware-Code im Feld, wodurch die Entwickler Fehler schneller beheben und schneller Firmware-Updates implementieren können. Bei der Entwicklung von Mobil- und Cloud-Anwendungen ist diese sogenannte DevOps-Philosophie seit langem Standard. Dank der Einführung sicherer Cloud-basierter IoT-Plattformen ist es möglich geworden, diesen Ansatz auch auf die Embedded-Entwicklung zu übertragen.

DevOps für die Embedded-Entwicklung

Aus wirtschaftlicher Sicht führt diese DevOps- Fehlerbenachrichtigungen zu weniger unzufriedenen Kunden, da weniger Endnutzer von Fehlern im Produktionscode betroffen sind. Embedded Software enthält trotz aller Qualitätsprüfungen und Tests fast immer noch ein paar Fehler, die beim Release übersehen wurden, die aber in der Regel nicht bei jedem Gerät direkt auftreten. Wenn man frühzeitig von dem Fehler erfährt, bleibt also in den meisten Fällen etwas Zeit, das Problem zu beheben, bevor allzu viele Kunden davon betroffen sind. Mit DevAlert werden Entwickler innerhalb von Sekunden nach dem ersten Auftreten des Fehlers benachrichtigt und die bereitgestellte visuelle Trace-Diagnostik ermöglicht eine schnelle Fehleranalyse sowie -korrektur. Die Entwickler können dann umgehend ein automatisches Over-the-Air-Update zur Behebung des Problems versenden. Die sofortige Benachrichtigung und die Trace-Diagnose können die Reparaturzeit erheblich verkürzen und die Zahl der vom Problem betroffenen Kunden so klein wie möglich halten.

Die höhere Zuverlässigkeit der Geräte verringert die Haftungsrisiken für Unternehmen und senkt zudem die Kosten für Kundensupport, Rücksendungen und das Debugging. Die bereitgestellte Trace-Diagnostik erleichtert es den Entwicklern erheblich, Kundenprobleme zu reproduzieren, da sie Informationen direkt vom Gerät erhalten und sich nicht auf die Beschreibung der Umstände durch den Anwender verlassen müssen. Ohne automatisches Geräte-Feedback sind sie darauf angewiesen, dass die Endbenutzer alle Probleme melden und ausreichend detaillierte Informationen bereitstellen. Ein vager Fehlerbericht wie „das System reagiert nicht mehr“ ist nicht besonders hilfreich und es kann Wochen dauern, bis eine wahrscheinliche Ursache gefunden wird. Und selbst dann bleibt es immer eine bestmögliche Vermutung – Entwickler können nicht mit Sicherheit wissen, ob sie das richtige Problem gelöst haben.

Software-Alerts – nicht nur zur Fehlerbeseitigung geeignet

Es gibt aber noch einen Aspekt, den man nicht vergessen sollte: Alerts müssen sich nicht zwangsweise auf Software-Bugs und die daraus resultierenden Fehler beziehen. Da die Entwickler frei definieren können, wo und wann Warnmeldungen generiert werden sollen, könnten sie die Alerts beispielsweise auch zur Überwachung wichtiger Anwendungskennzahlen (KPIs) verwenden, um so den Grund für gelegentliche Leistungsprobleme zu erkennen.

Die Überwachung der Benutzerschnittstelle kann ebenfalls interessante Informationen liefern. Angenommen der Benutzer öffnet ein Menü auf einem Touchscreen, z.B. im Infotainment-System seines Autos, und weiß dann nicht, wie er weitermachen soll. Um solche Probleme abzufangen, kann der Anwendungsentwickler nach jedem Eingabe-Ereignis einen Timer starten und einen Alert erzeugen, z.B. wenn innerhalb von 5 Sekunden keine Eingabe erfolgt. Wenn dann viele Meldungen bezüglich dieses Teils der Benutzeroberfläche eingehen, können Unternehmen dieses wichtige Feedback nutzen, um bessere Produkte zu entwickeln.

Alles in allem hat das Software-Tracing mit direkter Fehlermeldung vom Gerät über die Cloud große Vorteile und lässt sich mit einer Lösung wie Percepio DevAlert relativ einfach realisieren. Allerdings bedarf es für einen echten DevOps-Arbeitsverlauf neben der Fähigkeit, Over-the-Air-Updates vorzunehmen, auch einer agilen, reaktionsschnellen Entwicklungsorganisation, die sich der Grenzen von Software-Tests sowie der Bedeutung fortlaufender Verbesserungen auch nach dem Firmware-Release bewusst ist.

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

(ID:46950920)