Szybkie wdrażanie aplikacji wykorzystujących uczenie maszynowe współpracujących z urządzeniami brzegowymi

Uczenie maszynowe (ML) oferuje ogromny potencjał tworzenia inteligentnych produktów, jednak złożoność i wyzwania związane z modelowaniem sieci neuronowych (NN) i tworzeniem aplikacji ML dla urządzeń brzegowych ograniczają możliwości deweloperów w zakresie szybkiej realizacji przydatnych rozwiązań. Chociaż łatwo dostępne narzędzia sprawiły, że tworzenie modeli ML jest ogólnie łatwiejsze, konwencjonalne praktyki rozwojowe w zakresie ML nie zostały przemyślane pod kątem wymagań rozwiązań dla Internetu rzeczy (IoT), motoryzacji, układów przemysłowych czy innych rozwiązań wbudowanych.

Niniejszy artykuł zawiera krótkie wprowadzenie do modelowania sieci neuronowych (NN). W dalszej części przedstawia i opisuje, jak korzystać z kompleksowej platformy uczenia maszynowego (ML) firmy NXP Semiconductors, która pozwala deweloperom na bardziej efektywne dostarczanie gotowych rozwiązań ML.

Szybki przegląd modelowania sieci neuronowych (NN)

Algorytmy uczenia maszynowego (ML) zapewniają deweloperom radykalnie odmienną opcję tworzenia aplikacji. Zamiast pisać kod oprogramowania przeznaczony do rozwiązywania problemów, takich jak klasyfikacja obrazów, deweloperzy uczą modele sieci neuronowych, przedstawiając zbiór danych, takich jak obrazy podpisane rzeczywistą nazwą (lub klasą) obiektu zawartego w obrazie. W procesie uczenia wykorzystuje się różne metody obliczania parametrów modelu, takich jak wagi i wartości odchyleń dla poszczególnych neuronów i warstw, umożliwiając modelowi wykonywanie dość dokładnej predykcji prawidłowej klasy obrazu wejściowego (ilustracja 1).

Ilustracja 1: w pełni połączona sieć neuronowa (NN), która klasyfikuje obiekty wejściowe z użyciem parametrów wagi i odchylenia ustawionych podczas uczenia. (Źródło ilustracji: NXP Semiconductors)

Badacze uczenia maszynowego rozwinęli szeroką gamę architektur sieci neuronowych wykraczających poza tę ogólną, w pełni połączoną sieć neuronową przedstawioną na ilustracji 1. Na przykład aplikacje do klasyfikacji obrazów zazwyczaj wykorzystują konwolucyjną sieć neuronową (CNN), czyli wyspecjalizowaną architekturę, która dzieli rozpoznawanie obrazu na fazę początkową, w ramach której znajdowane są kluczowe cechy obrazu, a następnie fazę klasyfikacji, w której przewiduje się prawdopodobieństwo, że należy on do jednej z kilku klas zidentyfikowanych podczas uczenia (ilustracja 2).

Ilustracja 2: eksperci uczenia maszynowego wykorzystują wyspecjalizowane architektury sieci neuronowych, takich jak przedstawiona konwolucyjna sieć neuronowa (CNN) do określonych zadań, takich jak rozpoznawanie obrazów. (Źródło ilustracji: NXP Semiconductors)

Chociaż wybór odpowiedniej architektury modelu i schematu uczenia ograniczono do ekspertów uczenia maszynowego (ML), dostępność wielu narzędzi otwartoźródłowych i komercyjnych znacznie uprościła opracowywanie modeli dla wdrożeń na dużą skalę. Obecnie deweloperzy mogą definiować modele za pomocą kilku linijek kodu (listing 1) i wykorzystując narzędzia, takie jak otwartoźródłowa przeglądarka modeli Netron do generowania graficznej reprezentacji modelu (ilustracja 3) w celu sprawdzenia definicji poszczególnych warstw i połączeń.

Kopiuj
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: deweloperzy mogą definiować modele sieci neuronowych przy użyciu zaledwie kilku linijek kodu. (Źródło kodu: NXP Semiconductors)

Ilustracja 3: wygenerowana w przeglądarce Netron graficzna reprezentacja modelu zdefiniowanego w listingu 1 może pomóc deweloperowi w udokumentowaniu funkcji i połączeń poszczególnych warstw. (Źródło ilustracji: Stephen Evanczuk, uruchamianie przeglądarki Netron na kodzie źródłowym modelu NXP z listingu 1)

W celu ostatecznego wdrożenia inne narzędzia usuwają struktury modelu wymagane tylko podczas uczenia i przeprowadzają inne optymalizacje w celu stworzenia wydajnego modelu wnioskowania.

Dlaczego tworzenie aplikacji opartych na uczeniu maszynowym (ML) dla inteligentnych produktów było tak trudne?

Definiowanie i trenowanie modelu dla Internetu rzeczy (IoT) lub innych inteligentnych produktów odbywa się zgodnie z podobnym przepływem pracy, takim jak tworzenie modelu dla aplikacji wykorzystujących uczenie maszynowe w skali korporacyjnej. Jednak poza tym podobieństwem tworzenie aplikacji uczenia maszynowego (ML) dla urządzeń brzegowych wiąże się z wieloma dodatkowymi wyzwaniami. Wraz z opracowywaniem modeli projektanci stają przed znanymi wyzwaniami związanymi z opracowaniem głównej aplikacji wymaganej do uruchomienia produktu opartego na mikrokontrolerze MCU. W rezultacie przeniesienie uczenia maszynowego do urządzenia brzegowego wymaga zarządzania dwoma powiązanymi przepływami pracy (ilustracja 4).

Ilustracja 4: opracowywanie aplikacji brzegowej opartej na uczeniu maszynowym (ML) rozszerza typowy deweloperski przepływ pracy mikrokontrolera MCU o przepływ pracy ML wymagany do trenowania, walidacji i wdrażania modelu ML. (Źródło ilustracji: NXP Semiconductors)

Deweloperzy pracujący nad układami wbudowanymi znają przepływ pracy charakterystyczny dla mikrokontrolera MCU, jednak wykorzystanie uczenia maszynowego (ML) może przynieść ze sobą dodatkowe wymagania w stosunku do aplikacji opartej na mikrokontrolerze MCU, gdyż deweloperzy będą pracować nad utworzeniem zoptymalizowanego modelu wnioskowania ML. W rzeczywistości projekt ML dramatycznie wpływa na wymagania urządzenia wbudowanego. Duże obciążenia obliczeniowe i wymagania dotyczące pamięci, zwykle wiążące się z realizacją modeli, mogą przekraczać zasoby mikrokontrolerów stosowanych w produktach IoT i produktach inteligentnych. Aby zmniejszyć wymagania dotyczące zasobów, eksperci ML stosują na sieciach modeli różne techniki, takie jak przycinanie, kompresja, kwantyzacja z niższą precyzją, a nawet parametry jednobitowe i wartości pośrednie (i nie tylko).

Jednak nawet przy zastosowaniu wspomnianych metod optymalizacji deweloperzy wciąż mogą stwierdzić, że parametry działania konwencjonalnych mikrokontrolerów są niewystarczające do obsługi dużej liczby operacji matematycznych związanych z algorytmami uczenia maszynowego. Z drugiej strony użycie wysokowydajnego procesora aplikacji może obsłużyć obciążenia obliczeniowe uczenia maszynowego, jednak takie podejście może skutkować zwiększonymi opóźnieniami i niedeterministycznymi odpowiedziami, pogarszając charakterystykę czasową ich rzeczywistego wbudowanego projektu.

Oprócz wyzwań związanych z wyborem sprzętu, opracowanie zoptymalizowanych modeli ML dla urządzeń brzegowych wiąże się z dodatkowymi wyzwaniami, charakterystycznymi dla rozwoju układów wbudowanych. Ogromna liczba narzędzi i metod opracowanych zastosowań uczenia maszynowego na skalę korporacyjną może nie być dobrze skalowalna w przypadku aplikacji i środowiska pracy dewelopera pracującego nad układem wbudowanym. Nawet doświadczeni deweloperzy układów wbudowanych, którzy spodziewają się szybkiego wdrożenia urządzeń opartych na uczeniu maszynowym, mogą mieć trudności ze znalezieniem skutecznego rozwiązania wśród wielu dostępnych architektur, narzędzi, struktur i przepływów pracy modeli sieci neuronowych.

Firma NXP zajmuje się zarówno parametrami działania sprzętu, jak i aspektami implementacji modelu w rozwoju rozwiązań wykorzystujących uczenie maszynowe w środowisku brzegowym. Na poziomie sprzętowym wysokie parametry działania mikrokontrolera MCU typu crossover i.MX RT1170 firmy NXP spełniają rozbudowane wymagania wydajnościowe rozwiązań wykorzystujących uczenie maszynowe w środowisku brzegowym. Aby w pełni wykorzystać tę bazę sprzętową, firma NXP zaoferowała środowisko rozwojowe oprogramowania ML eIQ (edge intelligence) i pakiety oprogramowania aplikacji, które stanowią skuteczne rozwiązanie do tworzenia gotowych aplikacji uczenia maszynowego zarówno dla niedoświadczonych, jak i doświadczonych deweloperów ML.

Efektywna platforma do tworzenia aplikacji uczenia maszynowego gotowych do użycia na urządzeniach brzegowych

Procesory typu crossover i.MX RT firmy NXP łączą w sobie odpowiedź o niskiej latencji w czasie rzeczywistym z użyciem tradycyjnych wbudowanych mikrokontrolerów z możliwościami wykonawczymi wysokowydajnych procesorów aplikacyjnych. Do serii procesorów i.MX RT1170 typu crossover firmy NXP należy energooszczędny procesor ARM® Cortex®-M4 oraz wysokowydajny procesor Arm Cortex-M7 z rozbudowanym zestawem bloków funkcjonalnych i urządzeń peryferyjnych potrzebnych do uruchamiania wymagających aplikacji, w tym rozwiązań opartych na uczeniu maszynowym w urządzeniach wbudowanych (ilustracja 5).

Ilustracja 5: procesory i.MX RT1170 typu crossover firmy NXP łączą energooszczędność znaną z konwencjonalnych mikrokontrolerów z możliwościami wysokowydajnego przetwarzania procesorów aplikacyjnych. (Źródło ilustracji: NXP Semiconductors)

Środowisko eIQ firmy NXP w pełni zintegrowane ze środowiskami programistycznymi MCUXpresso SDK i Yocto firmy NXP, zostało zaprojektowane specjalnie w celu ułatwienia implementacji modeli wnioskowania w układach wbudowanych zbudowanych z mikroprocesorów i mikrokontrolerów NXP. Zawarty w środowisku eIQ zestaw narzędzi eIQ Toolkit obsługuje przepływy pracy dostarczania własnych danych (BYOD) i dostarczania własnych modeli (BYOM) za pomocą kilku narzędzi, w tym Portalu eIQ, narzędzia do tworzenia modeli eIQ Model Tool i narzędzi wiersza poleceń (ilustracja 6).

Ilustracja 6: zestaw narzędzi eIQ Toolkit opracowany przez firmę NXP wspiera deweloperów pracujących w trybie dostarczania własnych danych (BYOD), którzy muszą stworzyć model, oraz pracujących w trybie dostarczania własnych modeli (BYOM), którzy muszą wdrożyć własny istniejący model w systemie docelowym. (Źródło ilustracji: NXP Semiconductors)

Portal eIQ został zaprojektowany do obsługi przepływów pracy w trybie dostarczania własnych danych (BYOD) zarówno dla ekspertów, jak i deweloperów, którzy dopiero zaczynają opracowywać modele uczenia maszynowego (ML). Zapewnia graficzny interfejs użytkownika (GUI), który pomaga łatwiej ukończyć każdy etap przepływu pracy w ramach opracowywania modelu.

Na początkowym etapie rozwoju, narzędzie do zarządzania zbiorem danych z Portalu eIQ pomaga deweloperom w imporcie danych, przechwytywaniu ich z podłączonej kamery lub z urządzenia zdalnego (ilustracja 7).

Ilustracja 7: narzędzie do zarządzania zbiorem danych z Portalu eIQ ułatwia kluczowe zadanie przygotowania danych szkoleniowych. (Źródło ilustracji: NXP Semiconductors)

Użycie narzędzia do zarządzania zbiorem danych pozwala deweloperom dodawać oznaczenia lub etykiety do poszczególnych elementów w zbiorze danych, oznaczając etykietą cały obraz lub tylko konkretne regiony zawarte w określonej ramce ograniczającej. Funkcje rozszerzeń pomagają deweloperom zapewnić niezbędną różnorodność zbioru danych poprzez rozmycie obrazów, dodanie losowego szumu, zmianę cech, takich jak jasność lub kontrast oraz inne metody.

W kolejnej fazie Portal eIQ pomaga deweloperom wybrać typ modelu najlepiej dopasowany do zastosowania. Deweloperów, którzy nie mają pewności co do typu modelu, kreator wyboru modelu prowadzi przez proces wyboru w oparciu o typ zastosowania i bazę sprzętową. Deweloperzy, którzy już wiedzą, jakiego typu modelu potrzebują, mogą wybrać niestandardowy model dostarczony z instalacją eIQ lub inne niestandardowe implementacje.

Portal eIQ prowadzi deweloperów przez kolejny krytyczny etap szkolenia, zapewniając intuicyjny graficzny interfejs użytkownika (GUI) do modyfikowania parametrów szkolenia i przeglądania zmian w dokładności przewidywania modelu na każdym etapie szkolenia (ilustracja 8).

Ilustracja 8: deweloperzy używają narzędzia do trenowania z Portalu eIQ, aby obserwować poprawę dokładności szkolenia na każdym kroku i modyfikować ją w razie potrzeby. (Źródło ilustracji: NXP Semiconductors)

W kolejnym kroku interfejs GUI Portalu eIQ pomaga deweloperom w walidacji modelu. Na tym etapie model jest konwertowany w taki sposób, aby mógł działać w architekturze docelowej, co pozwala określić jego rzeczywiste parametry działania. Po zakończeniu walidacji na ekranie walidacji wyświetlana jest macierz pomyłek - podstawowe narzędzie do walidacji uczenia maszynowego, które umożliwia deweloperom porównywanie rzeczywistej klasy obiektu wejściowego z klasą przewidywaną przez model (ilustracja 9).

Ilustracja 9: w narzędziu do walidacji Portalu eIQ deweloperzy mają do dyspozycji macierz pomyłek wygenerowaną po uruchomieniu modelu na docelowej architekturze. (Źródło ilustracji: NXP Semiconductors)

Podczas ostatecznego wdrożenia deweloperzy mają do dyspozycji wachlarz docelowych aparatów wnioskowania w zależności od procesora, m.in.:

• Arm CMSIS-NN (wspólny standard interfejsu oprogramowania mikrokontrolerów, sieci neuronowe) jądra sieci neuronowych opracowane w celu maksymalizacji parametrów działania i minimalizacji zużycia pamięci przez sieci neuronowe na rdzeniach procesorów Arm Cortex-M
• Arm NN SDK (sieci neuronowe, zestaw rozwojowy oprogramowania) - zestaw narzędzi i aparat wnioskowania zaprojektowane do łączenia między innymi istniejących struktur sieci neuronowych z procesorami Arm Cortex-A
• DeepViewRT - zastrzeżony aparat wnioskowania firmy NXP dla mikrokontrolerów i.MX RT typu crossover
• Glow NN - oparty na kompilatorze Glow firmy Meta (redukującym grafy) i zoptymalizowany przez firmę NXP dla rdzeni Arm Cortex-M przy użyciu odwołań funkcji do jąder CMSIS-NN lub biblioteki Arm NN, jeśli jest dostępna, w przeciwnym razie przez kompilację kodu z własnej biblioteki natywnej
• ONXX Runtime - narzędzia firmy Microsoft Research zaprojektowane w celu optymalizacji wydajności procesorów Arm Cortex-A.
• TensorFlow Lite for Microcontrollers - uproszczona wersja TensorFlow Lite, zoptymalizowana pod kątem uruchamiania modeli uczenia maszynowego na mikrokontrolerach i.MX RT typu crossover
• TensorFlow Lite - wersja TensorFlow zapewniająca wsparcie dla mniejszych systemów

W przypadku przepływów pracy w trybie dostarczania własnych modeli (BYOM) deweloperzy mogą użyć narzędzia do tworzenia modeli eIQ Model Tool, aby przejść bezpośrednio do analizy modelu i profilowania czasowego dla poszczególnych warstw. Zarówno w przypadku przepływów pracy w trybie dostarczania własnych danych (BYOD), jak i dostarczanie własnych modeli (BYOM), deweloperzy mogą używać narzędzi wiersza poleceń eIQ, które zapewniają dostęp do funkcji narzędzi, a także funkcji eIQ niedostępnych bezpośrednio przez graficzny interfejs użytkownika.

Oprócz funkcji opisanych w niniejszym artykule, zestaw narzędzi eIQ Toolkit posiada szeroki zestaw możliwości, w tym konwersję i optymalizację modeli, które znacznie wykraczają poza zakres niniejszego artykułu. Jednak w przypadku szybkiego prototypowania gotowych aplikacji uczenia maszynowego, deweloperzy mogą na ogół szybko przejść przez proces tworzenia i wdrażania, bez potrzeby korzystania z wielu bardziej wyrafinowanych możliwości środowiska eIQ. W rzeczywistości wyspecjalizowane pakiety oprogramowania aplikacyjnego (App SW) firmy NXP oferują kompletne aplikacje, które deweloperzy mogą wykorzystać do natychmiastowej ewaluacji lub jako podstawę własnych, niestandardowych zastosowań.

Szybka ewaluacja rozwoju modelu za pomocą pakietu oprogramowania aplikacyjnego

Pakiety oprogramowania aplikacyjnego firmy NXP zawierają kompletną aplikację opartą na uczeniu maszynowym, która obejmuje gotowy do produkcji kod źródłowy, sterowniki, oprogramowanie pośredniczące i narzędzia. Na przykład pakiet oprogramowania aplikacyjnego ML State Monitor oferuje natychmiastowe, oparte na uczeniu maszynowym (ML) rozwiązanie częstego problemu określania stanu złożonych systemów na podstawie danych z czujników (ilustracja 10).

Ilustracja 10: deweloperzy mogą używać pakietów oprogramowania aplikacyjnego NXP, takich jak pakiet oprogramowania aplikacyjnego NXP ML State Monitor, do natychmiastowej ewaluacji lub jako podstawy tworzenia własnego kodu. (Źródło ilustracji: NXP Semiconductors)

Pakiet oprogramowania aplikacyjnego ML State Monitor stanowi kompletne rozwiązanie dla aplikacji przeznaczonej do wykrywania, kiedy wentylator pracuje w jednym z czterech stanów:

• ON (WŁĄCZONE)
• OFF (WYŁĄCZONE)
• CLOGGED (ZABLOKOWANE), gdy wentylator jest włączony, ale przepływ powietrza jest utrudniony
• FRICTION (TARCIE), gdy wentylator jest włączony, ale co najmniej jedna łopatka wentylatora doświadcza nadmiernego tarcia podczas pracy

Co równie ważne dla deweloperów modeli, pakiet oprogramowania aplikacyjnego ML State Monitor zawiera modele uczenia maszynowego (ML), a także kompletny zestaw danych reprezentujących odczyty przyspieszeniomierza z wentylatora pracującego w każdym z podanych czterech stanów.

Deweloperzy mogą analizować kod, modele i dane dostarczone w pakiecie oprogramowania aplikacyjnego ML State Monitor, aby zrozumieć, jak używać danych z czujnika do trenowania modelu, tworzenia modelu wnioskowania i walidacji wnioskowania względem walidacyjnego zbioru danych czujnika. W rzeczywistości platforma Jupyter Notebook ML_State_Monitor.ipynb firmy NXP, zawarta w pakiecie oprogramowania aplikacyjnego daje użytkownikom do dyspozycji gotowe do użycia narzędzie do badania przepływu pracy przy opracowywaniu modelu na długo przed wdrożeniem sprzętu.

Jupyter Notebook to interaktywna przeglądarkowa platforma wykonawcza języka Python, która umożliwia deweloperom natychmiastowe wyświetlanie wyników wykonywania kodu w języku Python. Uruchomienie platformy Jupyter Notebook generuje blok kodu w języku Python, po którym natychmiast następują wyniki uruchomienia tego bloku kodu. Te wyniki nie są statyczne, ale raczej stanowią rzeczywiste wyniki uzyskane przez uruchomienie kodu. Na przykład, po uruchomieniu platformy Jupyter Notebook ML_State_Monitor.ipynb firmy NXP, deweloperzy mogą natychmiast wyświetlić podsumowanie zbioru danych wejściowych (ilustracja 11).

Ilustracja 11: platforma Jupyter Notebook ML_State_Monitor.ipynb firmy NXP umożliwia deweloperom interaktywną pracę w ramach przepływu pracy rozwojowych nad modelem sieci neuronowej, wyświetlając dane szkoleniowe dostarczone w pakiecie oprogramowania aplikacyjnego ML State Monitor. [Uwaga: kod skrócony do celów prezentacji]. (Źródło ilustracji: Stephen Evanczuk, uruchamianie platformy Jupyter Notebook ML_State_Monitor.ipynb Jupyter Notebook firmy NXP)

Kolejna sekcja kodu w platformie Notebook zapewnia użytkownikowi graficzne przedstawienie danych wejściowych w formie oddzielnych wykresów sekwencji czasowej i częstotliwości (ilustracja 12).

Ilustracja 12: platforma Jupyter Notebook zapewnia programistom szeregi czasowe i wyświetlanie częstotliwości przykładowego zbioru danych o stanie wentylatora (OFF-WYŁĄCZONE: zielony; ON-WŁĄCZONE: czerwony; CLOGGED-ZABLOKOWANE: niebieski; FRICTION-TARCIE: żółty). [Uwaga: kod skrócony do celów prezentacji.] (Źródło ilustracji: Stephen Evanczuk, uruchamianie platformy Jupyter Notebook ML_State_Monitor.ipynb Jupyter Notebook firmy NXP)

Dodatkowe sekcje kodu odpowiadają za dalszą analizę danych, normalizację, kształtowanie i inne przygotowania, aż do momentu, gdy wykonanie kodu pozwoli osiągnąć tę samą definicję funkcji tworzenia modelu, model_create(), pokazaną wcześniej na listingu 1. Następna sekcja kodu wykonuje funkcję model_create() i wyświetla podsumowanie w celu szybkiej weryfikacji (ilustracja 13).

Ilustracja 13: platforma Jupyter Notatnik ML_State_Monitor.ipynb firmy NXP tworzy model (pokazany na listingu 1) i wyświetla informacje podsumowania modelu. (Źródło ilustracji: Stephen Evanczuk, uruchamianie platformy Jupyter Notebook ML_State_Monitor.ipynb Jupyter Notebook firmy NXP)

Po sekcji kodu do uczenia i ewaluacji modelu, platforma Jupyter Notebook ML_State_Monitor.ipynb wyświetla poszczególne macierze pomyłek dla pełnego zbioru danych, zbioru danych do uczenia i zbioru danych do walidacji (podzbiór zbioru danych wyłączony ze zbioru danych do uczenia). W tym przypadku macierz pomyłek dla pełnego zbioru danych wykazuje dobrą dokładność z niewielką liczbą błędów, polegających w szczególności na pomyleniu dla niewielkiego procentu zbiorów danych stanu zablokowanego (stan faktyczny według oznaczenia w oryginalnym zbiorze danych) ze stanem włączonym (ilustracja 14).

Ilustracja 14: deweloperzy mogą wyświetlać tego typu macierze pomyłek dla pełnego zbioru danych. (Źródło ilustracji: Stephen Evanczuk, uruchamianie platformy Jupyter Notebook ML_State_Monitor.ipynb firmy NXP)

W dalszej sekcji kodu model jest eksportowany do kilku różnych typów modeli i formatów używanych przez różne aparaty wnioskowania obsługiwane przez środowisko rozwojowe eIQ (ilustracja 15).

Ilustracja 15: platforma Jupyter Notebook ML_State_Monitor.ipynb firmy NXP pokazuje, w jaki sposób deweloperzy mogą zapisywać przeszkolony model w kilku różnych typach i formatach. (Źródło ilustracji: Stephen Evanczuk, uruchamianie platformy Jupyter Notebook ML_State_Monitor.ipynb Jupyter Notebook firmy NXP)

Wybór aparatu wnioskowania może mieć krytyczne znaczenie dla spełnienia określonych wymagań w zakresie parametrów działania. W przypadku omawianej aplikacji firma NXP mierzyła rozmiar modelu, rozmiar kodu i czas wnioskowania (czas wymagany do zakończenia wnioskowania na pojedynczym obiekcie wejściowym) przy wykorzystaniu modelu do kilku aparatów wnioskowania, z których jeden działa z częstotliwością 996MHz, a drugi z częstotliwością 156MHz (ilustracje 16 i 17).

Ilustracja 16: wybór typu modelu może dramatycznie wpłynąć na jego rozmiary, chociaż przedstawione tutaj istotne różnice mogą nie dotyczyć większych modeli. (Źródło ilustracji: NXP Semiconductors)

Ilustracja 17: czas wnioskowania może się znacznie różnić w przypadku oceny obiektu wejściowego po załadowaniu z pamięci RAM lub pamięci flash lub podczas pracy procesora z wyższą częstotliwością 996MHz w porównaniu do 156MHz. (Źródło ilustracji: NXP Semiconductors)

Jak zauważa firma NXP, omawiana przykładowa aplikacja wykorzystuje bardzo mały model, więc dość istotne różnice pokazane na tych ilustracjach mogą być znacznie mniej wyraźne w większym modelu używanym do złożonych klasyfikacji.

Budowanie układu do monitorowania stanu

Oprócz platformy Jupyter Notebook do interaktywnego badania przepływu pracy opracowywania modelu, pakiet oprogramowania aplikacyjnego ML State Monitoring firmy NXP zapewnia kompletny kod źródłowy do implementacji projektu na płytce ewaluacyjnej MIMXRT1170-EVK firmy NXP. Płytka ewaluacyjna bazująca na mikrokontrolerze MCU typu crossover MIMXRT1176DVMAA firmy NXP stanowi kompleksową platformę sprzętową z dodatkową pamięcią i licznymi interfejsami (ilustracja 18).

Ilustracja 18: płytka ewaluacyjna MIMXRT1170-EVK firmy NXP stanowi kompleksową platformę sprzętową do tworzenia aplikacji w oparciu o mikrokontroler MCU typu crossover z serii i.MX RT1170 firmy NXP. (Źródło ilustracji: NXP Semiconductors)

Deweloperzy mogą używać aplikacji do monitorowania stanu wentylatora firmy NXP, łącząc płytkę ewaluacyjną MIMXRT1170-EVK z opcjonalną płytką czujnikową FRDM-STBC-AGM01 firmy NXP, nakładką Arduino i odpowiednim bezszczotkowym wentylatorem prądu stałego o napięciu 5V, takim jak 4468 firmy Adafruit (ilustracja 19).

Ilustracja 19: deweloperzy mogą przetestować przykładową aplikację do monitorowania stanu wentylatora firmy NXP za pomocą prostego stosu zbudowanego na płytce ewaluacyjnej MIMXRT1170-EVK. (Źródło ilustracji: NXP Semiconductors)

Wykorzystując zintegrowane środowisko deweloperskie (IDE) MCUXpresso, deweloperzy mogą skonfigurować aplikację tak, aby po prostu pozyskiwać i przechowywać dane o stanie wentylatorów lub natychmiast uruchamiać wnioskowanie na uzyskanych danych za pomocą aparatu wnioskowania TensorFlow, DeepViewRT lub Glow (listing 2).

Kopiuj
/* 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: deweloperzy mogą łatwo skonfigurować przykładową aplikację w oprogramowaniu ML State Monitor firmy NXP, modyfikując definicje zawarte w pliku nagłówkowym sensor_collect.h. (Źródło kodu: NXP Semiconductors)

Aplikacja działa z prostym przepływem procesów. Główna procedura w sekcji main.c tworzy zadanie o nazwie MainTask, które jest procedurą zlokalizowaną w module sensor_collect.c.

Kopiuj
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: w przykładowej aplikacji do monitorowania stanu ML firmy NXP zadanie MainTask wywołuje podzadanie, którego celem jest pozyskanie danych lub uruchomienie wnioskowania. (Źródło kodu: NXP Semiconductors)

Zadanie MainTask wykonuje różne zadania inicjalizacji przed uruchomieniem jednego z dwóch podzadań, w zależności od definicji ustawionych przez użytkownika sekcji w sensor_collect.h:

• jeśli parametr SENSOR_COLLECT_ACTION ma ustawioną wartość SENSOR_COLLECT_LOG_EXT, zadanie MainTask uruchamia podzadanie SENSOR_Collect_LogExt_Task(), które gromadzi dane i zapisuje je na karcie SD, o ile takowa została skonfigurowana
• jeśli parametr SENSOR_COLLECT_ACTION ma ustawioną wartość SENSOR_COLLECT_RUN_INFERENCE, zadanie MainTask uruchamia podzadanie SENSOR_Collect_RunInf_Task(), które uruchamia aparat wnioskowania (Glow, DeepViewRT lub TensorFlow) zdefiniowany w sekcji sensor_collect.h wykorzystujący zgromadzone dane, oraz, jeśli zdefiniowano parametr SENSOR_EVALUATE_MODEL, wyświetla obliczone parametry działania oraz predykcję klasyfikacji

Kopiuj
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: przykładowa aplikacja pakietu ML State Monitor firmy NXP stanowi podstawowy wzorzec projektowy do pozyskiwania danych z czujników i uruchamiania wybranego aparatu wnioskowania na pozyskanych danych. (Źródło kodu: NXP Semiconductors)

Dzięki temu, że pakiet oprogramowania aplikacyjnego ML State Monitor firmy NXP zawiera pełny kod źródłowy wraz z kompletnym zestawem wymaganych sterowników i oprogramowania pośredniczącego, deweloperzy mogą łatwo rozszerzyć aplikację, dodając funkcje lub użyć jej jako punktu wyjścia do rozwoju własnego niestandardowego rozwiązania.

Podsumowanie

Wdrożenie uczenia maszynowego (ML) w środowisku brzegowym w inteligentnych produktach Internetu rzeczy (IoT) i innych zastosowaniach może zapewnić potężny zestaw funkcji, ale często powoduje, że deweloperzy mają problemy z zastosowaniem narzędzi i metod uczenia maszynowego opracowanych dla rozwiązań na skalę korporacyjną. Dzięki dostępności platformy rozwojowej NXP zawierającej procesory typu crossover i specjalistyczne oprogramowanie do opracowywania modeli, zarówno eksperci w dziedzinie ML, jak i deweloperzy z niewielkim lub żadnym doświadczeniem w ML mogą skuteczniej tworzyć aplikacje ML zaprojektowane specjalnie w celu spełnienia wymagań w zakresie wysokich parametrów działania środowiska brzegowego.