Sélection de l'interface du bus de communication par satellite

Les ingénieurs de test s’accordent généralement sur l’importance de l’expression « Sélectionnez le meilleur outil pour vos projets ». En effet, utiliser un outil inadapté peut vous faire perdre du temps et compromettre la qualité, alors qu’avec le bon outil, vous parvenez au résultat espéré en un temps record.

Les outils principaux se présentent sous forme d’instrumentation de mesure et de stimulus lors de la construction d’équipements électroniques de soutien au sol (EGSE) ou de STE de paiement spécialisés (SCOS, STE signifiant équipement de test spécialisé) pour l’intégration, le paiement et les tests de fabrication sur de grands volumes. Ces instruments incluent des produits connus comme les multimètres numériques (DMM), les oscilloscopes et les générateurs de signaux, ainsi que diverses catégories de produits nouvelles ou évolutives tels que les transcepteurs de signaux vectoriels et les oscilloscopes tout-en-un. Cependant, sélectionner le meilleur outil pour vos projets est plus facile à dire qu’à faire, surtout lorsqu’il s’agit d’explorer et d’évaluer les nombreux avantages et inconvénients en jeu. Cela s’applique également aux instruments standardisés ainsi qu’aux instruments spécialisés, mais les interfaces de bus de communication par satellite ne sont souvent pas traitées avec la même rigueur.

Lorsqu’ils préparent la liste des instruments à inclure dans l’EGSE utilisé pour les tests de validation ou d’intégration, les ingénieurs de test consultent habituellement leurs plans de test et évaluent l’instrumentation sur le marché pour s’assurer que les meilleurs instruments sont installés afin de fournir des mesures complètes permettant de répondre aux exigences du plan de test.

Le plan de test d’un matériel sous test (DUT) spécifique nécessite souvent des étapes supplémentaires pour placer le DUT dans un état particulier ou lui envoyer une commande et écouter la réponse attendue ; ceci est particulièrement vrai lors du test des contrôleurs de vol et de système. Ces étapes peuvent inclure l'exécution de contrôles d'assurance qualité, l'exécution d'un sous-ensemble d’étapes de vérification de la conception sur le bus avionique même ou l'enregistrement des réponses pour une analyse ou une relecture ultérieure. Pour garantir l’intégration de cette fonctionnalité à l’EGSE, les ingénieurs de test s’intéressent souvent aux protocoles utilisés par le DUT lors de la communication ainsi qu’au marché commercial prêt à l'emploi (COTS) pour que l’instrument réponde à leurs besoins.

En fonction de la combinaison de plate-forme d’actifs de test et de DUT spécifique, de nombreuses options d’instrument d’interface d’un bus avionique spécifique sont disponibles au choix. S’agissant des protocoles les plus courants tels que MIL-STD-1553, ARINC-429 et SpaceWire, de nombreux fournisseurs d’instruments sur le marché disposent d’options prêtes à l’emploi capables de répondre à ces besoins. Cependant, s’il s’agit des bus haute vitesse ou de base tels que Fibre Channel (en particulier SpaceFibre), Serial RapidIO (SRIO), AFDX, High-Speed Data Bus (HSDB) et IEEE-1394b, ou des bus spécifiques à l'application tels que ARINC-708, ARINC-717 ou ARINC-818, les options sont beaucoup plus complexes et impliquent plus de considérations. 

De nombreuses interfaces de bus telles que SpaceWire sont désormais si répandues que les instruments d'interface sont maintenant standardisés. Il est désormais plus rentable pour les fournisseurs d’équipements de test d’intégrer les couches physiques, de liaison de données et réseau dans un périphérique à fonction fixe. Par exemple, STAR-Dundee propose plusieurs modules PXI d’interfaçage et de commutation des signaux de bus SpaceWire. Tout comme les instruments réservés aux autres protocoles de communication largement adoptés, tels que GPIB, au niveau matériel, ces instruments sont souvent structurés de manière similaire d’un fournisseur à l’autre pour être conformes à la norme spécifique. 

Ce qui pourrait permettre à un fournisseur d’équipements de test de différencier son produit d’un autre, ce sont les couches de données supérieures du modèle d’interconnexion des systèmes ouverts (OSI) dans lequel des fonctionnalités ou des capacités spécifiques sont implémentées pour prendre en charge le protocole. Il s'agit entre autres de la détection des erreurs, de la flexibilité de planification, de l'horodatage, de l'enregistrement des données et de l'insertion de défauts. Certains fabricants fournissent également l'accès aux données de chacune des couches OSI pour la surveillance ou la mise au point. Concernant les exigences de test de validation et d’intégration au niveau du système, une grande majorité des fonctionnalités plus nuancées ne sont souvent pas aussi essentielles à la réussite de l’application, la décision dépend donc généralement de la préférence de l’ingénieur.

Figure 1. Vue simplifiée des couches OSI de ARINC-664p7/AFDX

Lorsqu’un système de test nécessite des interfaces de protocole haute vitesse/de base ou spécifiques à l’application, la décision de sélection qui était autrefois simple est maintenant beaucoup plus difficile. Les ingénieurs de test négligent souvent la complexité associée à l’intégration de ces protocoles dans leurs systèmes de test. L’un des principaux défis posés par ces protocoles hautes performances est le passage de la transmission de données parallèle à la transmission série. 

Les séries standard gagnent en popularité, car la limitation physique des fréquences d'horloge des bus parallèles est d'environ 1 GHz à 2 GHz ; le décalage introduit par l'horloge individuelle et les lignes de données peut provoquer des erreurs de bits à des fréquences plus rapides. À la place, les bus série haute vitesse envoient des informations encodées qui contiennent à la fois des données et des informations d'horloge dans un ou plusieurs signaux différentiels, ce qui permet d’éviter les contraintes de vitesse des bus parallèles. De plus, l'utilisation de transcepteurs matériels série haute vitesse spécialisés avec des fonctionnalités avancées telles que la récupération d'horloge, la préaccentuation et l'égalisation renforce davantage ces avantages. 

La conception des interfaces de protocole série haute vitesse s'adapte parfaitement à l'exécution sur la toute dernière technologie FPGA. Par exemple, les émetteurs-récepteurs multi-gigabits sur les derniers FPGA Xilinx peuvent fonctionner à une vitesse supérieure à 30 Gb/s, ce qui en fait des candidats parfaits pour agir en tant que processeur de données d’un protocole de communication. Outre la complexité de la conception matérielle de ces instruments, l’IP du protocole elle-même est aussi plus complexe qu’un instrument de produit, car les protocoles ont tendance à être beaucoup plus complets et leurs exigences en matière de données sont plus rigoureuses en raison de la complexité requise pour gérer l’ordre de l'augmentation de l'ampleur des débits de données. 

Lorsqu’il s’agit d’intégrer une interface de protocole haute vitesse/de base ou spécifique à l’application dans un EGSE, plusieurs options se présentent souvent aux ingénieurs.

• L’option 1 consiste à jeter un œil sur le marché COTS et à trouver un fournisseur qui propose l’interface en question. En raison de la complexité de la conception matérielle et de l’IP, les ingénieurs doivent souvent travailler avec deux fournisseurs : l’un pour s’occuper du matériel série haute vitesse et l’autre du noyau IP du protocole.

• L’option 2 consiste à tirer parti de la conception de l’équipe de validation interne du DUT en question, qui combine un noyau IP avec une carte d’évaluation FPGA personnalisée ou prête à l’emploi pour l’intégrer dans l’EGSE. Bien que l’utilisation d’une conception personnalisée en interne puisse sembler attrayante, des risques susceptibles d’augmenter considérablement la charge du support peuvent subvenir avec le temps.

Figure 2. Gestion du cycle de vie d’un système de test « conçu localement »

Pour illustrer cela, la Figure 2 montre un exemple de la durée de vie d’un système de test et les événements qui ont un impact sur les coûts de maintenance de ce système au fil du temps. Une fois l’EGSE entièrement conçu, vérifiez si un composant de votre carte personnalisée est en fin de vie (EOL). Après tout, c’est probable, car les cycles d’actualisation technologiques des semi-conducteurs ont tendance à refléter le marché commercial. Et cela est plus susceptible si une conception est adoptée par l’équipe de validation parce que les préoccupations relatives au cycle de vie ne semblent pas être incluses dans leurs spécifications de conception. 

Dans une telle situation, soit l’achat à vie de ce composant et la gestion des pièces de rechange, soit la recherche et la revalidation de la conception matérielle sont en principe les choix qui s’imposent. Vous pouvez aussi envisager une obligation de mise à niveau du système d'exploitation, comme un changement de version de Windows, ou peut-être un passage à Linux. Ensuite, il faut réécrire les drivers et revalider la conception logicielle. Que faire lorsque les exigences du testeur changent au fil du temps ou lorsque de nouvelles fonctionnalités doivent être ajoutées ? Cela peut nécessiter une reconception du firmware ou du logiciel, voire peut-être de la couche physique, selon les exigences du DUT. Et enfin, que se passe-t-il quand le FPGA arrive en fin de vie ? Étant donné qu’aucune voie de mise à niveau n’est simple pour ces composants, une reconception complète est souvent requise. 

Ce sont des occurrences très réalistes pour le système de test qui, dans l’industrie de l’aérospatiale et de la défense, devra probablement durer des décennies. Souvent, lorsque ces défis d’obsolescence se posent, les concepteurs de l’EGSE d’origine et des programmes logiciels de test qui s’y exécutent ne sont plus là pour assister aux efforts de maintenance. En définitive, le coût de conception initial ne représente qu’un très petit pourcentage du coût du système de test sur sa durée de vie

À la place, dans la mesure du possible, les ingénieurs doivent envisager l’option 1 : une solution basée sur le COTS, en particulier une solution conçue pour une utilisation dans les applications de test et de mesure. Même avec la capacité en interne de concevoir et de gérer l’IP logicielle complexe requise pour interfacer avec le protocole de communication par satellite, la charge supplémentaire de maintenance et de support du matériel personnalisé implique qu’une approche COTS réduira le coût total des tests. 

Depuis des décennies, le secteur de l’aérospatiale et de la défense utilise l’instrumentation modulaire et les logiciels d’application NI pour réduire le coût global et les risques associés aux tests et au support de ses produits. Pendant ce temps, NI a mis au point la plate-forme PXI et a lancé depuis, plus de 600 modules PXI différents allant du CC aux ondes millimétriques. Outre l’instrumentation traditionnelle, les solutions d’intégration, de paiement et de test de fabrication sur de grands volumes fournies toutes les deux par NI, notre réseau de partenaires et plus de 70 membres PXISA proposant des éléments de plate-forme PXI, tels que STAR-Dundee, offrent la couverture la plus complète des interfaces de bus basées sur PXI tout en conservant la flexibilité pour « sélectionner le meilleur outil pour vos projets ».

Interfaces d’avioniques numériques pour les tests de fabrication et de dépôt

Interfaces génériques :

• MIL-STD-1553 
• RS-232/422/485 
• ARINC-429 
• CANbus 

Interfaces haute vitesse/de base :

• Fibre Channel (en particulier SpaceFibre)
• Serial RapidIO 
• ARINC-664p7/AFDX 
• 1394b FireWire 
• Ethernet (jusqu’à 40 GigE) 

Interfaces spécifiques à l'application :

• ARINC-708 
• ARINC-717 
• ARINC-818 
• SpaceWire 
• DVI

Dans certains cas, l’ingénieur de test juge qu’une approche COTS n’est pas viable et qu’une ingénierie sur mesure est requise. L’exemple du test d'un DUT communiquant via une version personnalisée d'un protocole particulier, est souvent mentionné. Cependant, même dans ces cas-là, il est recommandé d’éviter une conception personnalisée afin de réduire les risques liés au calendrier et la charge de maintenance future du test EGSE. Pour en savoir plus sur la construction de systèmes de test électroniques complets pour l’espace, notamment l’intégration de matériel d’interface de bus de communication COTS dans vos systèmes de test afin de résoudre des défis de conception personnalisés, lisez la note d’application.