Une estimation réduite du risque de firmware nécessite toujours un seuil de déploiement

Une estimation améliorée peut tout de même échouer à la politique de déploiement

Une étiquette de version décrit une intention. Une évaluation pré-déploiement doit examiner le comportement proposé par rapport au parc qui le recevra. Dans cette démonstration, l'état de la batterie, la récupération radio et l'usure de la flash influencent les défaillances modélisées, de sorte qu'une amélioration moyenne ne peut à elle seule déterminer si une version candidate respecte le seuil de risque déclaré.

Le cas étudié utilise un parc généré désigné Plano Water et des manifestes de firmware synthétiques. L'estimation initiale d'optimisation de batterie prédit 63 883 défaillances parmi 86 078 points de terminaison évalués. Un correctif avec limitation de courant d'appel réduit cette estimation à 2 449, mais son taux modélisé supérieur reste de 4,10 %. Tous deux reçoivent un avis NO-GO en vertu de la même règle de risque supérieur à 3,0 %.

La distinction importe lors de l'examen des éléments probants avant déploiement : demandez-vous quelle population a été évaluée, ce que l'incertitude englobe et quelle règle autorise le déploiement. Une comparaison favorable avec une version candidate antérieure ne répond qu'à l'une de ces questions.

Suivre le correctif de l'amélioration estimée au seuil de déploiement

Tous les parcs, manifestes, étiquettes de version et enregistrements présentés ici sont synthétiques. Ces captures réelles utilisent des profils assistés par modèle mis en cache, 200 itérations de Monte Carlo et la graine 1234. Une recommandation modélisée n'est pas un déploiement de firmware exécuté ni une preuve indépendante de sûreté sur le terrain.

Exemple concret : une estimation bien inférieure, le même NO-GO

Commençons par la population générée de Plano Water de 88 000 points de terminaison. L'instantané en évalue 86 078 et en exclut 1 922 présentant une télémétrie insuffisante. Nous comparons un manifeste initial d'optimisation de batterie avec un correctif avec limitation de courant d'appel par rapport à cette même population et à cette même politique, afin que l'amélioration et le seuil de déploiement restant puissent être examinés séparément.

1. Examiner l'estimation du comportement avant de se fier à l'étiquette de version

Le profil initial mis en cache estime le courant de base du modem à 120 mA plus un courant supplémentaire de 100 mA lors d'une écriture flash. Sa probabilité de récupération après réinitialisation est de 0,02. Le profil du correctif modifie ces entrées pour 100 mA de base, 10 mA de courant supplémentaire et une probabilité de récupération de 0,96. Il s'agit d'estimations dérivées du journal des modifications, et non de courants mesurés sur le matériel ou d'analyses d'un binaire de firmware.

La population générée présente une charge médiane de batterie de 69,0 % et un âge médian de 4,4 ans. Dans le modèle postulé de chute de tension, une écriture flash peut provoquer une réinitialisation lorsque la tension aux bornes chute sous 3,30 V ; l'échec de la récupération radio et la corruption flash contribuent aux défaillances modélisées. Un jeton de confiance élevée n'établit pas une certitude calibrée quant à ces entrées.

2. Comparer l'intervalle supérieur avec le seuil déclaré

La version candidate initiale prédit 63 883 défaillances, soit 74,22 % des points de terminaison évalués. Le correctif abaisse la prédiction à 2 449, soit 2,85 %. Il s'agit d'une nette amélioration modélisée, mais la barrière vérifie d'abord l'intervalle supérieur : 3 531 divisé par 86 078 donne environ 4,10 %, ce qui reste supérieur au blocage strict configuré de 3,0 %. Elle renvoie donc NO-GO, même si la moyenne est inférieure à 3,0 %.

L'intervalle de comptage modélisé à 90 % s'étend de 1 536 à 3 531 pour le correctif. Il décrit la dispersion des résultats simulés sous ces entrées, et non une plage garantie sur le terrain. La distinction pratique lors de l'examen se fait entre « meilleur que la version candidate précédente » et « à l'intérieur du seuil de déploiement déclaré » ; cet exemple ne satisfait qu'à la première condition.

3. Conserver le profil de comportement, changer la population

La même estimation comportementale du correctif aboutit à GO sur la population générée de la coopérative Hill Country Electric Co-op. Sa charge médiane de batterie est de 83,5 %, son âge médian est de 2,8 ans et un signal radio faible concerne 2,3 % des compteurs, contre 69,0 %, 4,4 ans et 13,4 % pour Plano. La comparaison montre pourquoi une estimation de firmware ne peut être dissociée de l'état de la population évaluée.

L'avis GO ne couvre pas les 1 778 points de terminaison exclus de la coopérative, n'autorise pas une tâche OTA et ne démontre pas que la même image est compatible avec le matériel de différents fabricants. Nous comparons un comportement d'écriture estimé à travers des distributions de santé générées, et ne déployons pas une image chez plusieurs fabricants.

4. Une estimation faible ne peut remplacer des preuves adéquates sur le firmware

Le cas du manifeste restreint sur la population de la coopérative ne prédit que 54 défaillances, avec un intervalle de comptage de 39 à 75 et un taux supérieur de 0,06 %. La confiance de son profil étant faible, la deuxième branche de la politique empêche le statut GO et recommande STAGED-CANARY. Il s'agit d'un profil différent : la probabilité de récupération est de 0,50 et l'amplification d'écriture est de 0,008, contre 0,96 et 0,004 pour le correctif.

La recommandation autre que GO propose une cohorte de 500 points de terminaison présentant le risque modélisé le plus bas, un palier de 72 heures et une télémétrie fraîchement observée avant tout élargissement ; la condition configurée pour le taux de défaillance observé est inférieure à 0,1 %. L'application n'exécute pas ce canari. Une cohorte saine sélectionnée n'établit pas non plus que la population dégradée ou exclue est sans danger.

5. Préserver les exclusions et le fondement de la décision

L'enregistrement HTML du cas initial ci-dessous montre comment la recommandation conserve l'instantané synthétique, la ventilation des cohortes, les exclusions et la note consultative. Les 1 922 points de terminaison sans télémétrie restent en dehors du dénominateur de prédiction et sont recommandés pour un examen manuel. L'exportation de l'enregistrement ne réalise pas cet examen et ne les comptabilise pas implicitement comme sains.

L'exportation conserve également les entrées du profil, la prédiction et l'intervalle, les seuils de politique, la graine et l'horodatage. Son identifiant est un hachage de contenu SHA-256 tronqué ; la signature de l'opérateur est en attente et le hachage du firmware est un espace réservé synthétique. Ces champs rendent la décision générée contrôlable, mais n'en font pas une approbation signée, un certificat de conformité ou une archive d'audit immuable.

Lire le benchmark sans dissimuler le contrôle nécessitant un examen

L'écran final associe trois mesures issues d'une évaluation synthétique fixe de 120 scénarios à deux contrôles de régression sur le profil actuel. Chaque scénario d'évaluation utilise 20 000 points de terminaison générés entièrement observés et 80 itérations de simulateur, avec la graine 2026. La vérité générée provient du même mécanisme postulé avec un bruit nouveau, et non d'un ensemble de données indépendant d'un service public.

Le danger est défini comme un taux de défaillance généré supérieur à 1,0 % ; NO-GO et STAGED-CANARY comptent tous deux comme bloqués. L'évaluation enregistre 74 vrais positifs, 13 faux positifs, 33 vrais négatifs et zéro faux négatif au sein de cette exécution synthétique fixe. Quatre contrôles réussis et un nécessitant un examen révèlent un écart sensible aux entrées ; ils n'établissent pas une exactitude parfaite, une validation indépendante ou une prévention universelle.

Questions avant un déploiement de firmware