Même quand les composants sont standardisés, la gestion de l'obsolescence en électronique c'est compliqué.
Par exemple, dans un de mes anciens projets, l'équipe responsable du matériel avait remplacé la puce de mémoire flash utilisée. Il s'agit d'un composant assez bien standardisé, ils ont donc trouvé un autre composant chez un autre fabricant, avec le même brochage et des timings équivalents ou plus rapide. Les tests se sont bien passés et le composant a été utilisé pour produire plusieurs machines.
Cependant, quelques semaines plus tard, en sortant ces machines du stock pour les déployer chez des clients, on s'apperçoit que le logiciel ne fonctionne plus! Après enquête, on finit par comprendre que quelques bits se sont effacés de la mémoire.
Une comparaison plus attentive des datasheets des deux composants a fini par révéler que les garanties sur le nombre de bits défectueux par bloc de mémoire étaient très différents entre les deux puces. Il a donc fallu modifier notre logiciel pour utiliser un algorithme correcteur d'erreur plus performant, capable de corriger ces erreurs plus nombreuses pour utiliser cette nouvelle mémoire de façon fiable.
Avec la difficulté de devoir migrer les machines existantes et déjà déployées avant la détection du problème (lecture et reprogrammation de la flash avec le nouveau code correcteur d'erreur par le bootloader), de devoir mettre à jour les outils de production pour écrire la flash sur les nouvelles machines produites directement avec le code d'erreur robuste, la gestion dans le code des deux versions du matériel avec les deux types de correction d'erreur (le nouveau utilisait du support matériel de la nouvelle puce de flash et ne pouvait donc pas être déployé sur l'ancienne carte), ...
Dans d'autres cas (par exemple des microcontrôleurs, où le remplacement nécessiterait une réécriture complète du firmware), le plus simple était de réagir à l'annonce d'obsolescence et d'acheter un gros stock de composants pour les années à venir. Si le volume de production est relativement faible et le composant pas très cher, les quelques milliers d'euros nécessaires pour ça vont être bien inférieurs au coût de conception d'un nouveau firmware et d'une nouvelle électronique.
Plus récemment dans un autre projet, c'est un changement de référence sur une simple diode qui a causé un changement de comportement du matériel. Je n'ai pas tous les détails car je ne suis pas responsable du matériel sur ce projet. Mais il y a une série de matériel avec la "mauvaise" diode sur laquelle une partie du circuit électronique ne fonctionne pas. Le moindre changement doit donc être validé avec tout le périmètre matériel et logiciel, et aussi dans toutes les conditions de température, humidité, ...
On comprend peut-être un peu mieux pourquoi les fabricants de téléphones préfèrent sortir régulièrement de nouveaux modèles plutôt que de faire ce type de micro mise à jour qui peut coûter presque aussi cher que de repartir de zéro.
[^] # Re: Projet FAMES sur le site du CEA
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La France va produire des processeurs. Évalué à 7.
Même quand les composants sont standardisés, la gestion de l'obsolescence en électronique c'est compliqué.
Par exemple, dans un de mes anciens projets, l'équipe responsable du matériel avait remplacé la puce de mémoire flash utilisée. Il s'agit d'un composant assez bien standardisé, ils ont donc trouvé un autre composant chez un autre fabricant, avec le même brochage et des timings équivalents ou plus rapide. Les tests se sont bien passés et le composant a été utilisé pour produire plusieurs machines.
Cependant, quelques semaines plus tard, en sortant ces machines du stock pour les déployer chez des clients, on s'apperçoit que le logiciel ne fonctionne plus! Après enquête, on finit par comprendre que quelques bits se sont effacés de la mémoire.
Une comparaison plus attentive des datasheets des deux composants a fini par révéler que les garanties sur le nombre de bits défectueux par bloc de mémoire étaient très différents entre les deux puces. Il a donc fallu modifier notre logiciel pour utiliser un algorithme correcteur d'erreur plus performant, capable de corriger ces erreurs plus nombreuses pour utiliser cette nouvelle mémoire de façon fiable.
Avec la difficulté de devoir migrer les machines existantes et déjà déployées avant la détection du problème (lecture et reprogrammation de la flash avec le nouveau code correcteur d'erreur par le bootloader), de devoir mettre à jour les outils de production pour écrire la flash sur les nouvelles machines produites directement avec le code d'erreur robuste, la gestion dans le code des deux versions du matériel avec les deux types de correction d'erreur (le nouveau utilisait du support matériel de la nouvelle puce de flash et ne pouvait donc pas être déployé sur l'ancienne carte), ...
Dans d'autres cas (par exemple des microcontrôleurs, où le remplacement nécessiterait une réécriture complète du firmware), le plus simple était de réagir à l'annonce d'obsolescence et d'acheter un gros stock de composants pour les années à venir. Si le volume de production est relativement faible et le composant pas très cher, les quelques milliers d'euros nécessaires pour ça vont être bien inférieurs au coût de conception d'un nouveau firmware et d'une nouvelle électronique.
Plus récemment dans un autre projet, c'est un changement de référence sur une simple diode qui a causé un changement de comportement du matériel. Je n'ai pas tous les détails car je ne suis pas responsable du matériel sur ce projet. Mais il y a une série de matériel avec la "mauvaise" diode sur laquelle une partie du circuit électronique ne fonctionne pas. Le moindre changement doit donc être validé avec tout le périmètre matériel et logiciel, et aussi dans toutes les conditions de température, humidité, ...
On comprend peut-être un peu mieux pourquoi les fabricants de téléphones préfèrent sortir régulièrement de nouveaux modèles plutôt que de faire ce type de micro mise à jour qui peut coûter presque aussi cher que de repartir de zéro.