Software-Tracing in vor Ort eingesetzten Geräten

Software-Tracing ist ein wichtiges Werkzeug in der Toolbox jedes Embedded-Entwicklers, insbesondere in Kombination mit fortschrittlicher Visualisierung. Die meisten eingebetteten Systeme haben viele zyklische Muster, bei denen sich dieselbe Sequenz immer wieder wiederholt. Beim Debuggen möchte man oft die Anomalien finden, also Abweichungen vom normalen zyklischen Verhalten, bei denen etwas Außergewöhnliches passiert ist.

Das Software-Tracing an sich ist jedoch nur eine Form der Datenerfassung. Die Suche nach einem Problem in einer Fülle von textuellen oder numerischen Protokolldaten ist vergleichbar mit der Suche nach der Nadel im Heuhaufen, aber mit der richtigen Visualisierung wird die Suche zu einem Problem der visuellen Mustererkennung, für die das menschliche Gehirn besonders gut gerüstet ist . Interaktive Grafiken, die Ausführungszeiten, Antwortzeiten, Aufgabenwechsel, Nachrichtenweitergabe zwischen Aufgaben anzeigen – all dies ermöglicht es einem Entwickler, Anomalien in der Ausführung seiner Firmware schnell zu erkennen und tiefer zu graben.

Tools für die visuelle Spurendiagnostik gibt es seit mindestens einem Jahrzehnt und haben sich für die Entwicklung und das Debugging im Labor als nützlich erwiesen. Da immer mehr Embedded-Software-Entwickler eine sichere Cloud-Konnektivität für das Internet der Dinge hinzufügen, ist es ganz natürlich, den Einsatz von Tracing in eingesetzten Geräten im Feld in Betracht zu ziehen, um reale Probleme zu erfassen, die während der Tests übersehen wurden. Schließlich erfordert softwarebasiertes Tracing keine zusätzliche Hardware und ein angeschlossenes IoT-Gerät ist offensichtlich in der Lage, Diagnose-Trace-Daten wie normale Anwendungsdaten hochzuladen. Auf diese Weise können Entwickler schnell auf verbleibende Softwareprobleme aufmerksam werden, die im realen Betrieb Probleme verursachen, und erhalten außerdem eine detaillierte Diagnose, um die Ursache zu verstehen.

Software-Tracing ist in diesem Szenario vergleichbar mit einem virtuellen „Flugschreiber“, wie er bei Verkehrsflugzeugen bei Unfällen eingesetzt wird. Es ist ein integrierter Bestandteil des Produkts, der ständig aufzeichnet und im Problemfall wichtige Informationen liefert. Aber im Gegensatz zu den echten Flugschreiberboxen ist es eine Softwarelösung und für Softwareprobleme gedacht.

Eine Lösung für diese Art der Überwachung von IoT-Geräten ist DevAlert von Percepio (Abbildung 1), das aus drei Teilen besteht:einem Firmware-Monitor, einer kleinen Bibliothek, die Sie Ihrer Firmware hinzufügen, um das Verfolgen und Hochladen von Warnungen zu ermöglichen; unser Tracealyzer-Tool für die visuelle Trace-Diagnostik; und ein Cloud-Dienst, der für die Kategorisierung und Speicherung von Warnungen, die Benachrichtigung von Entwicklern, das Herausfiltern doppelter Warnungen und mehr verantwortlich ist.

Abbildung 1. Percepio DevAlert bietet IoT-Entwicklern sofortiges Feedback zu Fehlern in ihren mit der Cloud verbundenen Geräten und ermöglicht so eine schnelle kontinuierliche Verbesserung der Gerätesoftware.
(Zum Vergrößern auf das Bild klicken)

Die erste Version läuft auf AWS und ist für RTOS-Anwendungen gedacht, die AWS IoT Core verwenden, aber die Lösung kann für andere Cloud-Plattformen angepasst werden.

Software-Tracing und Cloud-Konnektivität
Die Rückverfolgung im Entwicklungslabor und die Rückverfolgung bereitgestellter Geräte sind zwei verschiedene Dinge. Wenn Sie heute visuelle Spurendiagnostik im Labor einsetzen und diese auf das Feld ausweiten möchten, müssen Sie einige Dinge durchdenken.

Im Vergleich zu einer direkten physischen Verbindung wie USB oder Ethernet bietet eine Cloud-Verbindung sowohl eine begrenzte Bandbreite als auch viel längere Reaktionszeiten. Das Hochladen von beispielsweise 5 KB Daten kann über eine drahtlose Schnittstelle Dutzende oder Hunderte von Millisekunden erfordern. Bei diesem Ansatz werden jedoch nicht fortlaufend Traces übertragen, sondern nur, wenn ein Alert generiert wird und nur ein kleiner Trace der letzten Ereignisse. Warnungen sind nur für ungewöhnliche, aber wichtige Dinge gedacht, beispielsweise wenn ein Fehler im Anwendungscode festgestellt wurde, wie z. B. ein fehlgeschlagener Sanity-Check, ein harter Fehler oder ein Watchdog-Reset.

Jedes mit dem Internet verbundene Gerät muss sicher sein. Daher ist es wichtig, keine neuen Angriffsvektoren einzuführen. Wir lösen dies in DevAlert, indem wir uns auf bestehende Cloud-Konnektivität verlassen, anstatt eine neue Verbindung einzuführen. Dies nutzt die Sicherheit von AWS und anderen führenden IoT-/Cloud-Anbietern, die verifizierte SDKs für Cloud-Konnektivität anbieten, die nach Best Practices gesichert sind, wie z. B. Geräteauthentifizierung mit X.509-Zertifikaten und verschlüsselte Kommunikation mit TLS. Dies würde dann DevAlert-Uploads genauso sicher machen wie normale IoT-Anwendungsdaten, und für zusätzliche Sicherheit benötigt es nur eine unidirektionale Kommunikation:Es hört nie auf eingehende Nachrichten.

Bei diesem Ansatz werden Warnungen auf dasselbe Cloud-Konto hochgeladen, das normalerweise vom Gerät verwendet wird, und mit derselben Sicherheitsstufe. In der Cloud angekommen, wird ein kleiner Teil der Daten dem Cloud-Dienst zur Verfügung gestellt. Dies beinhaltet nicht die eigentlichen Trace-Daten, die als sensible Informationen angesehen werden können und daher im Cloud-Konto des Geräts verbleiben. Die Abbildungen 2a und 2b zeigen den Datenfluss und die Sicherheitsbarrieren im Detail.

Abbildung 2a. Der Datenfluss beginnt in der Gerätesoftware, wo Entwickler Warnungen zum Quellcode hinzufügen. Jede Warnung, die in das Cloud-Konto des Geräts hochgeladen wird, enthält eine kurze Ablaufverfolgung mit den neuesten Ereignissen vor der Warnung. Schließlich wird eine Metadatensignatur an den DevAlert-Clouddienst weitergeleitet. (Zum Vergrößern auf das Bild klicken)

Abbildung 2b. Der Cloud-Dienst vergleicht eingehende Warnungen mit früheren Warnungen aus der gesamten Geräteflotte des Kunden und benachrichtigt Entwickler über neue Probleme. Warnungen, bei denen es sich um Duplikate handelt, werden gezählt und gespeichert, es werden jedoch keine Benachrichtigungen gesendet. Auf diese Weise werden die Posteingänge der Entwickler nicht überflutet, wenn dieselbe Warnung auf mehreren Geräten ausgelöst wird. (Zum Vergrößern auf das Bild klicken)

Die Betriebskosten für den Empfang von Warnungen an ein Cloud-Konto sind in der Regel gering, obwohl dies natürlich vom Volumen abhängt. Solange keine Probleme erkannt werden, werden zunächst keine Warnungen gesendet. Im Allgemeinen verlangen Cloud-Anbieter auch sehr wenig für das Senden und Speichern von gelegentlichen Warnmeldungen. Die meisten IoT-Anwendungen generieren viel mehr Daten, was sich in den Preisen der IoT-/Cloud-Dienste widerspiegelt. Das Senden von 1 Million MQTT-Nachrichten an AWS IoT Core kostet beispielsweise 1 US-Dollar.

Der Großteil der Alarmverarbeitung erfolgt im Cloud-Dienst, einem vollständig verwalteten Dienst, der von Percepio gehostet wird. Nur die Erstverarbeitung erfolgt im Cloud-Konto des Geräteentwicklers, was die Cloud-Kosten niedrig hält und die Integration vereinfacht.

Das Versenden von Over-the-Air-Updates zur Behebung gemeldeter Fehler kann möglicherweise etwas mehr kosten, da Sie viel mehr Daten und an alle Geräte übertragen müssen. AWS bietet ein Preisbeispiel, bei dem die Kosten für die Aktualisierung einer Flotte von 600.000 Geräten 1.275 US-Dollar betragen. Dies ist jedoch nicht sehr teuer im Verhältnis zu den Kosten, wenn ein Fehler nicht behoben wird – beschädigte Kundenerfahrung, niedrigere Produktbewertungen, niedrigere Verkäufe oder sogar Unfälle und rechtliche Schritte.

DevOps für die eingebettete Entwicklung
Wenn Sie Ihren IoT-Geräten ermöglichen, bei Softwareproblemen „nach Hause zu telefonieren“, hat dies einen erheblichen Vorteil. Das direkte Erkennen von Fehlern und die detaillierte Diagnose erzeugen eine Feedbackschleife zwischen Entwicklern und bereitgestelltem Code, die es Entwicklern ermöglicht, Fehler schneller zu beheben und aktualisierte Firmware schneller bereitzustellen – siehe Abbildung 3. Diese sogenannte DevOps-Philosophie ist seit langem der Standard in der Entwicklung von Mobilgeräten und Cloud-Anwendungen, und mit der Einführung sicherer Cloud-basierter IoT-Plattformen ist es auch für die Embedded-Entwicklung möglich geworden, auf diese Weise zu funktionieren.

Abbildung 3. Das DevAlert-Dashboard in Tracealyzer listet die zuletzt gemeldeten Warnungen und Ablaufverfolgungen auf.
(Zum Vergrößern auf das Bild klicken)

Aus geschäftlicher Sicht führt diese Überwachung im DevOps-Stil zu weniger unzufriedenen Kunden, da weniger Endbenutzer von Fehlern im Produktionscode betroffen sind. Die meiste eingebettete Software enthält trotz aller Verifizierungsbemühungen einige übersehene Fehler bei der Veröffentlichung, die jedoch normalerweise nicht bei jedem direkt auftauchen. Es bleibt oft etwas Zeit, um das Problem zu beheben, bevor viele Kunden betroffen sind, wenn Sie frühzeitig darüber Bescheid wissen. Im Idealfall sollten Entwickler innerhalb von Sekunden nach der allerersten Warnung benachrichtigt werden und die bereitgestellte Trace-Diagnose ermöglicht eine schnelle Analyse und Korrektur. Entwickler können dann ein automatisches Over-the-Air-Update versenden, um das Problem zu beheben. Die sofortige Awareness- und Trace-Diagnose kann die Reparaturzeit erheblich verkürzen und die Anzahl der betroffenen Kunden minimieren.

Eine verbesserte Gerätezuverlässigkeit reduziert Haftungsrisiken und senkt zudem die Kosten für Kundensupport, Rücksendungen und Fehlersuche. Die bereitgestellte Diagnose erleichtert Entwicklern das Reproduzieren von Kundenproblemen erheblich, da sie Informationen direkt vom Gerät erhalten und sich nicht auf die Beschreibung der Umstände durch den Benutzer verlassen müssen. Ohne automatisches Feedback verlassen Sie sich darauf, dass Ihre Endbenutzer alle Probleme melden und ausreichend detaillierte Informationen bereitstellen. Eine vage Fehlermeldung wie „Das System reagiert nicht mehr“ ist nicht sehr hilfreich und es kann Wochen dauern, bis eine wahrscheinliche Ursache gefunden wird. Und selbst dann ist es nur Ihre beste Vermutung – Sie können nicht wirklich wissen, ob Sie das richtige Problem gelöst haben.

Nicht nur Fehler
Zu beachten ist, dass sich Warnungen nicht nur auf übersehene Fehler und die daraus resultierenden Fehler beziehen müssen. Da Entwickler frei entscheiden können, wo und warum Warnungen generiert werden sollen, können sie diese auch zur Überwachung wichtiger Leistungskennzahlen der Anwendung verwenden und den Grund für gelegentliche Leistungsprobleme erkennen.

Auch die Überwachung der Benutzeroberfläche kann interessante Informationen liefern. Angenommen, Sie haben eine Situation, in der der Benutzer ein Menü auf einem Touchscreen öffnet, z. in den Infotainmentsystemen eines Autos und zögert dann, wo es weitergeht. Um solche Probleme abzufangen, kann der Anwendungsentwickler nach jedem Eingabeereignis einen Timer starten und eine Warnung generieren, wenn innerhalb von beispielsweise 5 Sekunden keine Eingabe empfangen wird. Wenn dann viele Warnungen über denselben Teil der Benutzeroberfläche eingehen, kann dies ein wichtiges Feedback sein, das Ihrem Unternehmen helfen kann, bessere Produkte zu entwickeln.

Alles in allem hat die Nutzung von Software-Tracing und Cloud-basierten Warnungen in bereitgestellten Geräten große Vorteile und ist nicht kompliziert. Um jedoch einen Workflow im DevOps-Stil vollständig zu implementieren, erfordert es die Fähigkeit zu Over-the-Air-Updates und eine reaktionsschnelle Entwicklungsorganisation, die die Grenzen von Softwaretests und die Bedeutung der kontinuierlichen Verbesserung auch nach der Veröffentlichung versteht.