Zustandsüberwachung in Echtzeit
Do it yourself: Condition based Monitoring
Die Zustandsüberwachung ist oft der Beginn für Industrie 4.0 in der Fertigung. Doch wie konkret ins Developement starten? Wiederverwertbare Entwicklungsplattformen mit Hardware und Open-Source-Software-Stack sind ein gutes und schnelles Starterkit.
»Do not start from the scratch«! Aus Entwicklersicht enthalten Anwendungen zur Zustandsüberwachung Sensoren, die lokale Verarbeitung inklusive Schnittstellen und meist individuelle Software oder Firmware. Entwicklungsplattformen bringen diese Elemente und dazu passende Hard- und Software bereits mit. Ohne auf dem »weißen Blatt Papier« starten zu müssen, können Ingenieure und Softwareentwickler für ihre gewünschte Zielanwendung Kompromisse beim Design finden und zugleich Tools und Infrastrukturen gemeinsam verwenden. Etwa, wenn Entwickler einen bestimmten Mikrocontroller oder ein spezielles FPGA für die Verarbeitung wählen möchten, Python-Codierung bevorzugen oder einen favorisierten Sensor wiederverwenden möchten. Die Entwicklungsplattformen eignen sich so als leistungsstarke Starterkits für Ingenieure, die eine optimierte CbM-Lösung (Condition-based Monito- ring) aufbauen möchten, und die Da- tenverarbeitung, Leistungsaufnahme bzw. Leistungsfähigkeit, die Software sowie die Datenanalyse an ihre Bedürfnisse anpassen wollen.
Ablauf einer Embedded-Entwicklung
Im Folgenden wird ein allgemeiner Entwicklungsablauf für ein Embedded-System von der Konzeption bis zur Produktion beleuchtet, als Referenz dient die CN0549-Plattform von Analog Devices. Bild 1 gibt einen Überblick über einen abstrahierten Entwicklungsablauf auf oberster Ebene.
Der Entwicklungsprozess beginnt mit der Datenrecherche. In dieser Phase ordnen die Anwender die Bedürfnisse und Kriterien der Anwendung den dafür erforderlichen Hard- und Softwareanforderungen zu. Aus der Sicht der Hardware können dies Parameter wie Schocktoleranz, analoge Signalbandbreite oder Messbereiche sein. Bei den Softwareanforderungen sind die Anzahl der benötigten Messdaten, die Abtastraten, das Frequenzspektrum, Überabtastung und digitale Filterung wichtige Parameter für CbM-Anwendungen. Die Entwicklungsplattformen sind meist extrem flexibel und ermöglichen Entwicklern, verschiedene Sensorkombinationen zu verwenden sowie die Datenerfassungsparameter auf die eigenen Anwendungsbedürfnisse ab- zustimmen.
Auf die Datenrecherche folgt die Algorithmenentwicklung, in welcher auch die Anwendung oder Nutzung des Systems erprobt wird. Dies beinhaltet normalerweise die Entwicklung von Modellen oder Algorithmen auf höherer Abstraktionsebene, die später auf das Embedded-System portiert werden sollen. Bevor das Design jedoch optimiert werden kann, muss es anhand von realen Daten und mit dem HiL-Verfahren (Hardware-in-the-Loop) validiert sein. Praxisnahe Plattformen bieten nicht nur eine direkte Integration mit gängigen High-Level-Ana-lysetools, sondern ermöglichen auch eine HiL-Validierung.
Sobald ein Design als brauchbar eingestuft ist, beginnt dessen Optimierung und die Einbettung der erforderlichen Softwarekomponenten. Bei der Ausarbeitung des Embedded-Designs kann dies eine Neuimplementierung bestimmter Algorithmen oder Softwareschichten erfordern, damit sie in einem FPGA oder auf einem Mikrocontroller mit begrenzten Ressourcen funktionieren. Dazu gehört eine kontinuierliche Verifizierung des Designs, während es zur finalen Validierung auf einen Prototyp oder auf produktionsnahe Hardware portiert wird.
Die abschließende Produktionsphase ähnelt zwar nur noch rudimentär der ursprünglichen Entwicklungsumgebung zu Beginn des Designs, muss aber die gleichen Anforderungen erfüllen. Da sich das finale System möglicherweise weit vom ursprünglichen Forschungssystem entfernt hat, kann es unmöglich oder schwierig sein, denselben Code oder dieselben Tests auszuführen. Dies kann zu Problemen bei Produktionstests sowie zu Fehlern in den Einheiten führen und erfordert zu deren Klärung wahrscheinlich zusätzliche Zeit und Kosten.
Wiederverwendung vermindert Risiken
Eine der einfachsten Möglichkeiten, Entwicklungsrisiken zu verringern, ist die Wiederverwendung möglichst vieler Hard- und Softwarekomponenten in jeder Designphase. Eine Entwicklungsplattform bietet meist viele Ressourcen, die Ingenieure direkt in allen Phasen der Entwicklung nutzen können. Die genannte Referenzplattform enthält u. a. Schaltpläne und Platinenlayoutdateien, einen offenen Software-Stack für optimierte sowie für voll ausgestattete Umgebungen sowie Integrationsmöglichkeiten für Tools wie Matlab und Python.
Endanwender können geprüfte Komponenten des jeweilgen Anbieters nutzen und die Teile auswählen, welche sie beim Übergang von der Forschung in die Produktion beibehalten oder ändern möchten. Dadurch können sich Ingenieure und Developer auf die Entwicklung von Algorithmen und die Systemintegration konzentrieren und müssen sich nicht mit der Schaltplaneingabe, mit Bauteilen oder der grundlegenden Softwareentwicklung beschäftigen. Die Nutzung von geprüften Hardwaremodulen und die Wiederverwendung von Softwareschichten, beispielsweise Gerätetreiber, HDL oder Anwendungsfirmware, verkürzt dementsprechend die Entwicklungszeit und kann die Markteinführung wesentlich beschleunigen.
Softwareentwicklung und Prozesse
Mit der Referenzplattform können Ingenieure in gängigen Sprachen wie C oder C++ arbeiten und zugleich Datenanalysetools verwenden, mit denen sie bereits Erfahrung haben, beispielsweise Matlab oder Python. Dies erfolgt in erster Linie über offene Standards und bestehenden Lösungen, die Embedded-Plattformen verschiedener Hersteller unterstützen.
Der System-Stack in Bild 2 gibt einen grundlegenden Überblick über die verschiedenen Komponenten des Plattformsystems CN0549 von Analog Devices. Die dunkelblauen Kästchen oben links stehen für die Sensor- und Datenerfassungskarte, die hellblauen und violetten Kästchen für die zur Datenverarbeitung verwendeten FPGA-Partitionen. Die Plattform unterstützt mit den Modellen Intel DE10-Nano und Xilinx CoraZ7-07 das Angebot der beiden großen FPGA-Hersteller. Das grüne Kästchen steht für die Verbindung zurück zum Host-PC. Dies ermöglicht den direkten Daten- zugriff von der Hardware auf die High-Level-Datenanalysetools für die Algorithmenentwicklung.
Der gesamte Code der Hardwarebeschreibungssprache (HDL, Hardware Description Language) ist quelloffen, sodass Entwickler Änderungen vornehmen können, um DSP-Funktionen in die Datenströme innerhalb der programmierbaren Logik (PL) einzufügen. Dies kann von Filtern über Zustände (State Machines) bis hin zu maschinellem Lernen (ML) alles sein. Je nach Partitionierung des Systems kann dieser Schritt auch im User Space (Benutzerbereich) oder in der Anwendungsschicht durchgeführt werden. Da der Code frei verfügbar ist, kann er je nach den Anforderungen der Endanwendung auf FPGAs von anderen Herstellern oder auf andere Prozessorfamilien portiert werden.
Je nach Anwendung gibt es innerhalb des Arm-Prozessors zwei Softwareoptionen:
➔ Linux: Es werden kernelinterne Treiber für das DAQ-Shield (Data Acquisition) bereitgestellt, die in das IIO-Framework (Input Output Industrial) innerhalb des Kernels integriert sind. Dies ist mit einer vollständigen Embedded-Linux-Distribution namens Kuiper Linux gekoppelt, die im Arm-Core-User-Space läuft und auf dem Raspberry Pi OS basiert.
➔ No-OS: Ein Bare-Metal-Projekt wird mit denselben Treibern bereitgestellt, die auch im Linux-Kernel verwendet werden, der mit den SDKs von Xilinx oder Intel eingesetzt wird. In einer Echtzeit-Betriebssystemumgebung (RTOS) ist dieses als alternative Implementierung einsetzbar.
Aufgrund der hohen Anzahl verfügbarer Tools sollten Entwickler mit Linux beginnen, um zunächst das System zu erlernen und die Entwicklung zu starten. Bei Linux gibt es außerdem eine enorme Anzahl von Packages und Treibern, die eine ideale Entwicklungsumgebung abbilden können. Sobald das Systemdesign stabil ist und optimiert werden kann, ist es üblich, zu No-OS zu wechseln und nur die dann erforderliche Software auszuliefern. Dies ist jedoch stark anwendungsabhängig, viele Unternehmen liefern für eine hohe Flexibilität beim Kunden vollständige Linux-Systeme aus.
Wie die Hardware-Beschreibungssprache für die programmierbare Logik sind auch die gesamte Kernel-Quelle, das Kuiper-Linux-Image und die No-OS-Projekte vollständig quelloffen. Somit können Endbenutzer jede Komponente nach Belieben verändern. Diese Codebasis ist auch auf andere Prozessorsysteme oder andere Laufzeitumgebungen portierbar.
Die letzte Komponente in Bild 2 repräsentiert links unten die Verbindung zum Host-PC (grünes Kästchen). Beim Betrieb des Systems können die Komponenten konfiguriert und die Daten zur Analyse auf ein Hostsystem übertragen werden, auf dem Entwickler mit Standardtools wie Matlab oder TensorFlow Algorithmen erstellen. Anschließend werden die Algorithmen auf das Em- bedded-Zielsystem übertragen, sodass diese ihre lokale Verarbeitungsleistung für schnellere Iterationen der Algorithmenentwicklung nutzen können.
- 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
