Come distribuire rapidamente applicazioni di apprendimento automatico predisposte per l'edge

L'apprendimento automatico (ML) offre un enorme potenziale per la creazione di prodotti intelligenti, ma la complessità e le sfide legate alla modellazione delle reti neurali (NN) e alla creazione di applicazioni ML per l'edge hanno limitato la capacità degli sviluppatori di fornire rapidamente soluzioni utili. Sebbene strumenti facilmente reperibili abbiano reso più accessibile la creazione di modelli di ML in generale, le pratiche di sviluppo di ML convenzionali non soddisfano i requisiti unici delle soluzioni per applicazioni di Internet delle cose (IoT), automotive, sistemi industriali e altre applicazioni embedded.

Questo articolo fornisce una breve introduzione alla modellazione NN. Viene quindi presentata e descritta la modalità di utilizzo di una piattaforma ML completa di NXP Semiconductors che consente agli sviluppatori di realizzare in modo più efficace applicazioni ML predisposte per l'edge.

Una rapida rassegna della modellazione NN

Gli algoritmi di ML offrono agli sviluppatori un'opzione radicalmente diversa per lo sviluppo di applicazioni. Anziché scrivere codice software destinato a risolvere esplicitamente problemi come la classificazione delle immagini, gli sviluppatori addestrano i modelli NN presentando un insieme di dati come le immagini annotate con il nome effettivo (o la classe) dell'entità contenuta nell'immagine. Il processo di addestramento utilizza una serie di metodi per calcolare i parametri di un modello, rispettivamente i pesi e i valori di bias per ciascun neurone e strato, consentendo al modello di fornire una predizione ragionevolmente accurata della classe corretta di un'immagine in ingresso (Figura 1).

Figura 1: Le reti NN, come questa rete completamente connessa, classificano un oggetto in ingresso utilizzando i parametri di peso e bias impostati durante l'addestramento. (Immagine per gentile concessione di NXP Semiconductors)

I ricercatori di ML hanno sviluppato un'ampia gamma di architetture NN oltre alla generica NN completamente connessa mostrata nella Figura 1. Ad esempio, le applicazioni di classificazione delle immagini utilizzano tipicamente le NN convoluzionali (CNN), un'architettura specializzata che suddivide il riconoscimento delle immagini in una fase iniziale che individua le caratteristiche chiave di un'immagine, seguita da una fase di classificazione che predice la probabilità che essa appartenga a una delle diverse classi stabilite durante l'addestramento (Figura 2).

Figura 2: Gli esperti di ML utilizzano architetture NN specializzate, come questa rete neurale convoluzionale (CNN), per compiti specifici come il riconoscimento delle immagini. (Immagine per gentile concessione di NXP Semiconductors)

Sebbene la selezione di un'architettura di modello e di un regime di addestramento appropriati sia stata limitata agli esperti di ML, la disponibilità di numerosi strumenti open-source e commerciali ha semplificato notevolmente lo sviluppo di modelli per le implementazioni su larga scala. Oggi gli sviluppatori possono definire i modelli con poche righe di codice (Listato 1) e utilizzare strumenti come il visualizzatore di modelli open-source Netron per generare una rappresentazione grafica del modello (Figura 3) con cui verificare la definizione di ogni livello e la connettività.

Copy
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

Listato 1: Gli sviluppatori possono definire i modelli NN utilizzando solo poche righe di codice. (Codice per gentile concessione di NXP Semiconductors)

Figura 3: Generata dal visualizzatore Netron, questa rappresentazione grafica del modello definito nel Listato 1 può aiutare lo sviluppatore a documentare la funzione e la connettività di ciascun livello. (Immagine per gentile concessione di Stephen Evanczuk, esecuzione di Netron su codice sorgente modello NXP nel Listato 1)

Per la distribuzione finale, altri strumenti eliminano le strutture del modello necessarie solo durante l'addestramento ed eseguono altre ottimizzazioni per creare un modello di inferenza efficiente.

Perché lo sviluppo di applicazioni basate su ML per i prodotti intelligenti è così difficile

La definizione e l'addestramento di un modello per l'IoT o altri prodotti intelligenti segue un flusso di lavoro simile a quello della creazione di un modello per le applicazioni di apprendimento automatico su scala aziendale. Al di là di questa somiglianza, tuttavia, lo sviluppo di applicazioni di ML per l'edge comporta numerose sfide aggiuntive. Oltre allo sviluppo del modello, i progettisti devono affrontare il problema di sviluppare l'applicazione principale necessaria per far funzionare il loro prodotto basato su microcontroller (MCU). Di conseguenza, portare ML all'edge richiede la gestione di due flussi di lavoro interconnessi (Figura 4).

Figura 4: Lo sviluppo di un'applicazione basata su ML per l'edge estende il tipico flusso di lavoro di sviluppo delle MCU embedded con un flusso di lavoro ML necessario per addestrare, convalidare e distribuire un modello ML. (Immagine per gentile concessione di NXP Semiconductors)

Sebbene il flusso di lavoro del progetto MCU sia familiare agli sviluppatori embedded, il progetto ML può imporre ulteriori requisiti all'applicazione basata su MCU, in quanto gli sviluppatori lavorano per creare un modello di inferenza ML ottimizzato. In effetti, il progetto di ML ha un impatto notevole sui requisiti del dispositivo embedded. Il pesante carico computazionale e i requisiti di memoria solitamente associati all'esecuzione dei modelli possono superare le risorse dei microcontroller utilizzati nell'IoT e nei prodotti intelligenti. Per ridurre i requisiti di risorse, gli esperti di ML applicano tecniche come il pruning della rete di modelli, la compressione, la quantizzazione per una precisione inferiore o addirittura parametri e valori intermedi a un solo bit.

Anche con questi metodi di ottimizzazione, tuttavia, gli sviluppatori possono comunque notare che i microcontroller convenzionali non hanno le prestazioni necessarie per gestire il gran numero di operazioni matematiche associate agli algoritmi di ML. D'altro canto, l'uso di un processore applicativo ad alte prestazioni potrebbe gestire il carico computazionale di ML, ma questo approccio potrebbe comportare un aumento della latenza e una risposta non deterministica, degradando le caratteristiche in tempo reale del loro progetto embedded.

Oltre alle sfide legate alla selezione dell'hardware, la realizzazione di modelli di ML ottimizzati per l'edge presenta ulteriori problematiche uniche allo sviluppo embedded. Il gran numero di strumenti e metodi sviluppati per le applicazioni di ML su scala aziendale potrebbe non essere adatto all'applicazione e all'ambiente operativo dello sviluppatore embedded. Anche gli sviluppatori embedded esperti che si aspettano di implementare rapidamente dispositivi basati sul ML possono avere difficoltà a trovare una soluzione efficace tra le numerose architetture, strumenti, framework e flussi di lavoro disponibili per i modelli NN.

NXP si occupa sia delle prestazioni hardware sia dell'implementazione dei modelli nello sviluppo di ML per l'edge. A livello hardware, i microcontroller crossover i.MX RT1170 ad alte prestazioni di NXP soddisfano gli ampi requisiti prestazionali di ML per l'edge. Per sfruttare al meglio questa base hardware, l'ambiente di sviluppo software ML eIQ (edge intelligence) di NXP e i pacchetti software applicativi offrono agli sviluppatori ML, inesperti o esperti che siano, una soluzione efficace per creare applicazioni ML predisposte per l'edge.

Una piattaforma efficace per lo sviluppo di applicazioni ML predisposte per l'edge

I processori crossover i.MX RT di NXP combinano la risposta in tempo reale e a bassa latenza dei microcontroller embedded tradizionali con le capacità di esecuzione dei processori applicativi ad alte prestazioni. La serie di processori crossover i.MX RT1170 di NXP integra un processore ARM®Cortex®-M4 ad alta efficienza energetica e un processore ARM Cortex-M7 ad alte prestazioni con un'ampia serie di blocchi funzionali e periferiche necessari per eseguire applicazioni complesse, tra cui soluzioni basate su ML in dispositivi embedded (Figura 5).

Figura 5: I processori crossover i.MX RT1170 di NXP combinano la capacità di efficienza energetica dei microcontroller convenzionali con la capacità di elaborazione ad alte prestazioni dei processori applicativi. (Immagine per gentile concessione di NXP Semiconductors)

Completamente integrato negli ambienti di sviluppo SDK MCUXpresso e Yocto di NXP, l'ambiente eIQ di NXP è progettato appositamente per facilitare l'implementazione di modelli di inferenza sui sistemi embedded realizzati con microprocessori e microcontroller NXP. Incluso nell'ambiente eIQ, eIQ Toolkit supporta i flussi di lavoro BYOM (Bring Your Own Data) e BYOM (Bring Your Own Model) attraverso diversi strumenti, tra cui eIQ Portal, eIQ Model Tool e gli strumenti a riga di comando (Figura 6).

Figura 6: eIQ Toolkit di NXP supporta gli sviluppatori BYOD che devono creare un modello e gli sviluppatori BYOM che devono distribuire il modello esistente su un sistema finale. (Immagine per gentile concessione di NXP Semiconductors)

Progettato per supportare i flussi di lavoro BYOD sia per gli sviluppatori esperti sia per quelli alle prime armi con lo sviluppo di modelli di ML, il portale eIQ fornisce un'interfaccia grafica utente (GUI) che aiuta a completare più facilmente ogni fase del flusso di lavoro di sviluppo del modello.

Nella fase iniziale dello sviluppo, lo strumento per set di dati del portale eIQ aiuta gli sviluppatori a importare i dati, acquisire i dati da una telecamera collegata o da un dispositivo remoto (Figura 7).

Figura 7: Lo strumento per set di dati del portale eIQ facilita il compito critico della preparazione dei dati di addestramento. (Immagine per gentile concessione di NXP Semiconductors)

Utilizzando lo strumento per set di dati, gli sviluppatori annotano ogni elemento del set etichettando l'intera immagine o solo regioni specifiche contenute in un riquadro di delimitazione specificato. Una funzione di incremento aiuta gli sviluppatori a fornire la diversità necessaria al set di dati sfocando le immagini, aggiungendo rumore casuale, modificando caratteristiche come la luminosità o il contrasto e altri metodi.

Nella fase successiva, il portale eIQ aiuta gli sviluppatori a selezionare il tipo di modello più adatto all'applicazione. Per gli sviluppatori incerti sul tipo di modello, una procedura guidata di selezione del modello li guida attraverso il processo di selezione in base al tipo di applicazione e alla base hardware. Gli sviluppatori che conoscono già il tipo di modello desiderato possono selezionare un modello personalizzato fornito con l'installazione di eIQ o altre implementazioni personalizzate.

Il portale eIQ accompagna gli sviluppatori nella fase di addestramento successiva, fornendo un'interfaccia grafica intuitiva per modificare i parametri di addestramento e visualizzare i cambiamenti nell'accuratezza della predizione del modello con ogni fase di addestramento (Figura 8).

Figura 8: Gli sviluppatori utilizzano lo strumento di addestramento del portale eIQ per osservare i miglioramenti nell'accuratezza dell'addestramento a ogni passo e per modificarli qualora sia necessario. (Immagine per gentile concessione di NXP Semiconductors)

Nella fase successiva, l'interfaccia grafica del portale eIQ aiuta gli sviluppatori a convalidare il modello. In questa fase, il modello viene convertito per l'esecuzione sull'architettura target, per determinarne le prestazioni effettive. Al termine della convalida, la schermata visualizza la matrice di confusione, uno strumento di convalida ML fondamentale che consente agli sviluppatori di confrontare la classe effettiva dell'oggetto in ingresso con la classe prevista dal modello (Figura 9).

Figura 9: Lo strumento di convalida del portale eIQ fornisce agli sviluppatori la matrice di confusione risultante dall'esecuzione di un modello su un'architettura target. (Immagine per gentile concessione di NXP Semiconductors)

Per la distribuzione finale, l'ambiente offre agli sviluppatori una scelta di motori di inferenza target, a seconda del processore, tra cui:

• ARM CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network): kernel per reti neurali sviluppati per massimizzare le prestazioni e ridurre al minimo l'ingombro di memoria delle reti neurali sui core del processore ARM Cortex-M;
• ARM NN SDK (Neural Network, Software Development Kit): una serie di strumenti e un motore di inferenza progettati per creare un ponte tra i framework di reti neurali esistenti e i processori ARM Cortex-A, e non solo;
• DeepViewRT: motore di inferenza proprietario di NXP per MCU crossover i.MX RT;
• Glow NN: basato sul compilatore Glow (Graph Lowering) di Meta e ottimizzato da NXP per i core ARM Cortex-M utilizzando chiamate di funzione ai kernel CMSIS-NN o alla libreria ARM NN, se disponibili, altrimenti compilando il codice dalla propria libreria nativa;
• ONXX Runtime: strumenti di Microsoft Research progettati per ottimizzare le prestazioni dei processori ARM Cortex-A;
• TensorFlow Lite for Microcontrollers: una versione più piccola di TensorFlow Lite, ottimizzata per l'esecuzione di modelli di apprendimento automatico sugli MCU crossover i.MX RT;
• TensorFlow Lite: una versione di TensorFlow che offre supporto per sistemi più piccoli.

Per i flussi di lavoro BYOM, gli sviluppatori possono utilizzare eIQ Model Tool per passare direttamente all'analisi del modello e alla profilazione temporale per strato. Sia per i flussi di lavoro BYOD che per quelli BYOM, gli sviluppatori possono utilizzare gli strumenti a riga di comando di eIQ, che consentono di accedere alle funzionalità dello strumento e alle caratteristiche di eIQ non disponibili direttamente tramite l'interfaccia grafica.

Oltre alle funzioni descritte in questo articolo, eIQ Toolkit supporta un'ampia serie di funzionalità, tra cui la conversione e l'ottimizzazione dei modelli, che vanno ben oltre lo scopo di questo articolo. Tuttavia, per la prototipazione rapida di applicazioni ML predisposte per l'edge, gli sviluppatori possono in genere procedere rapidamente con lo sviluppo e la distribuzione, senza dover ricorrere a molte delle funzionalità più sofisticate dell'ambiente eIQ. Infatti, i pacchetti specializzati di software applicativo (App SW) di NXP offrono applicazioni complete che gli sviluppatori possono utilizzare per la valutazione immediata o come base per le proprie applicazioni personalizzate.

Come valutare rapidamente lo sviluppo del modello utilizzando un pacchetto App SW

I pacchetti App SW di NXP forniscono un'applicazione completa basata su ML, combinando codice sorgente, driver, middleware e strumenti pronti per la produzione. Ad esempio, il pacchetto App SW ML State Monitor di NXP offre una soluzione immediata basata su ML al problema frequente di determinare lo stato di sistemi complessi sulla base degli input dei sensori (Figura 10).

Figura 10: Gli sviluppatori possono utilizzare i pacchetti App SW di NXP, come ML State Monitor, per una valutazione immediata o come base per lo sviluppo di codice personalizzato. (Immagine per gentile concessione di NXP Semiconductors)

Il pacchetto App SW ML State Monitor implementa una soluzione completa per un'applicazione destinata a rilevare quando una ventola funziona in uno dei quattro stati:

• ON
• OFF
• CLOGGED, quando è acceso, ma il flusso d'aria è ostruito
• FRICTION, quando è acceso ma una o più pale incontrano un attrito eccessivo durante il funzionamento

Altrettanto importante per gli sviluppatori di modelli, il pacchetto App SW ML State Monitor include modelli ML e un set di dati completo che rappresenta le letture dell'accelerometro di una ventola funzionante in ciascuno dei quattro stati.

Gli sviluppatori possono studiare il codice, i modelli e i dati forniti nel pacchetto App SW ML State Monitor per capire come utilizzare i dati del sensore per addestrare un modello, creare un modello di inferenza e convalidare l'inferenza rispetto a un set di dati del sensore di convalida. Infatti, ML_State_Monitor.ipynb Jupyter Notebook di NXP, incluso nel pacchetto App SW, è uno strumento immediato e pronto per l'uso per studiare il flusso di lavoro di sviluppo del modello ben prima della distribuzione dell'hardware.

Jupyter Notebook è una piattaforma interattiva di esecuzione Python basata su browser che consente agli sviluppatori di visualizzare immediatamente i risultati dell'esecuzione di codice Python. L'esecuzione di un Jupyter Notebook genera un blocco di codice Python, immediatamente seguito dai risultati dell'esecuzione di quel blocco di codice. Questi risultati non sono semplici visualizzazioni statiche, ma sono i risultati effettivi ottenuti dall'esecuzione del codice. Ad esempio, quando gli sviluppatori eseguono ML_State_Monitor.ipynb Jupyter Notebook di NXP, possono visualizzare immediatamente un riepilogo del set di dati in ingresso (Figura 11).

Figura 11: ML_State_Monitor.ipynb Jupyter Notebook di NXP consente agli sviluppatori di lavorare in modo interattivo attraverso il flusso di lavoro di sviluppo del modello di rete neurale, visualizzando i dati di addestramento forniti nel pacchetto App SW ML State Monitor. [Nota: codice troncato per motivi di visualizzazione.] (Immagine per gentile concessione di Stephen Evanczuk, che esegue ML_State_Monitor.ipynb Jupyter Notebook di NXP)

La successiva sezione di codice Notebook fornisce all'utente una visualizzazione grafica dei dati in ingresso, presentati come grafici separati per sequenza temporale e frequenza (Figura 12).

Figura 12: Jupyter Notebook fornisce agli sviluppatori serie temporali e visualizzazioni di frequenza del set di dati sullo stato della ventola (OFF: verde; ON: rosso; CLOGGED: blu; FRICTION: giallo). [Nota: Codice troncato per motivi di presentazione.] (Immagine per gentile concessione di Stephen Evanczuk, che esegue ML_State_Monitor.ipynb Jupyter Notebook di NXP)

Altre sezioni di codice forniscono ulteriori analisi dei dati, normalizzazione, modellazione e altre preparazioni, fino a quando l'esecuzione del codice raggiunge la stessa definizione della funzione di creazione del modello, model_create(), mostrata in precedenza nel Listato 1. La sezione di codice successiva esegue la funzione model_create() e stampa un riepilogo per una rapida convalida (Figura 13).

Figura 13: ML_State_Monitor.ipynb Jupyter Notebook di NXP crea il modello (mostrato nel Listato 1) e visualizza le informazioni di riepilogo del modello. (Immagine per gentile concessione di Stephen Evanczuk, che esegue ML_State_Monitor.ipynb Jupyter Notebook di NXP)

Dopo una sezione di codice per l'addestramento e la valutazione del modello, ML_State_Monitor.ipynb Jupyter Notebook visualizza ogni matrice di confusione per il set di dati completo, il set di dati di addestramento e il set di dati di convalida (un sottoinsieme set di dati escluso da quello di addestramento). In questo caso, la matrice di confusione per l'intero set di dati mostra una buona accuratezza con una certa quantità di errori, in particolare quando il modello confonde una piccola percentuale del set di dati come nello stato ON quando in realtà sono nello stato CLOGGED, come annotato nel set di dati originale (Figura 14).

Figura 14: Gli sviluppatori possono visualizzare matrici di confusione come questa per l'intero set di dati. (Immagine per gentile concessione di Stephen Evanczuk, che esegue ML_State_Monitor.ipynb Jupyter Notebook di NXP)

In una sezione di codice successiva, il modello viene esportato in diversi tipi e formati utilizzati dai vari motori di inferenza supportati dall'ambiente di sviluppo eIQ (Figura 15).

Figura 15: ML_State_Monitor.ipynb Jupyter Notebook di NXP mostra come gli sviluppatori possano salvare il modello addestrato in diversi tipi e formati. (Immagine per gentile concessione di Stephen Evanczuk, che esegue ML_State_Monitor.ipynb Jupyter Notebook di NXP)

La scelta del motore di inferenza può essere di fondamentale importanza per soddisfare specifici requisiti prestazionali. Per questa applicazione, NXP ha misurato la grandezza del modello, la dimensione del codice e il tempo di inferenza (tempo necessario per completare l'inferenza su un singolo oggetto in ingresso) quando il modello è destinato a diversi motori di inferenza, uno funzionante a 996 MHz e uno a 156 MHz (Figure 16 e 17).

Figura 16: La scelta del tipo di modello può avere un grande impatto sulla grandezza del modello, anche se le differenze sostanziali mostrate qui potrebbero non valere per i modelli più grandi. (Immagine per gentile concessione di NXP Semiconductors)

Figura 17: Il tempo di inferenza può differire significativamente per la valutazione di un oggetto in ingresso quando viene caricato dalla RAM o dalla memoria flash o quando il processore funziona a una frequenza più alta di 996 MHz rispetto a 156 MHz. (Immagine per gentile concessione di NXP Semiconductors)

Come nota NXP, questa applicazione campione utilizza un modello molto piccolo, quindi le differenze piuttosto marcate mostrate in queste figure potrebbero essere sostanzialmente meno pronunciate in un modello più grande utilizzato per classificazioni complesse.

Creare una soluzione di sistema per il monitoraggio dello stato

Oltre a Jupyter Notebook per l'esplorazione interattiva del flusso di lavoro di sviluppo del modello, il pacchetto App SW ML State Monitoring di NXP fornisce il codice sorgente completo per l'implementazione del progetto sulla scheda di valutazione MIMXRT1170-EVK di NXP. Pensata per un MCU crossover MIMXRT1176DVMAA di NXP, la scheda di valutazione è una piattaforma hardware completa, con memoria aggiuntiva e molteplici interfacce (Figura 18).

Figura 18: La scheda di valutazione MIMXRT1170-EVK di NXP offre una piattaforma hardware completa per lo sviluppo di applicazioni basate sull'MCU crossover serie i.MX RT1170 di NXP. (Immagine per gentile concessione di NXP Semiconductors)

Gli sviluppatori possono utilizzare l'applicazione Fan State di NXP per predire lo stato di un ventola impilando la scheda di valutazione MIMXRT1170-EVK su una scheda sensore opzionale FRDM-STBC-AGM01 di NXP, uno shield Arduino e una ventola c.c. brushless da 5 V adatta, come 4468 di Adafruit (Figura 19).

Figura 19: Gli sviluppatori possono testare l'applicazione di esempio dello stato della ventola di NXP con un semplice stack costruito sulla scheda di valutazione MIMXRT1170-EVK. (Immagine per gentile concessione di NXP Semiconductors)

Utilizzando l'ambiente di sviluppo integrato (IDE) MCUXpresso, gli sviluppatori possono configurare l'applicazione in modo da acquisire e memorizzare semplicemente i dati di stato della ventola oppure eseguire immediatamente l'inferenza sui dati acquisiti utilizzando un motore di inferenza TensorFlow, un motore di inferenza DeepViewRT o un motore di inferenza Glow (Listato 2).

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

Listato 2: Gli sviluppatori possono facilmente configurare l'applicazione di esempio ML State Monitor di NXP modificando le definizioni incluse nel file di intestazione sensor_collect.h. (Codice per gentile concessione di NXP Semiconductors)

L'applicazione funziona con un flusso di processo semplice. La routine principale in main.c crea un task chiamato MainTask, una routine che si trova nel modulo sensor_collect.c.

Copy
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

Listato 3: Nell'applicazione di esempio ML State Monitor di NXP, MainTask invoca un sottotask per acquisire dati o eseguire l'inferenza. (Codice per gentile concessione di NXP Semiconductors)

MainTask esegue varie operazioni di inizializzazione prima di avviare uno dei due sottotask, a seconda delle definizioni impostate dall'utente in sensor_collect.h:

• se SENSOR_COLLECT_ACTION è impostato su SENSOR_COLLECT_LOG_EXT, MainTask avvia il sottotask SENSOR_Collect_LogExt_Task(), che raccoglie i dati e li memorizza sulla scheda SD, se configurata;
• se SENSOR_COLLECT_ACTION è impostato su SENSOR_COLLECT_RUN_INFERENCE, MainTask avvia il sottotask SENSOR_Collect_RunInf_Task(), che esegue il motore di inferenza (Glow, DeepViewRT o TensorFlow) definito in sensor_collect.h sui dati raccolti e, se è definito SENSOR_EVALUATE_MODEL, visualizza le prestazioni risultanti e la predizione di classificazione.

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

Listato 4: L'applicazione di esempio ML State Monitor di NXP dimostra il modello di progettazione di base per l'acquisizione dei dati del sensore e l'esecuzione del motore di inferenza selezionato sui dati acquisiti. (Codice per gentile concessione di NXP Semiconductors)

Poiché il pacchetto App SW ML State Monitor di NXP fornisce il codice sorgente completo insieme a una serie di driver e middleware necessari, gli sviluppatori possono facilmente estendere l'applicazione per aggiungere funzionalità o utilizzarla come punto di partenza per lo sviluppo personalizzato.

Conclusione

L'implementazione di ML per l'edge di prodotti intelligenti nell'IoT e in altre applicazioni può fornire una serie di potenti funzionalità, ma spesso gli sviluppatori hanno difficoltà ad applicare strumenti e metodi di ML sviluppati per applicazioni su scala aziendale. Grazie alla disponibilità di una piattaforma di sviluppo NXP che comprende processori crossover e un software specializzato per lo sviluppo di modelli, sia gli esperti di ML sia gli sviluppatori con poca o nessuna esperienza di ML possono creare più efficacemente applicazioni di ML progettate specificamente per soddisfare i requisiti di efficienza delle prestazioni edge.