Validieren und Kalibrieren
Interne Zustände von Embedded-Systemen messen
Erst Messungen am Prototyp ermöglichen es, ein Embedded-System mit Hard- und Software zu verifizieren. In vielen Fällen ist dazu der Zugriff auf relevante Daten aus den internen Zuständen notwendig. Diese Daten können mit einem Software-Oszilloskop und Middleware aufbereitet und analysiert werden.
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.
Jobangebote+ passend zum Thema
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?
Vielen Lesern ist die Antwort sicherlich bekannt: In der Realität ist die Komplexität von Systemen oft größer als die Genauigkeit der Modelle. Selbst in modellintensiven Bereichen wie dem Leiterplattendesign können laut dem Systemdesign-Professor Eric Bogatin Simulation und Modellierung Messungen nicht vollständig ersetzen [1].
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.
- Interne Zustände von Embedded-Systemen messen
- Das Software-Oszilloskop es:scope
- Literatur
Lesen Sie mehr zum Thema
