{"id":1810,"date":"2024-07-29T08:40:00","date_gmt":"2024-07-29T06:40:00","guid":{"rendered":"https:\/\/essaar.de\/?p=1810"},"modified":"2024-11-11T10:54:56","modified_gmt":"2024-11-11T09:54:56","slug":"embedded-systeme-messen","status":"publish","type":"post","link":"https:\/\/essaar.de\/en\/embedded-systeme-messen\/","title":{"rendered":"Measure internal states of embedded systems(DE)"},"content":{"rendered":"\n

Dieser Artikel wurde am 29.07.2024 auf elektronik.net<\/a> und am 23.07.2024 in Ausgabe 15\/16 des Elektronik-Magazins<\/a> ver\u00f6ffentlicht.<\/em><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Embedded-Systeme vereinen Elektronik sowie Software und erm\u00f6glichen so die Datenverarbeitung in elektronischen Ger\u00e4ten. Aber nicht nur die Produkte selbst, sondern auch deren Entwicklung, Wartung und Qualit\u00e4tssicherung erfordern die Handhabe von Daten. Wissenschaftliche und technische Erkenntnisse flie\u00dfen bereits in den Entwurf eines neuen Produkts ein. Begleitet von Simulationen und Modellierungen entsteht dann ein Entwurf, der dieses Konzept in die Realit\u00e4t umsetzen kann. Doch erst Messungen am Prototyp erm\u00f6glichen es, den Erfolg der Umsetzung zu verifizieren. In vielen F\u00e4llen ist dazu der Zugriff auf relevante Daten aus den internen Zust\u00e4nden des Embedded-Systems notwendig. Diese Daten m\u00fcssen dann als Messwerte aufbereitet und analysiert werden.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Messdaten in der Entwicklung: Notwendigkeit und Aufwand<\/h2>\n\n\n\n

Daten sind in der Entwicklung untrennbar mit Modellierungen, Simulationen und Messungen an Prototypen verbunden. In einer idealen Welt k\u00f6nnten Simulationen und Modellierungen die gesamte Entwicklung \u00fcbernehmen, Prototypen und Messungen daran w\u00e4ren \u00fcberfl\u00fcssig, und der Entwicklungsaufwand w\u00e4re geringer. Doch warum sind Messungen trotz fortschrittlicher Simulationen \u00fcberhaupt noch notwendig?<\/p>\n\n\n\n

Messungen sind notwendig, um die Funktion der entwickelten Systeme zu verifizieren, die Modelle an die Realit\u00e4t anzupassen und schlie\u00dflich mithilfe von Prototypen Fehler fr\u00fchzeitig zu erkennen und erfolgreich zu beheben. Zus\u00e4tzlich wird die Technik der Embedded-Systeme immer komplexer und die Vernetzung der Ger\u00e4te nimmt zu [2]. Durch das Zusammenspiel von Hardware und Software wird das Systemverhalten, das sich aus dem Zusammenwirken mehrerer, oft auch unabh\u00e4ngig voneinander entwickelter Teilsysteme ergibt, schwieriger zu modellieren und in fr\u00fchen 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\u00fchren.<\/p>\n\n\n\n

Messungen sind also unerl\u00e4sslich. Gleichzeitig sind sie aber auch aufwendig \u2013 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\u00fchzeitige Identifikation von Softwarefehlern die Kosten f\u00fcr die Fehlerbehebung deutlich reduziert, das schreibt auch die NASA in ihren Berichten [3]. Schmitt und Pfeifer [4] zeigen analog dazu, dass die Kosten f\u00fcr die Behebung von Fehlern in sp\u00e4teren Entwicklungsphasen zehnmal h\u00f6her sein k\u00f6nnen als die Kosten f\u00fcr eine fr\u00fchere Entdeckung, z. B. durch Prototypen und gut konzipierte Messkampagnen.<\/p>\n\n\n\n

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\u00f6nnen damit im Gesamtprojekt die Kosten optimieren. Die Aufwandsbetrachtung ist folglich eng mit dem zu erwartenden Informationsgewinn verbunden. Um ein vollst\u00e4ndiges Bild f\u00fcr 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.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Qualit\u00e4t der Daten und der Datenhandhabe<\/h2>\n\n\n\n
\"\"
Bild 1. Die Datenwertsch\u00f6pfungskette l\u00e4sst sich mit der \u00d6l-Wertsch\u00f6pfungskette vergleichen.<\/figcaption><\/figure>\n\n\n\n

Der oft zitierte Satz \u00bbData is the new oil\u00ab mag abgedroschen klingen, bietet jedoch eine treffende Analogie f\u00fcr diese Handhabe: \u00c4hnlich wie bei \u00d6l handelt es sich bei der Handhabe der Daten um eine Wertsch\u00f6pfungskette (Data Value Chain), die von der Erfassung \u00fcber 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\u00e4t \u00fcber diese gesamte Kette hinweg zu erhalten und gleichzeitig den Aufwand gering zu halten.<\/p>\n\n\n\n

Bevor Qualit\u00e4tsattribute dieser Daten und deren Bedeutung im Kontext von Embedded-Systemen betrachtet werden, zun\u00e4chst eine Anmerkung: Signale, Parameter und Variablen aus dem Speicher des Controllers werden erst durch einen Kontext \u2013 Zeitpunkt, Einheit und Name \u2013 zu relevanten Messungen. Erst dieser Kontext macht die Messdaten aussagekr\u00e4ftig f\u00fcr das Systemverhalten und dessen Fehlerzust\u00e4nde und erm\u00f6glicht deren Nutzung zur Kalibrierung oder Validierung des Systems.<\/p>\n\n\n\n

Nun zur Qualit\u00e4t der Daten selbst: H\u00e4ufig identifizierte Attribute sind zum Beispiel Genauigkeit, Konsistenz, Vollst\u00e4ndigkeit und Aktualit\u00e4t der Daten [6]. Sie h\u00e4ngen von der Datenhandhabe ab und sind in der Anwendung immer mit Kompromissen und Einschr\u00e4nkungen verbunden. Dies gilt auch im Kontext der Embedded-Systeme: Die Kommunikation der internen Zust\u00e4nde erfolgt \u00fcber Schnittstellen, die eine Schnittstellenabh\u00e4ngigkeit der Datenhandhabe mit sich bringen. Auch die m\u00f6gliche Datenrate und deren Auswirkungen auf die Leistung des Systems sind zu betrachten. Dar\u00fcber 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\u00e4t zu erhalten.<\/p>\n\n\n\n

F\u00fcr die Datenwertsch\u00f6pfungskette bedeutet dies, dass relevante Informationen zug\u00e4nglich und nutzbar sein m\u00fcssen. F\u00fcr die Umsetzung werden entsprechende Werkzeuge ben\u00f6tigt. Die Qualit\u00e4t dieser Werkzeuge bestimmt die Qualit\u00e4t der Datenwertsch\u00f6pfungskette und somit die Qualit\u00e4t der datengetriebenen Entwicklung.<\/p>\n\n\n\n

Messungen in der Software<\/h2>\n\n\n\n

F\u00fcr eine \u00dcbersicht lassen sich die Werkzeuge nach dem Grad ihrer Integration in das Testsystem kategorisieren: Messungen am Ger\u00e4t, im Ger\u00e4t und im Gesamtsystem. Bei all diesen Methoden werden Kompromisse in Bezug auf die Qualit\u00e4tsattribute der Daten und dem Messaufwand eingegangen.<\/p>\n\n\n\n

Messungen am Ger\u00e4t<\/h2>\n\n\n\n

Messungen am Ger\u00e4t liefern durch Messger\u00e4te, z. B. Oszilloskop, eine gute Datenqualit\u00e4t und eignen sich zur Analyse der Hardware und der externen Schnittstellen. Sie bieten jedoch nur einen begrenzten Einblick in interne Zust\u00e4nde, wenn diese nicht \u00fcber externe Schnittstellen zug\u00e4nglich sind. F\u00fcr die Durchf\u00fchrung und Anpassung der Messung k\u00f6nnen der physikalische Anschluss und die Konfiguration der Messger\u00e4te am Pr\u00fcfling mit einem hohen Aufwand verbunden sein.<\/p>\n\n\n\n

Messungen im Ger\u00e4t<\/h2>\n\n\n\n

Messungen \u00bbim Ger\u00e4t\u00ab, zum Beispiel \u00fcber Datenlogger, k\u00f6nnen Daten direkt im laufenden eingebetteten System erfassen und kontextualisieren. Sie bieten damit im laufenden Betrieb einen guten Zugriff auf interne Softwarezust\u00e4nde. Um auf bestimmte ben\u00f6tigte Daten zugreifen zu k\u00f6nnen, sind jedoch \u00c4nderungen an der Softwarekonfiguration erforderlich. Au\u00dferdem kann die Systemleistung durch den Mehraufwand beeintr\u00e4chtigt werden.<\/p>\n\n\n\n

Messungen im Gesamtsystem<\/h2>\n\n\n\n

Messungen mit Emulatoren und Hardware-in-the-Loop-Systemen sind optimal f\u00fcr umfassende Systemtests einschlie\u00dflich der Wechselwirkungen zwischen Hardware und Software unter simulierten Betriebsbedingungen, sind jedoch kosten- und wartungsintensiv. Dar\u00fcber hinaus h\u00e4ngen die Genauigkeit und die Relevanz der gewonnenen Daten stark von der Genauigkeit der Simulation und der Qualit\u00e4t der Modellierung ab.<\/p>\n\n\n\n

\"\"
Bild 2. Austausch zwischen der Middleware es:prot und dem Software-Oszilloskop es:scope.<\/figcaption><\/figure>\n\n\n\n

Diese \u00dcberlegungen zeigen zusammengenommen, dass sich f\u00fcr die Zug\u00e4nglichkeit interner Zust\u00e4nde die Messung in der Ger\u00e4tesoftware eignet, wenn die einhergehenden Herausforderungen adressiert werden. Dieser Ansatz wird von der Middleware<\/a> es:prot [7] und der Software es:scope [8] verfolgt, die in Bild 2 schematisch gezeigt werden.<\/p>\n\n\n\n

Die Middleware<\/a> ber\u00fccksichtigt den Leistungsaspekt durch eine m\u00f6glichst ressourceneffiziente Implementierung. Ferner wird der Aufwand der Softwarekonfiguration durch einen flexiblen Funktionsaufbau adressiert: Daten des Mikrocontrollers werden ausgew\u00e4hlt und \u00fcber eine beliebige Kommunikationsschnittstelle zug\u00e4nglich gemacht. Diese Daten stehen dem Software-Oszilloskop es:scope dann in Echtzeit zur Verf\u00fcgung \u2013 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\u00f6glich, das System und seine Parameter zu validieren und zu kalibrieren.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Middleware f\u00fcr den Zugang zu relevanten Daten<\/h2>\n\n\n\n

Systemvariablen als Messwerte in Leseprozessen und als Parameter in Schreibprozessen stellt es:prot zur Verf\u00fcgung. Dazu werden die auf dem eingebetteten System selektierten Daten zu Messdaten kontextualisiert, in Datenpaketen zusammengefasst, ggf. vorverarbeitet und an der gew\u00fcnschten Schnittstelle gehandhabt. Der Code der Middleware<\/a> ist Hardware-abstrakt geschrieben und liegt im C-Format vor, sodass die Open-Source-Bibliothek plattformunabh\u00e4ngig in ein Projekt eingebunden werden kann.<\/p>\n\n\n\n

\u00dcber den \u00bbSignal Manager\u00ab, \u00bbCommand Manager\u00ab und \u00bbTransport Layer & Flow Control\u00ab, die ebenfalls in Bild 2 zu sehen sind, kann die Middleware<\/a> Messdaten \u00fcber ein beliebiges Kommunikationsprotokoll versenden. Die bei der Implementierung einstellbare \u00bbConfig\u00ab legt dazu die Schnittstellenparameter fest:<\/p>\n\n\n\n