Helyi eszközökön futó gépi tanulási alkalmazások gyors rendszerbe állítása

A gépi tanulás (ML) óriási lehetőségeket kínál az intelligens termékek létrehozására, de a neurális hálózatok (NN) modellezésével és a helyi eszközökön futó gépi tanulási alkalmazások létrehozásával járó összetettség és kihívások korlátozzák a fejlesztők azon képességét, hogy gyorsan hozzanak létre hasznos megoldásokat. Bár a könnyen elérhető eszközök általánosságban hozzáférhetőbbé tették a gépi tanulási modellek létrehozását, a hagyományos gépitanulás-fejlesztési technológiákat nem úgy tervezték, hogy megfeleljenek a dolgok internetéhez (IoT), az autóiparhoz, az ipari rendszerekhez és más beágyazott eszközökhöz kapcsolódó megoldások egyedi követelményeinek.

Ez a cikk rövid bevezetést nyújt a neurális hálózatok modellezésébe. Ezután ismerteti, hogyan lehet használni az NXP Semiconductors átfogó gépi tanulási platformját, amely lehetővé teszi a fejlesztők számára, hogy hatékonyabban fejlesszenek helyi eszközökön futó gépi tanulási alkalmazásokat.

A neurális hálózatok modellezésének gyors áttekintése

A gépi tanulási algoritmusok a fejlesztők számára a korábbiaktól drámaian eltérő lehetőségeket kínálnak az alkalmazásfejlesztésre. Ahelyett, hogy olyan szoftverkódot írnának, amely kifejezetten olyan problémák megoldására szolgál, mint a képosztályozás, a fejlesztők a neurális hálózati modelleket úgy tanítják be, hogy egy adathalmazt, például a képen szereplő személy vagy objektum tényleges nevével (vagy osztályával) fémjelzett képeket mutatnak be nekik. A betanítási folyamat különböző módszereket használ a modell paramétereinek, azaz az egyes neuronok és rétegek súlyának és torzítási értékének kiszámításához, ami lehetővé teszi, hogy a modell viszonylag pontosan jósolja meg a bevitt kép helyes osztályát (1. ábra).

1. ábra: Az olyan neurális hálózatok, mint az ábrán látható teljesen összekapcsolt hálózat, a betanítás során beállított súly- és torzítási paraméterek segítségével osztályozzák a bevitt objektumokat (kép: NXP Semiconductors)

A gépi tanulást kutatók az 1. ábrán látható általános teljesen összekapcsolt neurális hálózaton túlmenően a neurális hálózati architektúrák széles skáláját fejlesztették ki. A képosztályozó alkalmazások például jellemzően a konvolúciós neurális hálózatot (CNN) használják, egy olyan speciális architektúrát, amely a képfelismerést felosztja egy kezdeti fázisra, amely megkeresi a kép kulcsfontosságú jellemzőit, majd egy osztályozási fázisra, amely megjósolja annak valószínűségét, hogy a kép a betanítás során létrehozott osztályok valamelyikébe tartozik-e (2. ábra).

2. ábra: A gépi tanulási szakértők az olyan egyedi feladatokhoz, mint a képfelismerés, speciális neurális hálózati architektúrákat használnak, amilyen például ez a konvolúciós neurális hálózat (CNN) (kép: NXP Semiconductors)

Bár a megfelelő modellarchitektúra és betanítási rendszer kiválasztását eddig kizárólag gépi tanulási szakértők végezték, a számos nyílt forráskódú és kereskedelmi eszköz megjelenése nagymértékben leegyszerűsítette a nagyszámú rendszerbe állításhoz szükséges modellfejlesztést. Ma a fejlesztők néhány sornyi kóddal definiálhatnak modelleket (1. lista), és olyan eszközökkel, mint például a nyílt forráskódú Netron modellnéző, létrehozhatják a modell grafikus megjelenítését (3. ábra) az egyes rétegek definíciójának és összekapcsolhatóságának ellenőrzésére.

Másolja a vágólapra
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

1. lista: A fejlesztők néhány sornyi kóddal definiálhatnak neurálishálózat-modelleket (kód: NXP Semiconductors)

3. ábra: Az 1. listán definiált modellnek a Netron modellnéző által előállított grafikus megjelenítése segíthet a fejlesztőknek dokumentálni az egyes rétegek funkcióit és összekapcsolhatóságát (kép: Stephen Evanczuk, az 1. listán szereplő modellforráskód futtatása a Netron modellnézőben)

A végső rendszerbe állítás során más eszközök eltávolítják a csak a betanítás során szükséges modellstruktúrákat, és egyéb optimalizálásokat végeznek a hatékony következtetési modell létrehozása érdekében.

Miért olyan nehéz gépi tanuláson alapuló alkalmazásokat fejleszteni az intelligens termékekhez?

A dolgok internetéhez (IoT) és más intelligens termékekhez való modellek definiálása és betanítása hasonló munkafolyamatot követ, mint a vállalati szintű gépi tanulási alkalmazások modelljének létrehozása. Ezen a hasonlóságon túlmenően azonban a helyi eszközökre szánt gépi tanulási alkalmazások fejlesztése több további feladatot is jelent. A modellfejlesztés mellett a tervezőknek a mikrovezérlő- (MCU-) alapú termékük futtatásához szükséges fő alkalmazás fejlesztésének már ismerős feladatával is szembe kell nézniük. Ennek eredményeképpen a gépi tanulás helyi eszközökre történő áthelyezéséhez két egymással összefüggő munkafolyamatot kell kezelniük (4. ábra).

4. ábra: Egy gépi tanuláson alapuló, ám helyi eszközökön futó alkalmazás fejlesztése kibővíti a beágyazott mikrovezérlőknél megszokott jellegzetes fejlesztési munkafolyamatot egy a gépi tanulási modell betanításához, hitelesítéséhez és rendszerbe állításához szükséges gépi tanulási munkafolyamattal (kép: NXP Semiconductors)

Bár a mikrovezérlős projekt munkafolyamata ismerős a beágyazott eszközökre alkalmazásokat fejlesztők számára, a gépi tanulási projekt további követelményeket támaszthat a mikrovezérlő-alapú alkalmazással szemben, amikor a fejlesztők egy optimalizált gépi tanulási következtetési modell létrehozásán dolgoznak. Valójában a gépi tanulási projekt drámaian befolyásolja a beágyazott eszközzel szemben támasztott követelményeket. A modellek végrehajtásához általában kapcsolódó nagy számítási terhelés és memóriaigény meghaladhatja a dolgok internetén és az intelligens termékekben használt mikrovezérlők erőforrásait. Az erőforrásigény csökkentése érdekében a gépi tanulási szakértők olyan technikákat használnak, mint a modellhálózat letisztítása, a tömörítés, a kvantálás kisebb pontosságra vagy akár egybites paraméterekre és közbenső értékekre, valamint egyéb módszereket.

A fejlesztők azonban még ezekkel az optimalizálási módszerekkel együtt is azt tapasztalhatják, hogy a hagyományos mikrovezérlők nem rendelkeznek a gépi tanulási algoritmusokhoz kapcsolódó nagyszámú matematikai művelet elvégzéséhez szükséges teljesítménnyel. Másrészt egy nagy teljesítményű célprocesszor használata megoldást jelenthetne a gépi tanulás jelentette számítási terhelés kezelésére, de ez a megközelítés nagyobb késleltetést és nem determinisztikus választ eredményezhet, ami rontaná a beágyazott eszköz valós idejű jellemzőit.

A hardver kiválasztásával kapcsolatos kihívások mellett a beágyazott eszközök fejlesztésénél további egyedi kihívásokat jelent a helyi eszközökre optimalizált gépi tanulási modellek létrehozása. A nagyvállalati szintű gépi tanulási rendszerekhez kifejlesztett eszközök és módszerek nagy száma nem feltétlenül méretezhető jól a beágyazott fejlesztői alkalmazásokhoz és azok működési környezethez. Még a gépi tanuláson alapuló eszközök gyors rendszerbe állítására számító tapasztalt beágyazotteszköz-fejlesztők is nehezen találnak hatékony megoldást a neurális hálózati modellre épülő elérhető architektúrák, eszközök, keretrendszerek és munkafolyamatok sokasága között.

Az NXP a helyi eszközökön futó gépi tanulás fejlesztésének mind a hardveres teljesítményhez, mind a modell megvalósításához kapcsolódó szempontjaival foglalkozik. Hardverszinten az NXP nagy teljesítményű i.MX RT1170 hibrid processzorai megfelelnek a helyi eszközökön futó gépi tanulás széles körű teljesítménykövetelményeinek. Ennek a hardveralapnak a teljes kihasználása érdekében az NXP eIQ (edge intelligence, helyi eszközökhöz készült intelligencia) gépi tanulási szoftverfejlesztő környezete és az alkalmazásszoftver-csomagok hatékony megoldást kínálnak mind a tapasztalatlan, mind a tapasztalt gépitanulás-fejlesztőknek a helyi eszközökre szánt gépi tanulási alkalmazások létrehozásához.

Hatékony platform a helyi eszközökön futó gépi tanulási alkalmazások fejlesztéséhez

Az NXP i.MX RT hibrid processzorok ötvözik a hagyományos beágyazott mikrovezérlők valós idejű, kis késleltetésű válaszát a nagy teljesítményű célprocesszorok végrehajtási képességeivel. Az NXP i.MX RT1170 jelű hibrid processzorcsaládja egy energiatakarékos ARM® Cortex®-M4 mikrovezérlőt és egy nagy teljesítményű ARM Cortex-M7 processzort egyesít, és az NXP az erőforrás-igényes alkalmazásoknak, köztük a beágyazott eszközök gépi tanuláson alapuló megoldásainak futtatásához szükséges funkcionális blokkok és perifériák kiterjedt választékát mellékeli hozzájuk (5. ábra).

5. ábra: Az NXP i.MX RT1170 hibrid processzorai egyesítik a hagyományos mikrovezérlők energiatakarékos képességeit a célprocesszorok nagy feldolgozási teljesítményével (kép: NXP Semiconductors)

Az NXP MCUXpresso SDK és Yocto fejlesztői környezetekbe teljesen beépülő NXP eIQ környezetet kifejezetten arra tervezték, hogy megkönnyítse a következtetési modellek létrehozását az NXP-mikroprocesszorokkal és -mikrovezérlőkkel épített beágyazott rendszerekben. Az eIQ környezet részét képező eIQ Toolkit eszközkészlet több eszköz, köztük az eIQ Portal, az eIQ Model Tool és parancssori eszközök segítségével támogatja a saját adatokra (BYOD) és a saját modellre (BYOM) épülő munkafolyamatokat (6. ábra).

6. ábra: Az NXP eIQ Toolkit eszközkészlet támogatja azokat a (saját adatokra épülő alkalmazásokat fejlesztő) BYOD-fejlesztőket, akiknek modellt kell létrehozniuk, és azokat a (saját modellre épülő alkalmazásokat fejlesztő) BYOM-fejlesztőket, akiknek saját meglévő modelljüket kell egy célrendszerre átvinniük (kép: NXP Semiconductors)

Az eIQ Portal eszközt úgy tervezték, hogy mind a szakértők, mind a gépi tanulási modellek fejlesztésével újonnan ismerkedő fejlesztők esetében támogassa a BYOD-munkafolyamatokat, és olyan grafikus felhasználói felületet (GUI) kínál, amely segít a fejlesztőknek a modellfejlesztési munkafolyamat egyes szakaszainak könnyebb végrehajtásában.

A fejlesztés kezdeti szakaszában az eIQ Portal adathalmaz-gondozó eszköze segít a fejlesztőknek az adatok importálásában és a csatlakoztatott kameráról vagy egy távoli eszközről történő adatrögzítésben (7. ábra).

7. ábra: Az eIQ Portal adathalmaz-gondozó eszköze megkönnyíti a betanítási adatok előkészítésének kritikus fontosságú feladatát (kép: NXP Semiconductors)

Az adathalmaz-gondozó eszközzel a fejlesztők az adathalmaz minden egyes elemét magyarázatokkal vagy címkékkel látják el, megcímkézve az egész képet, vagy annak csak egy meghatározott határolókereten belül elhelyezkedő bizonyos területeit. A kiegészítési (augmentációs) funkció segít a fejlesztőknek abban, hogy a képek elmosásával, véletlenszerű zaj hozzáadásával, a jellemzők, például a fényerő vagy a kontraszt megváltoztatásával és más módszerekkel biztosítsák az adathalmazban a szükséges eltéréseket.

A következő fázisban az eIQ Portal segít a fejlesztőknek kiválasztani az alkalmazáshoz legjobban illeszkedő modelltípust. A modelltípust illetően bizonytalan fejlesztőket egy modellválasztó varázsló végigvezeti a kiválasztási folyamaton az alkalmazás típusa és a hardverbázis alapján. Azok a fejlesztők, akik már tudják, hogy milyen típusú modellre van szükségük, választhatnak az eIQ telepítése során telepített egyéni modellek közül, vagy használhatnak saját maguk által létrehozott modelleket.

Az eIQ Portal végigvezeti a fejlesztőket a betanítás következő kritikus lépésén, és logikusan használható grafikus felhasználói felületet kínál a betanítási paraméterek módosításához és az egyes betanítási lépések során a modell előrejelzési pontosságában bekövetkezett változások megtekintéséhez (8. ábra).

8. ábra: A fejlesztők az eIQ Portal betanítási eszközét használják arra, hogy minden egyes lépésnél megfigyeljék a betanítási pontosság javulását, és szükség esetén módosítsák a betanítási lépéseket (kép: NXP Semiconductors)

A következő lépésben az eIQ Portal grafikus felhasználói felülete segít a fejlesztőknek a modell hitelesítésében. Ebben a fázisban a modellt úgy alakítják át, hogy a célarchitektúrán fusson, hogy meg lehessen határozni a tényleges teljesítményét. Amikor a hitelesítés befejeződik, a hitelesítő képernyő megjeleníti a zavarmátrixot, amely a gépi tanulás egyik alapvető hitelesítőeszköze, és lehetővé teszi a fejlesztők számára, hogy összehasonlítsák a bevitt objektum tényleges osztályát a modell által megjósolt osztállyal (9. ábra).

9. ábra: Az eIQ Portal hitelesítőeszköze a fejlesztők rendelkezésére bocsátja a modell célarchitektúrán történő futtatása során kapott zavarmátrixot (kép: NXP Semiconductors)

A végleges rendszerbe állításhoz a környezet a processzortól függően a következő célkikövetkeztető motorokat (alapprogramokat) teszi elérhetővé a fejlesztők számára:

• ARM CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network – szabványos közös mikrovezérlős szoftveres illesztőfelület neurális hálózatokhoz) – az ARM Cortex-M processzormagokon futó neurális hálózatok teljesítményének maximalizálására és memóriaigényének minimálisra csökkentésére kifejlesztett neurális hálózati kernelek (programmagok).
• ARM NN SDK (Neural Network, Software Development Kit – szoftverfejlesztő készlet neurális hálózatokhoz) – egy eszközkészlet és következtetőmotor, amelyet a meglévő neurális hálózati keretrendszerek és többek között az ARM Cortex-A processzorok közötti összeköttetés megteremtésére terveztek.
• DeepViewRT – az NXP saját fejlesztésű következtetőmotorja i.MX RT hibrid processzorokhoz.
• Glow NN – a Meta cég Glow (gráfcsökkentő) fordítóprogramján alapuló, az NXP által az ARM Cortex-M processzormagokra optimalizált célkikövetkeztető motor, amely (ha elérhetőek) a CMSIS-NN kernelekre vagy az ARM NN könyvtárra irányuló függvényhívásokat használ, egyéb esetekben pedig a saját könyvtára segítségével végez kódfordítást.
• ONXX Runtime – a Microsoft Research eszközei, amelyeket az ARM Cortex-A processzorok teljesítményének optimalizálására terveztek.
• TensorFlow Lite for Microcontrollers – a TensorFlow Lite kisebb, mikrovezérlőkhöz készült, gépi tanulási modellek i.MX RT hibrid processzorokon való futtatására optimalizált változata.
• TensorFlow Lite – a TensorFlow kisebb rendszerek támogatására készült verziója.

A (saját modellre épülő) BYOM-munkafolyamatok esetében a fejlesztők az eIQ Model Tool segítségével közvetlenül a modellelemzésre és a rétegenkénti időprofilok készítésére léphetnek. A fejlesztők mind a (saját adatokra épülő) BYOD-, mind a BYOM-munkafolyamatok esetében használhatják az eIQ parancssori eszközeit, amelyekkel hozzá lehet férni a felhasználói felületről közvetlenül nem elérhető eszközfunkciókhoz és eIQ-funkciókhoz is.

Az eIQ Toolkit az ebben a cikkben ismertetett funkciók mellett számos olyan képességet támogat, beleértve a modellátalakítást és -optimalizálást is, amelyek jóval túlmutatnak a jelen cikk keretein. A helyi eszközökre szánt gépi tanulási alkalmazások prototípusának gyors kialakítása során azonban a fejlesztők általában tempósan haladhatnak a fejlesztés és a rendszerbe állítás útján, és ritkán kell sokat használniuk az eIQ környezet kifinomultabb képességei közül. Az NXP speciális alkalmazásszoftver-csomagjai (App SW-csomagok) kész alkalmazásokat kínálnak, amelyeket a fejlesztők használhatnak azonnali kiértékelésre vagy saját egyedi alkalmazásaik alapjaként.

A modellfejlesztés gyors kiértékelése az alkalmazásszoftver-csomagok segítségével

Az NXP App SW-csomagok gépi tanuláson alapuló kész alkalmazásokat kínálnak, egy csomagban egyesítve a gyártásra kész forráskódot, illesztőprogramokat, köztes szoftvereket és eszközöket. Az NXP ML State Monitor App SW Pack (állapotfigyelő alkalmazásszoftver-csomag gépi tanuláshoz) csomagja például gépi tanuláson alapuló azonnali megoldást kínál az összetett rendszerek állapotának érzékelőktől kapott bemenőjelek alapján történő meghatározása jelentette gyakori problémára (10. ábra).

10. ábra: A fejlesztők az NXP alkalmazásszoftver-csomagjait, például az ML State Monitor App SW Pack csomagot használhatják azonnali kiértékelésre vagy egyedi kód fejlesztésének alapjaként (kép: NXP Semiconductors)

Az ML State Monitor App SW Pack csomag kész megoldást kínál olyan alkalmazásokhoz, amelyek feladata annak érzékelése, hogy a ventilátorra az alábbi négy állapot melyike jellemző:

• Bekapcsolva (ON)
• Kikapcsolva (OFF)
• Eltömődött (CLOGGED), amikor a ventilátor be van kapcsolva, de a légáramlás akadályozva van
• Súrlódás (FRICTION), amikor a ventilátor be van kapcsolva, de egy vagy több ventilátorlapát működés közben túlzott mértékben súrlódik valamihez

A modellfejlesztők számára ugyanilyen fontos, hogy az ML State Monitor App SW Pack csomag tartalmaz gépi tanulási modelleket, valamint egy teljes adathalmazt, amelyben megtalálhatók a ventilátor gyorsulásmérőjének mért értékei mind a négy üzemállapotra vonatkozóan.

A fejlesztők tanulmányozhatják az ML State Monitor App SW Pack csomagban található kódot, modelleket és adatokat, hogy megértsék, hogyan lehet felhasználni az érzékelőadatokat a modellek betanítására, következtetési modell létrehozására és a következtetésnek egy hitelesítő érzékelőadat-halmazon végzett hitelesítésére. Igazából az alkalmazásszoftver-csomagban található NXP ML_State_Monitor.ipynb Jupyter Notebook még jóval a hardver összeállítása előtt egy azonnal használható eszközt kínál a modellfejlesztési munkafolyamat tanulmányozásához.

A Jupyter Notebook egy interaktív (párbeszédes), böngészőalapú, a Python nyelvre épülő végrehajtási platform, amely lehetővé teszi a fejlesztők számára, hogy azonnal megtekinthessék a Python-kód futtatásának eredményeit. A Jupyter Notebook futtatása egy Python-kódblokkot állít elő, amelyet azonnal követ a kódblokk futtatásának eredménye. Ezek az eredmények nem egyszerűen statikus adatok, hanem a kód futtatásával kapott tényleges eredmények. Amikor például a fejlesztők futtatják az NXP ML_State_Monitor.ipynb Jupyter Notebook eszközt, azonnal megtekinthetik a bemeneti adatállományra vonatkozó összefoglalót (11. ábra).

11. ábra: Az NXP ML_State_Monitor.ipynb Jupyter Notebook segítségével a fejlesztők interaktív módon dolgozhatnak a neurálishálózat-modell fejlesztésére szolgáló munkafolyamatot használva, és megtekinthetik az ML State Monitor App SW Pack csomagban található betanítási adatokat [Megjegyzés: A kódot a megjelenítés miatt itt csonkítottuk.] (kép: Stephen Evanczuk, az NXP ML_State_Monitor.ipynb Jupyter Notebook futtatása)

A Jupyter Notebook eszközben a következő kódrészlet a bemeneti adatok grafikus megjelenítését biztosítja a felhasználó számára, külön grafikonon mutatva az időbeli sorrendet és a frekvenciát (12. ábra).

12. ábra: A Jupyter Notebook megjeleníti a fejlesztők számára a ventilátor állapotára vonatkozó mintaadathalmazból az időbeli sorrendet és frekvenciát (kikapcsolva: zöld; bekapcsolva: piros; eltömődött: kék; súrlódás: sárga) [Megjegyzés: A kódot a megjelenítés kedvéért csonkítottuk.] (kép: Stephen Evanczuk, az NXP ML_State_Monitor.ipynb Jupyter Notebook futtatása)

A további kódrészek további adatelemzést, normalizálást, jelformálást és egyéb előkészítést végeznek, amíg a kód végrehajtása el nem éri ugyanazt a model_create() modellkészítési függvénydefiníciót, amely korábban az 1. listán szerepelt. A következő kódrészlet futtatja ezt a model_create() függvényt, és kiír egy összefoglalót a gyors hitelesítéshez (13. ábra).

13. ábra: Az NXP ML_State_Monitor.ipynb Jupyter Notebook létrehozza a modellt (lásd: 1. lista), és megjeleníti a modell összefoglaló adatait (kép: Stephen Evanczuk, az NXP ML_State_Monitor.ipynb Jupyter Notebook futtatása)

A modell betanítására és kiértékelésére szolgáló kódrészletet követően az ML_State_Monitor.ipynb Jupyter Notebook megjeleníti mindegyik zavarmátrixot a teljes adathalmazra, a betanítási adathalmazra és a hitelesítési adathalmazra (az adathalmaznak a betanítási adathalmazból kizárt részhalmazára) vonatkozóan. Ebben az esetben a teljes adathalmazra vonatkozó zavarmátrix kielégítő pontosságot mutat némi hibával, leginkább ott, ahol a modell az adathalmazok kis százalékát tévesen ON (bekapcsolt) állapotúnak értelmezi, miközben azok az eredeti adathalmazban valójában CLOGGED (eltömődött) állapotúként vannak megjelölve (14. ábra).

14. ábra: A fejlesztők megtekinthetik a teljes adathalmazra vonatkozó, ehhez hasonló zavarmátrixokat (kép: Stephen Evanczuk, az NXP ML_State_Monitor.ipynb Jupyter Notebook futtatása)

Egy későbbi kódrészletben a modellt az eIQ fejlesztőkörnyezet által támogatott különböző következtetőmotorok által használt több különböző modelltípusba és formátumba exportáljuk (15. ábra).

15. ábra: Az NXP ML_State_Monitor.ipynb Jupyter Notebook bemutatja, hogy a fejlesztők hogyan menthetik a betanított modelljüket többféle modelltípusban és formátumban (kép: Stephen Evanczuk, az NXP ML_State_Monitor.ipynb Jupyter Notebook futtatása)

A következtetőmotor kiválasztása kritikus fontosságú lehet az egyedi teljesítménykövetelmények teljesítése szempontjából. Ennél az alkalmazásnál az NXP mérte a modell méretét, a kód méretét és a következtetési időt (ez a következtetés befejezéséhez szükséges idő egyetlen bemeneti objektum esetében), amikor a modellt több, nevezetesen egy 996 MHz-es és egy 156 MHz-es sebességgel futó következtetőmotoron való futtatásra tervezték (16. és 17. ábra).

16. ábra: A modelltípus megválasztása drámai hatással lehet a modell méretére, bár az itt látható szembeötlő különbségek a nagyobb modellekre nem feltétlenül érvényesek (kép: NXP Semiconductors)

17. ábra: A bemeneti objektumok kiértékelésénél jelentősen eltérő lehet a következtetési idő, ha az objektumot RAM memóriából vagy flashmemóriából töltik be, vagy ha a processzort magasabb frekvencián (996 MHz, illetve 156 MHz) működtetik (kép: NXP Semiconductors)

Amint az NXP megjegyzi, ez a mintaalkalmazás egy nagyon kis méretű modellt használ, és az ábrákon látható meglehetősen nagy különbségek egy nagyobb, összetett osztályozásra használt modell esetében lényegesen kevésbé lennének hangsúlyosak.

Állapotfigyelésre szolgáló rendszermegoldás létrehozása

A modellfejlesztési munkafolyamat interaktív szemléltetésére szolgáló Jupyter Notebook mellett az NXP ML State Monitoring App SW Pack csomagja kész forráskódot kínál a tervnek az NXP MIMXRT1170-EVK fejlesztőkártyáján történő gyakorlati megvalósításához. Az NXP MIMXRT1176DVMAA hibrid processzor köré épülő fejlesztőkártya átfogó hardverplatformot kínál, további memóriával és több csatlakozóval kiegészítve (18. ábra).

18. ábra: Az NXP MIMXRT1170-EVK fejlesztőkártyája átfogó hardverplatformot kínál az NXP i.MX RT1170 sorozatú hibrid processzorra épülő alkalmazások fejlesztéséhez (kép: NXP Semiconductors)

A fejlesztők az NXP ventilátorállapot-jelző alkalmazást használhatják a ventilátor állapotának előrejelzésére, ha az MIMXRT1170-EVK fejlesztőkártyát kiegészítik egy külön kapható NXP FRDM-STBC-AGM01 érzékelőkártyával, egy Arduino pajzzsal és egy megfelelő 5 V-os szénkefe nélküli egyenáramú ventilátorral, például az Adafruit cég 4468 jelű ventilátorával (19. ábra).

19. ábra: A fejlesztők az NXP ventilátorállapot-jelző mintaalkalmazását tesztelhetik egy az MIMXRT1170-EVK fejlesztőkártyára épülő egyszerű összeállítással (kép: NXP Semiconductors)

Az MCUXpresso beépített fejlesztőkörnyezet (IDE) segítségével a fejlesztők beállíthatják az alkalmazást úgy, hogy az egyszerűen csak begyűjtse és tárolja a ventilátor állapotadatait, vagy úgy, hogy azonnal futtasson következtetést a megszerzett adatokon egy TensorFlow következtetőmotort, DeepViewRT következtetőmotort vagy Glow következtetőmotort használva (2. lista).

Másolja a vágólapra
/* 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

2. lista: A fejlesztők a sensor_collect.h fejlécfájlban szereplő definíciók módosításával könnyen beállíthatják az NXP ML State Monitor (gépi tanulási állapotfigyelő) mintaalkalmazást (kód: NXP Semiconductors)

Az alkalmazás egy egyszerű folyamatot követve működik. A main.c részben található main rutin létrehoz egy MainTask nevű feladatot, amely a sensor_collect.c modulban található rutin.

Másolja a vágólapra
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

3. lista: Az NXP ML State Monitor mintaalkalmazásban a MainTask feladat meghív egy részfeladatot az adatgyűjtéshez vagy a következtetés futtatásához (kód: NXP Semiconductors)

A MainTask feladat különböző inicializálási feladatokat hajt végre, mielőtt elindítja a két részfeladat egyikét, attól függően, hogy a felhasználó a sensor_collect.h fejlécfájlban milyen definíciókat adott meg:

• Ha a SENSOR_COLLECT_ACTION értéke SENSOR_COLLECT_LOG_EXT, a MainTask a SENSOR_Collect_LogExt_Task() részfeladatot indítja el, amelyik összegyűjti az adatokat, és az SD-kártyán tárolja azokat, ha ez van beállítva.
• Ha a SENSOR_COLLECT_ACTION értéke SENSOR_COLLECT_RUN_INFERENCE, a MainTask a SENSOR_Collect_RunInf_Task() részfeladatot indítja el, amely lefuttatja a sensor_collect.h fejlécfájlban definiált következtetőmotort (Glow, DeepViewRT vagy TensorFlow) az összegyűjtött adatokon, és ha a SENSOR_EVALUATE_MODEL úgy van definiálva, megjeleníti az eredményül kapott teljesítményt és osztályozási előrejelzést.

Másolja a vágólapra
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 */

4. lista: Az NXP ML State Monitor mintaalkalmazás szemlélteti az érzékelőadatok gyűjtésére és a kiválasztott következtetőmotornak a gyűjtött adatokon való futtatására szolgáló alapvető tervezési mintát (kód: NXP Semiconductors)

Mivel az NXP ML State Monitor App SW Pack kész forráskódot kínál a szükséges illesztőprogramok és köztes szoftverek teljes készletével együtt, a fejlesztők könnyen bővíthetik az alkalmazást, hogy új funkciókat adjanak hozzá, vagy használhatják saját egyedi fejlesztéseik kiindulópontjaként.

Összegzés

A gépi tanulásnak a dolgok internetére kapcsolódó és egyéb intelligens készülékekben lévő helyi eszközökön való használata hatékony funkciók elérését teszi lehetővé, de a fejlesztőknek gyakran kell megküzdeniük a vállalati szintű alkalmazásokhoz kifejlesztett gépi tanulási eszközök és módszerek helyi eszközökön való használatával. Így, hogy rendelkezésre áll az NXP hibrid processzorokból és célirányos modellfejlesztő szoftverekből álló fejlesztőplatformja, a gépi tanulás szakértői és a gépi tanulás terén kevés vagy semmilyen tapasztalattal nem rendelkező fejlesztők egyaránt hatékonyabban hozhatnak létre olyan gépi tanulási alkalmazásokat, amelyeket kifejezetten a helyi eszközök hatékony munkavégzésére vonatkozó követelményeket szem előtt tartva terveznek.