MCU, MPU, PLD -

Machine Learning und Sensorfusion auf Embedded-MCU Ohne Cloud und ohne PC

In Sensoranwendungen zur Predictive Maintenance kann ein Arm- Mikrocontroller völlig ausreichen, um Künstliche Intelligenz zu implementieren. Andreas Mangler, Director Strategic Marketing & Communications bei Rutronik, hat das mit seinem technischen Team bewiesen.

eli: Herr Mangler, Sie haben mit Ihrem Team Algorithmen entwickelt, die weder eine Cloud noch einen performanten PC benötigen, sondern auf einem Mikrocontroller ausgeführt werden. Was ist der Hintergrund?

Mangler: Viele Industrieanwender wollen ihre Daten nicht bei einem Dienstleister oder auf einem dezentralen Industrie-PC analysieren, sondern in einem eigenständigen geschützten Umfeld: auf einer Embedded-MCU, idealerweise mit Hardwareverschlüsselung. Gerade in sicherheitsrelevanten Systemen oder da, wo funktionale Sicherheit in Echtzeit gefordert und quasi Ad-hoc-Entscheidungen in Mikro- oder Nanosekunden getroffen werden müssen, ist eine Embedded-Analytics-Lösung unumgänglich.

eli: Es geht also auch um die Sicherheit?

Mangler: Ja, der Schutz der IP und die Echtzeitfähigkeit des Systems stehen im Mittelpunkt der Entscheidung für Embedded Analytics, vor allem der Schutz der Rohdaten, der Algorithmen und deren sequenzielle Aneinanderreihung, um aus Big Data letztlich die gesuchten Informationen zu bekommen. Dabei nutzt Embedded Analytics meist mathematische Modelle, Muster und Funktionen, mit denen ein Soll-Ist-Vergleich mit den bereits angelernten und den gemessenen Daten durchgeführt wird. Bei vielen Aufgaben geht es also um Mustererkennung – Muster, die nicht zwangsläufig nur in der Bildverarbeitung von grafischen Daten vorhanden sind – sowie um die Verarbeitung von vielen Sensordaten mit unterschiedlichen physikalischen Messgrößen, die typischerweise zeitsynchron prozessiert werden, Stichwort Sensorfusion.

eli: Wie kann man sich das in der Praxis vorstellen, solch große Datenmengen und Algorithmen in einem kleinen Mikrocon­troller zu verarbeiten?

Mangler: Die Problemstellung bei der Sensorfusion ist mit dem Schlagwort VUCA gut beschrieben; es steht für Volatility, Uncertainty, Complexity und Ambiguity. Volatilität entsteht dadurch, dass sich das System hinsichtlich seiner Daten, Dynamik, Geschwindigkeit und Grenzwerte fortwährend ändert. Unsicherheiten gibt es etwa aufgrund von Rauschen und nicht vorhersehbaren Ereignissen. Zudem sind die Systeme typischerweise komplex, und es gibt Mehrdeutigkeiten, da manche Zustände verschiedene Ursachen haben können. Das Ziel besteht darin, diese versteckten Informationen abzuschätzen, um das System besser beschreiben zu können. Alleine schon mit dem vorherigen groben Abschätzen des Zustands lassen sich Daten reduzieren. Beispielsweise könnte die Regelung einer Gasheizung, die eine CO2-Analyse durchführen muss, parallel dazu die exakte Außentemperatur bestimmen. So kann die Heizung beim Einsatz in Norwegen sicherlich eine Temperatur von -30 °C im Winter bei der Messwertberechnung berücksichtigen. Aber in Südspanien ist diese Temperatur im Winter unrealistisch.

eli: Dann bestimmen der GPS-Sensor oder Logistikdaten des Heizungslieferanten die Menge der auszuwertenden Daten?

Mangler: Richtig. Die Formel lautet: Datenreduktion plus schlanke Algorithmen, die richtig kombiniert werden. Dabei sind vier Schritte notwendig. Erstens die Sensoreinsatzplanung, also wie viele Messaufnehmer welchen Typs werden wo benötigt? Im zweiten Schritt folgt die Datenauswahl: Welche Daten sind tatsächlich erforderlich, um Anomalien zu erkennen? Aus Big Data wird so Smart Data. Die Kunst besteht vor allem darin, genauso viele Daten auszuwählen wie nötig und so wenig wie möglich – und dabei die richtigen zu nehmen. Im dritten Schritt sind die Algorithmen für die Vorfilterung zu wählen. Dann folgt im vierten die für die Analyse notwendige Parameterextraktion. Alle Schritte müssen exakt auf das System und die Fragestellung abgestimmt sein, und es ist das grundsätzliche Problem der synchronen Datenverarbeitung bei der Sensorfusion zu berücksichtigen.

eli: Wie lässt sich das in der MCU ­umsetzen?

Mangler: Hierfür werden das physikalische System und die möglichen Zustände in der Realität betrachtet und beschrieben. Dies führt dann zu einer Zustandsabschätzung. Solche Modelle können vorab im Labor definiert und in der Look-up-Table des Mikrocontrollers abgelegt werden. Dann lassen sich die Sensordaten mit dem Modell vergleichen und Ausreißer schnell als Anomalie erkennen. Damit sind weniger Messpunkte nötig, was Speicherplatz spart.

eli: Können Sie das an einem praktischen Beispiel erläutern?

Mangler: Eine typische Anwendung wäre ein intelligenter Warmwasserspeicher, der mit einer Photovoltaikanlage verbunden ist. Ich beginne mit der Sensoreinsatzplanung und lege fest, dass mehrere Temperatur- sowie Druck- und Beschleunigungssensoren gebraucht werden. Nun kommt die Zustandsabschätzung: Da ich beispielsweise weiß, dass sich die Temperatur am Sonnenkollektor hierzulande nur zwischen -20 und +50 °C bewegen wird, können alle Daten außerhalb dieser Grenze wegfallen. Das Wasser im Speicher kann sich, rein physikalisch betrachtet, nicht von einer Minute auf die nächste um 30 °C erwärmen; so lässt sich das dynamische Verhalten über den Zeit- oder Frequenzbereich ebenfalls einschränken. Und ein Temperaturunterschied von einem Grad hat noch keinen Einfluss auf das System. Somit müssen die Daten nur bis zu einer Detailtiefe von 1 °C analysiert werden.

eli: Was folgt dann?

Mangler: Im nächsten Schritt gilt es, die relevanten Parameter für die Aufgabenstellung zu identifizieren, wie Schutz vor Überhitzung. Hierfür spielt die Temperatur der Sonnenkollektoren, des Kalt- und Warmwasserzuflusses, des Wärmetauschers und des Brenners eine Rolle. Deren Daten gilt es, aus der Sensorfusion herauszufiltern. Alle anderen brauchen nicht in die Analyse einzufließen. Darauf folgen weitere Filter, um die Datenmenge weiter zu reduzieren. Es geht also primär um die Identifikation der Parameter, die mein Gesamtsystem beeinflussen.

eli: Damit liegen jetzt ausgewählte, gefilterte Daten vor. Was kommt als nächstes?

Mangler: Nun lassen sich beispielsweise über statistische Filter bestimmte Muster und damit Anomalien erkennen – und das sind ja die interessanten Punkte, um in unserem Beispiel eine Überhitzung frühzeitig zu erkennen. Indem ich die Anomalien herausfiltere, kann ich die Datenanalyse auf diese beschränken. Um nun die Anomalien zu beschreiben, gilt es die Extremwerte des Systems, also die Minimal- und Maximalwerte, sowie die Wendepunkte mathematisch zu beschreiben. Bei Cloud und Edge Analytics wird das mit Differentialgleichungen realisiert.

eli: Das klingt nach zu viel Aufwand für Embedded Analytics.

Mangler: Deshalb haben wir die mathematische Kurvendiskussion durch ein selbstlernendes Iterationsverfahren ersetzt. Für die Extraktion der Daten und spätere Visualisierung ist eine zweidimensionale Darstellung hilfreich; später kann man eine dreidimensionale Darstellung wählen, um bestimmte identifizierte Parameter in deren z-Achse zu legen. Dies ist quasi mit einer topologischen Karte der Sensordaten vergleichbar.

eli: Wie sind Sie hierfür vorgegangen?

Mangler: Um die Extremwerte erkennbar zu machen und damit später die Sensormodelldaten zu vergleichen, haben wir eine dreidimensionale Analysemethode gewählt. Hier ist schon erkennbar, dass einige Parameter keinen oder nur geringen Einfluss auf die Anomalien haben. Diese Daten können dann vernachlässigt oder herausgefiltert werden. Um die vorher beschriebene topologische Landschaft mathematisch zu beschreiben, haben wir diese in weniger als 100 Segmente unterteilt und jedes Segment mit nur zehn Messpunkten für die Iteration beschrieben. Das beschränkt den benötigten Speicherplatz von vornherein. Die Differenz zwischen den Modelldaten und den abweichenden Daten haben wir mit ±1,5 % definiert. Das sind die Detektionsgrenzen der Anomalien.

eli: Dann kommt die MCU ins Spiel?

Mangler: Ja, wir haben auf einem STM32 F4 von STMicroelectronics ein selbstlernendes Iterationsverfahren implementiert und dabei die sogenannte Dictionary-Methode verwendet. Das heißt, wir haben iterative Abfragen programmiert, die bestimmen, mit welcher mathematischen Funktion aus dem Dictionary welcher Teilabschnitt der Sensorfunktion zu ersetzen ist. So sind wir schon in drei oder vier Abfrage-Loops zu einem Ergebnis gekommen, das die Sensorkennlinie mit mathematischen Basisfunktionen beschreibt – also eine exakte Modellierung des Systems, die Anomalien sofort erkennbar macht. Das Sensorfunktions-Dictionary hat hierbei nur fünf mathematische Basisfunktionen enthalten, wie radiale Basisfunktionen (RBF) oder lineare Funktionen. Durch den selbstlernenden Ansatz wurden die Segmente und die Anzahl der Daten noch weiter reduziert, sodass schließlich nur noch 30 Segmente nötig waren, also 300 statt 400 Datenpunkte. Und das alles passiert in Echtzeit.

eli: Lässt sich das mit jedem Mikro­controller umsetzen?

Mangler: In der Theorie ja, in der Praxis nein. Bei der Sensorsignalaufbereitung von mehreren Sensoren – also der Sensorfusion – steht die Echtzeitfähigkeit der MCU im Mittelpunkt. Bei zeitsynchronen Vorgängen, wie in MEMS-Sensoren mit sechs Freiheitsgraden, ist eine sehr effiziente Programmierung erforderlich. Bei zeitkritischen Messungen haben wir festgestellt, dass die Programmierung auf der HAL-Ebene (High-Abstraction Layer) zu Messfehlern im Zeitbereich führen kann beziehungsweise die dynamischen Veränderungen der zu detektierenden Anomalien nicht ausreichend waren. Daraus folgte die Entscheidung zur hardwarenahen Lowlevel-Layer-Programmierung.

eli: Und der Speicherplatz?

Mangler: Der hängt von der vorherigen Sensoreinsatzplanung ab. Wir haben den STM32 gewählt, weil die analoge und digitale Peripherie, verbunden mit der direkten Lowlevel-Ansprache, eine assemblernahe Programmierung zulässt, um dann mit dem vorhandenen RAM und ROM die Sensorfusion realisieren zu können.

eli: Ist dieses Verfahren nun auf einen speziellen Anwendungsfall zugeschnitten?

Mangler: Nein, dank der selbstlernenden Algorithmen können wir damit beliebige nichtlineare Systeme aller Sensortypen und -fusionen abbilden. Außerdem erfüllt es auch alle anderen Anforderungen an Embedded Analytics: Es funktioniert offline, also ohne Cloud, in Embedded-Echtzeitsystemen, läuft auf einer Standard-Arm-MCU, ist robust und skalierbar.

eli: Was war die größte Schwierigkeit bei der Entwicklung?

Mangler: Dass sie in verschiedenen Disziplinen umfassendes Know-how erfordert. Dafür braucht man ein Team aus Fachleuten. Für die Parameterauswahl und die Mustererkennung beziehungsweise die Bestimmung der Anomalien muss man das physikalische Gesamtsystem verstehen. Außerdem braucht es ein tiefes Verständnis für alle Sensortypen und ihre Funktionsweise, um die passende höhere Mathematik und selbstlernende Algorithmen zu wählen. Wir haben den großen Vorteil, hauseigene Sensor- und Analog- wie auch MCU-Embedded-Spezialisten in der Projektgruppe zu haben. Außerdem konnten wir sehr von den vorherigen Forschungsarbeiten unserer Partnerhochschulen profitieren sowie von den Spezialisten in unserem Third-Party-Hardware- und -Software-Netzwerk, wie Knowtion, ein Spezialist für Sensorfusion und automatische Datenanalyse.

eli: Danke für das Gespräch.

Rutronik Elektronische Bau-
elemente GmbH,
Industriestraße 2,
75228 Ispringen,
Tel. 07231 801-0,
E-Mail rutronik@rutronik.com,
www.rutronik.com
Proof-of-Concept-Entwicklung: Künstliche Intelligenz und Machine Learning auf der Embedded-MCU-Ebene ist keine reine Softwareaufgabe. Das umfassende physikalische und elektrochemische Verständnis der Sensoren und deren Funktion bezüglich Prozessanomalien sind zwingend notwendig, um Predictive Maintenance zu realisieren. Die hierzu notwendigen Ingenieurressourcen stellt Rutronik seinen Kunden zu Verfügung und unterstützt sie bei der Auswahl aufeinander abgestimmter Produkte.
Weitere Downloads zu diesem Artikel
Firmeninformationen
Weitere Beiträge zum Thema MCU, MPU, PLD
Alle Artikel des Ressorts
Weitere Beiträge zum Thema Embedded
Alle Artikel des Ressorts
© elektronikinformationen.de 2019 - Alle Rechte vorbehalten