Collins Aerospace 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 seule fonction et sur un banc de test mécanique unique. »

- Scott Christensen, Collins Aerospace

Le défi :

Collins Aerospace 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 matérielles 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.

 

Collins Aerospace 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’affaires 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, commerciaux ou militaires.  


Les besoins en test du secteur aérospatial

Les éléments remplaçables en escale (LRU), les composants et les contrôleurs pour l’aérospatiale nécessitent des tests rigoureux. Les entreprises telles que Collins Aerospace 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 commerciaux ou avions militaires). Collins Aerospace 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 de transmission associés tels que les tubes de torsion et les boitiers d’engrenages. Chaque composant de ces systèmes doit être testé individuellement et conjointement au niveau 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 rendait les solutions de test rigides. Le test automatique était minime et la prise en charge de multiples configurations limitée. 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 tout simplement pas d’adapter assez rapidement l’architecture fragmentée existante pour répondre aux exigences accrues. Il fallait également que Collins Aerospace 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.

 

 

 

 

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 optimiser les tests en standardisant l’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. Tout 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 obtenir un contrôle 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 un contrôle distribué qui s’appuie sur les capacités d’extension du matériel NI CompactRIO et FPGA, et une interface directe dont le contrôle/la commande de charge servoélectrique met 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 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 de passer à 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 l’alimentation en CA et CC ; un châssis de simulation, de commutation et de surveillance de l’effort de freinage ; des alimentations en CC 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 CA/CC pour le test de la qualité d’alimentation.

 

Nous utilisons un logiciel basé sur LabVIEW pour faire fonctionner le banc de test de 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 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 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). Nous pouvons également 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 suivre 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 et 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 un 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 Collins Aerospace

Grâce aux produits de mesure et de contrôle distribué 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 charge 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 pu réduire le temps de développement de nos équipements de test tout en nous positionnant de manière à faire face aux besoins futurs, avec notamment un laboratoire de test plus numérique. Nous nous sommes épargnés des mois de développement et des centaines de milliers de dollars investis dans 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, ce qui élimine le problème lié aux composants électroniques vieillissants et immobiles construits pour une seule fonction 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é et libèrent ainsi des investissements dans d’autres innovations.

 

Informations sur l’auteur :

Scott Christensen
Collins Aerospace

Figure 1. Système de commande des dispositifs hypersustentateurs Collins Aerospace
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 de Collins Aerospace utilise du matériel et des logiciels NI de contrôle/commande de charge.
Figure 5. Cette solution de test peut effectuer des tests physiques et 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 à 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 le matériel 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 graphique d’avion

L’architecture de test des systèmes construite par UTC Aerospace Systems est meilleure

Vidéo 1. Nate Holmes, Principal Solutions Manager chez NI, décrit l’architecture de test distribuée, déterministe et dynamique (D3) de Collins Aerospace (autrefois appelée United Technologies Aerospace Systems (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.