Architecture avancée de test de moteur-fusée pour une indépendance et une maintenance accrues des systèmes

En 2021, le nombre de tentatives de mise en orbite a été le plus élevé de l’histoire.¹ Des entreprises et des gouvernements du monde entier ont tenté 146 vols, dont 135 ont été couronnés de succès. L’année 2021 a vu battre le précédent record de 139 tentatives, établi au plus fort de la course à l’espace en 1967, alors que l’URSS et les États-Unis rivalisaient d’ardeur pour aller dans l’espace et au-delà. La course à l’espace des années 2020 ne se limite pas à deux pays. Les États-Unis, le Royaume-Uni, l’Europe, la Russie, la Chine, l’Inde, la Turquie, l’Iran, Israël, etc. réalisent désormais des lancements ; les six premiers mois de 2022 ont vu la tendance se poursuivre avec 72 vols réussis. Et cette course n’est plus seulement un projet gouvernemental : de nombreuses entreprises spatiales privées sont en compétition, apportant de grandes quantités d’argent d’investisseurs sur le marché.

Les nouvelles technologies de fusées favorisent l’essor des lancements spatiaux. SpaceX a lancé 31 missions Falcon 9 en 2021, toutes couronnées de succès. La nouvelle approche de l’entreprise en matière de conception des fusées lui a permis de lancer toutes ces missions avec des cœurs de fusée déjà utilisés ; seuls deux nouveaux premiers étages Falcon 9 ont été introduits afin de soutenir ces lancements. Comme les entreprises et les pays continuent d’investir pour rendre les lancements spatiaux plus fiables, réutilisables et abordables, le nombre de lancements et leur portée continueront d’augmenter.

L’infrastructure nécessaire au soutien de ces lancements évolue également. Il existe 35 ports spatiaux et installations de lancement en activité capables de prendre en charge des missions suborbitales, orbitales et extraorbitales. La liste des lieux d’implantation s’étend à tous les continents et à plus de 13 pays,² d’autres pays construisant actuellement de nouvelles installations. D’autres sites sont également utilisés pour tester les fusées qui décollent de ces installations. Cette aventure au cœur de l’industrie spatiale est passionnante.

La FAA réglemente les lancements de fusées sur le sol américain ou en dehors des États-Unis pour tout lancement effectué par un citoyen ou une entité américaine. ³ D’autres pays disposent de réglementations et d’organismes de régulation similaires ; une entreprise ne peut pas se lancer dans l’espace sans passer par les étapes d’ingénierie appropriées. L’une de ces étapes essentielles consiste à tester le véhicule-fusée et à démontrer ses grandes chances de réussite.

Le test d’une fusée commence par celui de ses différents composants. Les équipes d’ingénieurs testent séparément les matériaux et les composants qui constitueront la structure, les carburants et l’électronique. Ces composants sont ensuite assemblés et testés en tant que sous-systèmes, puis entièrement assemblés dans le cadre d’un test d’acceptation complet au niveau de l’étape.

Les produits NI sont utilisés à tous les niveaux du véhicule. La plate-forme de test structurel statique et de fatigue est idéale pour tester la résistance du réservoir de carburant aux contraintes d’un vol. Les instruments modulaires PXI de NI et le logiciel de test automatisé constituent une plate-forme puissante pour tester les circuits avioniques. L’architecture de test HIL LRU de NI est idéale pour générer divers cas de test visant à tester les contrôleurs avioniques. 

Cet article se concentre sur le test du moteur-fusée, mais de nombreux éléments s’appliqueront également au test final du véhicule complet.

Les tests de moteurs-fusées constituent une partie essentielle des tests de tous les types de moteurs-fusées ; ces tests sont nécessaires pour répondre aux réglementations de la FAA. La valeur des tests ne se limite toutefois pas au respect des réglementations. Un rapport de la NASA a démontré qu’il existe une corrélation positive entre le temps passé à tester les moteurs-fusées et leur fiabilité. ⁴ Chaque fabricant de moteurs doit décider comment équilibrer l’investissement et le coût des tests supplémentaires et le bénéfice attendu de ces tests.

Un test stand de moteur-fusée est une structure conçue pour maintenir et tester les moteurs-fusées en fournissant les systèmes de soutien et de contrôle nécessaires, y compris les structures de poussée de maintien, l’équipement de soutien au sol pour les propulseurs, les systèmes de refroidissement, la déviation des gaz d’échappement et l’automatisation pour la sécurité et la gestion opérationnelle pendant les tests. Pour tester un moteur-fusée, celui-ci est monté sur un test stand et mis à feu pendant une durée limitée. Le test stand pour moteur-fusée doit fournir une structure de maintien de la poussée nécessaire, un équipement de soutien au sol pour les propulseurs, le refroidissement, la dérivation et l’échappement, ainsi qu’un système de contrôle pour automatiser le test et maintenir la sécurité tout au long des opérations et du test. Les ingénieurs doivent décider si la fusée sera montée verticalement ou horizontalement, chacune des orientations présentant des avantages. Il est plus facile de corréler les mesures avec un moteur monté verticalement, car les forces se rapprochent davantage de celles subies en vol. Un moteur monté verticalement pose toutefois le problème de l’éloignement des gaz d’échappement de la fusée pendant le test, ce qui se fait généralement à l’aide d’un déviateur de flamme.

Figure 1. Éléments d’un test stand de moteur-fusée

L’échappement pose plusieurs problèmes à l’installation de test. Outre la chaleur, l’échappement est bruyant et sale. L’ajout d’un déluge d’eau à l’échappement peut fournir une certaine marge permettant d’éloigner la chaleur du moteur et un bouclier pour atténuer le bruit et les contaminants provenant de la communauté environnante.

Il existe de nombreuses variations lors d’un test de moteur-fusée. Un test standard au niveau de la mer peut être réalisé sur un test stand sans beaucoup d’équipement supplémentaire, mais d’autres tests peuvent nécessiter des environnements de test spécialisés. Par exemple, pour tester un propulseur de fusée destiné à contrôler l’attitude d’un satellite dans l’espace, le test stand a besoin d’une chambre à vide pour reproduire les conditions de fonctionnement prévues du moteur. Il arrive que d’autres tests nécessitent une chambre à vide thermique ou des dispositifs mécaniques supplémentaires pour tester le cardan du moteur.

Les stations de test varient également en fonction du stade de développement du moteur. Un test de moteur en début de développement peut inclure de nombreux capteurs supplémentaires, car les ingénieurs tentent de saisir davantage de dynamiques dans les performances du moteur. Un test stand effectuant des tests de qualification ou d’acceptation avant le vol peut tester un ensemble plus restreint de signaux qui vérifient le bon fonctionnement de l’appareil.

Une équipe d’ingénieurs chargée de concevoir un test de fusée doit tenir compte de tous ces besoins potentiels lors de la conception d’un nouveau test stand. Face à l’évolution rapide de la technologie des fusées, les ingénieurs doivent également prévoir les tests qui pourraient être nécessaires à l’avenir. La conception du test doit être suffisamment puissante pour répondre aux besoins connus, mais aussi assez flexible pour répondre à ceux qui évolueront au fil du temps.

Depuis plus de 30 ans, les ingénieurs NI travaillent en étroite collaboration avec leurs pairs qui conçoivent des systèmes de test de fusées. Au cours de cette période, les architectures ont évolué grâce à l’introduction de nouvelles technologies et techniques logicielles. Les meilleures pratiques issues d’applications connexes ( tests de moteurs à réaction, souffleries et autres grandes installations d’essai) ont influencé la conception des systèmes utilisés afin de tester les moteurs-fusées. Certains principes clés sont apparus comme essentiels à la réussite d’une conception architecturale destinée à tester les moteurs-fusées.

Une installation de test de fusée peut accueillir un seul ou plusieurs test stands. Chaque test stand nécessite le soutien de divers sous-systèmes ou blocs, qui peuvent être dédiés à un stand ou partagés entre plusieurs stands ou sites au sein de l’installation de test. Un superviseur du système de contrôle au sol à l’échelle de l’installation réunit tous les pads et test stands pour une gestion opérationnelle coordonnée des ressources de l’installation.

Figure 2. Sous-systèmes des installations de test de fusées

Les systèmes de contrôle des pads de soutien doivent assurer la fiabilité du contrôle, ainsi que des capacités de mesure permettant de suivre et d’améliorer les performances.

La mise en œuvre réussie d’un site de test de fusée nécessite une coordination minutieuse entre ces systèmes. Au fil des ans, un système de contrôle s’est développé dans les principales installations spatiales. Il s’agit d’un modèle de conception suffisamment souple pour répondre aux besoins de communication entre ces systèmes et à la variabilité des systèmes entre les tests. Dans les entreprises spatiales qui gèrent à la fois les installations de test et de lancement, de nombreux éléments du schéma sont partagés, afin de réduire les différences entre l’élément testé et le mode de lancement.

Cette architecture utilise un modèle de conception de système commun à tous les test stands et pads. Le modèle réalise le contrôle local nécessaire à chaque système, tout en partageant les informations entre eux afin d’assurer la synchronisation des opérations de test.

Figure 3. Modèle de conception d’un système de contrôle général

Dans ce modèle, les systèmes de contrôle lisent les entrées des processus de communication décrits plus loin dans cet article.

Un processus de mise à l’échelle convertit ces unités brutes en unités scientifiques appropriées au sous-système. Un tel processus peut également combiner plusieurs canaux en un seul canal calculé, par exemple, en additionnant toutes les cellules de charge de poussée afin d’obtenir une seule valeur de poussée. Un processus de mise à l’échelle applique également des étalonnages reconfigurables, car l’instrumentation peut changer entre les tests ou lors des opérations.

Un processus d’alarme évalue les points de données issus du processus de mise à l’échelle afin d’identifier les alarmes. Il est possible de classer les alarmes en plusieurs catégories, telles que les alertes permettant d’interrompre immédiatement un test ou d’avertir un opérateur d’un problème potentiel. Un processus d’alarme peut gérer l’arrêt réussi d’une séquence de test ou envoyer des commandes à d’autres systèmes afin de gérer ces actions. Les opérateurs de test sont en mesure de concevoir un arrêt d’urgence ou progressif à l’aide de cette architecture.

Lorsqu’aucune alarme n’empêche la progression du test, un processus logique analyse les valeurs des processus de lecture, de mise à l’échelle et d’alarme pour déterminer les actions suivantes. Un processus logique peut, par exemple, déterminer que la température d’un collecteur de fluide a atteint le point nécessitant d’ouvrir une vanne pour permettre à un fluide de circuler dans la canalisation (par exemple, refroidissement dans un collecteur Lox). Il émettra alors une commande à un autre sous-système distant ou transmettra une commande au processus séquentiel pour ouvrir la vanne localement.

Un processus séquentiel exécute ensuite les actions déterminées par des événements ordonnés et chronométrés avec des conditions (limites, frontières et lignes rouges) élaborées par les opérateurs de test et définies par les exigences de vol (simulation de contrôle de vol) ou de lancement/d’installation (simulation de lancement ou d’opérations d’essai nominales). Il est possible d’exécuter immédiatement les actions simples, tandis que les actions complexes peuvent faire l’objet d’un processus parallèle pour en assurer l’exécution séquentielle. Un processus séquentiel utilise les valeurs des processus de lecture, de logique et d’alarme comme entrées et met à jour les sorties du processus séquentiel parallèle si nécessaire.

La figure 3 représente ces fonctions sous la forme d’une série d’étapes ; mais dans l’application, ce modèle permet d’avoir des modules parallèles distincts qui exécutent leur propre thread tout en se synchronisant avec le thread opérationnel principal. Cela permet au thread principal de s’exécuter à une vitesse constante sans s’arrêter pour attendre la fin d’une action. Une boucle de système de contrôle fonctionne généralement entre 1 et 400 Hz, selon le système contrôlé.

Il est possible d’appliquer ce modèle de conception général à n’importe quel système de contrôle, mais dans les systèmes simples, certains éléments peuvent être optionnels ou gérés par un autre système. Un simple contrôleur de moteur peut, par exemple, être dépourvu de processus d’alarme ; au lieu de cela, un autre système peut gérer les conditions d’alarme sur la base de la sortie du système contrôlant le moteur. Il arrive qu’un système simple n’ait pas de processus séquentiel, mais qu’il soit contrôlé directement par le processus logique pour les systèmes de contrôle très basiques ou par le processus séquentiel d’un autre système de contrôle via iDDS ou gRPC, par exemple.

Figure 4. Services de communication

Un système de contrôle lit et écrit des commandes à distance et des données télémétriques par le biais de services de communication (p. ex. commander l’ouverture d’une vanne ou démarrer une séquence sur un autre système de contrôle distant contrôlant un pad de soutien). Ces services sont des programmes fantômes ou des microservices qui s’exécutent en arrière-plan et non directement dans l’application principale. Grâce à l’utilisation d’un service pour communiquer, au lieu de s’appuyer sur la fonction de lecture des entrées elle-même, l’application principale surveille les métriques du microservice de sorte qu’aucun problème n’ait d’incidence sur l’exécution de l’application principale. Cela permet d’abstraire la communication de la boucle de contrôle principale et de faciliter la mise à jour des équipements et des configurations au fur et à mesure que de nouveaux dispositifs dotés de nouvelles interfaces de communication sont disponibles.

La figure 4 présente quelques exemples de services de communication, mais il existe de nombreuses options de communication. L’équipe de conception de l’installation peut établir un protocole de communication personnalisé dédié à l’installation, ou sélectionner des protocoles standard prenant en charge l’équipement utilisé dans celle-ci.

Lors de l’achat de nouveaux équipements, un facteur clé sera la prise en charge des services de communication existants au sein de l’installation. Le contrôle du nombre de protocoles de communication sur le site simplifie le développement et la maintenance du logiciel. L’utilisation de services améliore le processus lorsqu’un nouveau protocole de communication est autorisé.

Figure 5. Modèle de conception des services de communication

Chaque service de communication devra être conçu pour répondre aux besoins d’un périphérique et d’un protocole.

Un service de communication type comporte certains éléments communs. Une machine à états est au cœur d’un service : elle suit l’état actuel du matériel et détermine l’état souhaité par la suite. Il se peut, par exemple, qu’un appareil doive être initialisé avant l’envoi d’une commande. La machine à états suit l’état d’initialisation de l’appareil, demande l’initialisation, puis l’envoi de la commande. Le service fournit des mesures contrôlables par les autres applications du réseau, notamment lorsqu’une étape s’arrête ou perd la communication avec un appareil. Cela peut provoquer des actions dans d’autres systèmes.

Figure 6. Consoles opérateur

Une interface matérielle communique avec le matériel à l’aide de l’API du fournisseur.

Une interface de communication conditionne les données pour le protocole, ce qui peut impliquer un formatage spécifique, des métadonnées, un cryptage ou une compression. Certains protocoles requièrent une gestion des échanges ou de la configuration, qui est transmise à la machine à états à des fins de gestion.

Pour permettre l’accès de l’opérateur, il est possible d’équiper chaque système de contrôle d’une console d’opérateur ou de plusieurs consoles. Il n’y a généralement qu’une seule console de commande active afin d’éviter toute confusion dans le système de contrôle. Il peut s’agir d’une console de contrôle dédiée ou d’une console avec arbitrage de contrôle, permettant à un opérateur de demander le contrôle.

Le caractère reconfigurable des consoles est une caractéristique de conception à prendre en compte. En raison de l’évolution des besoins entre les tests, ou même au cours d’un test, les ingénieurs de test doivent souvent accéder à des données supplémentaires dans ces consoles. Comme la plupart des données dont ils peuvent avoir besoin sont disponibles dans les services de communication, il est possible de créer des consoles grâce auxquelles les utilisateurs peuvent s’abonner à de nouveaux points de données sans modifier le code du logiciel proprement dit. Cela offre une certaine flexibilité aux ingénieurs qui ont besoin des données et protège le reste du système des modifications apportées au logiciel. La console peut, par exemple, s’abonner à tous les canaux de données des services de communication et permettre son utilisateur de sélectionner les signaux à visualiser. NI a utilisé ce modèle de conception lors de la création du Static Data Viewer avec G Web Development Software NI.

Les concepteurs doivent également se demander s’il convient d’exposer les signaux de commande aux consoles d’opérateur d’une manière configurable. Les ingénieurs de test peuvent ainsi modifier les capacités de contrôle sans avoir à mettre à jour le logiciel, ce qui accroît la productivité dans l’environnement rapide des tests de fusée. Cette capacité doit être conçue dans le service de communication qui transmet les données au système de contrôle lors de l’étape de lecture des entrées.

Une console peut être un dispositif ou un écran dédié à un système de contrôle spécifique ou combinée à d’autres consoles pour former un poste d’opérateur. Une station d’opérateur permet de visualiser et de contrôler l’ensemble du test stand à partir d’un seul endroit.

Tout cela forme une architecture complète.

Figure 7. Architecture des installations de test de fusées

Cette architecture présente les avantages suivants :

• Chaque système s’exécute indépendamment des autres. Il n’est donc pas nécessaire d’attendre qu’un autre système réponde.
• Les systèmes étant indépendants, chacun d’entre eux peut utiliser la technologie la plus appropriée sans que les décisions concernant les technologies des autres systèmes n’en soient affectées.
• Le modèle de conception commun à tous les systèmes simplifie le développement et la maintenance pour les équipes chargées du matériel et des logiciels.
• L’architecture peut évoluer au rythme de la croissance de l’installation tout en prenant en charge un nombre illimité de test stands et de systèmes de soutien.
• Elle prend en charge les composants de tous les fournisseurs et peut être mise à jour lorsque de nouvelles technologies sont disponibles.

Enfin, entièrement assemblée, une installation de test de fusée ressemble à l’image de la figure 8 :

Figure 8. Installation de test de fusées

L’architecture décrite dans cet article fournit un modèle de conception destinée aux systèmes de test de fusées. Il convient de prendre de nombreuses décisions techniques pour mettre en œuvre cette architecture. Cet article vise à guider une équipe à travers les aspects de l’architecture et à s’assurer que les plus critiques sont pris en compte dès le début du processus de conception.

Voici quelques-uns des sujets qui se sont avérés les plus importants à prendre en compte, et ce le plus tôt possible lors du processus décisionnel relatif à la mise en œuvre de l’architecture.

Latence du système

Dans chaque sous-système et dans l’ensemble de l’installation de test, quel est le retard le plus défavorable qui puisse être toléré pour maintenir le contrôle et la sécurité dans la zone de test ?

Le temps de latence dans le système résulte de plusieurs décisions de conception. Des boucles plus rapides augmentent la vitesse de communication d’un composant d’un système à un autre composant d’un autre système. Les ingénieurs doivent également tenir compte du nombre de sauts entre les systèmes : si les données doivent être transmises entre plusieurs systèmes pour atteindre la cible finale, les retards cumulés seront plus importants que si les données peuvent être transmises plus directement entre les systèmes de contrôle. Lors de la prise de décisions en matière de conception, il faut tenir compte de la manière dont les données sont mises à la disposition des autres systèmes (directement ou en étant copiées plusieurs fois entre les systèmes).

Temps

Les systèmes répartis dans l’installation auront des horloges différentes. Quel décalage temporel pouvez-vous tolérer dans vos mesures ?

La plupart des systèmes marquent les mesures avec l’horloge système de l’appareil local. Lors de l’analyse des données entre les systèmes, il est utile de pouvoir corréler les données entre ces systèmes. Une solution courante consiste à fournir une heure absolue pour tous les systèmes à l’aide de l’IEEE-1588 ou d’un protocole similaire. L’heure peut être fournie par le système de supervision de l’installation, ou les systèmes peuvent s’appuyer sur un signal GPS pour la base de temps.

La corrélation des données entre l’ordinateur de traitement et le système au sol est une question connexe. Cela est assez simple lors d’un test de fusée. Le processus se complique toutefois lors d’un lancement, car toute liaison entre le système au sol et la fusée sera perdue au moment du lancement. Comme les systèmes de test reproduisent les conditions de lancement, il convient d’en tenir compte lors de la conception du test stand.

Répartition des ressources partagées

Quels sous-systèmes seront partagés entre les test stands et quels sous-systèmes seront dédiés à un test stand spécifique ?

Il convient d’équilibrer deux coûts lorsqu’il est question de partager des ressources : les coûts de la duplication des ressources et les coûts du partage des ressources. La mise en place d’un système de réservoirs cryogéniques est très coûteuse. Mais l’acheminement des fluides cryogéniques vers deux test stands distincts entraîne également un coût et une complexité importants. Il arrive aussi que le partage des ressources limite la capacité d’exécution de deux activités en parallèle si celles-ci nécessitent toutes deux l’utilisation de la ressource.

Gestion des situations de compétition

Comment les ressources partagées seront-elles protégées des instructions concurrentes des systèmes de contrôle ?

Tout système de contrôle qui peut être contrôlé par plusieurs systèmes de commande court le risque d’effectuer une action involontaire en raison d’un manque de discipline dans le système de communication. Une vanne peut par exemple démarrer une opération sur la base d’une demande émanant d’un test stand, mais si un second test stand écrase le point de consigne, il en résultera une défaillance catastrophique des deux test stands.

L’équipe de conception doit examiner attentivement le système afin de déceler d’éventuelles conditions de course et de s’assurer qu’il existe une procédure de verrouillage appropriée pour tout signal de commande dans le système.

Les situations de compétition peuvent également affecter les données de mesure si elles sont écrasées avant qu’un système de stockage ne les récupère ; il est possible que les données récupérées ne soient pas celles qui étaient prévues.

Redondance

Quels sont les systèmes pour lesquels des contrôles redondants doivent être mis en place ? Quel sera le niveau de redondance ?

Il arrive que la redondance soit appliquée à de nombreux endroits d’un système : il peut y avoir des capteurs, des câbles, des dispositifs d’acquisition, des processeurs, des algorithmes ou des blocs d’alimentation redondants. Certaines entreprises du secteur spatial exigent une triple redondance dans l’ensemble du système afin de garantir une sécurité maximale. D’autres identifient les points de défaillance les plus risqués et concentrent les efforts de redondance sur eux.

L’équipe de conception a le choix entre plusieurs modèles de redondance pour chaque point du système. Dans le cas d’une redondance en veille, une unité secondaire identique sauvegarde l’unité primaire. Dans un système de veille à froid, l’unité secondaire est inactive et ne fonctionne que lorsqu’un chien de garde détermine que l’unité principale est défaillante. Dans un système de veille à chaud, l’unité secondaire est sous tension et surveille activement le système. Ses sorties ne sont toutefois utilisées que lorsqu’un chien de garde change de contrôle. Cela permet de réduire le temps d’arrêt en cas de panne sans pour autant préserver la fiabilité de l’unité secondaire puisqu’elle est en fonctionnement actif.

La redondance modulaire s’apparente à l’approche de secours à chaud, mais les deux systèmes fonctionnent en parallèle et génèrent des sorties pour le système. Un système de vote, parfois appelé commissaire-priseur ou votant, décide des sorties à utiliser. Cela permet des transferts sans interruption en cas de défaillance de l’un des contrôleurs. Ce modèle peut être étendu au-delà de deux contrôleurs à plusieurs contrôleurs. Ces exemples et d’autres sont traités dans le livre blanc de NI intitulé Redundant System Basic Concepts.

Exigences environnementales

Quels sont les environnements auxquels l’équipement de mesure sera soumis ? De quelle autre infrastructure avons-nous besoin pour protéger l’équipement de mesure et de contrôle ?

Lors d’un test de propulsion, les équipements situés sur le stand ou à proximité sont soumis à des conditions environnementales extrêmes. Il peut s’agir de chocs soudains, de vibrations continues et de températures élevées.

Entre les tests, les équipements sont également soumis à des conditions environnementales extrêmes. Les températures chaudes ou froides, l’humidité et le brouillard salin sont autant de menaces spécifiques à la disponibilité de l’équipement en vue d’un test.

Les ingénieurs doivent connaître les conditions environnementales du test stand. Grâce à ces informations, ils doivent sélectionner ou concevoir un équipement qui dépasse les exigences potentielles du système. Cela peut nécessiter d’acheter des équipements renforcés, d’ajouter une protection telle qu’un revêtement conforme, ou de protéger les équipements dans une armoire ou une dépendance à environnement contrôlé.

Topologie de réseau

Quelles technologies de réseau permettront d’obtenir des performances optimales pour le transfert de données sur le réseau, y compris la redondance en cas de défaillance d’un composant ?

De nombreuses options sont disponibles lors de la conception d’une topologie réseau. La réussite de la topologie d’installation passe par des conversations détaillées entre l’équipe d’infrastructure informatique et les équipes d’ingénierie de test. Les équipes de test devront décrire la largeur de bande passante des données, la latence et les besoins technologiques. L’équipe informatique devra comprendre le cryptage, la disposition et la redondance pour planifier la disposition du réseau.

Parmi les décisions prises lors de la conception du réseau, l’équipe dédiée doit choisir un modèle de redondance. Cela peut inclure l’installation de câbles réseau redondants dans l’ensemble de l’établissement, l’utilisation du protocole RSTP (Rapid Spanning Tree Protocol) et l’utilisation de plusieurs commutateurs de distribution.

Couverture des E/S

Quels signaux devons-nous mesurer ou contrôler ?

L’une des premières tâches de l’équipe d’ingénieurs consiste à dresser une liste des signaux à mesurer ou à contrôler dans le test stand. Lors de la documentation des signaux, ils doivent indiquer le type de signal, l’emplacement, la résolution, le débit de données, les besoins en matière d’excitation et de sécurité, ainsi que les niveaux de tension et de courant.

Grâce à ces informations, les ingénieurs peuvent rassembler les signaux dans des banques de mesures, puis sélectionner le matériel adéquat afin d’accéder à tous les signaux.

Bande passante de données

La topologie du réseau peut-elle gérer la quantité de données attendue lors d’un test ?

La conception du réseau, y compris les dispositifs informatiques, le matériel de commutation et l’architecture du sous-réseau, établit la limite de la quantité de données qu’il est possible de déplacer sur le réseau. L’équipe de conception doit examiner attentivement les composants du réseau afin d’identifier les éventuels goulets d’étranglement du système.

Un calcul théorique peut guider la conception d’un système, mais les applications de réseau n’atteignent jamais les débits de données théoriques complets. La surcharge des données et les temps de latence ont un impact sur le débit total du réseau. Lors de la conception d’un réseau, il est conseillé de maintenir les débits de données à un niveau nettement inférieur à la limite théorique.

Sécurité

Quels systèmes de sécurité faudra-t-il mettre en place ?

Une installation dédiée à la fabrication des fusées présente de nombreuses conditions dangereuses. Une erreur liée à la conception, à la mise en œuvre ou à l’exploitation des systèmes peut entraîner un accident catastrophique. L’équipe de conception doit connaître les protocoles de sécurité exigés par les lois fédérales et locales. L’équipe de conception doit également réfléchir à la manière de protéger le personnel, l’équipement et la zone associée à la station de test à l’aide de moyens qui ne sont pas couverts par les lois.

Certaines zones d’une installation dédiée aux fusées sont dangereuses en raison des gaz utilisés pour alimenter le moteur de la fusée. Il est parfois impossible de confiner entièrement ces gaz, ce qui crée une zone où toute étincelle électrique risque de provoquer un incendie ou une explosion. Pour éviter cela, tout équipement situé dans la zone dangereuse doit être intrinsèquement sûr, c’est-à-dire incapable de produire une étincelle. On peut y parvenir en déplaçant l’équipement électrique en dehors de la zone dangereuse. Il est également possible de placer une vanne à commande électrique à l’extérieur de la zone, de sorte que le seul équipement de la zone soit le tuyau qui part de la vanne.

S’il convient de placer un appareil à l’intérieur de la zone dangereuse, l’équipement doit être certifié comme étant à sécurité intrinsèque par son fournisseur. Aux États-Unis, il s’agit d’une certification de classe 1 Div 1. En Europe, il s’agit d’une certification ATEX qui dépend du type de gaz.

Si un appareil se trouve à l’extérieur de la zone dangereuse, mais qu’il émet un signal dans cette zone, il doit être doté d’une barrière intrinsèque pour éviter qu’une étincelle générée dans l’appareil ne soit transmise dans la zone. Même les dispositifs de faible niveau, comme les instruments de mesure à thermocouple, nécessitent une barrière intrinsèque pour empêcher l’alimentation du dispositif (comme une alimentation connectée) de passer dans la zone. Il est possible de fixer une barrière intrinsèque sur le trajet du signal entre l’appareil et la zone dangereuse. Elle offre une protection contre les pics de tension et de courant. Il convient de noter que les barrières intrinsèques varient en fonction du type de signal ; ainsi, une barrière conçue pour un thermocouple ne conviendrait donc pas à un contrôleur de vanne.

Certifications

Quelles certifications l’installation, les systèmes de soutien et le test stand doivent-ils respecter ?

Différentes certifications sont requises pour différentes zones en fonction des populations, de l’objectif de l’installation, des lois locales et de l’objectif de l’équipement de la fusée. Un test de fusée effectué sur une base de l’armée de l’air américaine peut, par exemple, nécessiter une certification AFSPCMAN 91-7108 avant la réalisation de toute activité liée à la fusée.

Outre les certifications requises pour effectuer le test, les certifications ont une incidence sur l’objectif de ce dernier. Si le but du test est de certifier le moteur de la fusée en vue de son utilisation, la conception du test stand doit répondre aux exigences de la certification en question. Par exemple, la norme MIL-STD-8109 garantit que l’appareil testé répond aux conditions d’utilisation prévues. La norme MIL-STD-20210 garantit que les composants de moins de 136 kg (300 livres) répondent aux exigences électriques et environnementales d’une application exigeante. Ces normes peuvent être obligatoires si le département de la Défense des États-Unis est susceptible d’acquérir la technologie testée.

La conception d’une installation dédiée au test des fusées, avec le test stand et les systèmes de soutien, est un projet de grande envergure axé sur les détails. Ce document vise à fournir un modèle de conception général et une approche du processus de conception. L’objectif de ce document n’est pas de décrire chaque étape du processus, mais précisons toutefois que le processus de conception suivra ces étapes de base. Si ce processus dépasse les capacités de votre équipe de conception, reportez-vous à la section suivante dédiée aux services pour savoir comment impliquer NI et ses partenaires dans le processus de conception.

Identification des systèmes

Sortie : Diagramme des systèmes et sous-systèmes qui seront conçus dans l’installation

Commencez par identifier les systèmes de l’installation. En fonction des besoins actuels et futurs de l’installation, définissez l’emplacement des test stands et des systèmes de soutien. Planifiez le transfert entre les systèmes et les connexions. Décidez quels systèmes de support seront partagés et lesquels seront dédiés au test stand.

Création de la configuration système requise

Sortie : Exigences détaillées pour chaque système et sous-système à concevoir dans l’installation

Documentez les exigences pour chacun des systèmes identifiés. Dressez la liste des entrées et des sorties attendues, y compris les fréquences de mise à jour et le protocole de communication. Documentez les fonctionnalités attendues du système, y compris les performances requises. Décidez quelle équipe fonctionnelle de l’entreprise sera chargée de la conception de chacun des systèmes.

Identifiez les exigences à l’échelle de l’installation

Sortie : Exigences détaillées des systèmes et de l’infrastructure qui relieront les installations entre elles

À l’aide de la configuration système requise, identifiez les performances nécessaires au système d’installation pour supporter ces systèmes. Documentez la fréquence de mise à jour nécessaire pour répondre aux exigences de latence de l’ensemble des systèmes et composants. Travaillez avec l’équipe informatique pour définir les exigences en matière d’infrastructure de réseau et répondre aux besoins des systèmes. Calculez les débits de données des scénarios les plus défavorables dans le système.

Sélectionnez les technologies

Sortie : Liste des technologies couvrant les besoins du système et de l’installation

À l’aide des exigences du système et de l’installation, identifiez les technologies spécifiques qui seront acquises ou développées pour répondre aux besoins documentés. Rencontrez les fournisseurs afin d’identifier les technologies prêtes à l’emploi qui peuvent être utilisées. Travaillez avec les équipes d’ingénieurs afin d’identifier une approche d’ingénierie personnalisée et de combler les lacunes qui subsistent au niveau des systèmes. Dans la mesure du possible, testez les performances des systèmes pour vous assurer qu’ils répondent aux exigences.

Services de communication sur la conception

Sortie : Documentez les exigences et la mise en œuvre de chacun des services de communication à utiliser pour les systèmes et l’équipement de l’installation

En vous appuyant sur une bonne compréhension des technologies disponibles pour les systèmes, documentez les besoins de chacun des services de communication. Identifiez les entrées, les sorties et le traitement de chacun des services. Identifiez l’expertise nécessaire à la mise en œuvre complète des services.

Conception des contrôleurs du système

Sortie : Documents de conception pour chacun des contrôleurs du système au sein de l’installation

Appliquez les exigences de configuration système requise aux technologies sélectionnées pour les systèmes et les installations. Documentez les intrants, les extrants et la fonctionnalité souhaités à l’aide de critères de performance spécifiques. Identifiez l’expertise nécessaire à la mise en œuvre des contrôleurs du système.

Mettez en œuvre des contrôleurs de système et des services de communication

Sortie : Code s’exécutant sur chacun des contrôleurs du système et entre les systèmes

Développez le code qui s’exécute sur chacun des contrôleurs du système et dans chaque service de communication. Documentez la moindre modification par rapport aux documents relatifs aux exigences et vérifiez que les modifications n’ont pas d’incidence sur d’autres systèmes. Appliquez les principes d’ingénierie appropriés au développement, y compris les tests unitaires, afin de vérifier que chaque composant répond aux exigences documentées.

Connectez les contrôleurs du système

Sortie : Mises à jour des valeurs entre les systèmes de contrôle

Connectez les contrôleurs du système et les services de communication. Vérifiez que les systèmes fonctionnent correctement et dans les limites des performances attendues. Continuez à réaliser des tests unitaires sur les composants, les sous-systèmes et les systèmes au fur et à mesure qu’ils sont connectés.

Validez les performances du système

Sortie : Validation de la performance de chaque composant du système, du système et des systèmes interconnectés

Une fois tout le système en place, effectuez des tests de validation complets des systèmes et du système dans son ensemble. Examinez les exigences pour vérifier qu’elles sont toutes respectées. Signalez le moindre comportement inattendu aux développeurs et répétez l’opération jusqu’à ce que vous obteniez les performances souhaitées.

Créez des stations opérateur et des affichages

Sortie : Écrans et stations opérateur pour contrôler et visualiser les systèmes

Les consoles opérateur seront développées en même temps que les systèmes ; des améliorations de la convivialité seront apportées aux consoles et les consoles d’opérateur finales seront créées.

Plusieurs avancées technologiques récentes peuvent être utilisées dans cette architecture de test de fusée.

gRPC

gRPC est un framework open source hautes performances qui peut s’exécuter dans n’importe quel environnement. Développé par Google et basé sur l’appel de procédure à distance (RPC), gRPC a rapidement gagné en popularité au cours des cinq dernières années et permet de transmettre des données entre les parties d’un système. Avec gRPC, une application client peut appeler directement une méthode sur une application serveur sur une autre machine, comme s’il s’agissait d’un objet local. Cela facilite la création d’une architecture distribuée, comme celle du test des fusées. Les outils logiciels et matériels NI fonctionnent avec gRPC. Obtenez des informations sur les ressources d’assistance et la compatibilité gRPC.

iDDS

iDDS est un protocole d’abstraction de données développé par Rolls-Royce et MDS Aero pour les tests de moteurs à turbine à réaction. Il propose un service de communication pour collecter des données à partir des nœuds d’instrumentation, qui sont ensuite mises à la disposition des abonnés sur le réseau. L’iDDS s’appuie sur l’épine dorsale du service de distribution de données (DDS) et sur la norme de l’Object Management Group (OMG). Il définit également le conditionnement des données d’instrumentation sur le réseau DDS, y compris les données de mesure telles que les métadonnées de canal, l’horodatage, la configuration et la surveillance de l’état. Comme la communication entre les appareils est normalisée dans le modèle iDDS, les caractéristiques spécifiques des fournisseurs ne sont pas prises en compte, ce qui facilite le remplacement des équipements lorsqu’une nouvelle technologie est disponible, même s’il s’agit d’un nouveau fournisseur.

NI propose des solutions matérielles et logicielles sur mesure destinées aux tests de moteurs-fusées, intégrant des exigences de sécurité en constante évolution, de nouveaux capteurs et des technologies demandées par le marché. Notre logiciel fournit des outils pour les solutions de test personnalisées, la visualisation des données en temps réel, l’enregistrement et le séquencement de test automatisé. Ces solutions logicielles améliorent l’analyse des données, la gestion des installations et l’efficacité globale des tests grâce à des plates-formes puissantes et adaptables.

Les plates-formes matérielles, telles que NI PXI, NI CompactDAQ et NI CompactRIO, sont conçues pour résister à des conditions extrêmes et supporter une vaste gamme de signaux, garantissant des mesures et un contrôle fiables et précis lors des tests de moteurs-fusées. Ces systèmes modulaires robustes offrent des mesures distribuées et des capacités de traitement local, améliorant ainsi l’exactitude et la flexibilité des tests. Découvrez nos solutions de test de la propulsion des moteurs-fusées pour savoir comment tester plus de moteurs dans un délai imbattable.

• Solution pour tester la propulsion des moteurs-fusées
• Logiciel système Data Acquisition Software de la NASA pour le test de propulsion de fusée
• Révolutionner l’efficacité du développement de fusées avec des tests

Notes de bas de page

¹ https://arstechnica.com/science/2022/01/thanks-to-china-and-spacex-the-world-set-an-orbital-launch-record-in-2021
² https://www.go-astronomy.com/space-ports.php
³ https://www.ecfr.gov/current/title-14/chapter-III
⁴ https://ntrs.nasa.gov/api/citations/20050182932/downloads/20050182932.pdf

Références

• https://static.e-publishing.af.mil/production/1/ssc/publication/sscman91-710v3/sscman91-710v3.pdf
• https://www.atec.army.mil/publications/mil-std-810g/mil-std-810g.pdf
• https://nepp.nasa.gov/DocUploads/1F6AB74B-4517-4AD0-A34813268E75B8EB/MIL-STD-202.pdf