Le « côté gauche » du V)

Cliquez pour la section précédente : Étape 2

L’Étape 3 est l’endroit où la conception devient physique : la conception électronique et mécanique, qui avancent généralement main dans la main. Si vous avez entendu parler du modèle en V en ingénierie (un modèle classique de processus de développement), le côté gauche du « V » est entièrement consacré à la conception et à l’implémentation – et c’est exactement là où nous sommes. Autrement dit, nous nous concentrons sur la conception du matériel qui sera ensuite vérifié et validé sur le côté droit du V. (Pas d’inquiétude si le modèle en V ne vous est pas familier ; l’idée clé est que la conception matérielle tend à être un processus séquentiel à aborder avec soin. Une fois qu’une carte électronique est imprimée ou qu’un boîtier plastique est moulé, faire des changements devient délicat – lisez : coûteux.)

L’Étape 3 se décompose en quelques sous-étapes. Point important : c’est aussi l’étape où le développement matériel et logiciel commence à travailler en parallèle (plus sur le côté logiciel à l’étape suivante). Sur la piste matérielle, voici comment les choses se déroulent typiquement :

Capture de schéma : le plan électronique

Tout produit électronique commence par un dessin – pas du genre artistique, mais un schéma. La capture de schéma est l’endroit où la conception du circuit électrique est esquissée en détail avec des outils CAO spécialisés (comme Altium, Eagle ou KiCad). Voyez le schéma comme le plan de votre circuit : il montre chaque composant (microcontrôleur, capteurs, condensateurs, connecteurs, et plus) et comment ils sont tous électriquement connectés par des nets (fils). C’est comme cartographier une ville d’électronique où chaque composant est un bâtiment et les nets sont les routes qui les relient.

Cette étape est cruciale parce qu’il est bien plus facile (et moins cher) de corriger les erreurs sur un diagramme que sur une carte physique. Une fois le schéma rédigé, une revue minutieuse s’impose. Typiquement, l’ingénieur exporte le schéma en PDF et le fait circuler pour revue par les pairs. Des yeux frais peuvent attraper quelque chose que vous avez manqué – par exemple, « Oups, la broche d’alimentation du capteur de température n’est pas connectée ! » ou « Cette valeur de résistance semble bizarre pour le limiteur de courant de la LED. » Attraper ces problèmes maintenant épargne beaucoup de maux de tête plus tard.

À ce stade, certaines équipes mènent aussi une AMDEC (Analyse des modes de défaillance et de leurs effets, FMEA en anglais) sur les parties critiques de la conception, comme l’alimentation ou les circuits de sécurité. L’AMDEC est essentiellement une façon structurée de demander « De quelles façons ce circuit pourrait-il échouer, et que se passe-t-il si cela arrive ? » Par exemple, et si le capteur de température tombait en court-circuit (c.-à-d. que ses deux broches se connectent accidentellement en interne) ? Est-ce que cela ferait simplement lire une valeur extrême au capteur, ou est-ce que cela pourrait endommager toute la carte en tirant trop de courant ? En posant ces questions « et si » inconfortables tôt, vous pouvez ajouter des protections ou décider si le risque est acceptable. Ce genre de prospective rend l’appareil plus fiable sur le long terme.

Pendant ce temps – et c’est là que le travail en parallèle entre en jeu – l’équipe logiciel/firmware n’a pas à attendre les bras croisés que le matériel soit terminé. À partir du schéma, les ingénieurs firmware peuvent commencer à créer un HAL (Hardware Abstraction Layer) ou au moins son squelette. Essentiellement, ils mettent en place les interfaces logicielles pour les périphériques du microcontrôleur (timers, interfaces de communication comme I2C ou SPI pour ces capteurs, etc.). Ils peuvent même écrire des tests unitaires ou du code de simulation pour ces drivers sur un PC. Imaginez un développeur écrivant du code qui simule des lectures de capteur juste pour tester la logique – ainsi, l’équipe firmware construit déjà la fondation. Donc, quand la vraie carte électronique arrive, une bonne partie de la structure du code est prête et n’attend qu’à être essayée sur le matériel réel. Cet effort parallèle signifie que les gens du logiciel ne se tournent pas les pouces ; ils posent des fondations qui faciliteront le bring-up du matériel plus tard.

Layout PCB : du schéma à la carte physique

Une fois la conception du schéma finalisée et revue, il est temps de transformer ce plan électronique en une vraie carte électronique. C’est la phase de layout PCB. Avec un autre ensemble d’outils CAO (souvent la même suite que pour les schémas, comme Altium ou KiCad, qui peuvent basculer en mode layout), l’ingénieur place chaque empreinte de composant sur une carte virtuelle et commence à router les pistes de cuivre qui relient le tout. Si le schéma est le plan, le layout PCB est l’étape où vous décidez exactement à quoi cette ville de composants ressemblera physiquement – comme décider où chaque bâtiment se pose et comment les routes (fils) courront entre eux sur le paysage réel de la carte.

Le résultat du layout PCB est un ensemble de fichiers (les fameux fichiers Gerber) que les fabricants utilisent pour fabriquer la carte. Un autre livrable utile est un modèle 3D (souvent un fichier STEP) de la carte. Ce modèle 3D est particulièrement utile côté conception mécanique – vous pouvez l’importer dans votre conception de boîtier pour vérifier que la carte et tous ses composants rentrent dans le logement du produit sans collisions (personne ne veut un connecteur USB qui dépasse là où le boîtier n’a pas de trou !).

Pendant le layout PCB, il est critique de garder en tête les directives Design for Manufacturing (DFM) et Design for Test (DFT). En termes simples, le DFM signifie concevoir la carte pour qu’elle puisse être fabriquée de façon fiable et rentable, et le DFT signifie la concevoir pour qu’elle puisse être testée facilement plus tard.

Par exemple :

• DFM : évitez de placer des composants trop près du bord de la carte ou si serrés que les machines d’assemblage peinent à les souder. Assurez-vous que le layout peut être fabriqué sans problème.
• DFT : ajoutez des pastilles de test ou un connecteur spécial pour pouvoir connecter l’équipement de test ou les programmateurs à la carte en production. Ainsi, chaque unité sortant de la ligne peut être facilement vérifiée (imaginez une prise pratique pour programmer le firmware ou mesurer des signaux sur chaque appareil).

Il est bien plus facile d’inclure ces mesures maintenant que de réaliser plus tard que vous avez mille unités finies sans moyen facile de vérifier si elles sont pleinement fonctionnelles !

Beaucoup d’équipes utilisent une checklist pendant le layout pour s’assurer que rien n’est oublié – des choses comme ajouter des fiducials (petites marques qui aident les machines d’assemblage automatisées à aligner la carte), maintenir les dégagements corrects entre les parties haute tension, étiqueter les connecteurs importants, et ainsi de suite.

Pendant que l’équipe matériel est occupée à router des pistes et à transpirer sur les détails de la carte, l’effort logiciel parallèle continue. L’équipe firmware, connaissant les modèles exacts de capteurs et composants du schéma, peut commencer à écrire le vrai code des drivers (ou au moins des placeholders) d’après les datasheets de ces composants. Elle peut utiliser des émulateurs de capteurs ou écrire du code factice qui mime ce que le capteur ferait. L’équipe cloud/backend, si votre produit IoT en a une, peut aussi prendre de l’avance : par exemple, mettre en place une base de données cloud basique et des endpoints API pour recevoir les données de l’appareil. Essentiellement, chacun prépare sa pièce du puzzle pour que, quand les premières cartes physiques arrivent, ce ne soit pas un démarrage à froid pour le reste de l’équipe. Au moment où la conception du PCB est envoyée en fabrication, votre firmware peut déjà avoir un « hello world » prêt pour la carte et votre cloud peut avoir un petit serveur de test qui attend de loguer le premier point de donnée de l’appareil. Ce développement concurrent raccourcit vraiment la boucle d’itération plus tard.

Construction de prototypes : donner vie au matériel

Le layout PCB terminé et vérifié, il est temps de passer des fichiers numériques aux objets physiques. La première étape consiste à faire fabriquer les cartes. Typiquement, vous envoyez ces fichiers Gerber à un fabricant de PCB (il existe de nombreux fabricants rapides qui peuvent produire des cartes en quelques jours). En parallèle, vous voudrez vous assurer que tous les composants qui vont sur la carte (le microcontrôleur, les capteurs, les puces, etc.) sont en main. Conseil de pro : commandez les pièces critiques ou à long délai dès que vous avez confiance dans votre schéma et votre sélection de composants ! Pendant les pénuries mondiales de puces, beaucoup d’équipes l’ont appris à leurs dépens – vous ne voulez pas attendre 12 semaines un capteur ou une puce radio particulier pendant que vos cartes restent là, vides.

Une fois que vous avez les PCBs nus et toutes les pièces, vous assemblez quelques unités prototypes. Cela peut être fait en interne si vous avez un labo bien équipé et une main sûre pour la soudure, ou vous pouvez utiliser un service d’assemblage pour souder tous ces minuscules composants. Le résultat est un ensemble (souvent une petite poignée, comme 1 à 5 cartes) d’appareils prototypes.

Vient maintenant l’un des moments les plus excitants (et angoissants) du développement matériel : le bring-up, terme simple pour la première fois où vous mettez la carte sous tension et voyez si elle fonctionne. Il est courant de faire cela prudemment – par exemple, en utilisant une alimentation de labo avec une limite de courant pour éviter de griller les choses s’il y a un court-circuit quelque part. Tout le monde au labo peut retenir son souffle quand vous basculez l’interrupteur. La carte s’allume-t-elle sans laisser échapper la fumée magique des composants brûlés ? (Espérons que oui !)

Après la mise sous tension, vous vérifiez méthodiquement les bases. Tous les rails d’alimentation sont-ils aux tensions attendues ? (Vérifiez au multimètre ou à l’oscilloscope.) Le microcontrôleur (MCU) se réveille-t-il et exécute-t-il du code ? Un premier test classique consiste souvent à vérifier si un firmware simple qui fait clignoter une LED ou envoie un message « Hello, world » sur un port série tourne. Si vous voyez cette LED clignoter ou recevez ce message sur votre ordinateur, c’est un vrai jalon – cela signifie que le cœur de votre carte est vivant et en forme.

Ensuite, vous testerez la communication avec les périphériques clés : le MCU peut-il parler au capteur en I2C ou SPI comme prévu ? Les capteurs retournent-ils des données raisonnables ? C’est à ce stade que vous pourriez découvrir des problèmes. Peut-être qu’un capteur ne lit rien à cause d’une erreur de câblage ou d’un bug firmware subtil. Le bring-up est un jeu de détective, où ingénieurs matériel et firmware travaillent ensemble pour dépanner tout problème. Par exemple, si la lecture de température est toujours zéro, l’ingénieur firmware peut déboguer le code pendant que l’ingénieur matériel sonde les connexions au multimètre – ensemble, ils détermineront si c’est un problème d’initialisation logicielle ou si les lignes SDA et SCL du capteur ont été inversées sur le PCB.

Pendant le bring-up du prototype, vous guettez aussi tout problème d’alimentation ou thermique. Quelque chose chauffe-t-il plus qu’il ne devrait ? (Conseil de pro : toucher prudemment les puces pour sentir la chaleur ou utiliser une caméra infrarouge peut attraper les points chauds.) La carte tire-t-elle plus de courant que prévu (ce qui pourrait indiquer que quelque chose est mal câblé ou qu’un composant est défectueux) ? Ces tests garantissent que votre prototype non seulement fonctionne, mais est aussi sûr et performe dans les paramètres attendus.

Si votre appareil est censé communiquer sans fil ou répondre à certaines normes réglementaires (comme les émissions FCC pour les gadgets sans fil aux USA), cette étape de prototype est un bon moment pour faire un peu de test de pré-conformité. Cela peut signifier emmener l’appareil dans un laboratoire pour un scan préliminaire des émissions de radiofréquence afin d’attraper les gros problèmes tôt. Vous ne voulez pas découvrir au test de certification final que votre carte se comporte comme un émetteur radio accidentel sur une fréquence non approuvée !

Pendant que l’équipe matériel est occupée au bring-up, l’équipe firmware bat maintenant son plein pour tester son code sur l’appareil réel. Tous ces drivers et composants HAL commencés plus tôt peuvent être chargés sur la vraie carte. C’est là que le firmware peut avoir besoin d’ajustements – peut-être que les hypothèses de timing étaient un peu à côté, ou qu’une interruption a besoin d’un réglage maintenant qu’elle est sur du vrai silicium. Si vous utilisez un RTOS (Real-Time Operating System) sur le microcontrôleur, c’est le moment de commencer à ajuster les priorités des tâches ou le timing, puisque sur le matériel réel vous pouvez observer la performance réelle. L’équipe cloud peut aussi voir les premières vraies données traverser le système ! Par exemple, le prototype peut réellement envoyer une lecture de température à un serveur de test, confirmant que tout le flux de bout en bout (appareil -> cloud -> base de données) fonctionne au moins à petite échelle.

L’Étape 3 implique souvent quelques itérations. Il est rare que tout soit parfait du premier coup – et c’est tout à fait normal. Vous pourriez trouver une erreur sur la carte (comme une piste mal câblée ou une erreur d’empreinte de composant) qui exige une petite réparation chirurgicale sur les prototypes (bonjour, bodge wires et rafistolages !), ou elle peut être assez significative pour justifier de spinner un PCB révisé pour la prochaine série de prototypes. Chaque itération est une chance de s’améliorer : peut-être repositionnez-vous un connecteur difficile d’accès, ou ajustez-vous le circuit pour réduire le bruit sur une lecture de capteur, etc. Ne soyez pas découragé par le besoin d’itérations ; c’est attendu en développement matériel.

Tout au long de cette étape, une collaboration étroite entre les équipes matériel et logiciel est vitale. Quand un problème survient, les deux côtés doivent coiffer leur chapeau de détective et travailler ensemble. Le capteur ne lit-il rien parce que le firmware est faux, ou y a-t-il un pont de soudure qui court-circuite quelque chose sur le PCB ? En communiquant découvertes et hypothèses, l’équipe peut converger sur le problème plus vite. Ce dépannage collaboratif est l’une des parties les plus formatrices du processus – et il renforce souvent la compréhension qu’a l’équipe du produit dans son ensemble.

Gardez aussi un œil sur l’avenir : si vous prévoyez de fabriquer ce produit à l’échelle un jour, utilisez cette phase de prototype pour réfléchir à la fabrication et aux tests sur le long terme. Vous vous souvenez du DFM et du DFT ? C’est le moment de valider ces décisions. Par exemple, si vous avez inclus un header de programmation, essayez de l’utiliser dans un test de production simulé : pouvez-vous facilement connecter et programmer la carte ? Si vous avez ajouté des pastilles de test, sont-elles accessibles à un testeur bed-of-nails ? Il est bien plus facile d’ajuster votre conception pour la testabilité maintenant que quand vous avez une ligne de production qui tourne.

À la fin de l’Étape 3, vous devriez avoir un ou plusieurs appareils prototypes fonctionnels et un solide ensemble de leçons apprises. Vous aurez des données initiales sur les performances (comme : combien de puissance votre appareil consomme-t-il réellement ? Le capteur performe-t-il avec précision en conditions réelles ?). Vous aurez probablement aussi une liste de corrections ou d’améliorations pour la prochaine version. Plus important encore, vous avez construit la fondation physique de votre produit IoT – quelque chose que vous pouvez tenir dans vos mains et qui fonctionne réellement.

Quand ce premier prototype prend finalement vie et envoie des données comme prévu, une petite célébration est bien méritée – la plupart des ingénieurs matériel ont ressenti une étincelle du « Il est vivant ! » du Dr Frankenstein à ce moment-là. Prenez-la. Le matériel, c’est dur, et vous venez de franchir un jalon majeur sur le chemin de l’idée à la réalité.