Zustandsüberwachung in Echtzeit
Do it yourself: Condition based Monitoring
Fortsetzung des Artikels von Teil 1
Erste Schritte mit CbM-Daten
Die Verwendung von Arm-Prozessor und programmierbarer Logik erfolgt normalerweise später im Entwicklungsablauf, wenn das System für den Einsatz optimiert wird. Ein üblicher Einstiegspunkt für Entwickler ist daher zunächst die Fernverbindung zum Embedded-System von einer Workstation aus. Wenn Linux auf einem Embedded-System läuft, ist die Ausführung von Code aus der Ferne oder lokal auf einer Workstation aufgrund der Konzeption der Infrastruktur relativ transparent. Dies ist primär auf die offene Bibliothek libIIO zurückzuführen.
libIIO ist eine Schnittstellenbibliothek, die ein vereinfachtes und konsistentes Zugriffsmodell auf verschiedene Gerätetreiber ermöglicht, die sich im Linux-IIO-Framework im Kernel befinden. Die Bibliothek ist der Kern dessen, was den Einsatz der CbM-Plattform so flexibel macht, und bietet die Funktionalität für Datenstreaming und Gerätesteuerung.
libIIO selbst besteht aus zwei Hauptkomponenten:
➔ Der libIIO-Bibliothek, eine C-Bibliothek für den Zugriff auf verschiedene IIO-Treibereigenschaften oder -funktionen. Dies umfasst das Streaming von Daten zu und von Geräten wie ADCs, DACs und Sensoren.
➔ Dem IIO-Daemon iiod, der für die Verwaltung des Zugriffs zwischen der libIIO-Bibliothek beziehungsweise den Clients zuständig ist, welche die Bibliothek verwenden, und der Kernel-Schnittstelle zu den Treibern.
libIIO und iiod selbst bestehen aus Komponenten, die verschiedene Zugriffsmethoden auf die Treiber in Backends ermöglichen. Backends sorgen für die Steuerung und den Datenfluss für libIIO von lokalen und entfernten Benutzern. Da sie auf Komponenten basieren, können neue Backends in das System aufgenommen werden.
Derzeit unterstützt libIIO vier Backends:
➔ Lokal: Ermöglicht den Zugriff auf lokal zugängliche Treiber für Hardware, die mit demselben Rechner verbunden ist.
➔ USB: Dieses Backend nutzt die libusb und ermöglicht die Fernsteuerung von Treibern über eine USB-Verbindung.
➔ Seriell: Stellt eine allgemeinere Schnittstelle für Boards zur Verfügung, die über serielle Verbindungen angeschlossen sind. UART ist die häufigste Verwendung.
➔ Netzwerk: Das am häufigsten verwendete und IP-basierte Remote-Backend für den netzübergreifenden Zugriff auf Treiber.
Der Überblick auf Systemebene in Bild 3 zeigt, wie die Komponenten von libIIO verwendet werden und wie sie sich in ein Gesamtsystem einfügen
. Links in der Blockschaltung ist das Embedded-System zu sehen, auf dem die libIIO-Bibliothek installiert ist und der iiod-Daemon läuft. Über das Embedded-System können Benutzer auf das lokale Backend und sogar auf das Netzwerk-Backend zugreifen. Im Programmcode können Anwender mit einer einzigen Zeilenänderung zwischen beiden umschalten. Es sind keine weiteren Änderungen am Zielcode erforderlich.
Die linke Seite von Bild 4 repräsentiert einen entfernten Host, auf dem ein beliebiges Betriebssystem laufen könnte. Es gibt offizielle Pakete für Windows, macOS, Linux und BSD. Im Diagramm wird das Netzwerk- oder IP-basierte Backend verwendet. Es könnte jedoch auch eine serielle, USB- oder PCIe-Verbindung sein. Aus Benutzersicht kann libIIO von der C-Bibliothek selbst oder von vielen der verfügbaren Bindungen zu anderen Sprachen genutzt werden. Darunter: Python, C#, Rust, Matlab und Node.js. Dies bietet eine große Auswahl für Benutzer, die von ihren Anwendungen aus Schnittstellen zu verschiedenen Treibern benötigen.
Anwendungen und Tools
Entwicklern, die mit einem neuen Gerät beginnen, wird die direkte Verwendung von libIIO im Allgemeinen nicht empfohlen. Daher gibt es viele Higher-Level-Anwendungen, die auf libIIO aufbauen und grundlegende Konfigurationsmöglichkeiten für jedes IIO-Device über die Befehlszeile und im GUI-Format bieten. Dies sind die IIO-Tools beziehungsweise das IIO-Oszilloskop.
Bei den IIO-Tools handelt es sich um eine Reihe von Kommandozeilen-Tools, die zusammen mit libIIO ausgeliefert werden und für Low-Level-Debugging und automatische Aufgaben durch Skrip- ting nützlich sind. Für Labortests kann es zum Beispiel nützlich sein, die Plattform für verschiedene Abtastratenmodi einzurichten und Daten zu sammeln. Dies lässt sich mit ein paar Zeilen Bash oder einem Batch-Skript, welches die IIO-Tools nutzt, leicht erledigen.
Bild 5 zeigt ein einfaches Beispiel, das lokal oder aus der Ferne ausgeführt werden kann, um die Abtastrate und den Eingangs-Gleichtakt des A/D-Wandlers zu ändern. Das Beispiel verwendet ein IIO-Tool namens iio_attr, mit welchem Benutzer die Gerätekonfigurationen leicht aktualisieren können.
Der gebräuchlichste Einstiegspunkt für Benutzer ist jedoch die GUI-Anwendung IIO-Oscilloscope, die man üblicherweise als OSC bezeichnet. OSC ist genau wie die IIO-Tools zum generischen Gebrauch konzipiert, sodass die Steuerung jedes IIO-Treibers ermöglicht wird. Da OSC auf libIIO basiert, kann es per Fernzugriff oder auf dem Board selbst ausgeführt werden. Es enthält jedoch auch ein Plug-in-System, mit dem spezielle Registerkarten (Tabs) für bestimmte Treiber oder Kombinationen von Treibern hinzugefügt werden können.
Bild 6 zeigt die Plug-in-Tabs, die automatisch für CN0540-basierte Boards geladen werden, einschließlich der Tabs für Steuerung und Überwachung. Die Tabs stellen eine einfache Schnittstelle für den Zugriff auf die Low-Level- Funktionen der ADC-, DAC- und Steuerpins des CN0540 sowie ein grundlegendes Diagramm der Datenerfassungskarte und der Testpunktüberwachung zur Verfügung.
Der letzte wichtige Aspekt von OSC ist das Erfassungsfenster. Dies ermöglicht die Darstellung von Daten, die von ADCs oder beliebigen libIIO-basierten Puffern erfasst wurden. Bild 7 zeigt das Erfassungsfenster im Frequenzbereichsmodus, in welchem die Spektralinformationen der Daten aufgezeichnet werden.
Weitere grafische Darstellungen, da- runter Zeitbereichs-, Korrelations- und Konstellationsdiagramme, sind verfügbar. Dies ist nützlich für die stichprobenartige Überprüfung eines Geräts, für das Debugging oder während des Evaluierungsprozesses. Für die Plot-Darstellungen gibt es gängige Hilfsmittel wie Marker, Spitzenerkennung, Erkennung von Oberwellen und sogar Phasenabschätzung. Da OSC auch quelloffen ist, kann es von jedem Entwickler erweitert werden, um weitere Plug-ins oder Diagramme hinzuzufügen oder bestehende Funktionen zu ändern.
- Do it yourself: Condition based Monitoring
- Erste Schritte mit CbM-Daten
- Integration der Entwicklungsumgebung für Algorithmen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Eingebettete Künstliche Intelligenz
KI für die Massen!
Sichere Cloud-Services für Gaia-X
Leuchtturmprojekt Structura-X startet
