Vérification et validation avec TestStand

Avant de discuter des pratiques exemplaires de vérification et de validation, il est important de comprendre d’abord la différence entre ces concepts et la façon dont ils s’appliquent à un système de test.

Validation

Pendant le développement d’un système de test, la première étape consiste à comprendre et à documenter les exigences du test. Pour définir ces exigences, vous commencez à partir des spécifications de l’unité sous test (UUT) et développez les exigences de test pour vous assurer que toutes les déficiences de l’UUT sont détectées. À ce stade du développement, il est essentiel de s’assurer que les exigences définissent pleinement les conditions de défaillance de l’UUT. Le processus consistant à s’assurer que le système de test accomplit l’intention d’origine est appelé validation.

La validation est le processus consistant à évaluer si un système atteint réellement son objectif ou son intention.

La validation doit avoir lieu tout au long du processus de développement des tests, mais doit commencer durant la phase de collecte des exigences, car toutes les défaillances sont beaucoup plus faciles à résoudre au début du cycle de vie du projet. La validation peut inclure une procédure officielle de test réussi/en échec, ou il peut s’agir d’une forme subjective d’étude de convivialité réalisée avec des clients, des utilisateurs ou des patients. La validation comprend souvent des exigences subjectives, telles que « rejette les produits défectueux » ou « a une interface utilisateur conviviale ». Dans la mesure du possible, vous devez définir des exigences de niveau inférieur plus détaillées pour soutenir ces déclarations subjectives, afin de vous assurer que toutes les parties concernées sont d’accord sur ce qui est prévu.

Vérification

Une fois les exigences de test détaillées développées, les développeurs de tests peuvent concevoir et implémenter un système de test qui couvre les exigences. Lorsque le processus est terminé, les ingénieurs doivent s’assurer que le système de test couvre toutes les exigences définies. Le processus visant à garantir que le système de test répond correctement aux exigences spécifiées est appelé vérification.

La vérification est le processus consistant à déterminer si un système de test est construit conformément aux spécifications fournies dans une conception, un dessin, un énoncé de travail ou toute autre directive similaire.

Les tests de vérification doivent être effectués à plusieurs étapes du développement d’un produit. La vérification peut être effectuée sur tout le système dans son ensemble ou sur des composants plus petits du système de test.

Pour illustrer la différence entre la vérification et la validation, supposons qu’un service de test construise un élément de test simple pour mesurer la consommation de courant électrique d’une unité sous test (UUT). Le système de test doit comparer la mesure du courant pour les broches d’alimentation de l’UUT aux limites de test qui exigent que l’UUT consomme moins de 500 mA. Pour y remédier, les développeurs de tests définissent une exigence selon laquelle « le courant UUT ne doit pas dépasser 500 mA en pleine puissance ». Les développeurs conçoivent et implémentent ensuite un élément de test avec le matériel requis pour prendre cette mesure, et créent un cas de test pour vérifier le courant de l’UUT après avoir fourni la pleine puissance.

Pour effectuer la vérification du système de test, les développeurs vérifient que le système effectue la mesure correctement avec une répétabilité acceptable et produit une panne si la puissance dépasse 500 mA. Si le comportement du système de test correspond aux exigences, la vérification passe le test.

Cependant, un mode de défaillance existe pendant la fabrication : une diode installée à l’envers peut empêcher certaines parties du circuit de s’activer, entraînant une consommation de courant excessivement faible de 150 mA. Ce problème n’est pas signalé comme un échec par les systèmes de test, car seule une valeur limite maximale est testée et des unités défaillantes peuvent être expédiées. Bien que le système de test ait été construit correctement selon les spécifications, le système ne remplit pas l’objectif pour lequel il a été chargé et échoue à la validation. La spécification et le système de test doivent être modifiés pour incorporer une limite de mesure supérieure et inférieure, par exemple, entre 400 et 500 mA.

La vérification du système peut être relativement facile sur la base d’une spécification, d’un dessin ou d’un énoncé de travail bien rédigé, et les méthodes de test peuvent être très simples pour que les défauts soient faciles à trouver, mais la validation peut être plus difficile, comme le montre l’exemple précédent.

Étude d’impact

Une fois que la validation et la vérification d’un système de test sont terminées et que le système est mis en service, vous devrez probablement apporter des modifications ou des mises à jour au système. Ces mises à jour peuvent être dues à une maintenance, une réparation ou une tentative d’amélioration ou de correction des performances du système, comme le remplacement d’un instrument défaillant ou la modification d’un algorithme ou d’un paramètre. On parle d’étude d’impact lorsque vous apportez des modifications à un système, il est important de comprendre les parties du système de test à être revalidées pour garantir que les modifications n’introduisent pas de défauts. 

L’étude d’impact est le processus qui consiste à déterminer les composants d’un système de test touchés par un ensemble de modifications apportées.

Il est important d’effectuer une étude d’impact détaillée, car une modification peut entraîner un dysfonctionnement du système de manière imperceptible et entraîner des rappels de produits, des arrêts de production ou d’autres interférences avec les activités. Un changement peut également entraîner le bon fonctionnement du système, mais influencer le résultat ou les résultats des tests et mener à des décisions incorrectes concernant les produits testés. Le coût d’une modification manquée ou d’une validation incorrecte peut être extrêmement élevé. Dans certaines industries, les expéditions de produits défectueux peuvent entraîner un rappel de produit. La FDA se réserve le droit de prendre des mesures réglementaires. 

Afin d’atténuer l’incidence des modifications apportées à un système, il est important de concevoir le système de test de manière modulaire, de sorte que les modifications apportées à un composant n’aient pas de répercussions sur les autres. Pour ce faire, il est important de s’assurer que chaque composant est entièrement dissocié des autres composants et dispose de procédures indépendantes de validation. Par exemple, vous pouvez introduire une couche d’abstraction matérielle (HAL) qui fournit un ensemble standard de fonctions d’interface avec le matériel. Les fonctions définies par la HAL peuvent être validées indépendamment du système de test restant. Si vous effectuez une modification matérielle, l’incidence ne concernera que la couche HAL, car vous pouvez vérifier que les fonctions HAL ont le même comportement une fois la modification effectuée.

Normes industrielles de validation et de vérification

Les principes directeurs de V&V sont bien définis pour de nombreuses industries et sont décrits par des disciplines telles que les bonnes pratiques de fabrication (BPF) ou par des réglementations telles que ISO-9000, 21 CFR de la FDA ou les normes IEEE. Chaque système V&V est similaire, mais utilise une terminologie légèrement différente pour expliquer les exigences génériques des deux processus. Les exigences spécifiques ne sont généralement pas définies. Ce document explore les processus V&V pour les systèmes de test automatisés.

Dans la norme 21 CFR de la FDA, les exigences de validation se rapportant spécifiquement aux dispositifs médicaux sont vagues. Elles comprennent des énoncés indiquant qu’un dispositif médical doit être validé pour être conforme aux besoins de l’utilisateur et aux utilisations prévues, de sorte que le responsable du système qualité puisse définir les besoins et superviser les tests de validation. Pour les systèmes de test, une méthode de définition d’un test de validation peut être aussi simple que de garder une trace des modes de défaillance connus et de disposer d’échantillons de produits bons et mauvais pour garantir que le système détecte les défauts connus. Une autre méthode consiste à utiliser une procédure de test manuel fiable ou à inclure un autre système automatisé pour valider les résultats du nouveau système de test. 

Certains exemples de validation doivent être extrêmement approfondis, comme ceux qui concernent les industries des équipements médicaux, aéronautique, pharmaceutique, car les processus de validation comprennent des cas extrêmes de sécurité, de qualité ou de coût. Une validation approfondie du système peut prendre des semaines ou des mois à définir et à exécuter. Par exemple, si un système de test utilise une matrice de commutation dans une configuration 16 x 32, l’ingénieur de test peut tester toutes les combinaisons possibles de connexions à l’aide d’un testeur de continuité et s’assurer qu’aucune connexion restreinte n’est jamais établie. Un autre exemple pourrait consister à valider un système de communication dans lequel chaque commande et séquence de commandes possibles doit être testée et validée. Bien que de tels processus de validation puissent sembler extrêmes, il est impératif qu’aucun dommage, résultat incorrect ou qu’aucune blessure ne survienne en aucune circonstance.

Les processus V&V sont centrés sur des spécifications bien définies. La validation peut également entraîner des problèmes objectifs, tels que les besoins peu définis du marché ou de l’utilisateur final. La première étape la plus importante pour tout système de test est de rechercher et de documenter une bonne spécification de fonctionnement et les exigences V&V. S’assurer que le système de test est complet peut être difficile si les spécifications ne sont pas précises ou laissent place à interprétation ou à des ambiguïtés. Le test peut être interrompu si l’auditeur ou l’observateur trouve un paramètre non documenté ou implémenté de manière incorrecte. Une spécification bien rédigée implémentée avec soin peut aider à garantir un processus de V&V harmonieux.

La vérification nécessite un ou plusieurs documents de conception ou dessins pour déterminer ce que le système doit accomplir.  Les documents et les dessins peuvent couvrir un composant, un assemblage ou un système entier. La spécification et la méthodologie de test pour la vérification doivent consister en un document entièrement détaillé contenant autant d’informations que nécessaire pour créer un système de test .

Assurez-vous d’enregistrer toutes les modifications apportées aux spécifications, qu’elles aient été conçues par un client, par des ingénieurs ou à la suite d’apprentissage et de la découverte. Utilisez un processus de demande de changement pour enregistrer le changement et la raison, et pour rendre le changement officiel. La vérification réussit uniquement si vous faites correspondre les instructions, les paramètres et les limites de test au bon document. 

La conception d’un test de validation est souvent subjective et peut sembler être un art plus qu’une science. Bien que la sagesse et l’expérience puissent sembler les seuls outils de conception de validation, rappelez-vous que la collecte des exigences peut être révélatrice et utile. Les techniques comprennent l’examen des performances passées d’autres périphériques ou produits de test, des entretiens avec des opérateurs et de leurs superviseurs et l’étude des données de mesure passées. Une entreprise qui confie souvent des tâches à des intégrateurs de systèmes effectue un examen détaillé de chaque projet pour trouver des moyens d’améliorer le prochain projet et intègre ces idées dans une liste de contrôle pour le projet suivant.

TestStand est construit sur une architecture modulaire, avec de nombreux composants dissociés, y compris le moteur TestStand, les modèles de processus, le code de test et l’interface utilisateur. Cette architecture est bénéfique pour les efforts de V&V, car chaque composant peut être plus facilement analysé de manière indépendante. En outre, les modifications apportées aux systèmes de test existants nécessitent moins de revalidation, car l’incidence peut souvent être limitée à un seul composant.

L’architecture modulaire de TestStand permet à chaque composant d’être vérifié et validé indépendamment et réduit l’incidence des changements sur le système de test dans son ensemble.

Pendant la conception d’un système de test, il est important de prendre en compte la vérification et la validation et la manière dont vous pouvez concevoir le système pour faciliter ces efforts. Les sections suivantes présentent les pratiques exemplaires pour la conception des composants de votre système de test en tenant compte de la V&V.

Conception de fichiers de séquence

Lorsque vous développez des séquences de test, gardez à l’esprit les objectifs suivants :

• Composez la fonctionnalité en utilisant des sous-séquences pour les blocs logiques de fonctionnalité.
• Réduisez l’interaction entre les pas, ce qui réduit l’incidence des modifications apportées aux pas individuels sur le système de test.

En vous concentrant sur ces objectifs, vous pourrez mieux suivre la manière dont les exigences sont couvertes dans le code de test et réduire l’incidence des modifications que vous apportez aux pas individuels.  

Utilisation de pas séparés vs des paramètres de pas

Pendant la définition d’une condition pour un pas, déterminez si la condition s’appliquera un jour à plusieurs pas. L’utilisation des pas If/Else ou Case pour implémenter la logique est plus visible dans l’environnement TestStand, est extensible et peut être modifiée pour exécuter différentes options et inclure plus d’un pas par condition. Cependant, ils introduisent des relations entre les pas de test et le contrôle de flux. Pour une logique qui s’appliquera toujours à un seul pas, l’utilisation d’une condition préalable vous permet de contenir la logique et le pas dans un seul composant.
Utilisez une approche similaire pendant l’implémentation de la commutation dans votre code de test. Pour les itinéraires qui s’appliquent à un seul test, l’utilisation des paramètres de commutation d’un pas vous permet de composer la fonctionnalité de commutation avec le code de test. Pour un changement qui a une incidence sur plusieurs pas, l’utilisation de pas de commutation est plus visible dans une séquence et rend la séquence davantage auto-documentée.

Modularisation à l’aide de sous-séquences

Pour combiner les avantages de la mise en composants des paramètres de pas intégrés avec l’extensibilité de l’utilisation de pas séparés, vous pouvez créer des sous-séquences pour encapsuler des ensembles de pas associés. En contenant des ensembles de telles séquences dans un fichier de séquence séparé, vous pouvez créer efficacement un fichier de séquence qui est une bibliothèque de fonctions, qui peut être indépendamment validée et partagée entre plusieurs applications de test.
De plus, la séquence de test doit être composée presque entièrement de pas d’appel de séquence qui implémentent chacun un regroupement logique de tests. L’organisation des sous-séquences doit correspondre aux spécifications de test, où les exigences de haut niveau, telles que « le système doit tester les capacités audio du périphérique », doivent correspondre à une séquence du test, tandis que les exigences inférieures, telles que « le volume sonore maximum ne doit pas dépasser 80 dB » doit correspondre aux pas de la séquence.

Réduction des dépendances entre plusieurs pas

Vous pouvez également introduire des dépendances entre les pas dans le cas où un pas nécessite des données obtenues au pas précédent. Évitez d’utiliser la propriété PreviousStep pour accéder directement aux données à partir d’un autre pas, et utilisez plutôt une variable locale pour stocker les données du premier pas, puis accédez à la variable au pas ultérieur.

Vous devez également vous assurer que chaque pas définit ou vérifie indépendamment que les conditions requises sont définies avant l’exécution du test. Par exemple, si un pas de test de volume audio comprend un test de volume à volume faible, moyen et élevé, et qu’un pas ultérieur effectue un test de qualité audio qui doit être effectué à volume moyen, vous devez vous assurer que le volume est réglé sur moyen avant d’effectuer le test. Ce procédé garantit que les deux tests sont indépendants : apporter des modifications au test de volume audio n’aura pas d’incidence sur le test de qualité audio.

Documentation des séquences de test

Une documentation claire de vos fichiers de séquence est un élément important pour garantir que toutes les exigences de la spécification sont suffisamment couvertes. Cependant, vous devez éviter de répéter les informations de la documentation, telles que les valeurs limites ou les paramètres de test. 

Vous pouvez utiliser le nom et la description du pas pour documenter l’objectif d’un pas. Le nom du pas doit décrire ce que fait le pas et pourquoi il exécute une action, mais ne doit pas contenir les valeurs de paramètre définies dans le pas. Par exemple, au lieu de nommer un pas « Attendre », nommez le pas « Attendre le démarrage du système ». Si le nom nécessite plus d’informations, utilisez la propriété Description du pas pour spécifier des détails supplémentaires.

Vous pouvez également utiliser l’intégration de TestStand avec NI Requirements Gateway pour suivre efficacement où les exigences sont couvertes dans le code de test réel. NI Requirements Gateway vous permet de voir rapidement les exigences couvertes et vous permet de naviguer jusqu’au pas qui couvre l’exigence, ce qui accélère le processus de vérification.

NI Requirements Gateway vous permet de créer des liens entre vos documents d’exigences, vos séquences de test et vos rapports de test pour vous assurer que toutes les exigences sont couvertes

Vous utilisez le champ Exigences (Requirements), disponible pour les pas, les séquences et les fichiers de séquence, pour fournir des informations sur les exigences qu’ils couvrent. Vous pouvez utiliser ces champs avec NI Requirements Gateway pour créer un mappage entre votre document d’exigences et votre code de test afin de voir rapidement où les exigences sont couvertes. 

Utilisez le champ des exigences pour mapper des pas, des séquences ou des fichiers de séquence à des exigences spécifiques dans vos documents de spécification

Pour plus d’informations sur l’utilisation de NI Requirements Gateway avec TestStand pour suivre les exigences, reportez-vous au tutoriel Couplage de NI Requirements Gateway avec NI TestStand.

Développer des modules de code indépendants

Les pas TestStand appellent des modules de code pour communiquer avec le matériel d’instrumentation et d’automatisation. Les modules de code peuvent être implémentés dans un certain nombre de langages, notamment LabVIEW, C++ ou C#. Puisque TestStand fournit une frontière naturelle entre les pas et les modules de code, il est avantageux d’écrire des modules de code qui peuvent être testés et validés indépendamment de la séquence TestStand. 
Pour vous assurer que les modules de code peuvent être testés en dehors de la séquence de test, évitez d’utiliser SequenceContext ou d’autres références TestStand pour accéder directement aux données, et passez plutôt des données dans le module de code via des paramètres. Pour les cas où l’utilisation de SequenceContext est nécessaire, comme l’implémentation d’un moniteur de terminaison, concevez le module de code de sorte qu’il puisse fonctionner sans le code spécifique à TestStand. Dans un module de code LabVIEW, vous pouvez utiliser la fonction « pas une référence » pour vérifier si SequenceContext est valide avant de l’utiliser.

Avec des modules de code exécutables indépendamment, vous pouvez concevoir des éléments de test qui bouclent sur le module de code et passer toutes les permutations des paramètres d’entrée. L’élément de test peut alors comparer les résultats avec des résultats corrects connus pour valider que les modules de code se comportent comme prévu.

Modifier des modèles de processus à l’aide de plug-ins

Les modèles de processus TestStand gèrent des fonctionnalités de test qui ne sont pas spécifiques à une unité sous test, notamment le suivi UUT, la génération de rapports, l’enregistrement de la base de données et les tests par lots ou parallèles. Les modèles de processus fournis avec TestStand sont complexes. C’est pourquoi effectuer des modifications à ces modèles nécessite un effort de validation important. 

Les modèles de processus utilisent une architecture de plug-in qui implémente les capacités de génération de rapport et d’enregistrement de base de données par défaut. Vous pouvez utiliser cette architecture pour étendre les fonctionnalités des modèles de processus existants sans apporter de modifications aux fichiers de séquence de modèle de processus eux-mêmes. Pour ce faire, vous créez un plug-in personnalisé, qui est implémenté dans un fichier de séquence de plug-in séparé. Vous pouvez valider le comportement de ce plug-in indépendamment.

Les plug-ins de modèles de processus sont des composants séparés des fichiers de modèles de processus, qui peuvent être validés individuellement

Si vous devez apporter des modifications aux fonctionnalités directement dans les modèles de processus eux-mêmes, par exemple en modifiant la manière dont le modèle collecte le numéro de série UUT, envisagez de désactiver les pas du modèle de processus qui implémentent la fonctionnalité existante, puis créez un plug-in séparé pour la nouvelle fonctionnalité. En utilisant cette approche, les modifications futures que vous apporterez au comportement personnalisé peuvent être limitées au seul plug-in, qui sera plus facile à revalider. 

Pour plus d’informations sur la personnalisation des modèles de processus et des plug-ins, reportez-vous au document Pratiques exemplaires pour le développement et la personnalisation de modèles de processus NI TestStand.

Gestion de la configuration et des paramètres de test

Pendant le développement d’un système de test, il est important de s’assurer que tous les paramètres TestStand sont les mêmes sur toutes les stations exécutant le test et ne sont jamais modifiés sans une validation appropriée du changement. Cependant, étant donné que de nombreux composants TestStand ont des paramètres individuels, il peut être difficile de s’assurer qu’aucun changement n’est présent. En plus des paramètres TestStand, vous devez également vous assurer que les paramètres de l’instrument sont cohérents entre les systèmes de test. Les paramètres de l’instrument peuvent inclure les paramètres NI-DAQmx définis dans NI Measurement & Automation Explorer (MAX), ou les paramètres GPIB et COM d’un périphérique. Ces paramètres peuvent être nombreux et les tests de validation difficiles à concevoir.

Une façon de s’assurer que les paramètres sont corrects consiste à les définir par programme dans votre séquence de test, puis à interroger chaque paramètre pour s’assurer que le paramètre a été accepté par l’instrument ou le programme. Si le paramètre ne peut pas être interrogé, recherchez l’emplacement de stockage du paramètre et lisez-le à partir d’un fichier texte, INI ou XML. Le système peut vérifier et enregistrer l’état des éléments en dehors de TestStand et les garder sous contrôle.

Gestion des fichiers à l’aide des outils de contrôle du code source

Une autre approche de la gestion des paramètres consiste à contrôler strictement les fichiers contenant les paramètres. Les fichiers de configuration qui stockent tous les paramètres TestStand sont stockés dans le répertoire <TestStand Application Data>\Cfg. Pour les autres paramètres, reportez-vous à la documentation spécifique au produit pour plus d’informations sur l’emplacement des fichiers de paramètres
Les programmes de contrôle de code source (SCC) tels que Subversion, Perforce et Microsoft Visual Source Safe sont la méthode acceptée par l’industrie pour surveiller, contrôler et stocker les fichiers du système de test. Beaucoup de ces programmes sont conçus pour se conformer à l’interface Microsoft SCC et vous pouvez les utiliser à partir de TestStand ou LabVIEW. Dans certains cas, vous ne pouvez pas modifier un fichier sans en prendre temporairement possession et documenter vos modifications afin de les enregistrer. Ces programmes peuvent souvent vous indiquer les fichiers modifiés et analyser les anciens et les nouveaux fichiers pour mettre en évidence les modifications afin de simplifier la vérification.

Vous pouvez également utiliser les sommes de contrôle des fichiers pour vous assurer que les fichiers de paramètres n’ont pas changé depuis l’état validé. Pour utiliser cette approche, vous pouvez ajouter des étapes qui comparent la somme de contrôle à une somme de contrôle que vous calculez pour la valeur de fichier validée et génèrent un échec de test si elles ne correspondent pas.   

En plus du système de test, il est important de s’assurer que tous les matériels et logiciels prenant en charge le test sont dans un état connu et validé. Cette section fournit des techniques pour maintenir l’état du système et comment appliquer les modifications si nécessaire.

Gestion de la configuration du matériel

Vous devez sélectionner, installer, programmer et configurer correctement les instruments non seulement pour le système, mais également pour chaque test individuel. Par exemple, un multimètre numérique (DMM) ou un oscilloscope a plusieurs options à configurer pour une communication et une acquisition de signal appropriées qui doivent être vérifiées et validées à la fin d’un système de test et pour les changements de matériel à l’avenir.

La création d’une couche d’abstraction matérielle (HAL) pour gérer les interactions matérielles peut aider à réduire la revalidation requise durant la modification du matériel dans le système de test. Au lieu d’employer des modules de code spécifiques à chaque matériel dans une séquence de test, les HAL permettent de dissocier les types de mesure et les drivers spécifiques aux instruments de la séquence de test. Comme les procédures de test sont généralement définies en utilisant des types d’instruments (blocs d’alimentation [PS], multimètres numériques [DMM], sorties analogiques [AO], et relais) plutôt que des instruments spécifiques, le recours à des couches d’abstraction se traduit par une séquence de test plus aisément adaptable aux nouveaux instruments et besoins. Avec une HAL en place, vous pouvez valider le nouveau matériel en vous assurant que les fonctions HAL produisent la même sortie que le matériel précédent dans un ensemble de cas de test, sans qu’il soit nécessaire de tester complètement l’ensemble du système de test. Pour plus d’informations sur l’utilisation des HAL, reportez-vous à Principes fondamentaux du montage d’un système de test : Couches d’abstraction matérielle et de mesure.

C’est également une bonne idée de valider le matériel au moment de l’exécution. En lisant et en stockant les paramètres ou d’autres facteurs au moment de l’exécution, vous pouvez être sûr que les éléments qui doivent être validés avec le logiciel sont configurés et fonctionnent comme prévu. Par exemple, vos pas TestStand peuvent interroger les dates d’étalonnage d’un instrument pour s’assurer que l’étalonnage est à jour et peuvent vérifier le numéro de modèle et le numéro de série de l’instrument connecté à un port COM pour garantir que l’instrument n’a pas été remplacé. Concevoir votre séquence de test et même acheter des instruments en tenant compte de ces considérations peut aider à simplifier les processus de V&V.

Si vous prévoyez que votre matériel doit changer, vous devez considérer le changement dans un processus V&V. Si un instrument tombe en panne et qu’un autre instrument de la même marque et du même modèle est inséré, réfléchissez à ce que vous devez accomplir pour vérifier s’il fonctionne correctement et concevez un test pour vous assurer que le changement a réussi. L’utilisation de drivers et d’interfaces pour instruments virtuels interchangeables (IVI) pour la configuration de l’instrument peut aider à simplifier la transition entre deux instruments de la même marque ou du même modèle, ou entre deux instruments de marque ou de modèle différents.

Gestion de la configuration logicielle

Durant la maintenance d’un système de test, vous devrez envisager de mettre à niveau LabVIEW, TestStand ou tout autre programme pour profiter des nouvelles fonctionnalités dès qu’elles sont disponibles. Faire une telle mise à jour logicielle est toujours un déclencheur pour une revalidation et une revérification. Traitez une mise à niveau potentielle comme un exercice de retour sur investissement (ROI). Par exemple, pour obtenir une interface de développement simplifiée, vous souhaiterez peut-être effectuer une mise à niveau pendant le développement, mais pas après le déploiement du système. Cependant, comme c’est le cas avec les mises à niveau récentes de TestStand, une vitesse d’exécution améliorée peut se traduire par un temps de test plus court, un débit plus élevé et des revenus plus importants. Dans les deux cas, le coût de la revalidation est le facteur décisif, mais le coût peut également fournir un retour sur investissement positif et vaut donc la dépense et l’effort. En règle générale, plusieurs mises à niveau logicielles doivent être effectuées à la fois, afin de minimiser le nombre de fois où le logiciel doit être validé.

Pour maintenir un ensemble cohérent de logiciels sur un système de test, envisagez de créer une image de base à partir d’un système validé et d’utiliser cette image pendant la configuration de nouvelles stations de test. Cependant, même lorsque vous utilisez une image, vous devez vous assurer qu’aucune mise à jour logicielle n’a lieu. Pour le logiciel National Instruments, assurez-vous que le service de mise à jour NI est configuré pour ne jamais installer automatiquement les mises à jour. Par défaut, les mises à jour Microsoft se produisent automatiquement sur la plupart des ordinateurs. D’autres sociétés, telles que Sun, Apple et Adobe, utilisent également des mises à jour automatiques basées sur le Web. Vous devez désactiver toutes les modifications et mises à niveau automatiques sur tout système soumis à des processus V&V. Les modifications apportées par les mises à jour automatiques ne sont pas prévisibles et peuvent avoir des effets inconnus sur le fonctionnement et les paramètres. 

Votre service informatique peut avoir pour politique générale de contrôler les ordinateurs de l’entreprise, notamment en utilisant un logiciel antivirus, en définissant des politiques de sécurité telles que des écrans de veille et en installant des correctifs et des mises à niveau si nécessaire. Un service de fabrication doit travailler avec le service informatique pour aider à gérer les systèmes TestStand en les laissant intacts. Vous devez décider les éléments concernant spécifiquement vos ordinateurs, mais vos besoins peuvent contraster avec la politique informatique, comme la suppression des antivirus, la désactivation des écrans de veille et la dispense des mises à niveau ou des correctifs à l’échelle de l’entreprise.

Cliquez ici pour accéder à d’autres ressources de la série TestStand Advanced Architecture, qui traite de sujets d’intérêt pour les développeurs avancés en NI TestStand.