L’architecture logicielle système au cœur du test automatique

Étendre la modularité de l’architecture système à la couche logicielle apporte davantage de flexibilité et fournit un framework qui permet de développer des stratégies de gestion de cycle de vie complexes, conduisant à la réduction des temps de développement logiciel et à la limitation des problèmes d’obsolescence.

Le rôle du logiciel dans le test automatisé a pris une ampleur considérable. Dans les faits, les coûts de développement logiciel sont fréquemment deux à dix fois plus élevés que celui des équipements dans la plupart des systèmes de test actuels. La répartition au sein de nombreux départements de test reflète cette tendance qui consiste à employer davantage d’ingénieurs logiciels que d’ingénieurs matériels. En réponse à l’augmentation des coûts de développement logiciel et à l’accélération des cycles de développement des produits, de nombreuses sociétés mettent aujourd’hui l’accent sur la conception d’une architecture logicielle système robuste, afin d’optimiser la longévité et la réutilisation de leurs investissements logiciels. En fait, une enquête menée en 2010, par National Instruments auprès des responsables de test, a révélé qu’une attention accrue portée aux logiciels système arrivait en deuxième position des principales stratégies visant à accroître l’efficacité de leur processus de développement de test en 2011. Une tendance confirmée dans le rapport annuel « Perspectives du test automatique » que National Instruments vient de publier.

La plupart des sociétés s’éloignent des architectures logicielles monolithiques qui contiennent souvent du code figé et des appels d’accès directs aux drivers d’instruments. A l’inverse, elles recherchent des architectures logicielles modulaires sous la forme d’éléments distincts et néanmoins étroitement intégrés en ce qui concerne les logiciels de gestion de test, logiciels d’application et logiciels drivers. Ce type d’architecture permet aux ingénieurs d’employer les meilleurs outils pour chaque domaine et de choisir entre les outils « sur étagère » et les outils développés en interne à chaque niveau. Une tendance significative est l’extension de la modularité au niveau de chaque couche de l’architecture logicielle, notamment avec l’utilisation accrue de modèles de processus, de bibliothèques de modules de code et de couches d’abstraction matérielle.

Plusieurs modèles de processus pour différentes lignes de produits

Le logiciel de gestion de test définit le flux élémentaire d’automatisation et de séquencement d’un système de test. Ce modèle de processus est une technologie cruciale en raison de son rôle dans la séparation des tâches de test des autres tâches, ce qui permet aux ingénieurs de standardiser et de gérer facilement ces dernières sur différentes séquences et stations de test. Les tâches sans rapport avec le test comprennent majoritairement la connectivité avec l’entreprise pour les entrées de données, l’enregistrement des données dans une base qualité, la communication avec l’atelier et la génération de rapports de test. Avec ce framework modulaire, les entreprises peuvent disposer de quelques modèles de processus qu’elles peuvent mettre en œuvre sur différentes lignes de produits et sur des centaines de testeurs déployés, voire davantage. Le modèle de processus simplifie également les modifications apportées aux fonctions non liées au test dans une station de test, sans pour autant avoir d’incidence sur les tâches de test, réduisant ainsi le temps nécessaire à l’actualisation des stations de test déployées. Par exemple, les ingénieurs peuvent rapidement modifier le flux d’exécution d’une station de test en fonction de la demande du marché en changeant de modèles de processus (tests séquentiels, par lot ou parallèles).

Succès des bibliothèques de code de test réutilisables

La couche du logiciel d’application est aussi importante car elle a un impact direct sur les tâches liées au test d’un système. De nombreuses entreprises se sont tournées vers le développement de code de test modulaire ou « modules de code ». Appelés par les logiciels de gestion de test, ces modules effectuent les mesures et analyses utilisées afin de déterminer l’état réussite/échec d’un pas de test. De nombreux modules de code remplissent des fonctions d’E/S similaires sur différents types de produits sous test (DUT), et constituent donc un domaine essentiel pour la réutilisation et les responsabilités de développement distribué avec des méthodes de développement en équipe. Récemment, l’industrie a vu un nombre croissant de sociétés adopter des bibliothèques de code de test réutilisables et davantage d’outils de contrôle de code source (SCC).

De nombreux fournisseurs de logiciels d’application assurent désormais l’intégration avec les outils SCC et proposent des caractéristiques avancées telles que la différenciation-fusion pour répondre à cette tendance relative au développement de logiciels de test. Certaines entreprises ont même mis en place des directives afin de garantir un certain niveau de réutilisation et de développement en équipe pour éviter de réinventer la roue et de devenir trop dépendantes d’un seul et même développeur pour toute la connaissance relative au développement du code.

En outre, les sociétés intègrent de plus en plus de logiciels de gestion des exigences dans la couche des logiciels d’application. Cela permet un suivi précis de la couverture de test par rapport aux exigences de conception, ce qui est critique au sein des industries fortement régulées. De nouveaux logiciels de traçabilité des exigences offrent un lien entre les logiciels d’application et les environnements de gestion des exigences, comme Telelogic DOORS, afin de réduire considérablement le temps passé à tracer la couverture des exigences dans le développement des systèmes de test.

Couche d’abstraction matérielle : Deux approches de conception

Un dernier élément de l’architecture logicielle système est de plus en plus demandé et utilisé : il s’agit de la couche d’abstraction matérielle (HAL). Cette dernière se trouve dans la couche du driver de l’architecture logicielle système, entre le logiciel d’application et le matériel d’instrumentation, ce qui réduit le temps et les coûts associés à la migration ou à l’actualisation des systèmes de test. Deux approches permettent de concevoir une couche d’abstraction matérielle : l’approche centrée sur l’instrument et l’approche spécifique à une application. En ce qui concerne l’interface de programmation d’applications (API) centrée sur l’instrument, cette approche permet de définir un « standard » commun interne pouvant être utilisé sur plusieurs types de DUT.

Les instruments IVI (Interchangeable Virtual Instruments), couche d’abstraction matérielle standard, ont une approche d’abstraction centrée sur l’instrument. À savoir, les applications de test de plus haut niveau appellent une API centrée sur l’instrument, ce qui fait que tous les instruments se ressemblent (par exemple, IviScope Configure AcquisitionType). Dans une approche spécifique à une application, les applications de test appellent une API spécifique à une application qui correspond au type de test qui doit être réalisé (un test de LED par exemple). Une couche d’abstraction matérielle est une méthode qui a fait ses preuves pour développer et maintenir un système de test faiblement couplé. Elle gère mieux les décalages entre les cycles de vie des produits et de l’instrumentation de test, et évite le code de test fortement couplé avec l’instrumentation de test. Coupler faiblement le code de test et l’instrumentation de test améliore la conception globale d’un système, tout en le rendant plus facile à maintenir et plus évolutif tout au long de sa durée de vie.

Étendre la modularité de l’architecture système à la couche logicielle apporte davantage de flexibilité et fournit un framework permettant de développer des stratégies de gestion de cycle de vie complexes. Ces stratégies permettent de réduire les temps de développement logiciel et de limiter les problèmes d’obsolescence en facilitant la gestion de sujets tels que le calendrier de lancement des caractéristiques, les mises à jour de systèmes ainsi que les prévisions d’insertion de l’instrumentation et des technologies conclut National Instruments.

Déjà paru :