Schnelle Bereitstellung von Edge-fähigen Anwendungen für das maschinelle Lernen

Maschinelles Lernen (ML) bietet ein enormes Potenzial für die Entwicklung intelligenter Produkte, aber die Komplexität und die Herausforderungen, die mit der Modellierung neuronaler Netze (NN) und der Erstellung von ML-Anwendungen für den Edge-Bereich (Netzwerkrand) verbunden sind, haben die Fähigkeit der Entwickler eingeschränkt, schnell nützliche Lösungen zu entwickeln. Obwohl leicht verfügbare Tools die Erstellung von ML-Modellen im Allgemeinen zugänglicher gemacht haben, sind herkömmliche ML-Entwicklungsverfahren nicht auf die besonderen Anforderungen von Lösungen für das Internet der Dinge (IoT), die Automobilindustrie, industrielle Systeme und andere eingebettete Anwendungen ausgelegt.

Dieser Artikel bietet eine kurze Einführung in die NN-Modellierung. Anschließend wird eine umfassende ML-Plattform von NXP Semiconductors vorgestellt und beschrieben, mit der Entwickler effizienter für den Netzwerkrand ausgelegte ML-Anwendungen bereitstellen können.

Ein kurzer Überblick über die NN-Modellierung

ML-Algorithmen bieten Entwicklern eine völlig neue Option für die Anwendungsentwicklung. Anstatt Softwarecode zu schreiben, der explizit für die Lösung von Problemen wie der Bildklassifizierung gedacht ist, trainieren Entwickler NN-Modelle, indem sie eine Reihe von Daten wie Bilder vorlegen, die mit dem tatsächlichen Namen (oder der Klasse) der im Bild enthaltenen Entität versehen sind. Der Trainingsprozess verwendet eine Vielzahl von Methoden, um die Parameter eines Modells, d. h. die Gewichte und die Bias-Werte für jedes Neuron bzw. jede Schicht, zu berechnen, so dass das Modell eine einigermaßen genaue Vorhersage der richtigen Klasse eines Eingangsbildes liefern kann (Abbildung 1).

Abbildung 1: NNs wie dieses vollständig verknüpfte Netz klassifizieren ein Eingabeobjekt anhand von Gewichtungs- und Bias-Parametern, die beim Training festgelegt werden. (Bildquelle: NXP Semiconductors)

ML-Forscher haben eine breite Palette von NN-Architekturen entwickelt, die über das in Abbildung 1 gezeigte allgemeine, vollständig verbundene NN hinausgehen. Bei Anwendungen zur Bildklassifizierung wird beispielsweise typischerweise das Faltungs-NN (CNN) verwendet, eine spezialisierte Architektur, die die Bilderkennung in eine Anfangsphase aufteilt, in der die wichtigsten Merkmale eines Bildes ermittelt werden, gefolgt von einer Klassifizierungsphase, in der die Wahrscheinlichkeit vorhergesagt wird, dass das Bild zu einer von mehreren Klassen gehört, die während des Trainings festgelegt wurden (Abbildung 2).

Abbildung 2: ML-Experten verwenden spezialisierte NN-Architekturen wie dieses neuronale Faltungsnetzwerk (CNN) für bestimmte Aufgaben wie die Bilderkennung. (Bildquelle: NXP Semiconductors)

Obwohl die Auswahl einer geeigneten Modellarchitektur und eines geeigneten Trainingsprogramms bisher auf ML-Experten beschränkt war, hat die Verfügbarkeit zahlreicher Open-Source- und kommerzieller Tools die Modellentwicklung für groß angelegte Einsätze drastisch vereinfacht. Heutzutage können Entwickler Modelle mit ein paar Zeilen Code definieren (Listing 1) und Tools wie den Open-Source-Modellbetrachter Netron verwenden, um eine grafische Darstellung des Modells (Abbildung 3) zur Überprüfung der einzelnen Schichtdefinitionen und -verbindungen zu generieren.

Kopieren
def model_create(shape_in, shape_out):
    from keras.regularizers import l2
    
    tf.random.set_seed(RANDOM_SEED)
 
    model = tf.keras.Sequential()
    model.add(tf.keras.Input(shape=shape_in, name='acceleration'))
    model.add(tf.keras.layers.Conv2D(8, (4, 1), activation='relu'))
    model.add(tf.keras.layers.Conv2D(8, (4, 1), activation='relu'))
    
    model.add(tf.keras.layers.Dropout(0.5))
    
    model.add(tf.keras.layers.MaxPool2D((8, 1), padding='valid'))
    model.add(tf.keras.layers.Flatten())
    
    model.add(tf.keras.layers.Dense(64, kernel_regularizer=l2(1e-4), bias_regularizer=l2(1e-4), activation='relu'))
    model.add(tf.keras.layers.Dropout(0.5))
    model.add(tf.keras.layers.Dense(32, kernel_regularizer=l2(1e-4), bias_regularizer=l2(1e-4), activation='relu'))
    model.add(tf.keras.layers.Dropout(0.5))
    model.add(tf.keras.layers.Dense(shape_out, activation='softmax'))
    model.compile(optimizer='adam', loss='categorical_crossentropy', metrics=['acc'])
    
    return model

Listing 1: Entwickler können NN-Modelle mit nur wenigen Codezeilen definieren. (Code-Quelle: NXP Semiconductors)

Abbildung 3: Diese grafische Darstellung des in Listing 1 definierten Modells wird vom Netron-Viewer generiert und kann dem Entwickler helfen, die Funktion und Verbindung der einzelnen Schichten zu dokumentieren. (Bildquelle: Stephen Evanczuk, Ausführung von Netron für den NXP-Modell-Quellcode in Listing 1)

Für den endgültigen Einsatz entfernen andere Tools die Modellstrukturen, die nur während des Trainings benötigt werden, und führen andere Optimierungen durch, um ein effizientes Inferenzmodell zu erstellen.

Warum die Entwicklung ML-basierter Anwendungen für intelligente Produkte so schwierig war

Das Definieren und Trainieren eines Modells für das IoT oder andere intelligente Produkte folgt einem ähnlichen Arbeitsablauf wie das Erstellen eines Modells für maschinelle Lernanwendungen im Unternehmensmaßstab. Abgesehen von dieser Ähnlichkeit bringt die Entwicklung von ML-Anwendungen für den Edge-Bereich jedoch zahlreiche zusätzliche Herausforderungen mit sich. Neben der Modellentwicklung stehen die Entwickler vor der bekannten Herausforderung, die Hauptanwendung zu entwickeln, die für den Betrieb ihres Mikrocontroller(MCU)-basierten Produkts erforderlich ist. Um ML an den Netzwerkrand zu bringen, müssen daher zwei miteinander verknüpfte Arbeitsabläufe verwaltet werden (Abbildung 4).

Abbildung 4: Die Entwicklung einer ML-basierten Anwendung für den Edge-Bereich erweitert den typischen Arbeitsablauf bei der Entwicklung eingebetteter MCUs um einen ML-Arbeitsablauf, der zum Trainieren, Validieren und Bereitstellen eines ML-Modells erforderlich ist. (Bildquelle: NXP Semiconductors)

Obwohl der Arbeitsablauf des MCU-Projekts den Entwicklern von Embedded-Systemen vertraut ist, kann das ML-Projekt zusätzliche Anforderungen an die MCU-basierte Anwendung stellen, da die Entwickler an der Erstellung eines optimierten ML-Inferenzmodells arbeiten. Tatsächlich wirkt sich das ML-Projekt dramatisch auf die Anforderungen an das eingebettete Gerät aus. Die hohe Rechenlast und der Speicherbedarf, die in der Regel mit der Ausführung von Modellen verbunden sind, können die Ressourcen von Mikrocontrollern übersteigen, die im IoT und in intelligenten Produkten verwendet werden. Um den Ressourcenbedarf zu verringern, wenden ML-Experten Techniken wie Modellnetzbeschneidung, Komprimierung, Quantisierung auf niedrigere Präzision oder sogar Ein-Bit-Parameter und Zwischenwerte sowie andere Methoden an.

Selbst mit diesen Optimierungsmethoden können Entwickler jedoch feststellen, dass herkömmliche Mikrocontroller nicht die nötige Leistung für die große Anzahl von mathematischen Operationen haben, die mit ML-Algorithmen verbunden sind. Andererseits könnte ein leistungsstarker Anwendungsprozessor die ML-Rechenlast bewältigen, aber dieser Ansatz könnte zu erhöhten Latenzzeiten und nicht-deterministischen Reaktionen führen, was die Echtzeiteigenschaften des eingebetteten Designs beeinträchtigen würde.

Abgesehen von den Herausforderungen bei der Auswahl der Hardware ist die Bereitstellung optimierter ML-Modelle für den Edge-Bereich mit zusätzlichen Herausforderungen verbunden, die nur bei der Embedded-Entwicklung auftreten. Die große Anzahl von Werkzeugen und Methoden, die für ML-Anwendungen im Unternehmensmaßstab entwickelt wurden, lassen sich möglicherweise nicht gut auf die Anwendungen und Betriebsumgebungen von Embedded-Entwicklern übertragen. Selbst erfahrene Entwickler von eingebetteten Systemen, die ML-basierte Geräte schnell einsetzen wollen, haben oft Schwierigkeiten, aus der Fülle der verfügbaren NN-Modellarchitekturen, Tools, Frameworks und Arbeitsabläufe eine effektive Lösung zu finden.

NXP befasst sich sowohl mit der Hardware-Leistung als auch mit der Modellimplementierung bei der ML-Entwicklung für den Netzwerkrand (Edge-ML). Auf der Hardware-Ebene erfüllen die leistungsstarken Crossover-Mikrocontroller i.MX RT1170 von NXP die umfassenden Leistungsanforderungen von Edge-ML. Um die Vorteile dieser Hardware-Basis voll auszuschöpfen, bieten die ML-Softwareentwicklungsumgebung eIQ (Edge Intelligence) und die Anwendungssoftwarepakete von NXP sowohl unerfahrenen als auch erfahrenen ML-Entwicklern eine effektive Lösung zur Erstellung von für den Netzwerkrand ausgelegten ML-Anwendungen.

Eine effektive Plattform für die Entwicklung von ML-Anwendungen für den Netzwerkrand

Die Crossover-Prozessoren NXP i.MX RT kombinieren die Echtzeitfähigkeit und die geringe Latenz herkömmlicher Embedded-Mikrocontroller mit den Ausführungsfähigkeiten von leistungsstarken Anwendungsprozessoren. Die Crossover-Prozessorserie i.MX RT1170 von NXP integriert einen stromsparenden Arm®-Cortex®-M4- und einen leistungsstarken Arm-Cortex-M7-Prozessor mit einem umfangreichen Satz von Funktionsblöcken und Peripheriekomponenten, die für die Ausführung anspruchsvoller Anwendungen, einschließlich ML-basierter Lösungen in Embedded-Geräten, erforderlich sind (Abbildung 5).

Abbildung 5: Die Crossover-Prozessoren i.MX RT1170 von NXP kombinieren die energieeffizienten Fähigkeiten herkömmlicher Mikrocontroller mit den leistungsstarken Verarbeitungsfähigkeiten von Anwendungsprozessoren. (Bildquelle: NXP Semiconductors)

Die vollständig in die Entwicklungsumgebungen MCUXpresso SDK und Yocto von NXP integrierte NXP-eIQ-Umgebung wurde speziell dafür entwickelt, die Implementierung von Inferenzmodellen auf eingebetteten Systemen mit Mikroprozessoren und Mikrocontrollern von NXP zu erleichtern. Das in der eIQ-Umgebung enthaltene eIQ-Toolkit unterstützt BYOD- (Bring Your Own Data) und BYOM-Workflows (Bring Your Own Model) durch verschiedene Tools, darunter das eIQ-Portal, das eIQ-Model-Tool und Befehlszeilentools (Abbildung 6).

Abbildung 6: Das NXP-eIQ-Toolkit unterstützt BYOD-Entwickler, die ein Modell erstellen müssen, und BYOM-Entwickler, die ihr eigenes, bereits vorhandenes Modell auf einem Zielsystem einsetzen müssen. (Bildquelle: NXP Semiconductors)

Das eIQ-Portal wurde entwickelt, um BYOD-Workflows sowohl für Experten als auch für Entwickler, die neu in der Entwicklung von ML-Modellen sind, zu unterstützen. Es bietet eine grafische Benutzeroberfläche (GUI), die es den Entwicklern erleichtert, jede Phase des Arbeitsablaufs zur Modellentwicklung abzuschließen.

In der Anfangsphase der Entwicklung hilft das Kurator-Tool des eIQ-Portals den Entwicklern, Daten zu importieren, Daten von einer angeschlossenen Kamera zu erfassen oder Daten von einem entfernten Gerät zu erfassen (Abbildung 7).

Abbildung 7: Das Kurator-Tool des eIQ-Portals für Datensätze erleichtert die wichtige Aufgabe der Vorbereitung von Trainingsdaten. (Bildquelle: NXP Semiconductors)

Mit dem Kuratorwerkzeug für Datensätze können die Entwickler jedes Element im Datensatz beschriften, indem sie das gesamte Bild oder nur bestimmte Regionen innerhalb eines bestimmten Begrenzungsrahmens beschriften. Eine Augmentierungsfunktion hilft den Entwicklern, die benötigte Vielfalt in den Datensatz zu bringen, indem sie Bilder unscharf macht, zufälliges Rauschen hinzufügt, Merkmale wie Helligkeit oder Kontrast verändert und andere Methoden anwendet.

In der nächsten Phase unterstützt das eIQ-Portal die Entwickler bei der Auswahl des für die Anwendung am besten geeigneten Modells. Für Entwickler, die sich nicht sicher sind, welchen Modelltyp sie wählen sollen, führt ein Modellauswahlassistent durch den Auswahlprozess, der auf der Art der Anwendung und der Hardwarebasis basiert. Entwickler, die bereits wissen, welche Art von Modell sie benötigen, können ein benutzerdefiniertes Modell auswählen, das mit der eIQ-Installation oder anderen benutzerdefinierten Implementierungen geliefert wird.

Das eIQ-Portal führt die Entwickler durch den nächsten kritischen Trainingsschritt und bietet eine intuitive grafische Benutzeroberfläche zur Änderung der Trainingsparameter und zur Anzeige der Änderungen der Modellvorhersagegenauigkeit bei jedem Trainingsschritt (Abbildung 8).

Abbildung 8: Die Entwickler verwenden das Trainer-Tool des eIQ-Portals, um die Verbesserung der Trainingsgenauigkeit bei jedem Schritt zu beobachten und sie bei Bedarf zu ändern. (Bildquelle: NXP Semiconductors)

Im nächsten Schritt unterstützt das eIQ-Portal-GUI die Entwickler bei der Validierung des Modells. In dieser Phase wird das Modell so konvertiert, dass es auf der Zielarchitektur läuft, um seine tatsächliche Leistung zu ermitteln. Nach Abschluss der Validierung wird auf dem Validierungsbildschirm die Konfusionsmatrix angezeigt - ein grundlegendes ML-Validierungswerkzeug, mit dem Entwickler die tatsächliche Klasse des Eingabeobjekts mit der vom Modell vorhergesagten Klasse vergleichen können (Abbildung 9).

Abbildung 9: Das Validierungstool des eIQ-Portals liefert Entwicklern die Konfusionsmatrix, die sich aus der Ausführung eines Modells auf einer Zielarchitektur ergibt. (Bildquelle: NXP Semiconductors)

Für den endgültigen Einsatz bietet die Umgebung den Entwicklern je nach Prozessor eine Auswahl an Ziel-Inferenzmaschinen, darunter:

• Arm CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network) - Kerne für neuronale Netze, die entwickelt wurden, um die Leistung zu maximieren und den Speicherbedarf von neuronalen Netzen auf Arm-Cortex-M-Prozessorkernen zu minimieren
• Arm NN SDK (Neural Network, Software Development Kit) - eine Reihe von Tools und eine Inferenz-Engine, die, unter anderem, als Brücke zwischen bestehenden neuronalen Netzwerk-Frameworks und Arm-Cortex-A-Prozessoren entwickelt wurde
• DeepViewRT - NXPs proprietäre Inferenz-Engine für die i.MX-RT-Crossover-MCUs
• Glow NN - basiert auf Metas Glow-Compiler (Graph Lowering) und wird von NXP für Arm-Cortex-M-Kerne optimiert, indem Funktionsaufrufe zu CMSIS-NN-Kernen oder der Arm-NN-Bibliothek verwendet werden, sofern verfügbar, andernfalls wird der Code aus der eigenen Bibliothek kompiliert
• ONXX Runtime - Tools von Microsoft Research zur Optimierung der Leistung von Arm-Cortex-A-Prozessoren.
• TensorFlow Lite für Mikrocontroller - eine kleinere Version von TensorFlow Lite, optimiert für die Ausführung von Machine-Learning-Modellen auf i.MX-RT-Crossover-MCUs
• TensorFlow Lite - eine Version von TensorFlow mit Unterstützung für kleinere Systeme

Für BYOM-Workflows können Entwickler das eIQ-Model-Tool verwenden, um direkt zur Modellanalyse und zur Erstellung von Zeitprofilen pro Schicht überzugehen. Sowohl für BYOD- als auch für BYOM-Workflows können Entwickler eIQ-Befehlszeilentools verwenden, die Zugriff auf Toolfunktionen sowie auf eIQ-Funktionen bieten, die nicht direkt über die grafische Benutzeroberfläche verfügbar sind.

Neben den in diesem Artikel beschriebenen Funktionen unterstützt das eIQ-Toolkit eine Reihe weiterer Funktionen, einschließlich Modellkonvertierung und -optimierung, die den Rahmen dieses Artikels bei weitem sprengen würden. Für das Rapid Prototyping von Edge-fähigen ML-Anwendungen können Entwickler jedoch in der Regel schnell durch die Entwicklung und den Einsatz gehen, ohne viele der anspruchsvolleren Funktionen der eIQ-Umgebung nutzen zu müssen. Spezielle Pakete an Anwendungssoftware (App SW) von NXP bieten komplette Anwendungen, die Entwickler zur sofortigen Evaluierung oder als Grundlage für ihre eigenen kundenspezifischen Anwendungen verwenden können.

Schnelle Bewertung der Modellentwicklung mit Anwendungssoftware

Die App SW Packs von NXP bieten eine komplette ML-basierte Anwendung, die produktionsreifen Quellcode, Treiber, Middleware und Tools kombiniert. So bietet beispielsweise das ML State Monitor App SW Pack von NXP eine sofortige ML-basierte Lösung für das häufige Problem, den Zustand komplexer Systeme anhand von Sensoreingaben zu bestimmen (Abbildung 10).

Abbildung 10: Entwickler können App SW Packs von NXP wie das ML State Monitor App SW Pack zur sofortigen Evaluierung oder als Grundlage für die Entwicklung von kundenspezifischem Code verwenden. (Bildquelle: NXP Semiconductors)

Das ML State Monitor App SW Pack implementiert eine Komplettlösung für eine Anwendung, die erkennen soll, wann ein Lüfter in einem von vier Zuständen arbeitet:

• ON
• OFF
• CLOGGED, wenn das Gebläse eingeschaltet ist, aber der Luftstrom behindert wird
• FRICTION, wenn das Gebläse eingeschaltet ist, aber ein oder mehrere Lüfterflügel während des Betriebs auf übermäßige Reibung stoßen

Ebenso wichtig für Modellentwickler ist, dass das ML State Monitor App SW Pack sowohl ML-Modelle als auch einen vollständigen Datensatz mit Beschleunigungsmesswerten eines Lüfters enthält, der in jedem dieser vier Zustände arbeitet.

Entwickler können den Code, die Modelle und die Daten im ML State Monitor App SW Pack studieren, um zu verstehen, wie die Sensordaten verwendet werden, um ein Modell zu trainieren, ein Inferenzmodell zu erstellen und die Inferenz anhand eines Validierungssensordatensatzes zu validieren. Das Jupyter-Notebook ML_State_Monitor.ipynb von NXP, das im App SW Pack enthalten ist, bietet ein sofort einsatzbereites Tool zur Untersuchung des Modellentwicklungs-Workflows, lange bevor die Hardware bereitgestellt wird.

Das Jupyter-Notebook ist eine interaktive, browserbasierte Python-Ausführungsplattform, die es Entwicklern ermöglicht, die Ergebnisse der Ausführung von Python-Code sofort zu sehen. Die Ausführung eines Jupyter-Notebooks generiert einen Python-Codeblock, unmittelbar gefolgt von den Ergebnissen der Ausführung dieses Codeblocks. Diese Ergebnisse sind nicht einfach statische Anzeigen, sondern die tatsächlichen Ergebnisse, die durch die Ausführung des Codes erzielt werden. Wenn Entwickler beispielsweise das Jupyter-Notebook ML_State_Monitor.ipynb von NXP ausführen, können sie sofort eine Zusammenfassung des Eingabedatensatzes anzeigen (Abbildung 11).

Abbildung 11: Mit dem Jupyter-Notebook ML_State_Monitor.ipynb von NXP können Entwickler sich interaktiv durch den Workflow zur Entwicklung neuronaler Netzwerkmodelle arbeiten und dabei die im ML State Monitor App SW Pack bereitgestellten Trainingsdaten betrachten. [Hinweis: Der Code wurde hier aus Darstellungsgründen gekürzt] (Bildquelle: Stephen Evanczuk, unter Verwendung des Jupyter-Notebooks ML_State_Monitor.ipynb von NXP)

Der nächste Abschnitt des Codes im Notebook bietet dem Benutzer eine grafische Darstellung der Eingabedaten in Form von separaten Diagrammen für Zeitfolge und Frequenz (Abbildung 12).

Abbildung 12: Das Jupyter-Notebook bietet Entwicklern Zeitreihen- und Häufigkeitsanzeigen des Lüfterzustands-Datensatzes (OFF: grün; ON: rot; CLOGGED: blau; FRICTION: gelb). [Hinweis: Der Code wurde aus Darstellungsgründen gekürzt] (Bildquelle: Stephen Evanczuk, unter Verwendung des Jupyter-Notebooks ML_State_Monitor.ipynb von NXP)

Weitere Codeabschnitte dienen der weiteren Datenanalyse, Normalisierung, Formgebung und anderen Vorbereitungen, bis die Codeausführung dieselbe Funktionsdefinition für die Modellerstellung, model_create(), erreicht, die bereits in Listing 1 gezeigt wurde. Der nächste Codeabschnitt führt diese Funktion model_create() aus und gibt eine Zusammenfassung zur schnellen Validierung aus (Abbildung 13).

Abbildung 13: Das Jupyter-Notebook ML_State_Monitor.ipynb von NXP erstellt das Modell (wie in Listing 1 gezeigt) und zeigt die Modellzusammenfassung an. (Bildquelle: Stephen Evanczuk, unter Verwendung des Jupyter-Notebooks ML_State_Monitor.ipynb von NXP)

Nach einem Codeabschnitt für das Training und die Evaluierung des Modells zeigt das Jupyter-Notebook ML_State_Monitor.ipynb jede Konfusionsmatrix für den vollständigen Datensatz, den Trainingsdatensatz und den Validierungsdatensatz (eine Teilmenge des Datensatzes, die vom Trainingsdatensatz ausgeschlossen ist) an. In diesem Fall zeigt die Konfusionsmatrix für den gesamten Datensatz eine gute Genauigkeit mit einigen Fehlern, vor allem dort, wo das Modell einen kleinen Prozentsatz von Datensätzen als im ON-Zustand befindlich verwechselt, obwohl sie sich eigentlich im CLOGGED-Zustand befinden, wie im Originaldatensatz vermerkt (Abbildung 14).

Abbildung 14: Entwickler können Konfusionsmatrizen wie diese für den gesamten Datensatz anzeigen. (Bildquelle: Stephen Evanczuk, unter Verwendung des Jupyter-Notebooks ML_State_Monitor.ipynb von NXP)

In einem späteren Codeabschnitt wird das Modell in verschiedene Modelltypen und -formate exportiert, die von den verschiedenen von der eIQ-Entwicklungsumgebung unterstützten Inferenzmaschinen verwendet werden (Abbildung 15).

Abbildung 15: Das Jupyter-Notebook ML_State_Monitor.ipynb von NXP zeigt, wie Entwickler ihr trainiertes Modell in verschiedenen Modelltypen und -formaten speichern können. (Bildquelle: Stephen Evanczuk, unter Verwendung des Jupyter-Notebooks ML_State_Monitor.ipynb von NXP)

Die Wahl der Inferenzmaschine kann für die Erfüllung bestimmter Leistungsanforderungen von entscheidender Bedeutung sein. Für diese Anwendung hat NXP die Modellgröße, die Codegröße und die Inferenzzeit (Zeit, die benötigt wird, um die Inferenz für ein einzelnes Eingabeobjekt abzuschließen) gemessen, wenn das Modell auf mehrere Inferenz-Engines ausgerichtet ist, von denen eine mit 996 Megahertz (MHz) und eine mit 156 MHz läuft (Abbildungen 16 und 17).

Abbildung 16: Die Wahl des Modelltyps kann sich drastisch auf die Modellgröße auswirken, auch wenn die hier gezeigten drastischen Unterschiede bei größeren Modellen möglicherweise nicht zutreffen. (Bildquelle: NXP Semiconductors)

Abbildung 17: Die Inferenzzeit kann sich bei der Auswertung eines Eingabeobjekts erheblich unterscheiden, wenn es aus dem RAM oder dem Flash-Speicher geladen wird oder wenn der Prozessor mit einer höheren Frequenz von 996 MHz gegenüber 156 MHz betrieben wird. (Bildquelle: NXP Semiconductors)

NXP weist darauf hin, dass in dieser Beispielanwendung ein sehr kleines Modell verwendet wird, so dass die in diesen Abbildungen gezeigten recht deutlichen Unterschiede bei einem größeren Modell, das für komplexe Klassifizierungen verwendet wird, wesentlich weniger ausgeprägt sein könnten.

Aufbau einer Systemlösung für die Zustandsüberwachung

Neben dem Jupyter-Notebook für die interaktive Erkundung des Modellentwicklungs-Workflows bietet das NXP ML State Monitoring App SW Pack den vollständigen Quellcode für die Implementierung des Designs auf dem Evaluierungsboard MIMXRT1170-EVK von NXP an. Das Evaluierungsboard basiert auf einer Crossover-MCU MIMXRT1176DVMAA von NXP und bietet eine umfassende Hardwareplattform, die mit zusätzlichem Speicher und mehreren Schnittstellen ausgestattet ist (Abbildung 18).

Abbildung 18: Das Evaluierungsboard MIMXRT1170-EVK von NXP bietet eine umfassende Hardware-Plattform für die Entwicklung von Anwendungen auf Basis der Crossover-MCU der Serie i.MX RT1170 von NXP. (Bildquelle: NXP Semiconductors)

Entwickler können die NXP-Lüfterzustandsanwendung verwenden, um den Zustand eines Lüfters vorherzusagen, indem sie das Evaluierungsboard MIMXRT1170-EVK mit einem optionalen Sensorboard FRDM-STBC-AGM01 von NXP, einem Arduino-Shield und einem geeigneten bürstenlosen 5-Volt-Gleichstromlüfter wie dem 4468 von Adafruit kombinieren (Abbildung 19).

Abbildung 19: Entwickler können die Beispielanwendung für Lüfterzustände von NXP mit einem einfachen Stack testen, der auf dem Evaluierungsboard MIMXRT1170-EVK aufgebaut ist. (Bildquelle: NXP Semiconductors)

Mit der integrierten Entwicklungsumgebung (IDE) MCUXpresso können Entwickler die Anwendung so konfigurieren, dass sie einfach die Lüfterzustandsdaten erfasst und speichert oder sofort eine Inferenz auf die erfassten Daten mit Hilfe einer TensorFlow-Inferenz-Engine, einer DeepViewRT-Inferenz-Engine oder einer Glow-Inferenz-Engine durchführt (Listing 2).

Kopieren
/* Action to be performed */
#define SENSOR_COLLECT_LOG_EXT                  1   // Collect and log data externally
#define SENSOR_COLLECT_RUN_INFERENCE            2   // Collect data and run inference
 
/* Inference engine to be used */
#define SENSOR_COLLECT_INFENG_TENSORFLOW        1   // TensorFlow
#define SENSOR_COLLECT_INFENG_DEEPVIEWRT        2   // DeepViewRT
#define SENSOR_COLLECT_INFENG_GLOW              3   // Glow
 
/* Data format to be used to feed the model */
#define SENSOR_COLLECT_DATA_FORMAT_BLOCKS       1   // Blocks of samples
#define SENSOR_COLLECT_DATA_FORMAT_INTERLEAVED  2   // Interleaved samples
 
 
/* Parameters to be configured by the user: */
/* Configure the action to be performed */
#define SENSOR_COLLECT_ACTION                   SENSOR_COLLECT_RUN_INFERENCE
 
#if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
/* If the SD card log is not enabled the sensor data will be streamed to the terminal */
#define SENSOR_COLLECT_LOG_EXT_SDCARD           1   // Redirect the log to SD card, otherwise print to console

Listing 2: Entwickler können die Beispielanwendung NXP ML State Monitor einfach konfigurieren, indem sie die in der Header-Datei sensor_collect.h enthaltenen Defines ändern. (Code-Quelle: NXP Semiconductors)

Die Anwendung arbeitet mit einem unkomplizierten Prozessablauf. Die Hauptroutine in main.c erzeugt eine Aufgabe namens MainTask, die sich im Modul sensor_collect.c befindet.

Kopieren
void MainTask(void *pvParameters)
{
    status_t status = kStatus_Success;
 
    printf("MainTask started\r\n");
 
#if !SENSOR_FEED_VALIDATION_DATA
    status = SENSOR_Init();
    if (status != kStatus_Success)
    {
        goto main_task_exit;
    }
#endif
 
    g_sensorCollectQueue = xQueueCreate(SENSOR_COLLECT_QUEUE_ITEMS, sizeof(sensor_data_t));
    if (NULL == g_sensorCollectQueue)
    {
        printf("collect queue create failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
 
#if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
    uint8_t captClassLabelIdx;
    CAPT_Init(&captClassLabelIdx, &g_SensorCollectDuration_us, &g_SensorCollectDuration_samples);
    g_SensorCollectLabel = labels[captClassLabelIdx];
 
    if (xTaskCreate(SENSOR_Collect_LogExt_Task, "SENSOR_Collect_LogExt_Task", 4096, NULL, configMAX_PRIORITIES - 1, NULL) != pdPASS)
    {
        printf("SENSOR_Collect_LogExt_Task creation failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
#elif SENSOR_COLLECT_ACTION == SENSOR_COLLECT_RUN_INFERENCE
    if (xTaskCreate(SENSOR_Collect_RunInf_Task, "SENSOR_Collect_RunInf_Task", 4096, NULL, configMAX_PRIORITIES - 1, NULL) != pdPASS)
    {
        printf("SENSOR_Collect_RunInf_Task creation failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
#endif

Listing 3: In der Beispielanwendung NXP ML State Monitor ruft MainTask einen Subtask auf, um Daten zu erfassen oder Inferenzen durchzuführen. (Code-Quelle: NXP Semiconductors)

MainTask führt verschiedene Initialisierungsaufgaben durch, bevor eine von zwei Unteraufgaben gestartet wird, je nachdem, was der Benutzer in sensor_collect.h definiert hat:

• wenn SENSOR_COLLECT_ACTION auf SENSOR_COLLECT_LOG_EXT gesetzt ist, startet MainTask die Unteraufgabe SENSOR_Collect_LogExt_Task(), die Daten sammelt und auf der SD-Karte speichert, falls konfiguriert
• wenn SENSOR_COLLECT_ACTION auf SENSOR_COLLECT_RUN_INFERENCE gesetzt ist, startet MainTask die Unteraufgabe SENSOR_Collect_RunInf_Task(), die die in sensor_collect.h definierte Inferenz-Engine (Glow, DeepViewRT oder TensorFlow) gegen die gesammelten Daten laufen lässt und, wenn SENSOR_EVALUATE_MODEL definiert ist, die resultierende Leistung und Klassifikationsvorhersage anzeigt

Kopieren
if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
void SENSOR_Collect_LogExt_Task(void *pvParameters)
{
[code deleted for simplicity]
    while (1)
    {
[code deleted for simplicity]
            bufSizeLog = snprintf(buf, bufSize, "%s,%ld,%d,%d,%d,%d,%d,%d,%d\r\n", g_SensorCollectLabel, (uint32_t)(sensorData.ts_us/1000),
                    sensorData.rawDataSensor.accel[0], sensorData.rawDataSensor.accel[1], sensorData.rawDataSensor.accel[2],
                    sensorData.rawDataSensor.mag[0], sensorData.rawDataSensor.mag[1], sensorData.rawDataSensor.mag[2],
                    sensorData.temperature);
 
#if SENSOR_COLLECT_LOG_EXT_SDCARD
                SDCARD_CaptureData(sensorData.ts_us, sensorData.sampleNum, g_SensorCollectDuration_samples, buf, bufSizeLog);
#else
                printf("%.*s", bufSizeLog, buf);
[code deleted for simplicity]
    }
 
    vTaskDelete(NULL);
}
#elif SENSOR_COLLECT_ACTION == SENSOR_COLLECT_RUN_INFERENCE
[code deleted for simplicity]
 
void SENSOR_Collect_RunInf_Task(void *pvParameters)
{
[code deleted for simplicity]
    while (1)
    {
[code deleted for simplicity]
                /* Run Inference */
                tinf_us = 0;
                SNS_MODEL_RunInference((void*)g_clsfInputData, sizeof(g_clsfInputData), (int8_t*)&predClass, &tinf_us, SENSOR_COLLECT_INFENG_VERBOSE_EN);
 
[code deleted for simplicity]
#if SENSOR_EVALUATE_MODEL
                /* Evaluate performance */
                validation.predCount++;
                if (validation.classTarget == predClass)
                {
                    validation.predCountOk++;
                }
                PRINTF("\rInference %d?%d | t %ld us | count: %d/%d/%d | %s      ",
                       validation.classTarget, predClass, tinf_us, validation.predCountOk,
                       validation.predCount, validation.predSize, labels[predClass]);
 
                tinfTotal_us += tinf_us;
                if (validation.predCount >= validation.predSize)
                {
                    printf("\r\nPrediction Accuracy for class %s %.2f%%\r\n", labels[validation.classTarget],
                            (float)(validation.predCountOk * 100)/validation.predCount);
                    printf("Average Inference Time %.1f (us)\r\n", (float)tinfTotal_us/validation.predCount);
                    tinfTotal_us = 0;
                }
#endif
 
    }
 
exit_task:
    vTaskDelete(NULL);
}
#endif  /* SENSOR_COLLECT_ACTION */

Listing 4: Die Beispielanwendung NXP ML State Monitor demonstriert das grundlegende Entwurfsmuster für die Erfassung von Sensordaten und die Ausführung der ausgewählten Inferenzmaschine auf den erfassten Daten. (Code-Quelle: NXP Semiconductors)

Da das NXP ML State Monitor App SW Pack den vollständigen Quellcode zusammen mit einem kompletten Satz erforderlicher Treiber und Middleware bereitstellt, können Entwickler die Anwendung problemlos um zusätzliche Funktionen erweitern oder sie als Ausgangspunkt für ihre eigene Entwicklung nutzen.

Fazit

Die Implementierung von ML in intelligenten Produkten in IoT- und anderen Anwendungen am Netzwerkrand kann eine Reihe leistungsstarker Funktionen bereitstellen, doch haben Entwickler oft Schwierigkeiten, ML-Tools und -Methoden anzuwenden, die für Anwendungen im Unternehmensmaßstab entwickelt wurden. Mit der Verfügbarkeit einer NXP-Entwicklungsplattform, die Crossover-Prozessoren und spezialisierte Modellentwicklungssoftware umfasst, können sowohl ML-Experten als auch Entwickler mit wenig oder gar keiner ML-Erfahrung ML-Anwendungen effektiver erstellen, die speziell auf die Anforderungen an eine effiziente Edge-Performance zugeschnitten sind.