Développement de produit IoT, du concept au produit certifié en série.

Un produit IoT se conçoit pour les contraintes de l'objet fini : environnement de déploiement, autonomie, connectivité, encombrement et certification. Une carte de développement (Arduino, Raspberry Pi, kit d'évaluation constructeur) est excellente pour valider un concept et inadaptée à un déploiement industriel. Elle n'est pas construite pour la plage -40 °C / +85 °C, l'humidité, les vibrations et les perturbations électromagnétiques, elle traîne une nomenclature surdimensionnée que chaque exemplaire fabriqué paiera, et elle n'apporte aucun dossier de certification.

Chez AESTECHNO, avec plus de 10 ans d'expérience en conception électronique, nous prenons tout le chemin : électronique, firmware, intégration en boîtier, application mobile quand le produit en a besoin, industrialisation et campagne de certification. Les quatre contraintes qui décident d'un produit connecté, autonomie, radio, conformité et sécurité, se verrouillent au schéma ou se paient plus tard en re-spins. Notre méthode complète est publiée : concevoir l'électronique IoT, du concept au produit certifié.

Le protocole sans fil décide de la portée, du débit, du budget énergétique, du coût d'infrastructure et, au bout du compte, de la viabilité économique du produit. Nous l'arbitrons à partir du cas d'usage (intérieur ou extérieur, secteur ou batterie, mobilité, couverture réseau) plutôt qu'à partir du composant que l'équipe connaît déjà. LoRaWAN porte de 2 à 15 km entre 0,3 et 50 kbps sur passerelle privée ou réseau opérateur, le Bluetooth LE couvre 10 à 50 m jusqu'à 2 Mbps face à un smartphone ou une passerelle, NB-IoT et LTE-M offrent une couverture nationale contre un abonnement, le Wi-Fi apporte du débit et coûte de l'énergie.

Notre portfolio couvre l'ensemble de la couche radio en projets clients : Bluetooth Classic, BLE et 5.4 PAwR, Wi-Fi, LoRa et LoRaWAN, RFID, 5G et LTE-M. C'est cette couverture qui nous permet d'arbitrer sans biais commercial. Côté Bluetooth, nous avons développé un protocole PAwR personnalisé sur module Nordic synchronisant 100 devices à moins de 5 µs. Beaucoup de produits finissent par combiner deux radios, le BLE pour la configuration locale et un lien LPWAN pour la télémétrie. Voir LoRaWAN, NB-IoT et Sigfox comparés et Bluetooth 5.4 PAwR.

L'autonomie décide de la viabilité d'un capteur laissé sans maintenance, et la façon habituelle de se tromper consiste à la calculer sur les moyennes de datasheet. Pour nous, le chiffre de la datasheet est une cible, jamais la vérité du terrain. Nous profilons le cycle complet, veille, réveil, acquisition, traitement et émission RF, au Nordic PPK2, et nous descendons au picoampère sur les courants de veille profonde et quiescents avec un Keithley DMM7510, là où le profileur atteint sa limite de précision.

Ce que le profil révèle est rarement ce que l'équipe attendait. Sur un projet récent, nous avons mesuré 4,2 µA de courant de veille contre 0,9 µA annoncé dans la datasheet, écart dû à une résistance de pull-up laissée active par le firmware, et un seul GPIO mal configuré suffit à multiplier par dix le courant de veille. Les courants crête comptent autant : une émission RF peut demander plusieurs centaines de milliampères pendant quelques millisecondes, et la cellule doit les fournir. Nous avons conçu de nombreux produits intégrant batteries et systèmes BMS, du lithium primaire aux accumulateurs rechargeables avec protection, équilibrage et jauge de charge. Voir power management embarqué et autonomie batterie.

L'intégration d'antenne est l'une des erreurs les plus fréquentes et les plus coûteuses en conception IoT, parce qu'un design qui mesure bien sur le banc peut échouer une fois posé dans le boîtier de série. Le plan de masse fait partie du système d'antenne et sa taille comme sa forme pilotent l'adaptation et l'efficacité de rayonnement, les zones de keep-out doivent être tenues sans piste, sans plan de cuivre et sans composant à l'intérieur, et certaines formulations de plastique désaccordent aussi l'antenne, tandis qu'un boîtier métallique impose une antenne externe ou une fenêtre RF correctement conçue.

Nous caractérisons l'antenne sur chaque prototype IoT avant la production : coefficient de réflexion (S11) mesuré à l'analyseur de réseau vectoriel Keysight, bande passante vérifiée, rayonnement validé en conditions réelles avec le boîtier de série et non un boîtier de prototype. Sur un projet récent, nous avons mesuré 4 dB de perte d'efficacité rayonnée entre la carte nue et la même carte dans son boîtier de production, écart dû à une couche de peinture métallisée ajoutée tardivement par l'équipe mécanique. Nous avons mené des projets RF jusqu'à 10 GHz. Voir conception RF et antennes.

Les boîtiers IP65 et IP67 sont exigés en extérieur et en milieu industriel, et ils suppriment toute circulation d'air. La chaleur doit alors sortir par la carte et par les parois du boîtier, ce qui est une décision de schéma et de routage plutôt qu'une découverte au moment où le premier prototype dérive ou qu'un composant lâche prématurément.

Les stratégies que nous déployons : analyse thermique menée pendant la conception au lieu d'après un prototype en échec, derating des composants contre les courbes constructeur pour la température de jonction que le boîtier étanche imposera réellement, utilisation du PCB lui-même comme dissipateur par plans de cuivre, vias thermiques et pads exposés, et throttling thermique ou duty-cycle adaptatif côté firmware quand un fonctionnement continu ferait surchauffer le produit. Le comportement en température est ensuite validé dans notre chambre climatique -40 / +85 °C. Voir notre expertise mécanique et intégration.

Le passage d'un prototype qui fonctionne à la production série est l'endroit où les projets de produits connectés rencontrent leurs coûts non prévus. Une carte IoT combine en général du numérique dense, de l'analogique de mesure sensible et une section RF sur un même PCB, ce qui rend la DFM plus exigeante que d'habitude : contour de carte et trous de fixation dessinés pour une panélisation efficace, placement qui respecte les règles de l'assembleur sur les espacements, les orientations et les fiduciels, séquence d'assemblage planifiée quand le CMS et le traversant cohabitent, et points de test sur les rails, les bus et le chemin RF réellement accessibles à un testeur automatique.

Le banc de test série est la pièce la plus souvent repoussée en fin de projet, et c'est elle qui fixe la vitesse de montée en cadence. Il doit vérifier les rails, les lectures capteur, la puissance et la sensibilité RF et la communication des périphériques, rendre un verdict automatique sans jugement d'opérateur, et s'exécuter en secondes plutôt qu'en minutes, ce qui suppose des points de contact pogo-pin prévus dès le routage. Le provisioning firmware suit la même logique : identité unique, clés cryptographiques et données de calibration doivent être générées, stockées et injectées sur la ligne, avec un contrôle de version intégré au banc. Voir la DFM en électronique et notre expertise industrialisation.

La certification réglementaire est obligatoire pour tout produit IoT mis sur un marché, et l'essentiel de son résultat se joue bien avant la visite au laboratoire. Nous intégrons les exigences de la directive RED 2014/53/UE dès la première revue de schéma, parce qu'elle couvre en même temps les performances radio, la CEM et la sécurité électrique, et que les trois se planifient au démarrage du projet. Les émissions rayonnées et conduites sont pré-vérifiées avant le laboratoire accrédité, avec pour objectif de travail une marge réelle sur les gabarits EN 55032 Classe B plutôt qu'un passage tout juste.

Un module Bluetooth ou Wi-Fi déjà certifié CE et FCC simplifie sensiblement l'approbation du produit hôte, mais il ne certifie pas le produit fini : l'approbation du module couvre le module, et l'appareil complet passe quand même les essais CEM. La documentation technique (schémas, rapports d'essai, évaluations d'exposition RF) se construit tout au long de la conception au lieu d'être assemblée dans l'urgence à la fin. Tous les projets que nous avons menés jusqu'à la certification sont passés du premier coup : 100% de réussite aux certifications CE/FCC. Voir la certification CE et RED des produits IoT.

Un produit connecté est attaqué sur trois fronts : le matériel (extraction du firmware, bus de debug laissé ouvert), le réseau (interception, injection de commandes) et le chemin de mise à jour (firmware falsifié). La sécurité est une propriété de l'architecture, pas une fonctionnalité à livrer plus tard. Nous ancrons le secure boot dans le matériel, signons les images OTA (MCUboot sur MCU, RAUC sur Linux embarqué), passons le trafic réseau en TLS 1.3, stockons les secrets dans un élément sécurisé et désactivons JTAG et SWD en production, en alignement avec l'ETSI EN 303 645 pour le grand public et l'IEC 62443-4-2 pour l'industriel.

La longévité, c'est la même discipline appliquée à la nomenclature. Un produit qui reste des années sur le terrain survit à plusieurs cycles de vie de composants : le statut de cycle de vie se vérifie avant de figer une référence, les pièces déjà marquées NRND ou en fin de vie sont écartées, les composants critiques reçoivent une seconde source qualifiée, et une couche d'abstraction matérielle dans le firmware réduit un changement de capteur ou de MCU à une modification limitée. Nous avons accompagné des clients dans de vraies pénuries, en trouvant des alternatives viables et, lorsque aucune solution n'existait, en redesignant leurs produits. Voir la cybersécurité IoT industrielle.