Low-Code-Applikationen mit KI-basierter Sensorik ...

[kdw]

SSV-Vortrag auf den Low-Code-Days 2024 10./11. September 2024 in Hannover. Siehe https://lowcodeday.de/.



Um beispielsweise mit Hilfe einer Low-Code-Anwendung ein Formular in der IT-Welt zu digitalisieren, reichen als Datenquelle einfache Datenbankanbindung aus. Die Anwendungsentwicklung im IoT- und OT-Umfeld erfordert diesbezüglich spezielle Maßnahmen. Hier benötigen Digitalisierungsapplikationen in der Regel verschiedene Sensordaten, um eine bestimmte Aufgabenstellung mit möglichst großem Anwendernutzen zu erfüllen.

Aber nicht alle Sensordatenquellen liefern so einfach zu handhabende Messwerte, wie z. B. Temperatur-, Luftdruck- oder Luftfeuchtigkeitsmessungen. Vielfach hat man es in der Praxis mit deutlich komplexeren Daten und einer aufwendigen Informationsgewinnung zu tun. Ein typisches Beispiel wäre ein Vibrationssensor, der eine dreidimensionale Beschleunigungsmessung durchführt und am Ausgang jeweils einen x-, y- und z-Messwert zur Verfügung stellt. Um mit einem solchen Sensor beispielsweise Vibrationsdaten zu erzeugen, aus denen sich ein Maschinenzustand als Information für eine Low-Code-Anwendung ableiten lässt, sind sowohl spezielle Datenerfassungsmethoden (periodisches Abtasten der drei Beschleunigungsdimensionen innerhalb eines bestimmten Zeitfensters und Zusammenfassen der Daten) als auch eine umfangreiche Datenvorverarbeitung oder sogar Datenanalyse erforderlich. Dafür werden komplexe mathematische Funktionen benötigt, beispielsweise diskrete Fourier-Transformationen.

In Bezug auf eine Datenanalyse zur Zustandsbestimmung (Condition Monitoring) sind häufig sogar KI-Algorithmen aus dem Bereich des maschinellen Lernens (ML) erforderlich, die mit speziellen „Lerndaten“ trainiert werden. Ein Beispiel wären künstliche neuronale Netzwerke, um Vibrationsdatenbilder zu klassifizieren. In der Regel lassen sich solche aufwendigen Sensordatenverarbeitungsaufgaben nicht innerhalb der Low-Code-Funktionen realisieren. Alternativ lässt sich die Aufgabe in die Sensorik verlagern. Die Zielgröße am Sensorausgang wird dann bei einem solchen „Virtuellen Sensor“ oder „Softsensor“ nicht mehr direkt gemessen, sondern durch Algorithmen berechnet.

Der SSV-Vortrag zeigt an Hand eines Praxisbeispiels auf, wie mit einem KI-basierten Softsensor und einer Low-Code-Applikation ein manueller Testprozess in der Elektronikproduktion einer eDNP/8331-basierten IoT-Baugruppe automatisiert wird. Als KI-Baustein kommt in diesem Anwendungsbeispiel ein Autoencoder mit I-Signatur zum Einsatz. Die Instandsetzung von Baugruppen mit Produktionsfehlern wird durch eine Fehlerbaumanalyse (FTA) unterstützt.

VG KDW

[kdw]

Q: Wie lautet die zum Vortrag passende User Story?

A: Als Hersteller von Funk-basierten IoT-Gateways für kundenspezifische Anwendungen lassen wir verschiedene Baugruppen bei externen Dienstleistern anfertigen. Im Rahmen dieser Dienstleistung wird eine Leiterplatte mit elektronischen Bauelementen bestückt, optisch inspiziert und anschließend einem Funktionstest und Setup unterzogen. Dabei erhält die Baugruppe eine digitale Identität mittels SIM sowie PKI-Zertifikaten und wird über eine interne Mobilfunkschnittstelle auf einem Internet-Server angemeldet. Treten bei Inspektion, Test und Setup keine Fehler auf, wird die Baugruppe in ein Gehäuse montiert und vom Fertigungsdienstleister an uns ausgeliefert. Ansonsten wird ein Instandsetzungsprozess durchlaufen.

Für den Test und Setup stellen wir dem Dienstleister einen Testadapter mit KI-basiertem Softsensor zur Verfügung. Der Softsensor versorgt unsere Disponenten mit Detailinformationen zu jeder produzierten Baugruppe und unterstützt unseren Fertigungspartner bei der Instandsetzung fehlerhafter Baugruppen. Für den Zugriff und die Weiterverarbeitung der Baugruppeninformationen nutzt das Disponenten-Team verschiedene Low-Code-Anwendungen.


Q: Warum ist der Testadapter erforderlich?

A: Um die aus unserer Sicht kritischen Systemfunktionen gemäß den jeweiligen Anforderungen zu testen, entwickeln wir zu einer solchen Baugruppe einen individuellen Funktionstest, zu dem auch ein Testadapter plus eine Testsoftware gehören. Mit diesem Adapter begegnen wir im Rahmen dezentraler Wertschöpfungsprozesse den Herausforderungen eines möglichst umfassenden Funktionstests. Mit Hilfe des Testadapters erfolgt auch der Baugruppen-Setup, also das sogenannte Provisioning. Der Testadapter liefert zu jeder getesteten Baugruppe ein spezielles Datenbild, das aus typischen OT-Daten besteht, die nicht ohne weiteres IT-tauglich sind.


Q: Warum ist der Funktionstest eine Herausforderung?

A: Diese Aufgabe besitzt schon eine gewisse Komplexität. In der Gesamtschaltung der IoT-Baugruppe kommen u. a. Subsysteme zu Einsatz, die eine eigene Firmware besitzen (z. B. eMMC, 4G-Mobilfunkmodem). Da kann schon einiges schiefgehen. Des Weiteren wird ein 868 MHz-Funkchip plus Peripherie bestückt. Dieser Schaltungsteil enthält komplexe Analogtechnik, die sogar sensibel auf Fertigungstoleranzen des Leiterplattenmaterials reagiert (Funkreichweite). Zusätzlich existiert ein Spannungswandler-Schaltungsteil mit zahlreichen Bauteilen, der verschiedene Systemspannungen erzeugt. Ein Bestückungsfehler in diesem Schaltungsbereich lässt sich durch visuelle Prüfungen nicht in jedem Fall sicher erkennen.


Q: Was ist eine Low-Code-Anwendung?

A: Dieser Begriff klassifiziert Softwareanwendungen, die mit Hilfe einer Low-Code-Entwicklungsplattform erstellt wurden. Solche Plattformen ermöglichen die Anwendungsentwicklung mit minimalem Programmieraufwand, indem sie visuelle Tools, vorgefertigte Module und Drag-and-Drop-Funktionen bereitstellen. Die wichtigsten Merkmale einer Low-Code-Anwendung sind:

- Visuelle Entwicklung: Low-Code-Entwickler können die Benutzeroberfläche und Logik der Anwendung durch visuelles Modellieren erstellen, anstatt Code manuell zu schreiben.

- Vorlagen und Bausteine: Plattformen bieten vorgefertigte Komponenten und Templates, die schnell angepasst und verwendet werden können.

- Automatisierung: Viele Funktionen, wie die Verbindung zu Datenbanken, die Erstellung von Benutzeroberflächen oder die Implementierung von Geschäftslogik, werden durch die Plattform automatisiert.

- Schnelle Entwicklungszeit: Durch den geringen Programmieraufwand und die einfache Bedienung können Anwendungen deutlich schneller entwickelt und angepasst werden.


Q: Was sind die wichtigsten Vorteile von Low-Code-Anwendungen?

A: Neben der Zeitersparnis durch kurze Entwicklungszeiten im Vergleich zur traditionellen Anwendungsentwicklung ist die Kosteneffizienz ein großer Vorteil, da weniger hochspezialisierte Entwickler benötigt werden und auch Personen mit weniger Programmierkenntnissen (sogenannte Citizen Developer, also z. B. Anwender) praxistaugliche Applikationen erstellen können.


Q: Was sind typische Einsatzbereiche für Low-Code-Anwendungen?

A: Low-Code-Anwendungen werden häufig in Unternehmen eingesetzt, um interne Prozesse zu automatisieren, Web- und Mobile-Apps zu entwickeln oder bestehende Systeme zu integrieren. Besonders in Umgebungen, in denen schnell auf Veränderungen reagiert werden muss, wie zum Beispiel in der digitalen Transformation, sind sie sehr nützlich.


Q: Was sind typische Low-Code-Plattformen?

A: Ein typisches Beispiel aus der Open-Source-Welt ist Node-RED. Weitere bekannte kommerzielle Plattformen sind z. B. OutSystems, Mendix oder Microsoft Power Apps.


Q: Was ist ein Softsensor?

A: Ein Softsensor, auch virtueller Sensor oder Sensorfusion genannt, ist kein real existierender Sensor, sondern eine Modell-basierte Verknüpfung von „stellvertretenden Messgrößen“ zu einer Zielgröße. Softsensoren berechnen die gewünschte Zielgröße als Ausgangswert aus verschiedenen zu ihr korrelierenden Eingangsvariablen. Das Eingangsdatenbild kann aus Messdaten einzelner Hardware-Sensoren, aber auch Messwerten bzw. Variablen aus anderen Quellen bestehen. Wichtig ist, dass eine mathematisch beschreibbare Wechselbeziehung zwischen den einzelnen Eingangsvariablen und der Zielgröße existiert. Mit Hilfe des maschinellen Lernens (ML), also einem Teilbereich der künstlichen Intelligenz (KI), lassen sich sehr leistungsfähige Softsensoren für verschiedene Anwendungsbereiche erstellen.


Q: Was ist ein Autoencoder?

A: Ein Autoencoder ist ein spezieller Typ eines künstlichen neuronalen Netzwerks, das darauf ausgelegt ist, Eingangsdaten möglichst effizient zu kodieren und wiederherzustellen. Es besteht aus einem Encoder, einer Darstellungsebene (Code-Darstellung) und einem Decoder.

Der Encoder übernimmt die Eingabedaten und komprimiert sie für die sogenannte Code-Darstellung in ein Format mit einer reduzierten Dimensionsanzahl. Dies bedeutet, dass der Encoder die wesentlichen (also latenten) Merkmale der Eingabedaten in einer komprimierten Form speichert.

Die Code- bzw. Latent-Darstellung ist der zentrale, komprimierte Teil des Autoencoders, der die wichtigen Merkmale der Eingabedaten enthält. Die Idee dabei ist, dass diese Darstellungsebene eine geringere Dimensionsanzahl als die Originaldaten besitzt und daher auch weniger Speicherplatz benötigt.

Der Decoder als dritte Stufe übernimmt die komprimierte Latent-Darstellung und versucht daraus wieder die ursprünglichen Daten zu rekonstruieren. Das Ziel dabei ist, dass diese neuen Daten so nah wie möglich an den Originaldaten liegen.

Autoencoder eignen sich für unterschiedliche Aufgabenstellungen. Dazu gehören z. B. die Anomalieerkennung, Datenkompression und Rauschunterdrückung.


Q: Was ist eine Fehlerbaumanalyse?

A: Eine Fehlerbaumanalyse (Fault Tree Analysis, FTA) ist ein etabliertes Verfahren, um zu einer bekannten, aber unerwünschten Auswirkung die möglichen Ursachen zu bestimmten. Ausgehend von einem Top-Ereignis (also die bekannte Auswirkung, z. B. ein Fehlerbild „Motor springt nicht an“) werden rückwärtsgerichtet dessen möglichen Fehlerursachen ermittelt (z. B. „Kein Treibstoff“ oder „Anlasser ohne Funktion“ usw.). Dieser Top-Down-Ansatz ist sehr universell einsetzbar. Er eignet sich sowohl für einfache und hochkomplexe technische Prozesse als auch (Sub-) Systeme, also z. B. Baugruppen, Maschinen und Anlagen. Dabei wird innerhalb einer Baumstruktur mit deduktiven (abgeleiteten) Schlussfolgerungen sowie logischen UND- bzw. ODER-Verknüpfungen gearbeitet und über die verschiedenen Ebenen eines Funktionssystems die mögliche Beteiligung verschiedener Einzelkomponenten bzw. Einflussgrößen untersucht. Eine durch diese Systemanalysemethode jeweils entstehende Baumstruktur (also der Fehlerbaum) lässt sich mit Hilfe vordefinierter Symbole darstellen. Zur Fehlerbaumanalyse existieren die Normen IEC 61025 und DIN EN 61025. Die Methoden gemäß diesen Normen besitzen eine sehr große Schnittmenge zu den Ursache-Wirkung-Diagrammen (Ishikawa-Diagramme).


Q: Was ist eine I-Signatur?

A: „I“ ist ja bekanntlich das Symbol für den elektrischen Stromfluss. Insofern verstehen wir die „I-Signatur“ als Stromflusssignatur einer elektronischen Baugruppe mit digitalen Schaltkreisen, die mit den unterschiedlichen Betriebszuständen dieser Baugruppe korreliert. Eine solche Stromflusssignatur nutzen wir als Eingangsdaten für den Autoencoder. An Hand dieser Signatur kann der Autoencoder innerhalb weniger Sekunden zwischen normalen und anormalen Betriebszuständen der Baugruppe unterscheiden.


Q: Wie genau erfolgt die Strommessung einer I-Signatur?

A: Es erfolgt zunächst einmal eine Strommessung innerhalb eines Zeitfensters mit einer vorgegeben Abtastfrequenz, also z. B. eine Strommessung über ca. zwei Sekunden mit 100 Hertz. Die Rohdaten lassen sich bei Bedarf mittels digitaler Filter bearbeiten. Das Ergebnis wird mit Hilfe einer Diskreten Fourier-Transformation (DFT) in den Frequenzbereich übertragen und in einem Messdaten-Array gespeichert. Teilweise werden zusätzliche statische Kenngrößen errechnet. Alternativ lässt sich auch ein Bildobjekt mit einem Spektrogramm erzeugen. Die dabei entstandenen Daten werden an den Autoencoder weitergeleitet.


Q: Neben der Stromanalyse gehört auch eine Fehlerbaumanalyse zum Softsensor. Warum?

A: Wir halten die Fehlerbaumanalyse für eine sinnvolle Ergänzung mit Blick auf mögliche Instandsetzungsmaßnahmen defekter Baugruppen. Mit Hilfe der KI-basierten Komponente (also dem Autoencoder) überwachen wir z. B. den Betrieb eines technischen Systems und können daher eine Anomalie als unerwünschtes Fehlerbaum-Top-Ereignis erkennen. Über die Fehlerbaumanalyse stellen wir im Anomaliefall dem Anwender kontextbezogene Fehlerbehebungshinweise zur Verfügung. Mit anderen Worten: Ein Testadapter mit einem Softsensor liefert für eine nicht funktionierende Baugruppe wertvolle Instandsetzungshinweise.


Q: Muss es gleich eine KI bzw. ein künstliches neuronales Netzwerk sein, um die Strommessdaten einer zu prüfenden Baugruppe zu bewerten?

A: Diese Frage haben wir uns auch gestellt und den Sachverhalt kontrovers diskutiert. Sicherlich reicht unter gewissen Umständen eine statische Strommessung mit anschließender Fehlerbaumanalyse für die zu prüfenden Baugruppen aus, um in der Praxis zahlreiche mögliche Produktionsfehler zu identifizieren.

Wir sind allerdings von den vielfältigen Möglichkeiten künstlicher neuronaler Netzwerke nachhaltig beeindruckt. Damit lassen sich sehr viel komplexere Eingangsdatenbilder verarbeiten. Das führt zu höherwertigen Ausgangsinformationen. Man kann sich das sehr einfach an Hand eines Temperaturmessbeispiels verdeutlichen: Um an Hand eines einzelnen Temperaturmesswerts eine Software-basierte Entscheidung zu treffen, ist keine KI notwendig. Allerdings enthält ein solcher einzelner Messwert vielfach auch keine werthaltige Information und die Entscheidung ist evtl. ungenau. Wird stattdessen z. B. die Temperatur einer Oberfläche mit einem 8 x 8 oder 32 x 32 IR-Sensorarray gemessen, dass 64 oder 1.024 Temperaturmesswerte am Ausgang liefert, ist die Software-basierte Bewertung ohne KI schon eine Herausforderung. Mit einem entsprechend trainierten KI-Modell ist so etwas relativ einfach möglich. Das Ergebnis ist eine deutlich fundiertere Entscheidung.


Q: Warum benutzt der Softsensor in diesem Beispiel eine Mobilfunkverbindung?

A: Insgesamt nutzen wir den Softsensor in diesem Beispiel für drei Teilaufgaben:

1. Um IT-taugliche Daten zu jeder einzelnen Baugruppe einer Produktionscharge, die getestet wurde und das Provisioning durchlaufen hat, an den Hersteller zu liefern.

2. Um den Fertigungsdienstleister in Bezug auf die Instandsetzung fehlerhafter Baugruppen zu unterstützen. Dafür werden der Autoencoder (also die KI-Funktion) und die Fehlerbaumanalyse genutzt.

3. Für das Herstellen einer autarken Kommunikationsverbindung zwischen Testadapter sowie Softsensorfunktionen und Hersteller.


Q: Ist der KI-basierte Softsensor für Low-Code-Anwendungen eine SSV-Neuentwicklung?

A: Der Anwendungsfall ist neu, die Technik dahinter praxiserprobt. Die Embedded KI in einem solchen Softsensor basiert auf unserem Endpunkt-KI-Framework, dass wir ja bereits im Zusammenhang mit einem Embedded Intrusion Detection System (IDS) vorgestellt haben (siehe auch https://www.ssv-comm.de/forum/viewtopic.php?t=1647). Dazu gehört auch ein Workflow mit Datenerfassung in der Zielumgebung, ML-Modell-Codierung, Test und Optimierung, TFLITE-Dateierzeugung zum Modellexport in das Zielsystem, Modellintegration und Inferenzcode für das Zielsystem, Test in der Zielumgebung, Deployment usw.

[kdw]

Sie entwickeln Low-Code-Anwendungen und benötigen Daten aus industriellen Prozessen, Maschinen und Anlagen? Sie wollen einen KI-basierten Softsensor einmal ausprobieren? Melden Sie sich einfach bei uns. Wir stellen Ihnen gerne ein Testsystem zur Verfügung.



Kontakt: sales@ssv-embedded.de

[kdw]

Selbstverständlich lassen sich alle Softwarebausteine eines KI-basierten Softsensors bei Bedarf auch Over-the-Air (OTA) mit Software-Updates versorgen. Dafür nutzen wir unser praxisbewährtes OTA/SDU (SDU = Secure Device Update).


Siehe auch: https://www.ssv-embedded.de/produkte/ota-sdu/

Der KI-basierte Softsensor wird aus OTA/SDU-Sicht dabei zu einer Target Device. OTA/SDU wird auf Wunsch sogar zusammen mit einem A/B-Partitioning (A/B-Bootkonzept) eingesetzt, so dass sich im Falle eines Falles wieder der Zustand vor einem Update reaktivieren lässt.

[kdw]

... bitte einfach per E-Mail über sales@ssv-embedded.de anfordern.



Ansonsten siehe auch: https://www.linkedin.com/posts/ssv-software-systems_lowcode-digitaletransformation-germanlowcodeday-activity-7241757311445143552-FYlK?utm_source=share&utm_medium=member_desktop