Déployer rapidement des applications d'apprentissage automatique prêtes pour une utilisation en périphérie

L'apprentissage machine (ML, Machine Learning) offre un potentiel énorme pour créer des produits intelligents, mais la complexité et les défis liés à la modélisation des réseaux neuronaux (NN) et à la création d'applications ML pour la périphérie limitent la capacité des développeurs à fournir rapidement des solutions utiles. Bien que des outils facilement disponibles aient rendu la création de modèles ML plus accessible en général, les pratiques de développement ML conventionnelles ne sont pas conçues pour répondre aux exigences uniques des solutions pour l'Internet des objets (IoT), l'industrie automobile, les systèmes industriels et d'autres applications embarquées.

Cet article propose une brève introduction à la modélisation NN. Il présente et décrit ensuite comment utiliser une plateforme ML complète de NXP Semiconductors qui permet aux développeurs de fournir plus efficacement des applications ML prêtes pour une utilisation en périphérie.

Aperçu rapide de la modélisation NN

Les algorithmes ML offrent aux développeurs une option radicalement différente pour le développement d'applications. Plutôt que d'écrire un code logiciel destiné à résoudre explicitement des problèmes tels que la classification d'images, les développeurs entraînent les modèles NN en présentant un ensemble de données telles que des images annotées avec le nom réel (ou la classe) de l'entité contenue dans l'image. Le processus d'apprentissage utilise diverses méthodes pour calculer les paramètres du modèle, à savoir les poids et les valeurs de biais pour chaque neurone et chaque couche, respectivement, ce qui permet au modèle de fournir une prédiction raisonnablement précise de la classe correcte d'une image d'entrée (Figure 1).

Figure 1 : Les réseaux neuronaux tels que ce réseau entièrement connecté classifient un objet d'entrée en utilisant les paramètres de poids et de biais définis pendant l'entraînement. (Source de l'image : NXP Semiconductors)

Les chercheurs ML ont développé un large éventail d'architectures NN s'étendant au-delà du réseau neuronal générique entièrement connecté illustré à la Figure 1. Par exemple, les applications de classification d'images utilisent généralement un réseau neuronal convolutif (CNN), une architecture spécialisée qui divise la reconnaissance d'images en une phase initiale qui identifie les caractéristiques clés d'une image, suivie d'une phase de classification qui prédit la probabilité qu'elle appartienne à l'une des classes établies pendant l'entraînement (Figure 2).

Figure 2 : Les experts en ML utilisent des architectures NN spécialisées telles que ce réseau neuronal convolutif (CNN) pour des tâches spécifiques telles que la reconnaissance d'images. (Source de l'image : NXP Semiconductors)

Bien que la sélection d'une architecture de modèle et d'un programme d'entraînement appropriés soit limitée aux experts ML, la disponibilité de multiples outils commerciaux et open-source a considérablement simplifié le développement de modèles pour les déploiements à grande échelle. Aujourd'hui, les développeurs peuvent définir des modèles avec quelques lignes de code (Liste 1), et utiliser des outils tels que le visualiseur de modèles open-source Netron pour générer une représentation graphique du modèle (Figure 3) afin de vérifier la définition et la connectivité de chaque couche.

Copier
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

Liste 1 : Les développeurs peuvent définir des modèles NN avec seulement quelques lignes de code. (Source du code : NXP Semiconductors)

Figure 3 : Générée par le visualiseur Netron, cette représentation graphique du modèle défini dans la Liste 1 peut aider le développeur à documenter la fonction et la connectivité de chaque couche. (Source de l'image : Stephen Evanczuk, exécutant Netron sur le code source du modèle NXP dans la Liste 1)

Pour le déploiement final, d'autres outils éliminent les structures du modèle qui ne sont nécessaires que pendant l'entraînement et effectuent d'autres optimisations pour créer un modèle d'inférence efficace.

Pourquoi le développement d'applications basées ML pour les produits intelligents est-il si difficile ?

La définition et l'entraînement d'un modèle pour l'IoT ou d'autres produits intelligents suivent un flux de travail similaire à la création d'un modèle pour les applications d'apprentissage automatique à l'échelle de l'entreprise. Au-delà de cette similitude, cependant, le développement d'applications ML pour la périphérie présente de multiples défis supplémentaires. En plus du développement de modèles, les concepteurs sont confrontés aux défis bien connus de développer l'application principale requise pour faire fonctionner leur produit basé sur un microcontrôleur (MCU). Par conséquent, l'introduction de l'apprentissage automatique en périphérie nécessite la gestion de deux flux de travail interdépendants (Figure 4).

Figure 4 : Le développement d'une application basée ML pour la périphérie étend le flux de travail typique de développement de microcontrôleur embarqué avec un flux de travail ML nécessaire pour entraîner, valider et déployer un modèle ML. (Source de l'image : NXP Semiconductors)

Même si les développeurs de systèmes embarqués sont familiarisés avec le flux de travail de projet MCU, le projet ML peut imposer des exigences supplémentaires à l'application basée sur microcontrôleur, car les développeurs travaillent à la création d'un modèle d'inférence ML optimisé. En fait, le projet ML a un impact considérable sur les exigences du dispositif embarqué. La lourde charge de calcul et les besoins en mémoire généralement associés à l'exécution des modèles peuvent dépasser les ressources des microcontrôleurs utilisés dans l'IoT et les produits intelligents. Pour réduire les besoins en ressources, les experts ML appliquent des techniques telles que la réduction du réseau de modèles, la compression, la quantification à une précision inférieure, voire des paramètres à un seul bit et des valeurs intermédiaires, ainsi que d'autres méthodes.

Cependant, même avec ces méthodes d'optimisation, les développeurs peuvent constater que les microcontrôleurs conventionnels n'ont pas les performances nécessaires pour traiter le grand nombre d'opérations mathématiques associées aux algorithmes ML. D'autre part, l'utilisation d'un processeur d'application hautes performances pourrait prendre en charge la charge de calcul ML, mais cette approche pourrait entraîner une latence accrue et une réponse non déterministe, dégradant ainsi les caractéristiques en temps réel de leur conception embarquée.

Outre les défis liés à la sélection du matériel, l'élaboration de modèles ML optimisés pour la périphérie présente des difficultés supplémentaires propres au développement embarqué. Le grand nombre d'outils et de méthodes développés pour les applications ML à l'échelle de l'entreprise peut ne pas être adapté à l'application et à l'environnement d'exploitation du développeur de systèmes embarqués. Même les développeurs de systèmes embarqués chevronnés qui s'attendent à déployer rapidement des dispositifs basés ML peuvent avoir du mal à trouver une solution efficace parmi la multitude d'architectures, d'outils, de structures et de flux de travail disponibles pour les modèles NN.

NXP s'intéresse à la fois aux performances matérielles et aux aspects d'implémentation des modèles dans le développement ML en périphérie. Au niveau matériel, les microcontrôleurs crossovers hautes performances i.MX RT1170 de NXP répondent aux vastes exigences de performances ML en périphérie. Pour tirer pleinement parti de cette base matérielle, l'environnement de développement logiciel ML eIQ (Edge Intelligence) de NXP et les progiciels d'application offrent aux développeurs ML, qu'ils soient débutants ou expérimentés, une solution efficace pour créer des applications ML prêtes pour une utilisation en périphérie.

Une plateforme efficace pour le développement d'applications ML prêtes pour une utilisation en périphérie

Les processeurs crossovers i.MX RT de NXP combinent la réponse à faible latence en temps réel des microcontrôleurs embarqués traditionnels avec les capacités d'exécution des processeurs d'application hautes performances. La série i.MX RT1170 de processeurs crossovers de NXP intègre un processeur Arm® Cortex®-M4 basse consommation et un processeur Arm Cortex-M7 hautes performances, ainsi qu'un ensemble complet de blocs fonctionnels et de périphériques nécessaires à l'exécution d'applications exigeantes, y compris les solutions basées ML dans les dispositifs embarqués (Figure 5).

Figure 5 : Les processeurs crossovers i.MX RT1170 de NXP combinent la capacité de rendement énergétique des microcontrôleurs classiques avec la capacité de traitement hautes performances des processeurs d'application. (Source de l'image : NXP Semiconductors)

Entièrement intégré aux environnements de développement Yocto et MCUXpresso SDK de NXP, l'environnement eIQ de NXP est spécifiquement conçu pour faciliter la mise en œuvre de modèles d'inférence sur les systèmes embarqués construits avec des microprocesseurs et microcontrôleurs de NXP. Inclus dans l'environnement eIQ, l'eIQ Toolkit prend en charge les flux de travail BYOD (Bring Your Own Data) et BYOM (Bring Your Own Model) par le biais de plusieurs outils, notamment le portail eIQ, l'outil eIQ Model Tool et les outils de ligne de commande (Figure 6).

Figure 6 : L'eIQ Toolkit de NXP aide les développeurs BYOD qui doivent créer un modèle et les développeurs BYOM qui doivent déployer leur propre modèle existant sur un système cible. (Source de l'image : NXP Semiconductors)

Conçu pour prendre en charge les flux de travail BYOD, tant pour les experts que pour les débutants en matière de développement de modèles ML, le portail eIQ offre une interface utilisateur graphique (GUI) qui aide les développeurs à accomplir plus facilement chaque étape du flux de travail de développement de modèles.

Dans la phase initiale de développement, l'outil Data Set Curator du portail eIQ aide les développeurs à importer des données, à capturer des données à partir d'une caméra connectée ou à capturer des données à partir d'un dispositif à distance (Figure 7).

Figure 7 : L'outil Data Set Curator du portail eIQ facilite la tâche critique de préparation des données d'entraînement. (Source de l'image : NXP Semiconductors)

À l'aide de l'outil Data Set Curator, les développeurs annotent, ou étiquettent, chaque élément de l'ensemble de données en étiquetant l'image entière, ou seulement des régions spécifiques contenues dans une zone de délimitation spécifiée. Une fonction d'augmentation aide les développeurs à apporter la diversité nécessaire à l'ensemble de données en rendant les images floues, en ajoutant du bruit aléatoire, en modifiant des caractéristiques telles que la luminosité ou le contraste, et en appliquant d'autres méthodes.

Dans la phase suivante, le portail eIQ aide les développeurs à sélectionner le type de modèle le mieux adapté à l'application. Pour les développeurs incertains quant au type de modèle, un assistant de sélection de modèle les guide dans le processus de sélection en fonction du type d'application et de la base matérielle. Les développeurs qui savent déjà de quel type de modèle ils ont besoin peuvent choisir un modèle personnalisé fourni avec l'installation eIQ ou d'autres implémentations personnalisées.

Le portail eIQ guide les développeurs à travers l'étape suivante d'entraînement critique, en fournissant une interface graphique intuitive permettant de modifier les paramètres d'entraînement et de visualiser les changements de précision de prédiction du modèle à chaque étape d'entraînement (Figure 8).

Figure 8 : Les développeurs utilisent l'outil d'entraînement Trainer du portail eIQ pour observer l'amélioration de la précision d'entraînement à chaque étape, et pour modifier les paramètres, si nécessaire. (Source de l'image : NXP Semiconductors)

À l'étape suivante, l'interface graphique du portail eIQ aide les développeurs à valider le modèle. À ce stade, le modèle est converti pour fonctionner sur l'architecture cible afin de déterminer ses performances réelles. Une fois la validation terminée, l'écran de validation affiche la matrice de confusion — un outil de validation ML fondamental qui permet aux développeurs de comparer la classe réelle de l'objet d'entrée avec la classe prédite par le modèle (Figure 9).

Figure 9 : L'outil de validation du portail eIQ fournit aux développeurs la matrice de confusion résultant de l'exécution d'un modèle sur une architecture cible. (Source de l'image : NXP Semiconductors)

Pour le déploiement final, l'environnement offre aux développeurs un choix de moteurs d'inférence cibles en fonction du processeur, notamment :

• Arm CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network) — Noyaux de réseaux neuronaux développés pour maximiser les performances et minimiser l'empreinte mémoire des réseaux neuronaux sur les cœurs de processeurs Arm Cortex-M
• Arm NN SDK (Neural Network, Software Development Kit) — Ensemble d'outils et moteur d'inférence conçus pour faire le lien entre les structures de réseaux neuronaux existantes et les processeurs Arm Cortex-A, entre autres
• DeepViewRT — Moteur d'inférence propriétaire de NXP pour les microntrôleurs crossovers i.MX RT
• Glow NN — Basé sur le compilateur Glow de Meta et optimisé par NXP pour les cœurs Arm Cortex-M en utilisant des appels de fonction vers les noyaux CMSIS-NN ou la bibliothèque Arm NN si disponible, sinon en compilant le code à partir de sa propre bibliothèque native
• ONXX Runtime — Outils de Microsoft Research conçus pour optimiser les performances des processeurs Arm Cortex-A
• TensorFlow Lite for Microcontrollers — Version réduite de TensorFlow Lite, optimisée pour l'exécution de modèles d'apprentissage automatique sur les microcontrôleurs crossovers i.MX RT
• TensorFlow Lite — Version de TensorFlow prenant en charge les systèmes plus petits

Pour les flux de travail BYOM, les développeurs peuvent utiliser l'outil eIQ Model Tool pour passer directement à l'analyse du modèle et au profilage temporel par couche. Pour les flux de travail BYOD et BYOM, les développeurs peuvent utiliser les outils de ligne de commande eIQ qui donnent accès aux fonctionnalités d'outils, ainsi qu'aux fonctionnalités eIQ qui ne sont pas directement disponibles via l'interface utilisateur graphique.

Outre les fonctionnalités décrites dans cet article, l'eIQ Toolkit prend en charge un vaste ensemble de capacités, notamment la conversion et l'optimisation de modèles, qui dépassent largement le cadre de cet article. Cependant, pour le prototypage rapide d'applications ML prêtes pour une utilisation en périphérie, les développeurs peuvent généralement passer rapidement au développement et au déploiement sans avoir besoin d'utiliser les capacités les plus sophistiquées de l'environnement eIQ. En fait, les progiciels d'application spécialisés (App SW) de NXP offrent des applications complètes que les développeurs peuvent utiliser pour une évaluation immédiate ou comme base de leurs propres applications personnalisées.

Comment évaluer rapidement le développement d'un modèle à l'aide d'un progiciel App SW

Les progiciels d'application spécialisés de NXP fournissent une application basée ML complète, combinant le code source, des pilotes, des intergiciels et des outils prêts pour la production. Par exemple, le progiciel ML State Monitor App SW Pack de NXP offre une solution basée ML immédiate au problème fréquent de détermination de l'état de systèmes complexes à partir d'entrées de capteurs (Figure 10).

Figure 10 : Les développeurs peuvent utiliser les progiciels d'application spécialisés de NXP, tels que le ML State Monitor App SW Pack, pour une évaluation immédiate ou comme base pour le développement de code personnalisé. (Source de l'image : NXP Semiconductors)

Le progiciel ML State Monitor App SW Pack implémente une solution complète pour une application destinée à détecter quand un ventilateur fonctionne dans l'un de ces quatre états :

• ON (marche)
• OFF (arrêt)
• CLOGGED, lorsque le ventilateur est en marche mais que le flux d'air est obstrué
• FRICTION, lorsque le ventilateur est en marche mais qu'une ou plusieurs pales du ventilateur rencontrent une friction excessive pendant le fonctionnement

Tout aussi important pour les développeurs de modèles, le ML State Monitor App SW Pack inclut des modèles ML ainsi qu'un ensemble complet de données représentant les relevés de l'accéléromètre d'un ventilateur fonctionnant dans chacun de ces quatre états.

Les développeurs peuvent étudier le code, les modèles et les données fournis dans le ML State Monitor App SW Pack pour comprendre comment utiliser les données de capteur pour entraîner un modèle, créer un modèle d'inférence et valider l'inférence par rapport à un ensemble de données de capteur de validation. En fait, Jupyter Notebook ML_State_Monitor.ipynb de NXP, inclus dans le progiciel d'application spécialisé, fournit un outil immédiat et prêt à l'emploi pour étudier le flux de travail de développement du modèle bien avant tout déploiement matériel.

Jupyter Notebook est une plateforme d'exécution Python interactive basée sur un navigateur qui permet aux développeurs de visualiser immédiatement les résultats d'exécution de code Python. L'exécution d'un Jupyter Notebook génère un bloc de code Python, immédiatement suivi des résultats de l'exécution de ce bloc de code. Ces résultats ne sont pas de simples affichages statiques mais les résultats réels obtenus en exécutant le code. Par exemple, lorsque les développeurs exécutent Jupyter Notebook ML_State_Monitor.ipynb de NXP, ils peuvent immédiatement visualiser un résumé de l'ensemble de données d'entrée (Figure 11).

Figure 11 : Jupyter Notebook ML_State_Monitor.ipynb de NXP permet aux développeurs de travailler de manière interactive dans le flux de travail de développement de modèles de réseaux neuronaux, en visualisant les données d'entraînement fournies dans le progiciel ML State Monitor App SW Pack. [Note : le code est tronqué ici pour des raisons d'affichage]. (Source de l'image : Stephen Evanczuk, exécutant Jupyter Notebook ML_State_Monitor.ipynb de NXP)

La section suivante du code dans Notebook fournit à l'utilisateur un affichage graphique des données d'entrée, présentées sous forme de tracés séparés pour la séquence temporelle et la fréquence (Figure 12).

Figure 12 : Jupyter Notebook fournit aux développeurs des séries temporelles et des affichages de fréquence de l'ensemble de données sur l'état du ventilateur d'exemple (OFF : vert, ON : rouge, CLOGGED : bleu, FRICTION : jaune). [Note : le code a été tronqué pour des raisons de présentation]. (Source de l'image : Stephen Evanczuk, exécutant Jupyter Notebook ML_State_Monitor.ipynb de NXP)

D'autres sections de code permettent de poursuivre l'analyse, la normalisation et la mise en forme des données, ainsi que d'autres préparatifs, jusqu'à ce que l'exécution du code atteigne la même définition de fonction de création de modèle, model_create(), illustrée précédemment dans la Liste 1. La section de code suivante exécute cette fonction model_create() et imprime un résumé pour une validation rapide (Figure 13).

Figure 13 : Jupyter Notebook ML_State_Monitor.ipynb de NXP crée le modèle (illustré dans la Liste 1) et affiche les informations de synthèse du modèle. (Source de l'image : Stephen Evanczuk, exécutant Jupyter Notebook ML_State_Monitor.ipynb de NXP)

Après une section de code pour l'entraînement et l'évaluation du modèle, Jupyter Notebook ML_State_Monitor.ipynb affiche chaque matrice de confusion pour l'ensemble de données complet, l'ensemble de données d'entraînement et l'ensemble de données de validation (un sous-ensemble de l'ensemble de données exclu de l'ensemble de données d'entraînement). Dans ce cas, la matrice de confusion pour l'ensemble de données complet montre une bonne précision avec quelques erreurs, notamment lorsque le modèle confond un petit pourcentage d'ensembles de données comme étant dans l'état ON alors qu'ils sont en fait dans l'état CLOGGED comme annoté dans l'ensemble de données original (Figure 14).

Figure 14 : Les développeurs peuvent visualiser des matrices de confusion telles que celle-ci pour l'ensemble de données complet. (Source de l'image : Stephen Evanczuk, exécutant Jupyter Notebook ML_State_Monitor.ipynb de NXP)

Dans une section de code ultérieure, le modèle est exporté vers plusieurs types et formats de modèles différents utilisés par les divers moteurs d'inférence pris en charge par l'environnement de développement eIQ (Figure 15).

Figure 15 : Jupyter Notebook ML_State_Monitor.ipynb de NXP montre comment les développeurs peuvent enregistrer leur modèle entraîné dans plusieurs types et formats de modèles différents. (Source de l'image : Stephen Evanczuk, exécutant Jupyter Notebook ML_State_Monitor.ipynb de NXP)

Le choix du moteur d'inférence peut se révéler crucial pour répondre à des exigences de performances spécifiques. Pour cette application, NXP a mesuré la taille du modèle, la taille du code et le temps d'inférence (temps nécessaire pour terminer l'inférence sur un seul objet d'entrée) lorsque le modèle est destiné à plusieurs moteurs d'inférence, l'un s'exécutant à 996 mégahertz (MHz) et l'autre à 156 MHz (Figures 16 et 17).

Figure 16 : Le choix du type de modèle peut avoir un impact considérable sur la taille du modèle, bien que les différences radicales présentées ici puissent ne pas s'appliquer aux modèles plus grands. (Source de l'image : NXP Semiconductors)

Figure 17 : Le temps d'inférence peut varier de manière significative pour l'évaluation d'un objet d'entrée s'il est chargé à partir de la RAM ou de la mémoire Flash, ou lorsque le processeur fonctionne à une fréquence plus élevée de 996 MHz contre 156 MHz. (Source de l'image : NXP Semiconductors)

Comme le fait remarquer NXP, cette application d'exemple utilise un très petit modèle, de sorte que les différences plutôt marquées illustrées dans ces Figures pourraient être nettement moins prononcées dans un modèle plus grand utilisé pour des classifications complexes.

Construire une solution système pour la surveillance d'état

Outre Jupyter Notebook pour l'exploration interactive du flux de développement de modèles, le progiciel ML State Monitoring App SW Pack de NXP fournit le code source complet pour l'implémentation de la conception sur la carte d'évaluation MIMXRT1170-EVK de NXP. Architecturée autour du microcontrôleur crossover MIMXRT1176DVMAA de NXP, la carte d'évaluation fournit une plateforme matérielle complète, dotée de mémoire supplémentaire et de multiples interfaces (Figure 18).

Figure 18 : La carte d'évaluation MIMXRT1170-EVK de NXP fournit une plateforme matérielle complète pour le développement d'applications basées sur le microcontrôleur crossover série i.MX RT1170 de NXP. (Source de l'image : NXP Semiconductors)

Les développeurs peuvent utiliser l'application d'état de ventilateur de NXP pour prédire l'état d'un ventilateur en combinant la carte d'évaluation MIMXRT1170-EVK avec une carte de capteur FRDM-STBC-AGM01 en option de NXP, un shield Arduino et un ventilateur CC sans balais de 5 volts approprié tel que le 4468 d'Adafruit (Figure 19).

Figure 19 : Les développeurs peuvent tester l'application d'exemple d'état de ventilateur de NXP avec une pile simple construite sur la carte d'évaluation MIMXRT1170-EVK. (Source de l'image : NXP Semiconductors)

Avec l'environnement de développement intégré (IDE) MCUXpresso, les développeurs peuvent configurer l'application pour qu'elle acquière et stocke simplement les données relatives à l'état du ventilateur ou qu'elle exécute immédiatement une inférence sur les données acquises à l'aide d'un moteur d'inférence TensorFlow, DeepViewRT ou Glow (Liste 2).

Copier
/* 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 : Les développeurs peuvent facilement configurer l'application d'exemple NXP ML State Monitor en modifiant les définitions incluses dans le fichier d'en-tête sensor_collect.h. (Source du code : NXP Semiconductors)

L'application fonctionne selon un flux de processus simple. La routine principale dans main.c crée une tâche appelée MainTask, qui est une routine située dans le module sensor_collect.c.

Copier
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 : Dans l'application d'exemple NXP ML State Monitor, MainTask invoque une sous-tâche pour acquérir des données ou exécuter une inférence. (Source du code : NXP Semiconductors)

MainTask effectue diverses tâches d'initialisation avant de lancer l'une des deux sous-tâches, en fonction des définitions de l'utilisateur dans sensor_collect.h :

• Si SENSOR_COLLECT_ACTION est défini sur SENSOR_COLLECT_LOG_EXT, MainTask lance la sous-tâche SENSOR_Collect_LogExt_Task(), qui collecte les données et les stocke sur la carte SD si elle est configurée.
• Si SENSOR_COLLECT_ACTION est défini sur SENSOR_COLLECT_RUN_INFERENCE, MainTask lance la sous-tâche SENSOR_Collect_RunInf_Task(), qui exécute le moteur d'inférence (Glow, DeepViewRT ou TensorFlow) défini dans sensor_collect.h sur les données collectées et, si SENSOR_EVALUATE_MODEL est défini, affiche les performances et la prédiction de classification résultantes.

Copier
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 : L'application d'exemple NXP ML State Monitor démontre le modèle de conception de base pour l'acquisition de données de capteur et l'exécution du moteur d'inférence sélectionné sur les données acquises. (Source du code : NXP Semiconductors)

Comme le progiciel NXP ML State Monitor App SW Pack fournit le code source complet ainsi qu'un ensemble complet de pilotes et d'intergiciels requis, les développeurs peuvent facilement étendre l'application pour ajouter des fonctionnalités ou l'utiliser comme point de départ pour leur propre développement personnalisé.

Conclusion

La mise en œuvre de l'apprentissage automatique en périphérie dans les produits intelligents dans l'IoT et d'autres applications peut fournir un ensemble puissant de fonctionnalités, mais les développeurs ont souvent du mal à appliquer les outils et les méthodes ML développés pour les applications à l'échelle de l'entreprise. Grâce à la disponibilité d'une plateforme de développement de NXP comprenant des processeurs crossovers et des logiciels de développement de modèles spécialisés, tant les experts ML que les développeurs avec peu ou pas d'expérience en ML peuvent créer plus efficacement des applications ML spécialement conçues pour répondre aux besoins de performances efficaces en périphérie.