IA embarquée sur microcontrôleur STM32

Contexte & problème résolu

L'intelligence artificielle embarquée (Edge AI / TinyML) consiste à faire tourner un modèle de deep learning directement dans un microcontrôleur de quelques dizaines de kilo-octets de mémoire, plutôt que sur un serveur distant. Les bénéfices sont concrets : latence quasi nulle sans aller-retour réseau, fonctionnement hors-ligne, confidentialité des données qui ne quittent jamais le capteur, et coût comme consommation énergétique minimes.

Le verrou technique est la contrainte de ressources. Un réseau entraîné sur GPU manipule des paramètres en flottant 32 bits, alors que la cible ne dispose que de quelques centaines de kilo-octets de Flash pour les poids et de RAM pour les activations, sans système d'exploitation ni bibliothèque TensorFlow. Il faut donc concevoir des modèles volontairement légers, les compresser si nécessaire, puis les transpiler en code C optimisé pour le cœur ARM.

Tech Fox a traité le problème de bout en bout autour de deux démonstrateurs complémentaires partageant la même cible matérielle et le même pipeline de déploiement.

• Reconnaissance de chiffres MNIST par CNN : démonstrateur de référence qui valide toute la chaîne d'embarquement (conversion, allocation mémoire, protocole d'inférence série).
• Maintenance prédictive industrielle ; application métier : à partir de 6 relevés capteurs, classer l'état d'une machine et le type de panne, en gérant un déséquilibre de classes extrême (3 % de pannes).

Stack technique & architecture

Côté hôte, l'entraînement s'appuie sur TensorFlow / Keras (API Sequential, couches Conv2D, MaxPooling2D, Dense, Dropout), avec scikit-learn et imbalanced-learn pour le prétraitement et le rééquilibrage, sur environnement accéléré GPU. Les modèles sont exportés au format Keras HDF5 en flottant 32 bits.

Le déploiement passe par X-CUBE-AI (package STM32Cube.AI 10.2.0, moteur interne ST Edge AI Core 2.2.0), qui transpile le modèle en code C et tableaux de poids, intégré sous STM32CubeIDE et compilé en croisé par arm-none-eabi-gcc 13.3 avec la HAL STM32L4xx et CMSIS. La cible est un STM32L4R9AIIx (Cortex-M4 avec FPU) cadencé à 120 MHz, doté de 2 Mo de Flash et 640 Ko de SRAM.

Le pipeline global est identique pour les deux modèles : données, entraînement Keras/TF, compression éventuelle, conversion C par X-CUBE-AI, intégration firmware, puis validation temps réel. Un banc de test hardware-in-the-loop pilote la carte par liaison série et mesure la précision carte-en-main.

• Protocole série maison sur USART2 (115200 bauds, 8N1) : poignée de main par octets 0xAB / 0xCD entre l'hôte et la carte.
• L'hôte envoie le vecteur d'entrée en flottant 32 bits (784 valeurs pour une image MNIST 28x28, 6 valeurs capteurs standardisées pour la maintenance).
• Le firmware exécute le graphe compilé (init puis process), puis renvoie les probabilités softmax encodées sur un octet chacune (0-255).
• L'hôte reconstitue les probabilités, prend l'argmax, le compare à la vérité terrain et cumule la précision sur N itérations.

Démonstrateur de référence ; CNN MNIST

Un réseau convolutif volontairement minimaliste a été retenu pour tenir dans le budget mémoire du MCU tout en conservant l'extraction de motifs spatiaux propre à la convolution. L'architecture reçoit une image 28x28 en niveaux de gris et prédit le chiffre parmi dix classes via une sortie softmax.

L'enchaînement est le suivant : entrée 28x28x1, convolution 2 filtres 3x3 avec padding same et activation ReLU, sous-échantillonnage MaxPooling 2x2 (division par 4 des dimensions), mise à plat en 392 valeurs, couche dense cachée de 16 neurones ReLU, puis couche dense de sortie à 10 neurones softmax. La nomenclature interne C2_16_10 reflète directement cette topologie : 2 canaux convolutifs, 16 neurones cachés, 10 classes.

Le modèle totalise 6 478 paramètres (25,30 Kio de poids) et 23 874 MACC par inférence. Le rapport de génération révèle une asymétrie caractéristique des petits CNN : le bloc convolution plus pooling concentre 72,3 % du calcul, tandis que la couche dense cachée concentre 97,1 % des poids. Le réseau étant déjà minuscule, il a été déployé en flottant 32 bits sans compression, la quantification n'étant pas nécessaire pour tenir dans les 2 Mo de Flash.

• Empreinte embarquée : ~39,3 Kio de Flash (poids 25,3 Kio + runtime réseau 14,3 Kio) et ~5,9 Kio de RAM (activations 3,78 Kio + kernels 2,1 Kio).
• Moins de 2 % de la Flash et environ 1 % de la SRAM occupés : l'essentiel des ressources reste libre pour l'application.
• Validé carte-en-main à ~99 % de précision sur le jeu de test, confirmant la fidélité de la conversion X-CUBE-AI au modèle Keras d'origine.

Application industrielle ; maintenance prédictive

À partir de 6 grandeurs capteurs d'une machine-outil (type de produit encodé, température air, température process, vitesse de rotation, couple et usure d'outil) le réseau prédit si la machine va tomber en panne et de quel type. Le jeu de données AI4I 2020 (10 000 instances) présente un déséquilibre extrême : 9 661 instances normales pour seulement 339 pannes, soit environ 3 %. Un modèle naïf prédisant toujours l'absence de panne obtiendrait ~96,6 % de précision tout en étant parfaitement inutile.

Un perceptron multicouche compact a été retenu : entrée 6, dense 32 ReLU, dense 16 ReLU, sortie 6 softmax, soit seulement 992 MACC. La sortie couvre six classes (pas de panne, TWF usure d'outil, HDF dissipation thermique, PWF défaillance de puissance, OSF surcontrainte, autre panne). La classe RNF (panne aléatoire, sans signature capteur prédictible et représentée par un seul exemple) a été écartée à dessein.

Deux stratégies ont été comparées. Sans rééquilibrage, le modèle atteint 98 % de précision globale mais un recall de 0 % sur les pannes rares : trompeur et dangereux en production. Avec un sur-échantillonnage synthétique SMOTE partiel à 30 % appliqué au seul jeu d'entraînement, combiné à une régularisation Dropout 0,2 et L2 1e-3, la précision globale descend à ~90 % mais la détection des pannes devient effective. Ce compromis est le bon en maintenance : une fausse alerte coûte une inspection, une panne manquée coûte un arrêt de production.

• Recall des pannes après SMOTE : HDF 100 %, PWF 81 %, OSF 81 %, TWF 55 % (contre 0 % sans rééquilibrage), F1 pondéré de 0,93.
• SMOTE appliqué uniquement au jeu d'entraînement, jeu de test laissé déséquilibré pour une évaluation réaliste en conditions de production.
• Empreinte embarquée : 992 MACC, 13,78 Kio de Flash (0,67 % de 2 Mo) et 2,13 Kio de RAM (1,11 %).
• Précision on-device de 90 %, contre 91 % sur poste : l'écart de 1 % vient de la quantification 8 bits des probabilités transmises sur l'UART.

Calculs & fondements théoriques (techniques publiques)

La convolution 2D applique des filtres 3x3 qui balaient l'image par corrélation locale ; avec un padding same la carte de sortie conserve la dimension d'entrée, puis la non-linéarité ReLU (max de 0 et x) introduit la sélectivité. Le MaxPooling 2x2 réalise un sous-échantillonnage par maximum local, apportant invariance à la translation et réduction mémoire. Les couches denses effectuent un produit matrice-vecteur dont le coût mémoire domine, ce qui explique la concentration des poids sur la couche 392 vers 16 du CNN.

La sortie softmax convertit les logits en distribution de probabilités sommant à 1, base de l'argmax final, et l'entraînement minimise l'entropie croisée catégorielle éparse. Le levier de compression est la quantification, qui fait passer les poids du flottant 32 bits vers int16, int8 ou binaire : la quantification int8 divise par 4 l'empreinte des poids pour une perte de précision typiquement de l'ordre du pourcent, complétée au besoin par l'élagage des poids de faible magnitude.

La complexité de calcul se mesure en MACC (multiplications-accumulations par inférence), proportionnelle au temps d'exécution sur le MCU : 23 874 pour le CNN, 992 pour le MLP. Enfin SMOTE génère des exemples synthétiques de classe minoritaire par interpolation entre voisins proches, plus robuste au surapprentissage qu'une simple duplication.

Résultats, difficultés & compétences

Les courbes d'apprentissage du modèle de maintenance rééquilibré confirment l'absence de surapprentissage : accuracy d'entraînement (~0,92) et de validation (~0,90) restent proches et les pertes convergent ensemble, preuve que le duo SMOTE partiel plus régularisation est bien calibré. La principale difficulté, le déséquilibre de classes, a été résolue par un rééquilibrage plafonné à 30 % (un équilibrage total provoquait du surapprentissage) et un pilotage par matrice de confusion et recall par classe plutôt que par la seule précision globale.

L'écart de 1 % entre poste et carte a été diagnostiqué comme un effet de la quantification 8 bits des probabilités sur l'UART, et non un défaut du modèle, grâce au banc de validation hardware-in-the-loop qui compare les argmax à modèle identique.

• Deep learning appliqué : conception d'architectures CNN et MLP, entraînement Keras/TF, réglage d'hyperparamètres (Adam, learning rate, batch, EarlyStopping).
• Machine learning rigoureux : diagnostic du déséquilibre, calibration de SMOTE, régularisation, lecture critique des métriques (recall, precision, F1) au-delà de l'accuracy.
• TinyML / Edge AI : compression de modèles (quantification, élagage), analyse d'empreinte (MACC, Flash, RAM), transpilation vers code C embarqué.
• Systèmes embarqués STM32 : configuration CubeMX (horloges, USART, régions mémoire), intégration X-CUBE-AI, compilation croisée, HAL/CMSIS.
• Firmware & protocoles : boucle d'inférence temps réel, protocole série maison, banc de validation Python (pyserial + NumPy).