Interne Zustände von Embedded-Systemen messen

Dieser Artikel wurde am 29.07.2024 auf elektronik.net und am 23.07.2024 in Ausgabe 15/16 des Elektronik-Magazins veröffentlicht.

Embedded-Systeme vereinen Elektronik sowie Software und ermöglichen so die Datenverarbeitung in elektronischen Geräten. Aber nicht nur die Produkte selbst, sondern auch deren Entwicklung, Wartung und Qualitätssicherung erfordern die Handhabe von Daten. Wissenschaftliche und technische Erkenntnisse fließen bereits in den Entwurf eines neuen Produkts ein. Begleitet von Simulationen und Modellierungen entsteht dann ein Entwurf, der dieses Konzept in die Realität umsetzen kann. Doch erst Messungen am Prototyp ermöglichen es, den Erfolg der Umsetzung zu verifizieren. In vielen Fällen ist dazu der Zugriff auf relevante Daten aus den internen Zuständen des Embedded-Systems notwendig. Diese Daten müssen dann als Messwerte aufbereitet und analysiert werden.

Messdaten in der Entwicklung: Notwendigkeit und Aufwand

Daten sind in der Entwicklung untrennbar mit Modellierungen, Simulationen und Messungen an Prototypen verbunden. In einer idealen Welt könnten Simulationen und Modellierungen die gesamte Entwicklung übernehmen, Prototypen und Messungen daran wären überflüssig, und der Entwicklungsaufwand wäre geringer. Doch warum sind Messungen trotz fortschrittlicher Simulationen überhaupt noch notwendig?

Messungen sind notwendig, um die Funktion der entwickelten Systeme zu verifizieren, die Modelle an die Realität anzupassen und schließlich mithilfe von Prototypen Fehler frühzeitig zu erkennen und erfolgreich zu beheben. Zusätzlich wird die Technik der Embedded-Systeme immer komplexer und die Vernetzung der Geräte nimmt zu [2]. Durch das Zusammenspiel von Hardware und Software wird das Systemverhalten, das sich aus dem Zusammenwirken mehrerer, oft auch unabhängig voneinander entwickelter Teilsysteme ergibt, schwieriger zu modellieren und in frühen Entwicklungsphasen nur mit einer gewissen Unsicherheit vorhersagbar. Um das Verhalten des Gesamtsystems zu validieren, ist es daher erforderlich, die Messungen nicht nur an der Hardware, sondern auch an der Software durchzuführen.

Messungen sind also unerlässlich. Gleichzeitig sind sie aber auch aufwendig – der Bau eines Prototyps eines eingebetteten Systems ist mit mehr Aufwand verbunden als eine reine Modellierung und Simulation. Die Rolle der Messungen ist damit auch gleichzeitig immer eine Aufwandsbetrachtung. Es ist bekannt, dass eine frühzeitige Identifikation von Softwarefehlern die Kosten für die Fehlerbehebung deutlich reduziert, das schreibt auch die NASA in ihren Berichten [3]. Schmitt und Pfeifer [4] zeigen analog dazu, dass die Kosten für die Behebung von Fehlern in späteren Entwicklungsphasen zehnmal höher sein können als die Kosten für eine frühere Entdeckung, z. B. durch Prototypen und gut konzipierte Messkampagnen.

Iterative oder agile Entwicklungsmethoden, die immer wieder Validierungen einbauen, zeigen daher auch in der Elektronikentwicklung Einsparpotenziale [5]. Messbare Ergebnisse sichern die Entwicklungsschritte ab, helfen Fehler zu identifizieren und können damit im Gesamtprojekt die Kosten optimieren. Die Aufwandsbetrachtung ist folglich eng mit dem zu erwartenden Informationsgewinn verbunden. Um ein vollständiges Bild für die Bewertung des Informationsgewinns zu erhalten, ist es notwendig zu betrachten, was gute Daten und eine gute Messdatenhandhabe ausmachen, und dies im Kontext der eingebetteten Systeme einzuordnen.

Qualität der Daten und der Datenhandhabe

Der oft zitierte Satz »Data is the new oil« mag abgedroschen klingen, bietet jedoch eine treffende Analogie für diese Handhabe: Ähnlich wie bei Öl handelt es sich bei der Handhabe der Daten um eine Wertschöpfungskette (Data Value Chain), die von der Erfassung über die Aufbereitung und Analyse bis hin zur Speicherung und Nutzung im Einsatzgebiet reicht. Bild 1 veranschaulicht diese Analogie. Eine gute Datenhandhabe bedeutet, eine hohe Datenqualität über diese gesamte Kette hinweg zu erhalten und gleichzeitig den Aufwand gering zu halten.

Bevor Qualitätsattribute dieser Daten und deren Bedeutung im Kontext von Embedded-Systemen betrachtet werden, zunächst eine Anmerkung: Signale, Parameter und Variablen aus dem Speicher des Controllers werden erst durch einen Kontext – Zeitpunkt, Einheit und Name – zu relevanten Messungen. Erst dieser Kontext macht die Messdaten aussagekräftig für das Systemverhalten und dessen Fehlerzustände und ermöglicht deren Nutzung zur Kalibrierung oder Validierung des Systems.

Nun zur Qualität der Daten selbst: Häufig identifizierte Attribute sind zum Beispiel Genauigkeit, Konsistenz, Vollständigkeit und Aktualität der Daten [6]. Sie hängen von der Datenhandhabe ab und sind in der Anwendung immer mit Kompromissen und Einschränkungen verbunden. Dies gilt auch im Kontext der Embedded-Systeme: Die Kommunikation der internen Zustände erfolgt über Schnittstellen, die eine Schnittstellenabhängigkeit der Datenhandhabe mit sich bringen. Auch die mögliche Datenrate und deren Auswirkungen auf die Leistung des Systems sind zu betrachten. Darüber hinaus kann die Datenhandhabe am Aufwand zur Umsetzung und Anpassung in einem bestehenden Prozess bemessen werden. Zusammengenommen ist das Ziel einer effizienten Handhabe bei einem geringen Aufwand, eine hohe Datenqualität zu erhalten.

Für die Datenwertschöpfungskette bedeutet dies, dass relevante Informationen zugänglich und nutzbar sein müssen. Für die Umsetzung werden entsprechende Werkzeuge benötigt. Die Qualität dieser Werkzeuge bestimmt die Qualität der Datenwertschöpfungskette und somit die Qualität der datengetriebenen Entwicklung.

Messungen in der Software

Für eine Übersicht lassen sich die Werkzeuge nach dem Grad ihrer Integration in das Testsystem kategorisieren: Messungen am Gerät, im Gerät und im Gesamtsystem. Bei all diesen Methoden werden Kompromisse in Bezug auf die Qualitätsattribute der Daten und dem Messaufwand eingegangen.

Messungen am Gerät

Messungen am Gerät liefern durch Messgeräte, z. B. Oszilloskop, eine gute Datenqualität und eignen sich zur Analyse der Hardware und der externen Schnittstellen. Sie bieten jedoch nur einen begrenzten Einblick in interne Zustände, wenn diese nicht über externe Schnittstellen zugänglich sind. Für die Durchführung und Anpassung der Messung können der physikalische Anschluss und die Konfiguration der Messgeräte am Prüfling mit einem hohen Aufwand verbunden sein.

Messungen im Gerät

Messungen »im Gerät«, zum Beispiel über Datenlogger, können Daten direkt im laufenden eingebetteten System erfassen und kontextualisieren. Sie bieten damit im laufenden Betrieb einen guten Zugriff auf interne Softwarezustände. Um auf bestimmte benötigte Daten zugreifen zu können, sind jedoch Änderungen an der Softwarekonfiguration erforderlich. Außerdem kann die Systemleistung durch den Mehraufwand beeinträchtigt werden.

Messungen im Gesamtsystem

Messungen mit Emulatoren und Hardware-in-the-Loop-Systemen sind optimal für umfassende Systemtests einschließlich der Wechselwirkungen zwischen Hardware und Software unter simulierten Betriebsbedingungen, sind jedoch kosten- und wartungsintensiv. Darüber hinaus hängen die Genauigkeit und die Relevanz der gewonnenen Daten stark von der Genauigkeit der Simulation und der Qualität der Modellierung ab.

Diese Überlegungen zeigen zusammengenommen, dass sich für die Zugänglichkeit interner Zustände die Messung in der Gerätesoftware eignet, wenn die einhergehenden Herausforderungen adressiert werden. Dieser Ansatz wird von der Middleware es:prot [7] und der Software es:scope [8] verfolgt, die in Bild 2 schematisch gezeigt werden.

Die Middleware berücksichtigt den Leistungsaspekt durch eine möglichst ressourceneffiziente Implementierung. Ferner wird der Aufwand der Softwarekonfiguration durch einen flexiblen Funktionsaufbau adressiert: Daten des Mikrocontrollers werden ausgewählt und über eine beliebige Kommunikationsschnittstelle zugänglich gemacht. Diese Daten stehen dem Software-Oszilloskop es:scope dann in Echtzeit zur Verfügung – Messwerte in Leseprozessen und Parameter in Schreibprozessen. Die Messwerte visualisiert und analysiert es:scope in Plot-Fenstern. Gesetzte Parameter und Kommandos werden an das Embedded-System gesendet. Dadurch ist es möglich, das System und seine Parameter zu validieren und zu kalibrieren.

Middleware für den Zugang zu relevanten Daten

Systemvariablen als Messwerte in Leseprozessen und als Parameter in Schreibprozessen stellt es:prot zur Verfügung. Dazu werden die auf dem eingebetteten System selektierten Daten zu Messdaten kontextualisiert, in Datenpaketen zusammengefasst, ggf. vorverarbeitet und an der gewünschten Schnittstelle gehandhabt. Der Code der Middleware ist Hardware-abstrakt geschrieben und liegt im C-Format vor, sodass die Open-Source-Bibliothek plattformunabhängig in ein Projekt eingebunden werden kann.

Über den »Signal Manager«, »Command Manager« und »Transport Layer & Flow Control«, die ebenfalls in Bild 2 zu sehen sind, kann die Middleware Messdaten über ein beliebiges Kommunikationsprotokoll versenden. Die bei der Implementierung einstellbare »Config« legt dazu die Schnittstellenparameter fest:

• Die Anzahl der Signale, die vom eingebetteten System zum Computer und umgekehrt übertragen werden sollen.
• Die maximale Puffergröße in Bytes, die der ausgewählten Kommunikationsschnittstelle zugewiesen wird.
• Die Frequenz des Prozesses, der die Daten sendet, z. B. eine Timer-basierte Interrupt-Routine.
• Die Übertragungsgeschwindigkeit in bit/s der verwendeten Kommunikationsschnittstelle.

Der Datentransfer muss einmal initiiert werden. Eine anschließend verfügbare Überprüfungsfunktion erhält von der Kommunikationsschnittstelle den Hinweis, ob die Übertragung abgeschlossen ist oder nicht, und gibt diese Information an das Kommunikationsprotokoll weiter. Hierfür werden schwache Funktionen (Weak Functions) genutzt, die vom Benutzer überschrieben und so für das gewünschte Verhalten eingestellt werden können.

Mit der Initiierung wird auch die Kontextualisierung der Messdaten vorgenommen: Den Signalen werden ein Index, der Variablen-Typ, z. B. uint16_t, und ein Name zugeordnet. Der Messzeitpunkt wird automatisch erfasst. Als »digitale Messspitze« können außerdem ein Skalierfaktor, die Linienfarbe und Linienbreite definiert werden. Für einen Plug-and-play-Anschluss an das Software-Oszilloskop es:scope kann vorab ausgewählt werden, in welchen Plot-Fenstern die Signale angezeigt werden sollen. Während des eigentlichen Prozesses müssen dann nur die Daten in die entsprechenden Puffer eingetragen werden. Dies erfolgt für minimale Leistungseinbuße vorzugsweise mit einem DMA (Direct Memory Access), aber es ist auch in Timer-Interrupts möglich.

Es gibt drei Funktionen, die die Interaktion zwischen es:prot und es:scope steuern:

• Initiierung des Datenaustauschs: Diese Funktion startet den Datenaustausch mit es:scope. Das bedeutet, dass zusätzlich zum Senden der Messdaten an den Computer auch Daten von der Computer-Seite empfangen werden können.
• Abfrage aktueller Werte: Diese Funktion fragt die aktuellen Werte für ein bestimmtes Signal von der es:scope-Seite ab.
• Aufzeichnungssteuerung: Diese Funktion sendet einen Aufzeichnungsbefehl an den Computer oder beendet eine Aufzeichnung.

Darüber hinaus ist es möglich, auf die von es:scope gesendeten Terminalbefehle zuzugreifen. Da nun vorgestellt wurde, wie es:prot die Daten zugänglich macht, wird im nächsten Schritt beschrieben, wie diese Daten in es:scope genutzt werden können.

Das Software-Oszilloskop es:scope

Sobald das Software-Oszilloskop es:scope eine Verbindung zu es:prot hergestellt hat, können die verfügbaren Messdaten in Echtzeit visualisiert, analysiert und ausgewählte Parameter gesetzt werden. Über das Terminal können zudem Befehle an das eingebettete System gesendet werden. es:scope ist in Qt [9] geschrieben, sodass es für die gängigen Betriebssysteme Windows, macOS und Linux verfügbar ist. Außerdem ist Hardwarebeschleunigung ein zentraler Ansatz, durch die die Visualisierung der Daten über eine Grafikkarte laufen kann.

Das Software-Oszilloskop es:scope ist in Tabs und Fenster aufgebaut:

• Stream-Tab: Hier werden eingehende Signale den Plot-Fenstern zugeordnet, und neue Plot-Fenster können angelegt werden. Dieser Tab ist in Bild 3 gezeigt.
• Commands-Tab: Über die Konsole werden Befehle eingegeben und Parameter über eine Eingabemaske direkt im laufenden Betrieb angepasst, siehe Bild 4.
• Plot-Fenster: Das Plot-Fenster ist von Oszilloskopen inspiriert. Hier werden die Signale und deren Analysewerte visualisiert (Bild 5).

Bilder 3 bis 5

Mit diesem Aufbau ist der Fokus auf Validierungs- und Kalibrierungsaufgaben gerichtet. In den Plot-Fenstern können relevante Signale in Echtzeit verfolgt werden. Ähnlich wie bei einem traditionellen Oszilloskop sind hierfür Signal-Trigger, Cursor-Messungen, einstellbare Zeitfenster und verschiedene Darstellungsparameter möglich. Mit einer Fourier-Transformation kann das Frequenzspektrum eines Signals verfolgt werden, und mit der XY-Darstellung kann der Arbeitspunkt zweier Größen ermittelt werden. Analysewerte bieten zusätzliche Informationen wie den Mittelwert des Signals.

Eine Aufzeichnung kann von es:scope oder, falls der Benutzer dies erlaubt, vom Embedded-System aus über es:prot gestartet oder gestoppt werden. Letzteres ermöglicht, dass die Aufzeichnung und Speicherung von Daten durch das Embedded-System gesteuert wird, sodass automatisierte Testverfahren implementiert oder explizit die Zeiten untersucht werden können, in denen das Embedded-System eine Anomalie aufweist. Aufgenommene Daten können im tabellarischen .xlsx-, .csv- oder im proprietären .mat-Format von Matlab exportiert werden.

Für Kalibrierungsaufgaben steht die asynchrone Kommunikation vom Computer zum Embedded-System im Zentrum. Mit textbasierten Befehlen können im laufenden Betrieb die Betriebsmodi gewechselt und auf dem Controller ausgewählte Parameter neu gesetzt werden. Da in es:prot die Plot-Fenster-Konfigurationen der Signale voreingestellt werden können, ist eine Plug-and-play-Anwendung möglich: Ein Embedded-System wird hierfür mit es:scope auf einem Computer verbunden, und die Visualisierung für einen Abgleich kann starten. Damit werden die durch es:prot zugänglich gemachten Messwerte durch es:scope visualisiert, analysiert und Parameter der Kalibrierung beschreibbar. Die Software kann so in der Entwicklung, Qualitätssicherung und Wartung für die Messdatenhandhabe eingesetzt werden.

Im nächsten Abschnitt werden Anwendungsbeispiele genannt, bei denen diese Software für Kalibrierung und Validierung eingesetzt wurde.

Beispiele aus der Anwendung

Das Software-Oszilloskop es:scope wurde ursprünglich für Probleme in der Antriebstechnik entwickelt. Nachfolgend werden drei Anwendungsbeispiele vorgestellt, die den Einsatz der Software demonstrieren.

1. Optimierung einer Motor Control Unit (MCU)

In dieser Anwendung wurde eine MCU implementiert und mithilfe von es:scope optimiert. Dazu wurden die Parameter eines Reglers feinabgestimmt. Die Motorregelung wurde vorab auf Basis eines physikalischen Modells simuliert.

• Konfiguration: Referenzwerte in Strom, Position und Geschwindigkeit sowie die tatsächlichen Messwerte wurden für die Visualisierung ausgewählt und die Reglerparameter wurden für ein Stellen durch es:scope verfügbar gemacht.
• Tuning der Parameter: Während die Konvergenz und Stabilität eines Reglers beobachtet wurde, konnten Reglerparameter gesetzt werden und die Auswirkungen der jeweiligen Anpassung sofort untersucht werden.
• FFT-Analyse: Die FFT-Analyse der Motorströme wurde genutzt, um harmonische Anteile zu identifizieren.
• Debugging: es:scope diente anschließend auch als Debugging-Tool bei der Konfiguration eines digitalen Filters.

2. Charakterisierung eines Elektromotors

In einem weiteren Projekt [10] wurde ein Elektromotor charakterisiert. Sowohl die Prüfstandselektronik als auch die Motor Control Unit (MCU) des zu charakterisierenden Motors verwendeten die es:prot-Middleware und kommunizierten über Ethernet (UDP) und USB mit einem Computer, der es:scope ausführte. Dies ist schematisch in Bild 6 gezeigt.

• Befehle und Automatisierung: Während der Messkampagne konnten über es:scope Befehle an die Prüfstandselektronik und die MCU gesendet werden, um das Verhalten des Prüfstandes und des Motors zu beeinflussen und verschiedene Testszenarien durchzuspielen.
• Aufzeichnung: Die Aufzeichnung ermöglichte die Charakterisierung des Motors in einer längeren Messkampagne. Die Aufnahme wurde zu den Messzeiten automatisch von es:prot gestartet.
• Auswertung: Die aufgezeichneten Daten wurden exportiert und in Matlab ausgewertet, um eine Geschwindigkeits-Drehmoment-Kennlinie und den Wirkungsgrad des Motors zu bestimmen.

3. Kalibrierung kapazitiver Sensoren

Im letzten Beispiel wurde eine Auswerteelektronik für kapazitive Sensoren kalibriert.

• Visualisierung: Die Signalreaktion bei Betätigung der Sensoren wurde in Echtzeit verfolgt und aufgenommen.
• Analyse und Kalibrierung: Die aufgenommenen Signale wurden in Matlab analysiert, um das Kriechen der Sensoren im implementierten Modell zu berücksichtigen.
• Kalibrierung: Kalibrierparameter wurden gesetzt, um die Genauigkeit der gemessenen Werte zu optimieren.
• Validierung: Das Systemverhalten wurde abschließend mit es:scope validiert, aufgezeichnet und dokumentiert.

Neben diesen eigenen Anwendungen wird es:scope auch bereits überregional in KMUs, Konzernen und Forschungsstandorten angewandt und getestet. Die vielseitigen Einsatzmöglichkeiten und die präzise Datenhandhabung machen es:scope zu einem effektiven Werkzeug in der Entwicklung, Qualitätssicherung und Wartung.

[1] Bogatin, E.: Signal and Power Integrity. Pearson, 3. Auflage, 2018, S. 38, ISBN: 978-0134513416

[2] Wolff, J.: How Is Technology Changing the World, and How Should the World Change Technology? Global Perspectives. Vol. 2, Issue 1, 2021

[3] Stecklein, J.; et al.: Error Cost Escalation Through the Project Life Cycle. Nasa, 19. Juni 2004

[4] Schmitt, R. und Pfeifer, T.: Qualitätsmanagement: Strategien – Methoden – Techniken. Carl Hanser Verlag, 2015, S. 3, ISBN: 978-3446434325

[5] Berteletti, E.; et al.: It’s coming home: The return of agile hardware product development. McKinsey and Company, 6. Oktober 2023

[6] Scholl, C.; et al.: An Integrated Framework for Data Quality Fusion in Embedded Sensor Systems. Sensors 2023, H. 8, Nr. 3798

[7] es:prot – Überblick, Auswahlkriterien, Vorüberlegungen. es:saar, Website

[8] Software Oszilloskop für Eingebettete Laufzeitvariablen. es:saar, Website

[9] The Future of Digital Experiences. Qt Group, Website

[10] Grasso, E.; et al.: Analysis and Exploitation of the Star-Point Voltage of Synchronous Machines for Sensorless Operation. Energies 2019, H. 12, Nr. 4729