Rebuts liés au flashage sur le terrain
Les équipes qui flashent le firmware après que l'unité a quitté l'assemblage PCBA sous-estiment souvent les rebuts. Une unité qui refuse de prendre son firmware sur le banc de l'intégrateur part en retouche, en retour ou à la poubelle, et ce coût s'impute sur un autre compte que celui de la PCBA.
Lorsque l'on mesure les rebuts de bout en bout, le taux de rebut au flashage post-production tourne couramment entre 1 et 4 %. Sur un lot de 1 000 unités, cela représente 10 à 40 pièces de retouche ou de perte évitables. Un flashage côté production ramène ce taux sous les 0,5 % sur la plupart des lignes, parce que le défaut est détecté au poste de test et non chez l'intégrateur.
Dérive de configuration
Des unités flashées lors de sessions différentes, avec des révisions de firmware différentes, par des opérateurs différents finissent par dériver en configuration. Valeurs de calibration, paramètres réseau, drapeaux de debug. La dérive est invisible à la livraison et coûteuse au moment de l'intégration, quand une unité ne se comporte plus comme la suivante.
Le flashage côté production fait passer chaque unité par la même séquence de flashage, avec le même hash de firmware, le même template de provisionnement et le même bootloader signé. La dérive de configuration tombe à zéro.
Application stricte du firmware signé
Greffer un bootloader signé sur un produit déjà en production est pénible. Le brûlage des fusibles, la remise des clés, le cycle de vérification, tout doit être rétrofitté dans un flux qui n'avait pas été pensé pour cela.
Concevoir la ligne de production autour du firmware signé dès le départ rend l'opération triviale. Le bootloader est écrit en premier avec la référence de la clé de signature, l'application est écrite ensuite avec vérification du hash, l'eFuse est brûlée en troisième pour verrouiller la chaîne.
Conformité au CRA
Le Cyber Resilience Act exige une traçabilité du firmware au niveau unitaire. Une unité expédiée aujourd'hui peut avoir besoin d'une mise à jour de sécurité trois ans plus tard, et le fabricant doit savoir avec quelle version de firmware elle est partie.
Le flashage côté production journalise le hash du firmware contre le numéro de série dans une base de données. Le flashage sur le terrain ne produit pas ce journal, sauf si l'intégrateur en construit un de son côté, ce qui est rarement le cas.
Quand le flashage côté production devient rentable
En résumé : dès qu'un produit est suffisamment stable en firmware pour engager un lot de production, et que le coût unitaire du flashage sur le terrain ou de la dérive de configuration devient mesurable. Pour la plupart des produits industriels connectés, de gestion technique du bâtiment, d'énergie et de contrôle d'accès, ce seuil est franchi tôt en NPI.
Pour les produits dont le firmware change chaque semaine pendant le NPI, mieux vaut différer le flashage côté production jusqu'à la stabilisation du bootloader et des clés de signature, puis le basculer en ligne.
Sources
- Rapports sectoriels de l'IPC sur les taux de test et de flashage en production
- Espressif, documentation de production « Secure Boot v2 »
- NXP, guides de production « Secure boot and trust provisioning »