Les tests du micrologiciel USB PD doivent démontrer qu’une version proposée préserve le comportement requis dans les profils fixes, PPS, EPR, l’allocation de ports et la récupération des pannes. La comparaison la plus utile associe la référence publiée à la version candidate sous des entrées identiques et examine à la fois les événements de protocole décodés et la puissance délivrée. Un numéro de version modifié ou une recharge téléphonique réussie ne constitue pas une telle comparaison.
Pour un projet de développement de chargeur, sélectionnez des cas de régression à partir du comportement que le firmware peut influencer. Conservez les preuves de la version précédente et identifiez les exigences qui ont été délibérément modifiées. La portée du programme USB-C PD et le processus de contrôle de qualité de WECENT peuvent encadrer une discussion sur la version ; L’approbation du micrologiciel dépend toujours du modèle exact, de la construction, de la configuration et de la couverture de régression exécutée. Distinguez les améliorations prévues des différences inattendues avant la publication du candidat.
Qu’est-ce qui constitue une référence utile pour les tests du micrologiciel USB PD ?
Conservez la version de base et ses entrées reproductibles.
Une ligne de base doit préserver le micrologiciel exécutable et les paramètres persistants ainsi que la trace ; sans ces artefacts, une différence de comportement apparente peut rester impossible à reproduire de manière fiable.
Un ancien rapport sans version ou configuration exécutable constitue une base de référence faible. Enregistrez la version du contrôleur, la configuration du projet, la révision du matériel et tous les paramètres persistants qui survivent à une mise à jour. Conservez la liste de capacités sources et les règles d’allocation de ports pertinentes ainsi que la chaîne de version. Une incompatibilité de configuration peut autrement ressembler à une régression du micrologiciel.
La documentation de l’analyseur Infineon CY4500-EPR fournit un exemple d’outil pour capturer les preuves de protocole. Corrigez la version du décodeur ou documentez comment ses modifications affectent la comparaison. Faites correspondre les événements en fonction de leur signification et de leur stimulus plutôt que d’exiger une égalité octet par octet dans des horodatages sans rapport. Une ligne de base reproductible devrait permettre à un ingénieur de décider si une différence observée est intentionnelle, une variabilité inoffensive ou un changement qui viole une exigence.
Traitez une différence de trace comme une branche à étudier. Les horodatages modifiés peuvent refléter une variation normale de l’exécution ; La modification des profils proposés ou du comportement de récupération peut affecter l’exigence. Comparez les événements et les sorties équivalents avant d’exiger des captures identiques ou de considérer une différence comme inoffensive.
Comment choisir la couverture des appareils ?
Couvrez des comportements de protocole distincts et des cas d’utilisation client.
Un destinataire choisi pour une voie de négociation ne doit pas couvrir silencieusement une autre voie ; conserver la raison pour laquelle chaque dispositif physique ou gabarit de test contrôlé appartient à la matrice de régression.
Les échecs antérieurs méritent des cas de régression nommés lorsque leur déclencheur peut être reproduit. Incluez la révision exacte de l’appareil concerné ou un représentant justifié, ainsi que sa version du logiciel et son câble. Ajoutez des cas pour les nouvelles fonctionnalités et pour les fonctions partageant le chemin de code modifié. Une build qui modifie la gestion des demandes peut affecter plus que le seul profil nommé dans la demande de modification.
Enregistrez si un cas utilise un véritable dispositif de réception d’énergie, un appareil d’exercice de protocole contrôlé ou une charge électronique. Chacun répond à une question différente. Les appareils réels exposent un comportement d’interopérabilité ; les stimuli contrôlés rendent les conditions limites reproductibles ; les charges électriques testent la puissance fournie selon des demandes définies. La page de ressources USB-IF USB-C prend en charge la sélection des matériaux de conformité applicables, mais une matrice de périphérique interne ne doit pas être représentée comme une certification USB-IF.
À quoi la régression à profil fixe doit-elle comparer ?
Comparez les profils annoncés, les demandes acceptées et la livraison.
Vérifiez les profils inférieurs aussi délibérément que le profil principal ; une liste de capacités modifiée peut affecter la solution de repli ordinaire même lorsque la démonstration de puissance maximale semble toujours fonctionner.
Commencez par les profils requis par la spécification du produit. Si le candidat supprime ou modifie intentionnellement une fonctionnalité, identifiez le changement d’exigence approuvé et les scénarios client concernés. Testez la solution de repli de faible puissance utilisée par les dispositifs de réception d’énergie représentatifs ainsi que la sortie principale. Un succès de puissance maximale n’établit pas une sélection correcte sur les autres profils annoncés.
Conservez les observations de courant, de tension et de protocole à partir de la même acquisition ou d’instruments synchronisés. Si une demande est rejetée, vérifiez si c’est le comportement requis pour ses paramètres. S’il est accepté, examinez l’état de livraison après la transition correspondante. Conservez la précision des résultats, le traitement des demandes et la récupération comme des décisions distinctes afin qu’un réviseur de version puisse voir quelle exigence une différence inattendue menace réellement.
Un boîtier à profil fixe a besoin de l’objet réellement demandé, pas seulement de la tension attendue. Si les deux bâtiments produisent la même tension via des contrats différents, l’instantané électrique peut dissimuler une négociation modifiée. Conservez cette distinction lorsque le périphérique de réception d’énergie pris en charge dépend d’une capacité particulière.
Comment évaluer les changements du PPS ?
Limites des demandes de relecture et fonctionnement PPS soutenu.
Utiliser des requêtes répétables pour la gestion des limites et des dispositifs de réception d’énergie réels pour l’interopérabilité ; conservent leurs rôles distincts afin qu’une demande changeante du téléphone n’invalide pas la comparaison contrôlée du micrologiciel.
La documentation TI TPS25751 propose un exemple de composant de contrôle compatible PPS. Pour le produit en cours d’examen, vérifiez quels paramètres et chemins de code définissent la plage annoncée et le comportement actuel. Comparez une séquence de requêtes connue sur les deux versions plutôt que de vous fier uniquement à un téléphone dont les requêtes changent en fonction de la température ou de l’état de charge.
Conservez ensuite un cas d’appareil réel approprié pour vérifier l’interopérabilité selon son modèle de demande réel. Classez une différence comme une publicité modifiée, une réponse modifiée, un résultat délivré modifié ou un comportement soutenu modifié. Évaluer les cas de puissance limitée en utilisant l’exigence applicable ; ne présumez pas que toutes les paires de tension et de courant d’apparence valide peuvent être fournies simultanément. Un enregistrement de version doit relier chaque différence observée à la configuration approuvée ou à un défaut documenté.
Divisez la comparaison PPS en plage annoncée, traitement des demandes et résultat fourni. Un rejet de limite peut être correct alors qu’une demande valide à portée échoue. L’exécution uniquement du chemin de chargement ordinaire du téléphone peut ne jamais exercer la limite des contrôles de code modifiés.
Quel comportement EPR appartient à la régression ?
Inclure l’entrée, le fonctionnement maintenu et la sortie ordonnée.
L’essai doit se poursuivre au-delà de l’entrée en exploitation maintenue et de la sortie ; une lecture haute tension ne capture qu’un seul état au cours du cycle de vie que la version est censée prendre en charge.
La documentation TI TPS26750A illustre l’implémentation d’un contrôleur EPR. Il n’établit pas la configuration ou les performances d’un chargeur particulier. Choisissez des cas pour le mode implémenté et la version du protocole applicable. La qualification des câbles, les demandes des dispositifs de réception d’énergie et le comportement du chemin d’alimentation doivent tous être suffisamment visibles pour étayer le résultat.
Une modification de la gestion des connexions peut affecter l’EPR même lorsque les paramètres de puissance nominale restent identiques. Comparez les événements et les réponses de maintenance sous les entrées contrôlées et distinguez une combinaison non prise en charge d’un cas pris en charge ayant échoué. Conservez les captures de sortie et reconnectez-vous. La question d’acceptation pertinente est de savoir si le candidat gère correctement le cycle de vie spécifié, et non si le banc de test a obtenu une fois la plus grande puissance annoncée pour le produit.
La couverture d’entrée n’est pas une couverture de maintenance. Un candidat peut établir l’état EPR requis et le perdre ultérieurement en cas de maintenance ou d’événement de sortie. Conservez le même câble et le même dispositif de réception d’alimentation tout au long de ce cycle de vie, puis examinez le comportement modifié le plus tôt plutôt que uniquement la tension finale.
Comment rejouer les événements multiports ?
Corrigez la combinaison de charges et l’ordre de fixation.
Enregistrez le dispositif de réception d’énergie d’origine pendant qu’un deuxième port change d’état ; le nouvel appareil alimenté ne permet pas d’établir que le premier appareil a conservé la continuité de fonctionnement requise.
La note d’application de chargement USB-C multiport de TI explique un contexte de conception pour le contrôle de l’alimentation partagée. Un candidat peut délibérément modifier sa politique d’allocation, mais le comportement qui en résulte doit correspondre aux exigences du produit approuvé. Identifiez quel appareil de réception d’énergie conserve son contrat, lequel renégocie et lequel subit une interruption mesurable.
Utilisez plus qu’une condition statique de connexion de tous les ports lorsque l’utilisation prévue inclut l’ajout ou la suppression de périphériques. Conservez l’ordre de relance et l’état immédiatement avant chaque événement. Un téléphone encore en charge à la fin peut cacher une courte interruption qui redémarre un autre appareil. Comparez la sortie délivrée et l’état de fonctionnement pertinent du dispositif de réception d’énergie, puis distinguez un changement d’allocation acceptable d’une régression de continuité non approuvée.
| Cas et révision | Observation de base | Observation des candidats | Preuve de décision |
|---|---|---|---|
| Profil fixe requis ; constructions identifiées | Demande requise acceptée et résultat vérifié | Même demande rejetée | Suivi des capacités et des demandes ; enquêter sur une régression involontaire |
| Limite PPS ; constructions identifiées | Limite applicable traitée comme spécifié | Réponse différente au même stimulus | Demande codée et méthode approuvée ; déterminer si le changement est intentionnel |
| Attachement au deuxième port ; constructions identifiées | Modifications de l’allocation dans le cadre du comportement convenu | Le dispositif de réception d’énergie active redémarre de manière inattendue | Capture de l’état du dispositif de sortie et de réception d’énergie ; décision de continuité requise |
| Récupération des pannes ; constructions identifiées | La prochaine pièce jointe réussit | La pièce jointe suivante ne peut pas être négociée | Traces de défauts et de reconnexion ; la fermeture du défaut reste incomplète |
Quels cas de panne doivent être conservés après une correction ?
Conservez le déclencheur d’origine et l’exigence de récupération.
Répétez la connexion suivante après la réponse au défaut ; un arrêt de protection réussi peut laisser un état persistant involontaire que le test initial à un événement ne parviendrait pas à révéler.
Utilisez des méthodes de laboratoire approuvées pour les messages invalides, les événements de détachement ou les stimuli de panne électrique. Enregistrez quel instrument a généré l’événement et comment ses paramètres ont été contrôlés. Une capture mal formée ne constitue pas automatiquement une preuve que le produit a reçu le défaut prévu. Vérifiez la délivrance du stimulus avant d’interpréter la réponse.
Comparez la récupération du candidat avec l’état de retour requis : inactif, contrat rétabli ou autre condition explicitement définie. Répétez la connexion appropriée après la récupération pour exposer l’état persistant du contrôleur. Un correctif qui survit à un événement mais laisse la pièce jointe suivante inutilisable est incomplet pour cette exigence. Conservez ensemble la preuve de défaillance originale et le nouveau résultat, avec une explication claire de la raison pour laquelle la récupération observée soutient la résolution du défaut.
Un correctif peut supprimer le défaut visible tout en modifiant le repli ailleurs. Réutilisez le stimulus défaillant d’origine, puis examinez les états adjacents atteints par le même chemin de contrôle. C’est plus informatif que de réexécuter une démonstration de puissance maximale sans rapport et de qualifier la régression de terminée.
Quelles preuves doivent autoriser la sortie d’un firmware ?
Approuvez explicitement la couverture définie et les problèmes non résolus.
L’artefact de production installé doit correspondre au candidat approuvé ; archivez sa configuration avec la couverture exécutée afin que les essais d’ingénierie ne puissent pas être confondus avec la version du micrologiciel publiée.
Le package de version doit identifier la version, la somme de contrôle de configuration ou le contrôle d’artefact équivalent, le matériel compatible et la matrice exécutée. Les résumés doivent être en accord avec les traces et mesures sous-jacentes. Un cas marqué comme réussi doit avoir une exigence et un résultat traçables ; un cas non exécuté doit rester non exécuté plutôt que d’être déduit d’un périphérique associé.
Élaborez l’approbation des versions en fonction des différences, et non en fonction du nombre total de réussites. Classer chaque résultat modifié comme prévu, comme une violation des exigences ou comme non résolu ; un cas omis reste non exécuté. Acceptez ces responsabilités dans la spécification OEM/ODM. Gardez l’artefact approuvé distinct d’un candidat qui a simplement réussi un sous-ensemble pratique. Pour corriger un défaut, conservez le déclencheur d’origine et les chemins affectés adjacents afin que l’approbation démontre la correction sans dissimuler une nouvelle régression de repli, d’allocation de port ou de récupération.
Questions fréquentes
Un multimètre peut-il remplacer une trace de régression du micrologiciel PD ?
Non. Il peut fournir une lecture électrique utile dans une condition particulière, mais il ne montre pas l’échange de capacités, le traitement des demandes ou la séquence d’événements contrôlés par le micrologiciel. Combinez des mesures électriques appropriées avec une capture décodée ou un journal de contrôleur validé. Même une tension finale stable peut suivre une réinitialisation ou un repli inattendu. Les outils nécessaires dépendent du cas ; l’enregistrement doit révéler à la fois le comportement évalué et le résultat délivré lorsque ce résultat affecte l’acceptation.
Les mises à jour du logiciel de l’appareil doivent-elles modifier la matrice de régression ?
Examinez-les lorsqu’ils peuvent modifier le modèle de demande du périphérique de réception d’énergie, les modes pris en charge ou le comportement de démarrage. Conservez l’état de l’appareil précédemment approuvé lorsque cela est possible et ajoutez un état mis à jour identifié séparément. Sinon, un dispositif de réception d’énergie modifié peut faire apparaître le candidat chargeur différent de sa ligne de base sans établir de régression du chargeur. Expliquez la décision de couverture et préservez les deux identités logicielles. La matrice doit refléter les conditions client prises en charge tout en permettant à un ingénieur de reproduire la comparaison originale.
Que doit-il se passer une fois qu’une régression non résolue du micrologiciel est détectée ?
Gardez le candidat distinct de la version approuvée et utilisez le processus de contrôle des modifications du programme pour prendre une décision documentée sur le traitement des résultats. Préservez la ligne de base, les mesures de relance défaillantes et la couverture affectée avant d’envisager une correction ou un retour en arrière. La réutilisation d’une version antérieure nécessite également un matériel et une configuration compatibles ; ne présumez pas qu’il est automatiquement approprié pour chaque assemblage révisé. L’approbation technique doit expliquer l’artefact accepté et les limitations restantes plutôt que de laisser une différence non résolue disparaître dans un décompte général de tests réussis.
Conclusion : libérer un artefact avec ses preuves
Une version de micrologiciel est un changement de comportement contrôlé. Comparez le candidat exact avec une référence reproductible, couvrez les chemins pertinents fixes, programmables, à puissance étendue et à ports partagés, et conservez les défauts qui ont précédemment exposé des faiblesses. Utilisez de véritables dispositifs de réception d’énergie et des stimuli contrôlés pour leurs différents objectifs au lieu de traiter l’un ou l’autre comme une couverture complète. Avant la publication, séparez les modifications prévues des différences inexpliquées et identifiez chaque cas non résolu. Conservez ensemble l’artefact approuvé, la configuration et les captures de support afin que la version installée en production puisse correspondre aux preuves examinées par l’ingénierie.
{« @context »: « https://schema.org », « @type »: « FAQPage », « mainEntity »: [{« @type »: « Question », « name »: « Un multimètre peut-il remplacer une trace de régression du micrologiciel PD ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Non. Il peut fournir une lecture électrique utile dans une condition particulière, mais il ne montre pas l’échange de capacités, le traitement des demandes ou la séquence d’événements contrôlés par le micrologiciel. Combinez des mesures électriques appropriées avec une capture décodée ou un journal de contrôleur validé. Même une tension finale stable peut suivre une réinitialisation ou un repli inattendu. Les outils nécessaires dépendent du cas ; l’enregistrement doit révéler à la fois le comportement évalué et le résultat délivré lorsque ce résultat affecte l’acceptation. »}}, {« @type »: « Question », « name »: « Les mises à jour du logiciel de l’appareil doivent-elles modifier la matrice de régression ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Examinez-les lorsqu’ils peuvent modifier le modèle de demande du périphérique de réception d’énergie, les modes pris en charge ou le comportement de démarrage. Conservez l’état de l’appareil précédemment approuvé lorsque cela est possible et ajoutez un état mis à jour identifié séparément. Sinon, un dispositif de réception d’énergie modifié peut faire apparaître le candidat chargeur différent de sa ligne de base sans établir de régression du chargeur. Expliquez la décision de couverture et préservez les deux identités logicielles. La matrice doit refléter les conditions client prises en charge tout en permettant à un ingénieur de reproduire la comparaison originale. »}}, {« @type »: « Question », « name »: « Que doit-il se passer une fois qu’une régression non résolue du micrologiciel est détectée ? », « acceptedAnswer »: {« @type »: « Answer », « text »: « Gardez le candidat distinct de la version approuvée et utilisez le processus de contrôle des modifications du programme pour prendre une décision documentée sur le traitement des résultats. Préservez la ligne de base, les mesures de relance défaillantes et la couverture affectée avant d’envisager une correction ou un retour en arrière. La réutilisation d’une version antérieure nécessite également un matériel et une configuration compatibles ; ne présumez pas qu’il est automatiquement approprié pour chaque assemblage révisé. L’approbation technique doit expliquer l’artefact accepté et les limitations restantes plutôt que de laisser une différence non résolue disparaître dans un décompte général de tests réussis. »}}]}