Contraintes des systèmes embarqués¶

Avant de choisir un microcontrôleur ou un protocole, il faut identifier quelle contrainte domine votre projet — car optimiser pour la mauvaise contrainte est la première cause d'échec industriel.

Mémoire limitée : de quelques Ko à quelques Mo¶

Un serveur d'application dispose de dizaines de gigaoctets de RAM. Un microcontrôleur industriel typique tourne avec 64 Ko à 512 Ko. Cette différence d'un facteur 100 000 n'est pas un détail : elle impose un mode de pensée radicalement différent.

La mémoire embarquée se divise en deux ressources distinctes aux contraintes séparées : la Flash (programme + données en lecture seule) et la SRAM (variables, pile d'exécution, buffers). Les deux sont limitées, et leur rapport conditionne l'architecture du firmware.

Tableau comparatif : MCU vs SBC vs serveur¶

En embarqué, l'allocation dynamique (malloc) est souvent proscrite en production : un tas fragmenté dans un nœud qui tourne 5 ans sans redémarrage est une bombe à retardement. On préfère les pools mémoire statiques de taille fixe ou les allocations entièrement statiques, validables à la compilation.

Impact concret sur le code¶

Un stack TCP/IP complet comme lwIP consomme ~40 Ko de Flash et ~10 Ko de RAM. Sur un STM32F0 à 32 Ko de Flash, c'est impossible. La contrainte mémoire force le choix vers des protocoles plus légers (MQTT-SN sur UDP, CoAP) ou vers un microcontrôleur plus capable — avec l'impact correspondant sur le coût unitaire.

Énergie : la contrainte invisible¶

Pour un équipement alimenté sur secteur, l'énergie est transparente. Pour un nœud IoT sur batterie ou energy harvesting, c'est la contrainte qui détermine la faisabilité du projet.

Budget énergétique¶

Le budget énergétique d'un nœud IoT se calcule en milliampères-heure (mAh) consommés sur la durée de vie cible. La formule de base :

Durée de vie (h) = Capacité batterie (mAh) / Consommation moyenne (mA)

La consommation moyenne dépend du duty cycle : la fraction du temps pendant laquelle le nœud est actif.

I_moy = I_actif × t_actif + I_veille × t_veille

Exemple concret : un capteur de température envoie une mesure toutes les 10 minutes via LoRaWAN.

• Phase active (mesure + transmission) : 50 ms à 12 mA
• Phase veille profonde : 9 min 59 s 950 ms à 2,5 µA
• Consommation moyenne : (12 000 µA × 0,05 s + 2,5 µA × 599,95 s) / 600 s ≈ 2,5 µA en pratique

Avec une pile AA de 2 500 mAh : 2 500 000 µAh / 2,5 µA ≈ 114 ans en théorie. En pratique, l'autodécharge de la batterie (2–3 % par an) et les pertes du régulateur réduisent cela à 5–10 ans, ce qui reste excellent.

Energy harvesting¶

Quand aucune batterie n'est envisageable (maintenance impossible, volume de déploiement), le harvesting énergétique devient la seule option.

Le harvesting impose une gestion d'énergie sophistiquée : supercondensateur ou batterie tampon, régulateur MPPT (Maximum Power Point Tracking), logique de décision sur le niveau de charge disponible avant de déclencher une transmission.

Temps réel : dur, mou, et les nuances industrielles¶

"Temps réel" est l'un des termes les plus mal utilisés dans l'industrie. Il ne signifie pas "rapide" — il signifie "déterministe" : le système répond dans un délai garanti, quelles que soient les conditions de charge.

Temps réel dur vs mou¶

Exemples industriels détaillés¶

Freinage ABS (temps réel dur) : La roue doit être testée et la pression modulée en moins de 10 ms. Un dépassement d'échéance peut causer un accident. Le système utilise un microcontrôleur dédié avec garanties temporelles certifiées ISO 26262.

Monitoring vibration machine (temps réel mou) : Un accéléromètre échantillonne à 1 kHz. Un retard d'une mesure toutes les 10 000 cycles dégrade légèrement la détection d'anomalie, mais ne provoque pas de défaillance. FreeRTOS avec une tâche haute priorité convient.

Dashboard de supervision (meilleur effort) : Les données sont affichées avec un délai de 1 à 5 secondes. L'utilisateur attend une mise à jour quasi temps réel, mais un délai occasionnel est acceptable. Linux embarqué avec Node-RED convient parfaitement.

Coût unitaire et économie d'échelle¶

Dans un projet IoT industriel, le coût du nœud est un paramètre de conception aussi important que la performance.

Bill of Materials (BOM)¶

La BOM d'un nœud IoT typique comprend :

À 10 000 unités, le coût est divisé par 2,5. À 100 000 unités, certains composants voient leur coût réduit d'un facteur 5 à 10. Cela signifie que la décision d'intégrer un module radio tiers ou de concevoir son propre RF front-end ne peut se prendre qu'en connaissant les volumes prévisionnels.

Optimisation de la BOM : les leviers disponibles¶

Intégration progressive : un module radio certifié (ex. : Murata CMWX1ZZABZ-078 pour LoRa, u-blox SARA-R4 pour LTE-M) coûte 4–8 € mais inclut la certification radio (CE, FCC). Passer à un circuit intégré radio seul (SX1276) réduit le coût de 2–4 € mais impose des tests radio propres : coût NRE 15 000–50 000 €, pertinent uniquement au-delà de 20 000 unités.

Intégration MCU + Radio : certains SoC intègrent le MCU et la radio sur le même die. Le nRF52840 intègre un Cortex-M4 et un radio Bluetooth 5.0/802.15.4. L'ESP32-C6 intègre un cœur RISC-V, Wi-Fi 6, BLE 5.0 et Zigbee/Thread. Prix < 2 € en volume — contre 4–5 € pour une solution MCU + module radio séparés.

Conception pour la fabrication (DFM) : réduire le nombre de composants passifs, privilégier les boîtiers SMD standards (0402, 0603), éviter les composants nécessitant un placement manuel — chaque geste manuel en production coûte 0,05 à 0,20 € en main-d'œuvre.

Considérations de supply chain¶

Le coût unitaire calculé sur la BOM ne représente que 40 à 60 % du coût total de fabrication (COGS — Cost of Goods Sold). Les postes souvent oubliés en phase de conception :

Interactions entre contraintes : les tensions de conception¶

Les quatre contraintes ne sont pas indépendantes — elles interagissent, et optimiser l'une dégrade souvent les autres. Comprendre ces tensions est essentiel pour faire des compromis éclairés.

Mémoire vs Coût¶

Doubler la Flash d'un MCU (de 256 Ko à 512 Ko) coûte typiquement 0,30 à 0,80 € de plus par unité. Sur 50 000 unités, cela représente 15 000 à 40 000 € de surcoût annuel. La décision doit se prendre en connaissant le budget firmware prévu et la marge de croissance nécessaire.

Énergie vs Temps réel¶

Un système temps réel dur doit rester en écoute permanente des événements critiques — il ne peut pas entrer en deep sleep avec un réveil différé de 60 secondes. Cette contrainte oblige à maintenir le MCU dans un mode de veille légère (quelques centaines de µA) plutôt qu'en deep sleep (< 5 µA), réduisant l'autonomie d'un facteur 50 à 100.

La solution architecturale est parfois de séparer les responsabilités : un MCU ultra-low-power gère le wake-on-event et la collecte de données, tandis qu'un second MCU (ou le même, dans un mode moins profond) gère le temps réel.

Coût vs Fiabilité¶

Un composant "Commercial grade" (0 à 70 °C) coûte 30 à 50 % moins cher que son équivalent "Industrial grade" (-40 à +85 °C). En environnement contrôlé (intérieur climatisé), le commercial grade peut être acceptable. En extérieur ou dans une armoire non climatisée, c'est une économie illusoire qui se paie en retours terrain et en interventions de maintenance.

Tableau synthétique : tensions entre contraintes¶

Ces tensions sont des données d'entrée pour les revues d'architecture en phase de conception — les identifier explicitement dans un document de décision technique (ADR) évite de les redécouvrir douloureusement en phase de validation.

Arbre de décision : quelle contrainte domine votre projet ?¶

flowchart TD
    A[Nouveau projet IoT] --> B{Alimentation\ndisponible ?}
    B -- "Secteur / PoE" --> C{Contrainte\ntemps réel ?}
    B -- "Batterie / harvesting" --> D{Durée de vie\ncible > 2 ans ?}
    D -- Oui --> E[Contrainte ÉNERGIE dominante\nOptimiser duty cycle\nChoisir MCU ultra-low power\nLimiter les transmissions radio]
    D -- Non --> C
    C -- "Dur < 1 ms" --> F[Contrainte TEMPS RÉEL dominante\nRTOS certifié ou bare-metal\nMCU dédié, pas de Linux\nCertification IEC 61508 ?]
    C -- "Mou / best effort" --> G{Volume\nde déploiement ?}
    G -- "> 10 000 unités" --> H[Contrainte COÛT dominante\nOptimiser BOM\nConcevoir PCB custom\nNégocier volumes]
    G -- "< 10 000 unités" --> I{Traitement\nlocal requis ?}
    I -- "CV / ML / DSP lourd" --> J[Contrainte PUISSANCE CALCUL\nSBC ou SoC puissant\nFPGA si temps réel dur + DSP\nLinux embarqué]
    I -- "Collecte + transmission" --> K[MCU standard\nFreeRTOS / Zephyr\nProtocole réseau adapté]

Ce qu'il faut retenir¶

• Les systèmes embarqués IoT opèrent sous quatre contraintes principales : mémoire (Ko à Mo, pas Go), énergie (µA en veille, mAh de batterie), temps réel (dur ou mou selon l'application), et coût (la BOM conditionne la faisabilité à grande échelle).
• Le duty cycle est le levier le plus puissant pour l'autonomie : passer de 1 % à 0,01 % de temps actif peut multiplier l'autonomie par 100.
• "Temps réel" signifie déterministe, pas rapide — un ABS et un dashboard IoT ont des exigences de déterminisme radicalement différentes.
• Identifier la contrainte dominante en début de projet évite de sur-ingéniérer les aspects secondaires.

Chapitre suivant : Architectures processeur — ARM Cortex-M, RISC-V : choisir le cœur qui correspond à vos contraintes.