UTAS fait des économies de temps, d'argent et d'efforts en développant une architecture de test unifiée pour les systèmes électromécaniques

Scott Christensen, Collins Aerospace

"Nous avons mis au point une architecture sur laquelle tout un laboratoire de test peut fonctionner avec une série de frontaux mobiles communs, ce qui élimine le problème lié aux composants électroniques vieillissants et immobiles construits pour une fonction unique et sur un banc de test mécanique unique."

- Scott Christensen, Collins Aerospace

Le défi:

La société UTAS avait besoin de créer une architecture de test multifonctions de bout en bout pour les systèmes électromécaniques, qui soit suffisamment flexible pour couvrir une grande variété de tests de contrôleurs et de composants de l'aérospatiale tout au long du cycle de développement produit pour les programmes nouveaux et existants.

La solution​:

En adoptant le standard des plates-formes PXI et CompactRIO de NI et le logiciel LabVIEW, nous avons pu construire une architecture de test modulaire qui peut être facilement configurée, personnalisée et maintenue. Nous avons collaboré avec des partenaires Alliance de NI, dont Wineman Technology sur le logiciel et Sierra Peaks sur l'instrumentation et l'actionnement.

 

United Technologies Aerospace Systems (UTAS) est l'un des plus grands fournisseurs mondiaux de produits de pointe pour l'aérospatiale et la défense. L'entreprise compte environ 42 000 collaborateurs et génère un chiffre d'affaire annuel supérieur à 14 milliards de dollars. L'unité commerciale chargée des systèmes d'actionnement conçoit et fabrique des systèmes de commande des dispositifs hypersustentateurs pour les avions d'affaires, de ligne ou militaires.


Les besoins en test du secteur aérospatial

Les unités remplaçables en ligne (LRU), les composants et les contrôleurs pour l'aérospatiale nécessitent des tests rigoureux. Les entreprises telles que UTAS doivent tester une multitude de configurations et de variantes d'un type de pièce dans le cadre de nombreux programmes de fabrication aéronautique (jets d'affaires, avions de ligne ou avions militaires). UTAS conçoit un grand nombre de composants utilisés dans les systèmes de vol des avions. L'unité systèmes d'actionnement conçoit des systèmes qui traduisent les commandes du poste de pilotage en déplacement des gouvernes de bord d'attaque et de fuite (volets, becs). Ces systèmes sont composés d'unités de commande électronique des volets et des becs (SFECU, slat and flap electronic control units), de blocs d'entraînement (PDU, power drive units) et d'éléments associés de transmission tels que les tubes de torsion et les boitiers d'engrenages. Chacun des composants de ces systèmes doit être testé individuellement et conjointement aux niveaux du système et de l'avion.

 

Les défis de l'approche traditionnelle du test

La méthode de conception et de test reste relativement similaire pour tous les composants. Cependant, au sein de l'unité systèmes d'actionnement, nous utilisions de nombreux bancs de test pour différents types de tests de LRU, dont le développement, la qualification, la production et la réparation. De plus, nous utilisions de la charge hydraulique sur les grands systèmes de test (à la fois pour une utilisation en interne et pour les clients) dont la reconfiguration était à la fois longue et coûteuse. Nous perdions du temps à recréer des architectures et des procédures pour effectuer des tests tout au long du cycle de développement produit.

 

 

Par exemple, les bancs existants utilisaient de la charge hydraulique pour le test mécanique de LRU. De nombreuses modifications réalisées sur les tests étaient similaires ; nous devions remplacer la tuyauterie des systèmes hydrauliques et effectuer de nouvelles connexions à chaque fois que nous voulions reconfigurer notre installation de test. Même dans le cas du test électronique, les bancs de test avaient besoin de matériel de vol réel, ce qui ajoutait à la rigidité et la faible flexibilité des solutions de test. Le test automatique restait marginal, tout comme la prise en charge de multiples configurations. L'approche traditionnelle du test était coûteuse et chronophage. Notre unité a dû composer avec des délais serrés et des ressources limitées qui ne nous permettaient simplement pas d'adapter assez rapidement l'architecture fragmentée existante pour répondre aux exigences accrues. Il fallait également qu'UTAS conserve un avantage concurrentiel sur les autres fournisseurs pour réduire les coûts et les délais et remporter les programmes futurs, ce qui a conduit l'entreprise à développer une nouvelle architecture de test.

 

 

 

 

Les avantages d'une plate-forme de test commune à toutes les étapes du cycle de conception

Le travail préparatoire et l'investissement consacrés à notre nouvelle architecture distribuée, déterministe et dynamique (D3) est une approche prospective qui portera ses fruits dans les années à venir. Nous avons constaté que nous pouvions véritablement optimiser les tests en standardisant sur une architecture de test commune à toutes les étapes du cycle de développement d'un composant. L'architecture D3 nous a permis de mettre en œuvre les types de tests suivants : tests model-in-the-loop (MIL), software-in-the-loop (SIL), et hardware-in-the-loop (HIL) ; test de validation et vérification (V&V) matériel et logiciel (insertion de défauts) ; test de durabilité du cycle de vie ; laboratoire d'intégration de systèmes (« iron bird ») ; test d'intégration de système au niveau de l'avion ; banc de test de système de dispositifs hypersustentateurs (HLSTR, high-lift system test rig) avec test du système physique au niveau de l'avion ; banc de test de systèmes (STR, system test rig) avec tests de performances, d'endurance et de fatigue ; banc de contrôle des volets/becs (SFCR, slat/flap controller rig) dont les tests de développement logiciel, de simulation « fly-the-box », des fonctions logicielles, de régression logicielle, de système et de production automatique (procédures de test de validation ou ATP, acceptance test procedures) ; et tests physiques dont des tests d'émulation d'une aile et du « côté droit » en fonction de la charge totale sur le côté gauche.

 

Nous avons atteint plusieurs objectifs. D'abord, nous avons créé une plate-forme de test commune qui fournit une architecture de test de bout en bout et un testeur polyvalent. Nous avons utilisé le même banc SFECU tout au long du cycle en V pour le développement, les procédures de test de validation, le test « iron bird », les tests d'intégration de systèmes (SITS, system integration test stand), le test en production d'unités de commande électronique et le test en production de matériel mécanique. Ensuite, nous avons intégré du matériel modulaire maintenable et reconfigurable. Désormais, nous pouvons aisément étendre l'architecture pour répondre aux besoins de plus vastes systèmes, la reconfigurer en fonction des différents systèmes et éviter d'installer des câbles ou tuyaux réels pour connecter les composants du système. Enfin, nous disposons d'une architecture logicielle ouverte facile à intégrer. L'architecture à mémoire réflective nous permet de contrôler complètement nos bancs de test via des lectures et écritures en mémoire. Nous pouvons utiliser cette architecture séparément, ou l'intégrer dans des systèmes de test plus vastes, et nous obtenons un contrôle/commande distribué qui fournit une puissance de traitement qui augmente avec la taille du système.

 

Détails de l'architecture D3

L'architecture D3 est une solution de test hautement flexible, modulaire et polyvalente qui intègre des technologies matures de l'industrie en limitant autant que possible les nouvelles conceptions. Ces technologies incluent du contrôle/commande distribué qui s'appuie sur les capacités d'extension du matériel NI CompactRIO et FPGA, et une interface directe avec le contrôle/commande de charge servoélectrique mettant en œuvre un module d'interface de commande d'axes de la Série C, des servocommandes Kollmorgen AKD et des servomoteurs AKM.

 

 

 

Le banc de test SFECU est une plate-forme montée en rack qui contient tous les contrôleurs réels ou une combinaison de contrôleurs réels et simulés. Lorsqu'un seul contrôleur est installé, nous pouvons simuler l'autre contrôleur via le bus de données CAN. Nous utilisons le système pour simuler les composants électromécaniques qui composent l'avion. Des outils de simulation propriétaires nous permettent de simuler les modes de défaillance de l'avion. Totalement programmable, le banc permet de réaliser des cycles opératoires automatiques ou des tests fonctionnels spécifiques. Dans tous les cas, il est possible de remplacer du matériel simulé par du matériel réel ou vice versa.

 

 

Le matériel qui compose ces bancs de test permet le passage sur du matériel réel d'avion ou des transducteurs simulés contenus dans les sous-châssis des bancs de test. Le banc de test contient également du matériel permettant de surveiller les tensions et intensités d'alimentation discrètes et analogiques, ainsi que les signaux envoyés par et vers le contrôleur de l'avion. Plus précisément, ces bancs de test incluent un châssis de contrôle et de surveillance de puissance AC et DC ; un châssis de simulation, de commutation et de surveillance de l'effort de freinage ; des alimentations DC internes ; des systèmes de simulation, commutation et surveillance de résolveur ; des systèmes de simulation, commutation et surveillance discrets ; des systèmes de transmission et réception en ARINC 429 et CAN ; un système de contrôle et de surveillance de l'arrêt d'urgence ; des boîtiers de connexions des signaux ; des systèmes d'acquisition de données ; des systèmes d'interfaces LRU génériques vers adaptateurs LRU personnalisés ; et un ordinateur sous Windows doté d'une alimentation sans interruption.

 

Les bancs de test sont également dotés d'interfaces électriques externes vers l'espace de travail partagé (interfaces homme-machine), d'interfaces de matériel de vol réel, de transmetteurs et récepteurs de courant externes ARINC 429, et de systèmes externes d'alimentation AC/DC pour le test de la qualité d'alimentation.

 

Nous utilisons un logiciel basé sur LabVIEW pour faire fonctionner le banc de test pour SFECU, ce qui nous permet de configurer et d'utiliser le banc de test aussi bien manuellement qu'automatiquement. Nous pouvons également contrôler et surveiller les fonctions du banc de test via un bus de données déterministe à mémoire réflective.

 

Utilisations pour différentes interfaces utilisateurs graphiques et configurations de banc

Nous pouvons personnaliser, enregistrer et reconfigurer le logiciel pour qu'il prenne en charge de nombreuses interfaces utilisateurs et configurations de banc différentes. Le banc de test d'intégration d'intégration de systèmes (SITS) pour ECU de volets et becs nous permet, par exemple, d'utiliser la base du banc de test avec un modèle de bloc d'entraînement exécuté dans le banc de test et de simuler pleinement tous les transducteurs et signaux discrets. Il est possible de corriger le système, les survitesses, les sous-vitesses et les défauts de surface en utilisant le poste de pilotage SITS (matériel de vol) et de la simulation pour transmettre la commande du levier de contrôle des volets et becs à l'ECU et au modèle des volets et becs. Nous pouvons appliquer des défaillances sur l'ECU des volets et becs pour valider la logique du système EICAS (engine indicating and crew alerting system), et nous pouvons tester les écrans de maintenance lorsque le banc est connecté à l'ECU des volets et des becs en simulant la totalité des communications, charges, signaux discrets et transducteurs. Pour les procédures de test de validation (ATP) de l'ECU des volets et becs, nous pouvons utiliser les mêmes procédures que celles de l'installation de production. Nous avons la possibilité de choisir entre différentes méthodes ATP, dont la simulation circuit par circuit ou intégrale avec logiciel de vol (test fly-the-box). Le test peut également être automatisé avec une interface utilisateur minimaliste et personnalisée ainsi qu'un séquenceur de test exécutant des scripts Python.

 

En outre, l'architecture D3 offre des configurations de banc de certification et de test de système intégré (ISTCR, integrated system test certification rig), de remise en service de l'ECU des volets et becs (pour diagnostiquer les conditions qui ont entraîné un verrouillage sur la défaillance), d'enregistrement et d'affichage (l'utilitaire de configuration de l'enregistrement des données à mémoire réflective facilite l'enregistrement des valeurs depuis la mémoire réflective à une fréquence de 200 Hz), d'enregistrement de données CAN et ARINC, d'affichage de données (l'interface utilisateur graphique de l'avion affiche les lectures de chacun des résolveurs, courants, tensions, etc. ; nous pouvons construire, personnaliser et enregistrer des interfaces utilisateur graphiques à partir d’éléments standards construits en interne), et d'automatisation (création de scripts via TestStand, Python, ou tout langage de programmation via sockets et sérialisation JSON ; d'automatisation à partir d'applications/systèmes externes avec accès au RFM ; de profils de stimulus pour utiliser le contrôleur à travers code LabVIEW personnalisé ; l'enregistrement et la lecture de macros ; des fonctionnalités logicielles automatiques ; et des procédures de test de validation (ATP) automatiques).


 

Économies de coûts, de temps et de main-d'œuvre pour UTAS

Grâce aux produits de mesure et de contrôle/commande distribués de NI, nous avons pu réduire le temps nécessaire à la reconfiguration des tests de quelques semaines à un jour seulement. Notre architecture D3 est polyvalente (les mêmes tableaux de charges sont utilisés pour le système, l'ATP et l'iron bird ; le même banc SFECU utilisé pour le développement, l'iron bird, le SITS et l'ESIM), modulaire (aucun fil ou tuyau à connecter ; les logiciels et matériels sont construits à partir de conceptions communes à plusieurs avions), facile à intégrer (architecture logicielle ouverte ; écriture de script dans n'importe quel langage ; architecture RFM éprouvée qui permet de faire fonctionner le banc de test en mode isolé ou intégré), maintenable (élimine la construction habituelle de faisceaux de câbles en recourant largement aux circuits imprimés), et tournée vers l'avenir (notre équipe a élaboré des conceptions brevetables).

 

En développant une plate-forme de test commune pour répondre à nos besoins en HIL, V&V, intégration de systèmes et test en production pour divers projets voire architectures d'avions, nous avons réussi à réduire le temps de développement de nos équipements de test tout en nous positionnant de manière à faire face aux besoins futurs, qui comprennent un laboratoire de test plus numérique. Nous avons économisé des mois de développement et des centaines de milliers de dollars sur la construction de nouvelles plates-formes tout en réduisant l'effort nécessaire au fonctionnement du laboratoire de test. Nous avons mis au point une architecture sur laquelle tout un laboratoire de test peut fonctionner avec une série de frontaux mobiles communs, qui élimine le problème lié aux composants électroniques vieillissants et immobiles construits pour une fonction unique et sur un banc de test mécanique unique. Nous tâchons maintenant d'achever l'intégration de cette nouvelle architecture dans nos systèmes techniques et commerciaux afin d'automatiser complètement notre laboratoire de test, pour que les préoccupations relatives aux frais de main d'œuvre appartiennent enfin au passé, ce qui libère des investissements pour d'autres innovations.

 

Informations sur l’auteur:

Scott Christensen
Collins Aerospace

Figure 1. Système UTAS de commande des dispositifs hypersustentateurs
Figure 2. Connexions et communications au sein du système de commande
Figure 3. Banc de test développé avec LabVIEW et l'interface graphique utilisée pour le test de systèmes physiques
Figure 4. Le banc de test de systèmes d'UTAS utilise du matériel et des logiciels NI pour le contrôle/commande de charge
Figure 5. Cette solution de test peut effectuer des tests physiques tout comme des simulations. Elle met en œuvre le même contrôleur et logiciel pour tester le produit tout au long du cycle de conception.
Figure 6. Banc de test typique de SFECU avec 2 voies
Figure 7. Ce schéma de l'architecture flexible montre qu'elle a été construite pour faciliter la permutation entre le matériel simulé et réel. Chaque module communique avec les autres modules à l'aide de la mémoire réflective.
Figure 8. Cet affichage de configuration des tests et de gestion de l'interface utilisateur témoigne de la grande diversité des unités sous test pouvant être gérées par cette architecture commune, et montre comment il est possible de configurer une application au niveau du sous-système.
Figure 9. Exemple d'interface utilisateur

UTC Aerospace Systems Builds a Better System Test Architecture

Vidéo 1. Nate Holmes, Principal Solutions Manager chez NI, décrit l'architecture de test distribuée, déterministe et dynamique (D3) d'UTAS, qui couvre de bout en bout les besoins des programmes de test, de la simulation à la validation, la qualification et la MRO (maintenance, réparation et révision) de matériel.