Auswahl der Satellitenkommunikationsbus-Schnittstelle

Testingenieure sind sich im Allgemeinen einig, wie wahr die Worte „das richtige Werkzeug für die Aufgabe nehmen“ ist. Das liegt daran, dass die Verwendung des falschen Werkzeugs Zeit verschwenden und die Qualität beeinträchtigen kann, während das richtige Werkzeug in einem Bruchteil der Zeit das richtige Ergebnis liefern kann.

Die Hauptwerkzeuge sind Mess- und Stimulusgeräte beim Bau elektronischer Bodenunterstützungsgeräte (EGSE) oder spezialisierter Checkout-STEs (SCOS, wobei STE für Specialty Test Equipment steht) für Integrations-, Checkout- und Großserienfertigungstests. Zu diesen Messgeräten zählen bekannte Waren wie Digitalmultimeter (DMMs), Oszilloskope und Signalverlaufsgeneratoren sowie eine Vielzahl neuer und wechselnder Produktkategorien wie Vektorsignal-Transceiver und All-in-one-Oszilloskope. Aber die Auswahl des richtigen Werkzeugs für den Job ist viel leichter gesagt als getan, insbesondere wenn es um die Navigation und Bewertung der vielen Kompromisse geht. Dies gilt für Standard- und Spezialinstrumente gleichermaßen; Schnittstellen für Satellitenkommunikationsbusse werden jedoch häufig nicht mit der gleichen Strenge betrachtet.

Bei der Betrachtung der Liste der Instrumente, die in das EGSE für Validierungs- oder Integrationstests aufgenommen werden sollten, sind Testingenieure daran gewöhnt, ihre Testpläne zu konsultieren und die Instrumentierung auf dem Markt zu bewerten, um sicherzustellen, dass die richtigen Instrumente installiert werden, um eine vollständige Messabdeckung bereitzustellen, um die Anforderungen zu erfüllen Testplananforderungen.

Häufig erfordert der Testplan für ein bestimmtes zu testendes Gerät (der Prüfling) zusätzliche Schritte, um den Prüfling in einen bestimmten Zustand zu versetzen oder ihm einen Befehl zu senden und auf die erwartete Antwort zu horchen; dies gilt insbesondere beim Testen von Flug- und Systemsteuerungen. Diese Schritte können das Ausführen von Qualitätssicherungsprüfungen, das Ausführen einer Teilmenge der Entwurfsverifizierungsschritte auf dem Avionikbus selbst oder das Aufzeichnen von Antworten zur späteren Analyse oder Wiedergabe umfassen. Um sicherzustellen, dass diese Funktion in das EGSE integriert ist, achten Testingenieure oft darauf, welche Protokolle der Prüfling für die Kommunikation verwendet, und suchen auf den kommerziellen Standardmarkt (COTS) nach einem Messgerät, das ihren Anforderungen entspricht.

Abhängig von der Kombination aus Test-Asset-Plattform und spezifischem Prüfling steht eine breite Palette von Optionen für ein bestimmtes Avionik-Bus-Schnittstelleninstrument zur Auswahl. Wenn Sie die gängigsten Protokolle wie MIL-STD-1553, ARINC-429 und SpaceWire betrachten, gibt es mehrere Geräteanbieter auf dem Markt, die Standardoptionen bieten, die diese Anforderungen erfüllen können. Betrachtet man jedoch Hochgeschwindigkeits- oder Backbone-Busse wie Fibre Channel (insbesondere SpaceFibre), Serial RapidIO (SRIO), AFDX, High-Speed Data Bus (HSDB) und IEEE-1394b – oder anwendungsspezifische Busse wie ARINC-708, ARINC-717 oder ARINC-818 – dann werden die Optionen viel komplexer und erfordern mehr Überlegungen. 

Viele Bus-Schnittstellen, wie z. B. SpaceWire, sind so verbreitet, dass die Schnittstelleninstrumente handelsüblich geworden sind. Für Anbieter von Testgeräten ist es kostengünstiger geworden, die physische Ebene, die Datenverbindungsebene und die Netzwerkebene in ein Gerät mit fester Funktion zu integrieren. STAR-Dundee beispielsweise bietet mehrere PXI-Module zum Anschließen und Schalten von SpaceWire-Bussignalen an. Wie Instrumente für andere weit verbreitete Kommunikationsprotokolle – wie GPIB – auf Hardwareebene sind diese Instrumente oft von Anbieter zu Anbieter ähnlich aufgebaut, um den spezifischen Standard zu erfüllen. 

Raum für Unterschiede bei Testgeräten besteht bei den höheren Datenschichten des Open Systems Interconnection (OSI)-Modells, wo spezifische Merkmale oder Fähigkeiten zur Unterstützung des Protokolls implementiert sind. Dazu gehören Fehlererkennung, Zeitplanungsflexibilität, Zeitstempel, Datenaufzeichnung und Fehlersimulation, um nur einige zu nennen. Manche Hersteller bieten außerdem Zugriff auf die Daten jeder einzelnen OSI-Ebene zur Überwachung oder Fehlersuche. Bei Validierungs- und Integrationstestanforderungen auf Systemebene sind viele der nuancierteren Funktionen oft nicht so entscheidend für den Anwendungserfolg, sodass die Entscheidung normalerweise den Vorlieben des Ingenieurs folgt.

Abbildung 1: Vereinfachte Ansicht der OSI-Lagen von ARINC-664p7/AFDX

Wenn ein Testsystem Hochgeschwindigkeits-/Backbone- oder anwendungsspezifische Protokollschnittstellen erfordert, wird die ehemals einfache Auswahl ungemein schwieriger. Testingenieure übersehen oft die Komplexität, die mit der Integration dieser Protokolle in ihre Testsysteme verbunden ist. Eine der größten Herausforderungen, die diese leistungsstarken Protokolle mit sich bringen, ist der Übergang von der parallelen zur seriellen Datenübertragung. 

Serielle Standards sind zunehmend populär, da die physikalische Begrenzung der Taktraten paralleler Busse etwa 1 GHz bis 2 GHz beträgt. Die durch einzelne Takte und Datenleitungen verursachten Laufzeitunterschiede können bei schnelleren Raten Bitfehler verursachen. Stattdessen senden serielle Hochgeschwindigkeitsbusse kodierte Informationen, die sowohl Daten als auch Taktangaben in einem oder mehreren differentiellen Signalen enthalten, wodurch Geschwindigkeitsbeschränkungen bei parallelen Bussen vermieden werden. Darüber hinaus werden diese Vorteile durch die Verwendung spezialisierter serieller Hochgeschwindigkeits-Hardware-Transceiver mit erweiterten Funktionen wie Taktwiederherstellung, Vorverzerrung und Entzerrung noch weiter gesteigert. 

Entwürfe für serielle Hochgeschwindigkeitsprotokolle eignen sich gut zur Ausführung mit der neuesten FPGA-Technologie. So können z. B. die Multi-Gigabit-Transceiver auf den neuesten Xilinx-FPGA schneller als mit 30 Gbit/s betrieben werden, sodass sie ideal als Datenprozessor für ein Kommunikationsprotokoll fungieren können. Neben der Komplexität des Hardwaredesigns für diese Messgeräte ist die Protokoll-IP selbst auch komplexer als ein handelsübliches Gerät, da die Protokolle in der Regel viel mehr Funktionen haben und höhere Datenanforderungen aufweisen, was an der Komplexität liegt, die erforderlich ist, um diesen Anstieg in den Datenraten abzudecken. 

Wenn es darum geht, eine bestimmte Hochgeschwindigkeits-/Backbone- oder anwendungsspezifische Protokollschnittstelle in ein EGSE zu integrieren, stehen Ingenieure oft vor einer Reihe von Optionen.

• Option 1 besteht darin, auf den Markt mit handelsüblichen Geräten zu schauen und einen Anbieter zu finden, der die betreffende Schnittstelle anbietet. Aufgrund der Komplexität des Hardwaredesigns und der IP müssen Ingenieure oft mit zwei Anbietern zusammenarbeiten – einer für serielle Hochgeschwindigkeitshardware und einer für den Protokoll-IP-Kern.

• Option 2 besteht darin, den Entwurf des internen Validierungsteams für den betreffenden Prüfling zu nutzen, der einen IP-Kern mit einer benutzerdefinierten oder handelsüblichen FPGA-Evaluierungsplatine kombiniert und in den EGSE integriert. Auch wenn die Nutzung eines eigenen kundenspezifischen Designs attraktiv erscheinen mag, gibt es oft unsichtbare Risiken, die den Supportaufwand im Laufe der Zeit erheblich erhöhen können.

Abbildung 2: Lebenszyklusverwaltung eines „hausgemachten“ Testsystems

Um dies zu veranschaulichen, zeigt Abbildung 2 ein Beispiel über den gesamten Lebenszyklus eines Testsystems und die Ereignisse, die sich auf die Wartungskosten dieses Systems im Laufe der Zeit auswirken. Nachdem das EGSE vollständig entwickelt wurde, sollten Sie bedenken, dass eine Komponente auf Ihrer benutzerdefinierten Karte irgendwann an das Ende ihrer Lebensdauer (EOL) kommt. Dies ist schließlich zu erwarten, da die Aktualisierungszyklen der Halbleitertechnologie tendenziell den kommerziellen Markt widerspiegeln. Und es ist besonders wahrscheinlich, wenn ein Design vom Validierungsteam übernommen wird, da Lebenszyklusbelange wahrscheinlich nicht in ihren Designanforderungen enthalten waren. 

In einer Situation wie dieser sind entweder ein lebenslanger Kauf dieser Komponente und die Verwaltung von Ersatzteilen oder die Suche nach einem Ersatz und die erneute Validierung des Hardwaredesigns im Wesentlichen die einzigen Möglichkeiten. Oder denken Sie an ein vorgegebenes Upgrade des Betriebssystems, z. B. eine Änderung der Windows-Version oder einen Umstieg auf Linux. Anschließend müssen die Treiber neu geschrieben und der Softwareentwurf erneut validiert werden. Was passiert, wenn sich die Anforderungen für den Tester im Laufe der Zeit ändern oder neue Funktionen hinzugefügt werden müssen? Dadurch könnte je nach Anforderungen an den Prüfling eine Neuentwicklung der Firmware oder Software erforderlich werden – oder möglicherweise sogar der Bitübertragungsschicht. Und was passiert, wenn der FPGA ans Ende seiner Lebensdauer kommt? Für diese Komponenten gibt es keinen einfachen Upgrade-Pfad. Daher ist oft eine vollständige Neuentwicklung erforderlich. 

Das alles sind sehr realistische Fragen für ein Testsystem, das in der Luft- und Raumfahrt sowie in der Rüstung wahrscheinlich jahrzehntelang eingesetzt werden soll. Wenn diese Obsoleszenzprobleme auftreten, sind die Leute, die das ursprüngliche EGSE und die darauf laufenden Testsoftwareprogramme entwickelt haben, oft nicht mehr da, um bei Wartungsarbeiten zu helfen. Letztendlich machen die Vorlaufkosten für das Design nur einen sehr kleinen Prozentsatz der Kosten des Testsystems über seine Lebensdauer aus

Stattdessen sollten Ingenieure nach Möglichkeit Option 1 in Betracht ziehen: eine Lösung auf Grundlage handelsüblicher Teile, insbesondere eine für den Einsatz in Prüf- und Messanwendungen konzipierte Lösung. Selbst dann, wenn hausinterne Kapazitäten dazu bereitstehen, die komplexe Software-IP zu entwerfen und zu verwalten, die für die Schnittstelle mit dem Satellitenkommunikationsprotokoll erforderlich ist, bedeutet die zusätzliche Wartungs- und Instandhaltungslast der benutzerdefinierten Hardware, dass ein Ansatz mit handelsüblichen Teilen die Gesamtprüfkosten reduziert. 

Seit Jahrzehnten setzt man in der Luft- und Raumfahrt- und in der Verteidigungsindustrie auf modulare Messgeräte und Anwendungssoftware von NI, um die mit dem Test und Support der Produkte verbundenen Gesamtkosten und Risiken zu reduzieren. Während dieser Zeit leistete NI Pionierarbeit bei der PXI-Plattform und hat seitdem mehr als 600 verschiedene PXI-Module von DC bis mmWave auf den Markt gebracht. Zusätzlich zu herkömmlichen Messgeräten sorgen die Integrations-, Checkout- und Fertigungstestlösungen, die sowohl von NI, unserem Partnernetzwerk als auch den über 70 PXISA-Mitgliedern wie STAR-Dundee, die PXI-Plattformelemente bereitstellen, für die umfassendste Abdeckung von PXI-basierten Busschnittstellen bei gleichbleibender Flexibilität bei der Auswahl des „richtigen Werkzeugs für die Aufgabe“.

Digitale Avionikschnittstellen für Fertigungs- und Depottests

Allgemeine Schnittstellen:

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

Hochgeschwindigkeits-/Backbone-Schnittstellen:

• Fibre Channel (insbesondere SpaceFibre)
• Serielle RapidIO 
• ARINC-664p7/AFDX 
• 1394b Feuerdraht 
• Ethernet (bis zu 40 GigE) 

Anwendungsspezifische Schnittstellen:

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

Es gibt Fälle, in denen ein Testingenieur möglicherweise der Meinung ist, dass ein handelsüblicher Ansatz nicht realisierbar ist und eine benutzerdefinierte Entwicklung erforderlich ist. Ein häufig genanntes Beispiel ist das Testen eines Prüflings, der über eine benutzerdefinierte Version eines bestimmten Protokolls kommuniziert. Trotzdem wird auch in diesen Fällen empfohlen, benutzerdefinierte Entwürfe zu vermeiden, um das Zeitplanrisiko und die zukünftige Wartungslast des Test-EGSE zu reduzieren. Weitere Informationen zum Erstellen von vollständiger elektronischer Testsysteme für die Raumfahrt, einschließlich der Integration von handelsüblicher Kommunikationsbus-Schnittstellenhardware in Ihre Testsysteme zur Lösung benutzerdefinierter Entwurfsherausforderungen, finden Sie im Anwendungshinweis.