Sådan implementerer du hurtigt edge-ready maskinlæringsapplikationer

Maskinlæring (ML) giver et enormt potentiale for at skabe intelligente produkter, men kompleksiteten og udfordringerne i forbindelse med modellering af neurale netværk (NN) og oprettelse af ML-applikationer til edge-området har begrænset udviklernes evne til hurtigt at levere nyttige løsninger. Selv om lettilgængelige værktøjer har gjort det generelt lettere at skabe ML-modeller, er konventionelle ML-udviklingsmetoder ikke designet til at opfylde de unikke krav, der stilles til løsninger til Internet of Things (IoT), automotive, industrisystemer og andre indlejrede applikationer.

Denne artikel giver en kort introduktion til NN-modellering. Derefter introduceres og beskrives det, hvordan man bruger en omfattende ML-platform fra NXP Semiconductors, som giver udviklere mulighed for mere effektivt at levere edge-klare ML-applikationer.

En hurtig gennemgang af NN-modellering

ML-algoritmer giver udviklere en dramatisk anderledes mulighed for udvikling af applikationer. I stedet for at skrive softwarekode, der eksplicit skal løse problemer som billedklassificering, træner udviklere NN-modeller ved at præsentere et sæt data, f.eks. billeder, der er annoteret med det faktiske navn (eller klasse) på den enhed, der er indeholdt i billedet. Under træningsprocessen anvendes en række forskellige metoder til at beregne en models parametre for vægtning og bias-værdier for henholdsvis hver neuron og hvert lag, så modellen kan give en rimelig præcis forudsigelse af den korrekte klasse af et input-billede (figur 1).

Figur 1: NN'er som dette fuldt forbundne netværk klassificerer et inputobjekt ved hjælp af vægtnings- og bias-parametre, der er fastsat under træningen. (Billedkilde: NXP Semiconductors)

ML-forskere har udviklet en bred vifte af NN-arkitekturer ud over den generiske fuldt forbundne NN, der er vist i figur 1. F.eks. anvender billedklassificeringsapplikationer typisk konvolutionelt NN (CNN), en specialiseret arkitektur, der opdeler billedgenkendelse i en indledende fase, der finder nøgleelementer i et billede, efterfulgt af en klassifikationsfase, der forudsiger sandsynligheden for, at det tilhører en af flere klasser, der er fastlagt under træningen (figur 2).

Figur 2: ML-eksperter bruger specialiserede NN-arkitekturer som f.eks. dette konvolutionelt neuralt netværk (CNN) til specifikke opgaver som billedgenkendelse. (Billedkilde: NXP Semiconductors)

Selv om valget af en passende modelarkitektur og træningsregime har været begrænset til ML-eksperter, har tilgængeligheden af flere open source- og kommercielle værktøjer dramatisk forenklet modeludviklingen i forbindelse med store implementeringer. I dag kan udviklere definere modeller med nogle få linjer kode (liste 1) og bruge værktøjer som f.eks. open source-modelviseren Netron til at generere en grafisk repræsentation af modellen (figur 3) til at kontrollere hver lagdefinition og forbindelsesmuligheder.

Kopi
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: Udviklere kan definere NN-modeller ved hjælp af få kodelinjer. (Billedkilde: NXP Semiconductors)

Figur 3: Denne grafiske repræsentation af den model, der er defineret i liste 1, genereret af Netron-vieweren, kan hjælpe udvikleren med at dokumentere de enkelte lags funktion og forbindelsesmuligheder. (Billedkilde: Stephen Evanczuk, kører Netron på NXP model kildekode i liste 1)

Til den endelige implementering fjerner andre værktøjer de modelstrukturer, der kun er nødvendige under træningen, og foretager andre optimeringer for at skabe en effektiv inferensmodel.

Hvorfor det har været så vanskeligt at udvikle ML-baserede applikationer til intelligente produkter

Definition og træning af en model til IoT eller andre intelligente produkter følger en lignende arbejdsgang som ved oprettelse af en model til maskinlæringsapplikationer i virksomhedsskala. Ud over denne lighed giver udviklingen af ML-applikationer til edge-området imidlertid flere yderligere udfordringer. Sammen med modeludvikling står designerne over for de velkendte udfordringer med at udvikle den hovedapplikation, der er nødvendig for at køre deres mikrocontroller (MCU)-baserede produkt. Derfor kræver det at bringe ML til edge-området at styre to indbyrdes forbundne arbejdsgange (figur 4).

Figur 4: Ved udvikling af en ML-baseret applikation til edge-området udvides det typiske arbejdsflow for udvikling af indlejrede MCU'er med et ML-arbejdsflow, der er nødvendigt for at træne, validere og implementere en ML-model. (Billedkilde: NXP Semiconductors)

Selv om MCU-projektets arbejdsgang er velkendt for udviklere af indlejrede programmer, kan ML-projektet stille yderligere krav til den MCU-baserede applikation, når udviklerne arbejder på at skabe en optimeret ML-inferensmodel. Faktisk har ML-projektet en dramatisk indvirkning på kravene til den indlejrede enhed. Den store beregningsbelastning og de store hukommelseskrav, der normalt er forbundet med modeludførelse, kan overskride ressourcerne i de mikrocontrollere, der anvendes i IoT og intelligente produkter. For at reducere ressourcebehovet anvender ML-eksperter teknikker som modelnetværkssortering, komprimering, kvantisering til lavere præcision eller endog enkeltbitparametre og mellemliggende værdier og andre metoder for at reducere ressourcebehovet.

Selv med disse optimeringsmetoder kan udviklere dog stadig opleve, at konventionelle mikrocontrollere ikke har den nødvendige ydeevne til at håndtere det store antal matematiske operationer, der er forbundet med ML-algoritmer. På den anden side kan brugen af en højtydende applikationsprocessor håndtere ML-beregningsbelastningen, men denne fremgangsmåde kan resultere i øget latenstid og ikke-deterministisk respons, hvilket forringer realtidsegenskaberne i deres indlejrede design.

Ud over udfordringerne ved udvælgelse af hardware har leveringen af optimerede ML-modeller til edge-området yderligere udfordringer, der er unikke for indlejret udvikling. Det store antal værktøjer og metoder, der er udviklet til ML-applikationer på virksomhedsskala, kan ikke nødvendigvis tilpasses til udviklerens indlejrede applikation og driftsmiljø. Selv erfarne udviklere af indlejrede systemer, der forventer hurtigt at kunne implementere ML-baserede enheder, kan have svært ved at finde en effektiv løsning blandt et væld af tilgængelige NN-modelarkitekturer, værktøjer, rammer og arbejdsgange.

NXP beskæftiger sig med både hardwareydelse og modelimplementering i forbindelse med udvikling af edge ML. På hardwareniveau opfylder NXP's højtydende i.MX RT1170 crossover-mikrocontrollere de brede krav til ydeevne for edge ML. For at udnytte denne hardwarebase fuldt ud tilbyder NXP's eIQ (edge intelligence) ML-softwareudviklingsmiljø og applikationssoftwarepakker både uerfarne og erfarne ML-udviklere en effektiv løsning til at skabe edge-ready ML-applikationer.

En effektiv platform til udvikling af avancerede ML-applikationer

NXP i.MX RT crossover-processorer kombinerer den reelle respons i realtid og med lav latenstid fra traditionelle indlejrede mikrocontrollere med eksekveringsmulighederne fra højtydende applikationsprocessorer. NXP's i.MX RT1170 crossover-processorserie integrerer en strømeffektiv Arm® Cortex®-M4-processor og en højtydende Arm Cortex-M7-processor med et omfattende sæt funktionelle blokke og perifere enheder, der er nødvendige for at køre krævende applikationer, herunder ML-baserede løsninger i indlejrede enheder (figur 5).

Figur 5: NXP's i.MX RT1170-crossover-processorer kombinerer den strømbesparende kapacitet fra konventionelle mikrocontrollere med applikationsprocessorers højtydende behandlingskapacitet. (Billedkilde: NXP Semiconductors)

NXP eIQ-miljøet er fuldt integreret i NXP's MCUXpresso SDK og Yocto udviklingsmiljøer og er designet specielt til at lette implementeringen af inferensmodeller på indlejrede systemer, der er bygget med NXP mikroprocessorer og mikrocontrollere. eIQ Toolkit, der er inkluderet i eIQ-miljøet, understøtter BYOD- og BYOM-arbejdsgange (bring your own data) og BYOM-arbejdsgange (bring your own model) via flere værktøjer, herunder eIQ Portal, eIQ Model Tool og kommandolinjeværktøjer (figur 6).

Figur 6: NXP eIQ Toolkit understøtter BYOD-udviklere, der skal oprette en model, og BYOM-udviklere, der skal implementere deres egen eksisterende model til et målsystem. (Billedkilde: NXP Semiconductors)

eIQ Portal er designet til at understøtte BYOD-arbejdsgange for både eksperter og udviklere, der er nye inden for ML-modeludvikling, og eIQ Portal har en grafisk brugergrænseflade (GUI), der hjælper udviklerne med at gennemføre hvert trin i modeludviklingsarbejdsgangen.

I den indledende fase af udviklingen hjælper eIQ Portal's datasætkuratorværktøj udviklerne med at importere data, optage data fra et tilsluttet kamera eller optage data fra en fjernbetjeningsenhed (figur 7).

Figur 7: eIQ-portalens værktøj til kuratering af datasæt letter den kritiske opgave med at forberede træningsdata. (Billedkilde: NXP Semiconductors)

Ved hjælp af værktøjet til kuratering af datasæt kan udviklerne annotere eller mærke hvert element i datasættet ved at mærke hele billedet eller kun specifikke områder inden for en bestemt afgrænset boks. En augmenteringsfunktion hjælper udviklere med at give datasættet den nødvendige mangfoldighed ved at sløre billeder, tilføje tilfældig støj, ændre egenskaber som f.eks. lysstyrke eller kontrast og andre metoder.

I den næste fase hjælper eIQ Portal udviklerne med at vælge den type model, der passer bedst til applikationen. For udviklere, der er usikre på, hvilken type model de skal vælge, kan en modelvalgsguide hjælpe dem gennem valgprocessen baseret på applikationstypen og hardwarebasen. Udviklere, der allerede ved, hvilken type model de har brug for, kan vælge en brugerdefineret model, der leveres med eIQ-installationen, eller andre brugerdefinerede implementeringer.

eIQ Portal fører udviklerne gennem det næste kritiske træningstrin og giver en intuitiv GUI til at ændre træningsparametre og vise ændringerne i modellens forudsigelsesnøjagtighed med hvert træningstrin (figur 8).

Figur 8: Udviklerne bruger eIQ Portal's trænerværktøj til at observere forbedringerne i træningsnøjagtigheden med hvert trin og til at ændre dem om nødvendigt. (Billedkilde: NXP Semiconductors)

I det næste trin hjælper eIQ Portal GUI udviklerne med at validere modellen. I denne fase konverteres modellen til at køre på målarkitekturen for at bestemme dens faktiske ydeevne. Når valideringen er afsluttet, viser valideringsskærmen confusionmatrixen - et grundlæggende ML-valideringsværktøj, der giver udviklerne mulighed for at sammenligne inputobjektets faktiske klasse med den klasse, som modellen forudsiger (figur 9).

Figur 9: eIQ-portalens valideringsværktøj giver udviklerne den confusionmatrix, der fremkommer ved at køre en model på en målarkitektur. (Billedkilde: NXP Semiconductors)

Til den endelige implementering giver miljøet udviklerne et valg af målinferensmotorer afhængigt af processoren, herunder:

• Arm CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network) - neurale netværkskerner udviklet til at maksimere ydeevnen og minimere hukommelsesaftrykket for neurale netværk på Arm Cortex-M-processorkerner
• Arm NN SDK (neural network, software development kit) - et sæt værktøjer og en inferensmotor, der er designet til at bygge bro mellem eksisterende neurale netværksrammer og Arm Cortex-A-processorer, blandt andre
• DeepViewRT - NXPs proprietære inferensmotor til i.MX RT crossover MCU'er
• Glow NN - baseret på Metas Glow-kompiler (grafsænkning) og optimeret af NXP til Arm Cortex-M-kerner ved hjælp af funktionskald til CMSIS-NN-kerner eller Arm NN-biblioteket, hvis det er tilgængeligt, ellers ved at kompilere kode fra sit eget producentspecifikke bibliotek
• ONXX Runtime - Microsoft Researchs værktøjer, der er udviklet til at optimere ydeevnen for Arm Cortex-A-processorer.
• TensorFlow Lite for microcontrollere - en mindre version af TensorFlow Lite, optimeret til at køre maskinlæringsmodeller på i.MX RT crossover MCU'er
• TensorFlow Lite - en version af TensorFlow med understøttelse af mindre systemer

I BYOM-arbejdsgange kan udviklere bruge eIQ Model Tool til at gå direkte til modelanalyse og tidsprofilering pr. lag. Til både BYOD- og BYOM-arbejdsgange kan udviklere bruge eIQ-kommandolinjeværktøjer, som giver adgang til værktøjsfunktionalitet samt eIQ-funktioner, der ikke er tilgængelige direkte via GUI'en.

Ud over de funktioner, der er beskrevet i denne artikel, understøtter eIQ Toolkit et omfattende sæt funktioner, herunder modelkonvertering og optimering, som ligger langt uden for denne artikels rækkevidde. Til hurtig prototyping af edge-ready ML-applikationer kan udviklerne dog generelt hurtigt komme igennem udvikling og implementering uden at skulle bruge mange af de mere avancerede funktioner i eIQ-miljøet. Faktisk tilbyder specialiserede applikationssoftwarepakker (App SW) fra NXP komplette applikationer, som udviklere kan bruge til øjeblikkelig evaluering eller som grundlag for deres egne brugerdefinerede applikationer.

Hvordan man hurtigt evaluerer modeludvikling ved hjælp af en App SW Pack

NXP App SW Packs leverer en komplet ML-baseret applikation, der kombinerer produktionsklar kildekode, drivere, middleware og værktøjer. For eksempel tilbyder NXP ML State Monitor App SW Pack en øjeblikkelig ML-baseret løsning på det hyppige problem med at bestemme tilstanden af komplekse systemer baseret på sensorinput (figur 10).

Figur 10: Udviklere kan bruge NXP App SW Packs som f.eks. ML State Monitor App SW Pack til øjeblikkelig evaluering eller som grundlag for udvikling af brugerdefineret kode. (Billedkilde: NXP Semiconductors)

ML State Monitor App SW Pack implementerer en komplet løsning til en applikation, der har til formål at registrere, når en ventilator fungerer i en af fire tilstande:

• ON
• OFF
• CLOGGED, når ventilatoren er tændt, men luftstrømmen er blokeret
• FRICTION, når ventilatoren er tændt, men en eller flere ventilatorblade oplever for stor friktion under drift

Lige så vigtigt for modeludviklere er det, at ML State Monitor App SW Pack indeholder ML-modeller samt et komplet datasæt, der repræsenterer accelerometeraflæsninger fra en ventilator, der fungerer i hver af de fire tilstande.

Udviklere kan studere koden, modellerne og dataene i ML State Monitor App SW Pack for at forstå, hvordan de kan bruge sensordataene til at træne en model, oprette en inferensmodel og validere inferensen i forhold til et datasæt fra en valideringssensor. Faktisk giver NXPs ML_State_Monitor.ipynb Jupyter Notebook, der er inkluderet i App SW Pack, et øjeblikkeligt værktøj til at studere arbejdsgangen for modeludvikling i god tid før implementering af hardware.

Jupyter Notebook er en interaktiv browserbaseret Python-eksekveringsplatform, der giver udviklere mulighed for straks at se resultaterne af Python-kodeeksekvering. Når du kører en Jupyter Notebook, genereres en blok Python-kode, umiddelbart efterfulgt af resultaterne af kørslen af denne kodeblok. Disse resultater er ikke blot statiske visninger, men er de faktiske resultater, der opnås ved at køre koden. Når udviklere f.eks. kører NXPs ML_State_Monitor.ipynb Jupyter Notebook, kan de straks se en oversigt over inputdatasættet (figur 11).

Figur 11: NXPs ML_State_Monitor.ipynb Jupyter Notebook giver udviklere mulighed for at arbejde interaktivt gennem arbejdsgangen for udvikling af neurale netværksmodeller ved at se de træningsdata, der leveres i ML State Monitor App SW Pack. [Bemærk: Koden er afkortet her af hensyn til visningen.] (Billedkilde: Stephen Evanczuk, kører NXPs ML_State_Monitor.ipynb Jupyter Notebook)

Den næste sektion af koden i Notebook giver brugeren en grafisk visning af inputdataene, præsenteret som separate plot for tidsforløb og frekvens (figur 12).

Figur 12: Jupyter Notebook giver udviklere tidsserier og frekvensvisninger af datasættet for prøveblæsertilstand (OFF: grøn; ON: rød; CLOGGED: blå; FRICTION: gul). [Bemærk: Koden er afkortet af hensyn til præsentationen.] (Billedkilde: Stephen Evanczuk, kører NXPs ML_State_Monitor.ipynb Jupyter Notebook)

Yderligere kodeafsnit indeholder yderligere dataanalyse, normalisering, formning og andre forberedelser, indtil koden når frem til den samme definition af modeloprettelsesfunktionen, model_create(), som er vist tidligere i liste 1. Det næste kodeafsnit udfører denne model_create() funktion og udskriver et resumé for hurtig validering (figur 13).

Figur 13: NXPs ML_State_Monitor.ipynb Jupyter Notebook opretter modellen (vist i liste 1) og viser oplysninger om modeloversigten. (Billedkilde: Stephen Evanczuk, kører NXPs ML_State_Monitor.ipynb Jupyter Notebook)

Efter et afsnit med kode til træning og evaluering af modellerne viser ML_State_Monitor.ipynb Jupyter Notebook hver confusionmatrix for det fulde datasæt, træningsdatasættet og valideringsdatasættet (en delmængde af datasættet, der er udelukket fra træningsdatasættet). I dette tilfælde viser confusionmatrixen for hele datasættet en god nøjagtighed med en vis mængde fejl, især hvor modellen forveksler en lille procentdel af datasættene som værende i tilstanden ON, når de i virkeligheden er i tilstanden CLOGGED, som angivet i det oprindelige datasæt (figur 14).

Figur 14: Udviklere kan se confusionmatrixer som denne for det fulde datasæt. (Billedkilde: Stephen Evanczuk, kører NXPs ML_State_Monitor.ipynb Jupyter Notebook)

I et senere kodeafsnit eksporteres modellen til flere forskellige modeltyper og formater, der anvendes af de forskellige inferensmotorer, som understøttes af eIQ-udviklingsmiljøet (figur 15).

Figur 15: NXPs ML_State_Monitor.ipynb Jupyter Notebook viser, hvordan udviklere kan gemme deres trænede model i flere forskellige modeltyper og formater. (Billedkilde: Stephen Evanczuk, kører NXPs ML_State_Monitor.ipynb Jupyter Notebook)

Valget af inferensmotor kan være af afgørende betydning for at opfylde specifikke krav til ydeevne. For denne applikation målte NXP modelstørrelse, kodestørrelse og inferenstid (den tid, der kræves for at fuldføre inferens på et enkelt inputobjekt), når modellen er rettet mod flere inferensmotorer, en der kører med 996 megahertz (MHz) og en der kører med 156 MHz (figur 16 og 17).

Figur 16: Valget af modeltype kan have en dramatisk indflydelse på modellens størrelse, selv om de dramatiske forskelle, der er vist her, måske ikke gælder for større modeller. (Billedkilde: NXP Semiconductors)

Figur 17: Inferenstiden kan variere betydeligt for evaluering af et inputobjekt, når det indlæses fra RAM eller flash-hukommelse, eller når processoren drives ved en højere frekvens på 996 MHz i forhold til 156 MHz. (Billedkilde: NXP Semiconductors)

Som NXP bemærker, er der i denne prøveapplikation anvendt en meget lille model, så de ret markante forskelle, der vises i disse figurer, kan være betydeligt mindre udtalte i en større model, der anvendes til komplekse klassifikationer.

Opbygning af en systemløsning til overvågning af tilstanden

Ud over Jupyter Notebook til interaktiv udforskning af arbejdsgangen for modeludvikling indeholder NXP ML State Monitoring App SW Pack komplet kildekode til implementering af designet på NXPs MIMXRT1170-EVK-evalueringskort. Evalueringskortet er bygget op omkring en NXP MIMXRT1176DVMAA crossover MCU og udgør en omfattende hardwareplatform, komplet med ekstra hukommelse og flere grænseflader (figur 18).

Figur 18: NXPs MIMXRT1170-EVK-evalueringskort giver en omfattende hardwareplatform til udvikling af applikationer baseret på NXP i.MX RT1170-seriens crossover-MCU'er. (Billedkilde: NXP Semiconductors)

Udviklere kan bruge NXPs applikation til at forudsige en ventilators tilstand ved at stable MIMXRT1170-EVK-evalueringskortet sammen med et valgfrit NXP FRDM-STBC-AGM01-sensorkort, et Arduino-skjold og en egnet 5 volts børsteløs DC-ventilator, f.eks. Adafruits 4468 (figur 19).

Figur 19: Udviklere kan teste NXPs prøveprogram for ventilatortilstand med en simpel stak, der er bygget på MIMXRT1170-EVK-evalueringskortet. (Billedkilde: NXP Semiconductors)

Ved hjælp af det integrerede udviklingsmiljø (IDE) i MCUXpresso kan udviklere konfigurere programmet til blot at indsamle og gemme ventilatortilstandsdataene eller straks køre inferens på de indsamlede data ved hjælp af en TensorFlow-inferensmotor, DeepViewRT-inferensmotor eller Glow-inferensmotor (liste 2).

Kopi
/* 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

Liste 2: Udviklere kan nemt konfigurere NXP ML State Monitor-eksempelprogrammet ved at ændre de definitioner, der er inkluderet i headerfilen sensor_collect.h. (Billedkilde: NXP Semiconductors)

Applikationen fungerer med et ligetil procesflow. Hovedrutinen i main.c opretter en opgave kaldet MainTask, som er en rutine, der findes i modulet sensor_collect.c.

Kopi
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

Liste 3: I NXP ML State Monitor-prøveprogrammet påkalder MainTask en subtask til at indsamle data eller køre inferens. (Billedkilde: NXP Semiconductors)

MainTask udfører forskellige initialiseringsopgaver, før den starter en af to underopgaver, afhængigt af de definitioner, som brugeren har angivet i sensor_collect.h:

• hvis SENSOR_COLLECT_ACTION er sat til SENSOR_COLLECT_LOG_EXT, starter MainTask delopgaven SENSOR_Collect_LogExt_Task(), som indsamler data og gemmer dem på SD-kortet, hvis det er konfigureret
• hvis SENSOR_COLLECT_ACTION er sat til SENSOR_COLLECT_RUN_INFERENCE, starter MainTask delopgaven SENSOR_Collect_RunInf_Task(), som kører inferensmotoren (Glow, DeepViewRT eller TensorFlow) defineret i sensor_collect.h mod de indsamlede data, og hvis SENSOR_EVALUATE_MODEL er defineret, vises den resulterende præstation og klassifikationsprædiktion.

Kopier
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 */

Liste 4: NXP ML State Monitor-prøveapplikationen demonstrerer det grundlæggende designmønster for indsamling af sensordata og kørsel af den valgte inferensmotor på de indsamlede data. (Billedkilde: NXP Semiconductors)

Fordi NXP ML State Monitor App SW Pack indeholder fuld kildekode sammen med et komplet sæt nødvendige drivere og middleware, kan udviklere nemt udvide applikationen for at tilføje funktioner eller bruge den som udgangspunkt for deres egen brugerdefinerede udvikling.

Konklusion

Implementering af ML på edge i intelligente produkter i IoT og andre applikationer kan give en række effektive funktioner, men udviklerne har ofte haft svært ved at anvende ML-værktøjer og -metoder, der er udviklet til applikationer i virksomhedsskala. Med tilgængeligheden af en NXP-udviklingsplatform, der omfatter crossover-processorer og specialiseret software til udvikling af modeller, kan både ML-eksperter og udviklere med lidt eller ingen ML-erfaring mere effektivt skabe ML-applikationer, der er designet specifikt til at opfylde kravene til effektiv ydeevne i edge-områder.