Accélérer le cycle de vie de développement produit en réduisant le temps de test : Navigation dans le diagramme V

Les systèmes électromécaniques convertissent l’énergie en travail mécanique et inversement. Ils comportent des composants électroniques de contrôle (par exemple une unité de contrôle électronique, ECU) ou des contrôleurs embarqués (par exemple, une unité remplaçable en ligne, LRU) qui exécutent un logiciel spécialement conçu pour contrôler la mécanique, l’actionnement et les composants physiques selon les données de capteurs et d’autres systèmes. Les systèmes électromécaniques assurent la propulsion des véhicules et remplissent d’autres fonctions dans les avions, les véhicules au sol et les navires.   

Figure 1. Exemple de catégories de véhicules et types courants de systèmes électromécaniques

Bien que les fonctions, les méthodes d’action et les exigences de conception de ces systèmes puissent varier considérablement, le développement et le test des systèmes de véhicule électromécaniques suivent le même processus général. Les ingénieurs système conçoivent l’ensemble du véhicule et les exigences auxquelles doivent répondre les systèmes, les sous-systèmes et les composants du véhicule. D’autres équipes répondent à ces exigences en développant l’électronique, les logiciels et les composants mécaniques de commande appropriés par rapport aux spécifications. Ces équipes suivent leurs propres processus de développement (généralement une méthodologie commune comme Agile, adaptée à des exigences organisationnelles spécifiques) pour progresser dans les étapes de conception et de validation des composants spécifiques du système de véhicule électromécanique. Ensuite, le système est construit, intégré et testé par étapes, de façon itérative, pour produire le véhicule fini.

Figure 2. Processus généralisé de développement de produits pour systèmes électromécaniques

Le processus permettant de passer des exigences à la conception et à la validation est représenté de différentes manières, dont le modèle en V (Figure 3). Malgré toute la confusion entourant le modèle en V et ses nombreuses représentations et interprétations, c’est toujours un cadre utile qui sert à examiner les avantages d’une architecture de test universelle pour répondre aux besoins en tests tout au long de la conception.

Figure 3. La méthode de modèle V représente le processus de développement et les types de test associés

En général, le côté gauche du V représente le processus en détail, depuis les exigences de haut niveau jusqu’aux spécifications de niveau inférieur, en passant par la prise de décision progressive concernant la conception. Ces décisions sont plus fréquemment prises à l’aide d’une approche de conception basée sur un modèle qui englobe différents outils d’ingénierie assistée par ordinateur (IAO) en fonction du type de système en cours de développement. Pour en savoir plus sur ce sujet, consultez la documentation sur la transformation numérique et le jumelage numérique. Dans le bas du V, les systèmes ont été divisés en fonction de leurs composants de base les plus bas. La conception est prête à passer au stade de l’implémentation et les prototypes des composants sont prêts à être construits (Remarque : le code est également prêt à être déployé sur les prototypes exécutant le logiciel. C’est pourquoi le bas du V porte parfois le terme « déployer »). Le côté droit du V montre l’intégration de ces différentes pièces ensemble, la vérification de leur fonctionnement par rapport aux spécifications et la validation des performances par rapport aux exigences à chaque étape de l’intégration, depuis les composants de base jusqu’au niveau véhicule.

Remarque : Lorsque le système, les sous-systèmes et les détails des composants sont fournis, le développement du logiciel, des composants électriques et des composants mécaniques progresse en parallèle, comme illustré à la figure 2. D’autres équipes de conception et de test possédant l’expertise requise dans le domaine maîtrisent généralement le processus de développement.

Remarque : Les termes « vérification » et « validation » sont souvent utilisés indifféremment, et parfois le terme générique « V & V » est utilisé. En général, lors de la vérification, vous vous demandez : « Est-ce que je construis la chose correctement ? », puis vous vous assurez que le système fonctionne comme prévu (avec une marge de tolérance) par rapport à un ensemble de spécifications. Mais, lors de la validation, vous vous demandez : « Est-ce que je construis la "bonne chose" ? » Vous vous assurez que votre système, une fois terminé, peut effectuer les tâches pour lesquelles il a été conçu, avec des performances acceptables, mesurées par rapport à un ensemble d’exigences.

Les descriptions courtes et les définitions pour les tests suivants se trouvent approximativement dans l’ordre où vous les trouvez dans le processus de conception du produit, ce qui est très itératif en pratique. La possibilité de progresser rapidement et efficacement avec la conception en V, pour effectuer une itération de conception, est un avantage concurrentiel et une compétence clé de tout groupe de test de premier ordre. Une critique du modèle en V est qu’il représente un processus séquentiel du même type que la méthodologie de conception en cascade.

Test Model-in-the-Loop (MIL)

Pour le test MIL, vous modélisez à la fois le contrôleur et l’installation par logiciel. Vous effectuez ce type de test au début du processus de conception pour tester les stratégies de contrôleur et le comportement du système dans un environnement de simulation logicielle.

Test Software-in-the-Loop (SIL)

Pour le test SIL, vous modélisez l’installation, mais vous l’interfacez avec le code de contrôle réel écrit et exécuté dans le langage de développement sélectionné, puis compilé et exécuté sur le système de développement, parfois sur une machine virtuelle.

Test Processor-in-the-Loop (PIL)

Le test PIL est similaire au test SIL, mais le code de contrôle est écrit et compilé pour l’architecture de processeur et le système d’exploitation spécifiques qui seront utilisés dans le système déployé. Par exemple, si vous exécutez le code sur un FPGA spécifique, avec des paramètres spécifiques, vous le compilez pour ce scénario spécifique afin de garantir le bon fonctionnement de l’architecture réelle de traitement et pour garantir la disponibilité de ressources suffisantes. Il s’agit d’un pas de test distinct, car la mise en œuvre de l’architecture de traitement déployée et du matériel informatique peut s’avérer longue et fastidieuse, en particulier lorsque les optimisations de conception dans l’unité de commande électronique (ECU) provoquent des limitations et des compromis sur les fonctionnalités et les logiciels.

Prototypage rapide de systèmes de contrôle (RCP)

Le processus RCP est utilisé pour itérer rapidement sur des schémas de commande possibles à l’aide de modèles mathématiques fonctionnant sur un contrôleur temps réel et/ou un FPGA connecté via des E/S réelles à une installation réelle.

Test Hardware-in-the-Loop (HIL)

La simulation HIL teste le logiciel du contrôleur embarqué avec les composants physiques environnants et les capteurs simulés, afin que l’unité de commande électronique (ECU) effectue ses E/S électriques réelles avec un conditionnement de signaux, des niveaux de charge réels et la possibilité d’insertion de défauts.

Test physique

Les applications de test physique utilisent des mesures basées sur des transducteurs (tels que température, pression, contrainte/déformation, son/acoustique, accélération, déplacement, etc.) pour tester les caractéristiques physiques du composant ou du système testé. Les exemples d’applications comprennent le test de bruit, vibration et rudesse (NVH), ce qui implique de prendre des mesures acoustiques et de vibrations avec des microphones et des accéléromètres. D’autres exemples comme les tests de durabilité/de cycle de vie, bien connus sous les noms de test HALT (test de durée de vie extrêmement accéléré) et test HASS (essai de déverminage par contraintes thermomécaniques), visent à déterminer le comportement du produit sous test dans diverses conditions de fonctionnement anticipées.

Test d’intégration de système

1. Tout le côté droit du modèle en V met l’accent sur les niveaux successifs de test d’intégration. L’intégration implique généralement l’utilisation de deux types de systèmes essentiels :
   Les bancs de test sont utilisés pour tester l’intégration de divers composants dans un (sous) système unique pour le test au niveau du système. Les bancs d’essai conviennent pour une vaste gamme de tests, car ils rassemblent les divers composants de base dans un système opérationnel. Le fait de disposer d’un système fonctionnel facilite la configuration et l’exécution du test.
2. Le laboratoire d’intégration de systèmes ou « iron bird », qui consiste en l’intégration de plusieurs sous-systèmes à tester au niveau du véhicule, se rapproche de la configuration réelle du véhicule et des connexions du système. Il est utilisé pour le test du "système de systèmes" et le test des communications/interactions/conditions aux limites intersystèmes. Certains tests ne peuvent être couverts que par le biais de tests de grande magnitude sur l’infrastructure. Il s’agit là du dernier niveau d’essais avant la construction d’un prototype de véhicule pour les essais réels sur le terrain ou en vol.

Test MRO - Maintenance, réparations et obsolescence

Le test MRO ou test de dépôt couvre les services, les réparations et les mises à niveau dont les systèmes des véhicules ont besoin au cours de leur longue durée de vie, souvent de plusieurs décennies et de plusieurs générations. Parfois, le même équipement, ou une version modifiée, est utilisé pour les bancs d’essai du système. L’un des défis posés pour le test MRO consiste à maintenir efficacement les capacités de test tout au long du programme, en tenant compte des problèmes d’obsolescence du matériel et des logiciels du système de test, de la rotation du personnel et de la modification des exigences en raison des mises à niveau périodiques du système.

Test sur le terrain

Les véhicules utilisés pour les essais sur le terrain sont généralement dotés d’un grand nombre d’instruments, afin de fournir autant de données que possible sur le fonctionnement du véhicule au cours de ce type d’essai coûteux. Les considérations clés sont le poids/la taille, la capacité à alimenter l’équipement de test, ainsi que le stockage et la récupération des données. Bien que coûteux en temps et en argent, les tests sur le terrain restent un élément clé du processus de développement, car les modèles ne sont jamais parfaits et les interactions système sont complexes et peuvent entraîner un comportement imprévu qui n’avait pas été traité lors des procédures de test précédentes. Le test sur le terrain détermine si le produit est prêt.

Répondre aux besoins en tests tout au long du cycle de conception

Maintenant que vous connaissez mieux le processus de développement et les types de test associés, vous constatez l’avantage potentiel d’une architecture de test unifiée. La possibilité de répondre aux besoins en test tout au long du cycle de conception, du prototypage précoce à la validation logicielle, électrique et mécanique, en passant par les cellules de test système et les laboratoires d’intégration système, avec une seule plate-forme de test, permet un développement plus rapide des tests et une utilisation plus efficace des ressources. L’équipement et les personnes sont plus interopérables et interchangeables dans le modèle en V et pour tous les programmes. Cette capacité à progresser plus rapidement et plus facilement dans le modèle en V est extrêmement utile, en ce qui concerne les capacités de test et les itérations.

Une architecture de test unifiée offre des avantages similaires aux modèles de programmation orientée objet. Si vous savez que vous devez généralement développer le même type de système en utilisant des méthodes similaires, vous pouvez investir dans des blocs de construction de base pouvant être utilisés dans plusieurs projets et personnalisés en fonction des spécifications uniques de chaque projet.  

Cette approche de test basée plate-forme est plus robuste, car la plate-forme flexible et extensible qui sous-tend votre architecture de test garantit que les exigences changeantes et les demandes futures imprévues sur le système ne remettront pas tout votre travail en cause, en termes de fonctionnalités système et de capacités de test. Autrement dit, avec cette approche, vous pouvez vous préparer pour l’imprévu, et anticiper les futurs besoins en ne concevant pas concrètement chaque fonctionnalité. C’est une meilleure solution que les systèmes à fonction fixe spécialement conçus et pour lesquels vous devez explicitement concevoir la flexibilité et l’extensibilité dont vous pensez avoir besoin à l’avenir. Ces systèmes à fonction fixe vous obligent à faire des compromis entre le temps et le coût par rapport aux capacités.

Prise en charge du contrôle et de la simulation basés sur des modèles

Vous devez effectuer le maximum de tests possible, le plus tôt possible dans le processus de développement, afin d’accélérer le processus et garantir des tests moins chers et plus sûrs. Pour ce faire, vous pouvez utiliser une commande et une simulation basées sur un modèle afin de représenter correctement les stimuli et les conditions réelles en laboratoire. Cela vous aide à transférer des analyses, qui n’étaient auparavant possibles qu’avec des tests sur le terrain, dans le laboratoire d’intégration de systèmes ou sur les bancs de tests au niveau du système. Des techniques telles que l’enregistrement de stimuli du monde réel sur le terrain et leur « restitution » sur le système, via un actionnement contrôlé par modèle, améliorent ce type de test.
Vous pouvez également découpler les exigences de test des plans des autres équipes en simulant leurs composants. Toutefois, pour garantir une fidélité suffisante des résultats de test, vous devez passer du temps à valider la précision et l’efficacité des modèles et des méthodes utilisés pour simuler les composants.
Un autre avantage est la possibilité de mieux réaliser les tests difficiles à reproduire, dangereux et extrêmes. Cette couverture de test accrue se traduit par une plus grande confiance dans la conception.

Intégration et interopérabilité

Parfois, vous n’avez pas le choix quant au type ou à la marque de capteur, d’actionneur, d’instrument ou de logiciel que vous pouvez utiliser pour une fonction particulière. Faire fonctionner ensemble tous les éléments disparates d’un système représente souvent une part importante du coût de conception d’un système de test, en particulier lorsqu’il s’agit d’anciens composants lors de la refonte d’un testeur existant. La possibilité d’exploiter une plate-forme dotée d’une grande variété de fonctionnalités intégrées d’E/S et de matériels de tiers peut améliorer l’efficacité en maximisant la réutilisation et en minimisant le travail d’intégration. Une architecture d’E/S configurable/extensible et distribuée/synchronisée prend en charge les différents besoins des E/S pour différents cas de test tout au long du processus de conception et favorise la réutilisation entre programmes.

Gestion de systèmes et de données

Davantage de mesures, fournies toujours plus vite, produisent davantage de données - beaucoup plus de données - dans une variété de formats. De plus, davantage de clients doivent accéder à ces données dans le cadre de différents types de test du cycle de conception, afin de répondre à une plus grande demande de rapports. S’assurer que les données sont utilisables - et qu’elles sont réellement utilisées - présente déjà un défi. Vous devez pouvoir localiser et charger efficacement les données, les visualiser et les analyser de manière interactive, et gagner du temps en automatisant la génération de rapports. Une architecture de test unifiée doit fournir des cadres de gestion des données et des systèmes informatiques conviviaux au niveau de l’entreprise, afin d’améliorer la prise de décision, réduire le nombre de tests répétés, réduire le temps et les efforts de génération des rapports, et augmenter l’utilisation et la disponibilité des ressources pour que les données soient considérées comme un atout et non comme un inconvénient.

De plus en plus d’équipes de test et de développement ont des difficultés à gérer efficacement les systèmes de test déployés dans le monde entier, et à mettre en corrélation toutes les données générées. Une gestion efficace des systèmes de test distribués et des données peut être une source d’économies substantielles en termes de qualité des résultats obtenus, de réduction du temps d’immobilisation des équipements, et de renforcement de la confiance dans les données générées.

L’investissement dans une architecture de test unifiée, basée sur une plate-forme de test définie par logiciel, constitue une approche de premier ordre pour les équipes chargées de la conception et du test de systèmes de véhicules électromécaniques avancés. Cette approche permet un développement plus rapide des tests, une meilleure couverture de test, un fonctionnement plus efficace, une équipe plus souple et plus performante, une réduction des dépenses en capital, ainsi qu’une disponibilité et une maintenance améliorées du système de test à long terme, par rapport au développement intégral personnalisé en interne ou par sous-traitance.