La nomenclature à détection en périphérie : que spécifier, des IMU aux interfaces

Adam J. Fleischer
|  Créé: Août 12, 2026
At a Glance
Cet article explore les éléments critiques des systèmes de détection de bord et la manière de spécifier efficacement chaque composant dans la nomenclature (BOM). En mettant l’accent sur l’efficacité énergétique et les capacités de prise de décision locale des capteurs, les lecteurs apprendront à prioriser les spécifications qui influencent l’autonomie de la batterie et les performances globales.
Go Deeper with AI:
La couverture de nomenclature avec détection des bords

Points clés

  • Spécifiez chaque composant en fonction de ce qu’il peut décider localement et de ce que chaque décision coûte en énergie, car la question capteur-versus-hôte se répète sur chaque ligne de la nomenclature.
  • Les fonctions always-on sont les véritables différenciateurs : les interruptions wake-on-event, les classifieurs embarqués dans le capteur et la profondeur de FIFO déterminent combien de temps tout ce qui est en amont peut rester en veille.
  • La mémoire est devenue une ligne de nomenclature de premier plan en 2026, la bande passante LPDDR et sa disponibilité influençant les conceptions autant que le choix du capteur.
  • I3C devient le bus capteur par défaut, apportant l’adressage dynamique et les interruptions in-band conçues pour les architectures wake-on-event.

Une architecture, sept lignes de nomenclature

Un produit de détection en périphérie vit ou meurt selon quatre éléments : les capteurs qui observent le monde, le hub qui exécute les modèles, la mémoire qui les alimente et les interfaces qui relient l’ensemble de la pile. Si vous les choisissez selon leurs valeurs de crête, la conception fonctionnera sur l’établi mais échouera sur batterie. Un article complémentaire, On-Device Inference Is Remaking the Sensor Stack, présente une meilleure approche : pousser chaque décision vers l’étage le moins coûteux capable de la prendre. Cet article traduit cette règle en spécifications, composant par composant.

La fiche de spécifications, consolidée

Examinons les spécifications qui permettent de cerner chaque composant, la fonction d’edge AI qui mérite d’être payée et les interfaces typiques.

Composant

Spécifications clés à définir

Fonction d’edge AI à rechercher

Interface typique

IMU

Axes, plages pleine échelle simultanées, densité de bruit, stabilité du biais gyroscopique, ODR, profondeur de FIFO

Arbres de décision sans code, DSP programmable dans le capteur, fusion embarquée

I2C / I3C / SPI + interruption

Temps de vol
(ToF)

Nombre de zones, portée selon la lumière ambiante, FoV/FoI, précision, encombrement du module

Histogrammes sur puce, sortie distance + niveau de confiance

I2C / I3C (CSI-2 pour la classe image)

Radar 60 GHz

Bande passante de balayage, canaux Tx/Rx, antenne intégrée au boîtier, portée micro/macro

Moteur de présence autonome ou classifieur DSP sur puce

SPI + interruption

Microphone MEMS

RSB, AOP, type de sortie, tolérance d’appairage en réseau

Détection d’activité acoustique, NPU intégré au micro pour VAD et détection de mots-clés

PDM / I2S / TDM

Hub capteur / hôte

SRAM, bande passante mémoire, prise en charge des opérateurs NPU, courant en veille profonde, chaîne d’outils

Domaine hub always-on, synchro multi-flux, sécurité du modèle

Héberge les bus ci-dessus

Mémoire

SRAM (Ko), flash (Mo), capacité et bande passante LPDDR (Go/s)

Accueille le modèle INT8 plus les activations, avec marge pour l’OTA

Sur puce / LPDDR / PSRAM

Interfaces

Nombre de broches, débit, périphériques par bus, prise en charge des interruptions

Interruptions in-band, adressage dynamique (I3C)

I2C / I3C / SPI / PDM / I2S / CSI-2

IMU : plage, bruit et classifieur gratuit

L’unité de mesure inertielle (IMU) est le cheval de bataille des wearables, des traceurs d’actifs et de la surveillance d’état ; c’est aussi l’exemple le plus mature d’IA embarquée dans le capteur. Quatre domaines de spécifications déterminent le bon IMU :

  • Plages pleine échelle simultanées. Les composants bi-plage capturent simultanément les détails d’un mouvement à 16 g et des impacts à 80 g, ou des chocs industriels à 256 g, supprimant ainsi le choix forcé entre résolution et marge dynamique.
  • Densité de bruit et stabilité du biais gyroscopique. Elles déterminent la dérive en navigation estimée, et la classification d’activité grand public tolère bien davantage des deux que la navigation. Achetez le grade dont l’algorithme a besoin.
  • Le moteur embarqué dans le capteur. Les arbres de décision et machines à états sans code classifient les événements sans firmware, tandis que les DSP programmables dans le capteur exécutent des réseaux personnalisés. Vérifiez la prise en charge des outils et combien d’arbres ou d’états tiennent réellement.
  • Profondeur de FIFO et interruptions. Une FIFO profonde permet à l’hôte de lire par lots et de dormir plus longtemps, et les broches wake-on-event sont ce qui rend réel le réveil par paliers.

STMicroelectronics est en tête pour l’intelligence embarquée dans le capteur, tandis que TDK InvenSense, Bosch Sensortec et Analog Devices couvrent tout le spectre du grand public à l’industriel. Pour l’automobile et les conceptions à longue durée de vie, la conformité AEC-Q100 et les programmes de pérennité sur 10 ans sont des spécifications filtrantes.

Temps de vol : zones, lumière ambiante et avantage du module

Un capteur à temps de vol (ToF) fournit une distance, pas une image, ce qui explique sa diffusion des téléphones vers les ordinateurs portables, les robots et l’électroménager comme capteur de présence et de gestes avec protection de la vie privée intégrée. Le ToF direct (dToF) mesure sur puce le temps de retour des photons et fournit à l’hôte une distance ainsi qu’un indice de confiance, tandis que le ToF indirect échange plus de consommation contre des cartes de profondeur plus denses. Utilisez ces trois spécifications pour distinguer les options :

  • Nombre de zones. Du télémètre mono-zone jusqu’aux réseaux multi-zones 8x8, on couvre la présence, la posture et le geste, et les modules les plus récents atteignent 54 x 42 zones avec des portées allant jusqu’à 9 m pour la cartographie de profondeur.
  • Portée en conditions réelles de lumière ambiante. L’immunité à la lumière solaire est un point fort du dToF par rapport à l’infrarouge passif (PIR), mais vérifiez la portée donnée dans la fiche technique aux niveaux de lumière auxquels le produit sera réellement exposé, ainsi que le champ de vision et le champ d’illumination.
  • Conditionnement en module. La plupart des composants intègrent dans quelques millimètres l’émetteur, la matrice de diodes à avalanche monophotonique (SPAD) et l’optique, ramenant plusieurs lignes de nomenclature à une seule. Le choix discret versus module relève autant de l’approvisionnement que de l’ingénierie.

Radar 60 GHz : décider où s’exécute la classification

Le radar à ondes millimétriques détecte les macro-mouvements et micro-mouvements (y compris la respiration) dans la ligne de visée, dans l’obscurité et sans capturer d’imagerie identifiable. Certains composants servent de frontaux, exécutant des balayages FMCW (frequency-modulated continuous-wave) et un stockage FIFO sur puce, tandis qu’un modèle léger classe sur l’hôte. D’autres intègrent un DSP sur la puce et exécutent le classifieur dans le capteur. Une fois cette décision prise, portez attention à ces trois spécifications :

  • Bande passante de balayage, qui détermine la résolution en distance et la sensibilité aux micro-mouvements.
  • Nombre de canaux et antenne intégrée au boîtier, qui déterminent la résolution angulaire et suppriment la contrainte de conception RF.
  • Cyclage du duty cycle et reconfiguration dynamique, qui font basculer un composant entre des configurations présence et geste à la demande, sont là où se gagne le budget always-on.

Le paysage fournisseurs se divise selon les applications. Infineon domine le grand public et l’automatisation des bâtiments, tandis que TI domine la détection d’habitacle automobile. Les fournisseurs de modules offrent une autre option : payer plus cher, et l’antenne ainsi que l’adaptation arrivent préconçues.

Microphones MEMS : le RSB n’est que la moitié de la spécification

Le microphone est l’endroit où commence l’histoire de la consommation always-on, et le rapport signal/bruit (RSB) n’est qu’une partie de la fiche technique. Voici ce qu’il faut aussi vérifier :

  • RSB et point de surcharge acoustique (AOP) ensemble. Un événement fort qui sature est perdu pour le modèle, aussi bas que soit le bruit de fond ; les fournisseurs augmentent donc désormais l’AOP en même temps que le RSB. Les composants numériques premium poussent le RSB près de 70 dBA et maintiennent des points de surcharge au-delà de 133 dB SPL.
  • Type de sortie. La modulation de densité d’impulsions (PDM) est simple et omniprésente ; I2S et TDM délivrent un flux numérique propre à l’hôte sans codec externe. Faites correspondre le périphérique audio de l’hôte avant de sélectionner un composant.
  • Wake-on-sound. La détection d’activité acoustique fonctionne à partir d’environ 20 µA, gardant la détection de mots-clés et l’hôte lui-même en réserve tant qu’il n’y a rien à entendre.
  • Appairage en réseau.

 La formation de faisceaux nécessite une phase et une sensibilité appariées entre les composants ; vérifiez la spécification d’appairage par rapport aux valeurs d’une unité seule.

Hubs capteurs et calcul hôte : achetez du débit utile

L’hôte agrège les flux des capteurs, les horodate et les synchronise, exécute ce que les capteurs ne peuvent pas faire, et ne se réveille que lorsque les niveaux inférieurs le demandent. Les valeurs TOPS seules sont trompeuses ; au moment de la sélection du composant, vous devez donc :

  • Confirmer que le modèle tient. La SRAM sur puce pour les activations, la bande passante mémoire, la prise en charge des opérateurs et la maturité du compilateur déterminent le débit réellement obtenu. Faites passer le réseau réel dans la chaîne d’outils du fournisseur avant de valider ce socket.
  • Spécifier le domaine always-on. Le courant de veille profonde avec le hub capteur toujours éveillé est la consommation que la batterie devra supporter.
  • Évaluer la chaîne d’outils comme le silicium. La maturité logicielle est généralement le facteur bloquant, quel que soit le flux fournisseur ou la plateforme tierce utilisée par l’équipe.
  • Pour les conceptions industrielles, ajoutez à la liste le secure boot, la protection du modèle et les engagements de cycle de vie.

Le niveau hôte lui-même couvre désormais une large plage. En entrée de gamme, des microcontrôleurs équipés de NPU comme le STM32N6 de ST ont apporté la vision et l’audio accélérés aux budgets de puissance et de coût des MCU. Un niveau au-dessus, les composants construits autour de Ethos-U85 d’Arm apportent les opérateurs de transformeurs jusqu’au terminal. Tout en haut, des SoC edge comme le Dragonwing Q-8750 de Qualcomm exécutent des pipelines multimodaux et de petits modèles de langage. Faites correspondre le niveau au modèle le plus lourd que le produit exécutera, avec de la marge pour celui qu’il exécutera l’année prochaine.

Mémoire : la ligne qui fixe désormais le budget

La mémoire détermine si la conception fonctionne et, en 2026, si elle peut être livrée dans le budget. La SRAM embarquée constitue la véritable limite pour l’inférence de classe MCU, puisque les activations et les tampons de travail doivent y tenir, avec une enveloppe typique de 256 KB à 512 KB. La mémoire Flash stocke le modèle quantifié, dont la taille est d’environ un quart de celle de sa version originale en 32 bits une fois ramené à 8 bits, avec en plus une marge pour les mises à jour over-the-air et les partitions A/B. Dès que des pipelines de vision ou de petits modèles de langage entrent en jeu, une LPDDR externe s’impose, et la bande passante en Go/s, autant que la capacité, détermine ce que l’accélérateur peut fournir.

Mais spécifier la mémoire est la partie facile. La capacité DRAM s’est réorientée vers les centres de données IA, ce qui fait monter les prix de la LPDDR et allonge les délais d’approvisionnement. Vérifiez la disponibilité, le statut du cycle de vie et les sources alternatives avant le gel de la nomenclature. Dans ce cycle, cette vérification fait partie de la spécification.

Interfaces : façonner le trafic avant qu’il ne devienne coûteux

Le bus détermine le nombre de broches, la consommation et le nombre de capteurs pouvant partager une ligne. Une interface existe pour façonner le trafic avant qu’il n’atteigne la partie coûteuse du système, et les choix par défaut pour y parvenir ont changé :

  • I3C est en train de devenir la référence pour les bus de capteurs. L’adressage dynamique permet à plusieurs capteurs ToF ou IMU de partager un même bus sans jongler avec les adresses. Les interruptions en bande conviennent bien aux conceptions avec réveil sur événement, et la rétrocompatibilité I2C facilite la migration. Les nouveaux capteurs l’intègrent de plus en plus aux côtés de SPI.
  • SPI reste la solution pour les tâches à haut débit, en particulier les lectures FIFO radar et le streaming d’IMU à haut débit de données.
  • PDM, I2S et TDM transportent l’audio, TDM pouvant évoluer jusqu’aux réseaux de microphones.
  • MIPI CSI-2 alimente les caméras et les ToF de classe image dans un pipeline de vision local, de sorte que seules les caractéristiques et les métadonnées remontent en amont.

De la fiche technique à l’approvisionnement

Les principes de On-Device Inference Is Remaking the Sensor Stack s’appliquent à chaque ligne de la nomenclature : résolvez chaque décision au niveau le plus bas possible de la pile et privilégiez les composants qui transmettent des résultats plutôt que des échantillons bruts.

Chaque spécification ci-dessus est aussi un terme de recherche. La plage pleine échelle, le SNR et la mémoire embarquée correspondent à des filtres paramétriques sur Octopart, et lorsqu’une spécification est plus récente que l’ensemble de filtres (comme le nombre de zones ou un NPU intégré au capteur), la fiche technique est accessible en un clic depuis les mêmes résultats. Définissez les spécifications en fonction du budget de mise en veille et filtrez sur les valeurs qui le déterminent, et la nomenclature de détection en périphérie s’assemblera en une architecture cohérente.

 

A propos de l'auteur

A propos de l'auteur

Adam Fleischer is a principal at etimes.com, a technology marketing consultancy that works with technology leaders – like Microsoft, SAP, IBM, and Arrow Electronics – as well as with small high-growth companies. Adam has been a tech geek since programming a lunar landing game on a DEC mainframe as a kid. Adam founded and for a decade acted as CEO of E.ON Interactive, a boutique award-winning creative interactive design agency in Silicon Valley. He holds an MBA from Stanford’s Graduate School of Business and a B.A. from Columbia University. Adam also has a background in performance magic and is currently on the executive team organizing an international conference on how performance magic inspires creativity in technology and science. 

Related Technical Documentation

Ressources associées

Retournez à la Page d'Accueil
Thank you, you are now subscribed to updates.