Vernetzte eingebettete Systeme in der Aerospace- und Rüstungsindustrie

Verifikation und Absicherung von vernetzten eingebetteten Systemen in der Aerospace- und Rüstungsindustrie

Autor: Joe Cassar, Team Leader, dSPACE Inc.

Zur Existenz von Systemnetzwerken in Flugwerken, Satelliten und anderen Avionikgeräten gehört seit langem die intelligente serielle Kommunikation zwischen mehreren Komponenten und Systemen. Anfangs tauschten diese Systeme einfach seriell peer-to-peer aus. Dann entwickelten sie sich hin zu deutlich komplexeren und schnelleren Multipoint-Netzwerken.

OEMs und Lieferanten von Avionik benötigen Testsysteme zur Absicherung eingebetteter Software. Zu diesen Testsystemen gehört in vielen Fällen die Simulation des zu steuernden Systems zusammen mit LRU oder FADEC sowie anderen Avionikkomponenten. Bei derartigen Testsystemen handelt es sich um geschlossene Echtzeitsysteme, die oft als Hardware-in-the-Loop (HIL)-Systeme bezeichnet werden.

Um eingebettete Software zu validieren, ist es oft notwendig, verschiedene Schnittstellen von Kommunikationsnetzwerken zu emulieren, die unter realen Bedinungen physikalisch in einer Flugzeugzelle existieren würden. Ein HIL-System für eine einzelne Prüfeinheit (Unit under Test, UUT) sollte die Emulation nicht vorhandener Komponenten wie Steuerelektronik und Sensoren, die an einem bestimmten Kommunikationsnetzwerk teilnehmen, ermöglichen. In diesem Szenario ist die Fähigkeit, einen Kommunikationsbus wie ARINC429 zu simulieren, für den Softwaretest entscheidend. Ingenieure können die Prüfeinheit damit umfangreich testen, ohne dass echte Sensor- und Aktorschnittstellen zur Verfügung stehen müssen. Zudem ist meist die nahezu vollständige Absicherung der zu prüfenden Software mit minimalen physikalischen Komponenten möglich.

Zusätzlich zu einem physikalischen Komponententest kann es empfehlenswert sein, einen Prüfstand aufzubauen, mit dem mehrere Komponenten abgesichert und die tatsächliche Interaktion zwischen diesen Komponenten getestet werden können. In diesem Szenario ist es auch wichtig, die Kommunikation zwischen einer Prüfeinheit und einer anderen isolieren und übernehmen zu können, um Fehler einzufügen – im Wesentlichen, um bestimmte Teile der Nutzlastdaten zu manipulieren und gleichzeitig einen Großteil der Kommunikation zu erhalten. Dies ist wichtig, da es manchmal schwierig ist, den dynamischen Datenverkehr von nicht existierenden Komponenten zu emulieren. Allerdings ist es so möglich, die Interaktion zwischen den einzelnen Prüfeinheiten zusammen zu testen, um die Implementierung der Software auf Systemebene abzusichern.

Unter solchen Testbedingungen muss die Testausrüstung in der Lage sein, das Rückgrat der Bustechnologie eines integrierten Systems deterministisch nachzubilden. In den meisten Fällen ist der Einsatz eines eingebetteten Systems mit einem deterministischen Echtzeitbetriebssystem (RTOS) unabdingbar. QNX ist eines der populärsten kommerziellen RTOS, das verwendet wird, um eine deterministische Leistung zu erreichen. Um Determinismus zu gewährleisten, gehört allerdings mehr dazu als ein RTOS. Das eingebettete System, auf dem das RTOS ausgeführt wird, verwendet Peripheriegeräte – auch diese dürfen nicht gegen die Prinzipien des Determinismus verstoßen.

Deshalb ist es so wichtig, dass das Gesamtsystem richtig ausgelegt ist – und auch der Grund, warum COTS-Teile von mehreren Anbietern hier Unsicherheit schaffen. Dies ist ein wichtiges Kriterium, das oft übersehen wird, wenn ein System aus handelsüblichen Komponenten mehrerer Hardware-Anbieter zusammengesetzt wird, die nicht als Ganzes im Zusammenspiel getestet wurden.

In den meisten Fällen muss der Integrator dieser Systeme sicherstellen, dass die Produkte von^{Drittanbietern} die Anforderungen erfüllen. Schnittstellenkarten, die für die Bussimulation verwendet werden, sind oft auf unterschiedliche Testanwendungen ausgerichtet – und oft sind diese Karten in der Lage, Daten mit gepuffertem Datenspeicher über eine PCI- oder PCI-Express-Backplane in Echtzeit wiederzugeben.

Für Echtzeit-Testanwendungen – zu denen beispielsweise die Simulation eines dynamischen Anlagenmodells eines Motors oder Turbolüfters gehören – ist es notwendig, dass die für die Bussimulation verwendete Schnittstellenkarte und die CPU des PCs, auf dem das dynamische Modell in der RTOS-Umgebung läuft, in der Lage sind, Daten in einem diskreten Zeitschritt synchron auszutauschen. In solchen Anwendungen ist es nicht nur wichtig, die Bildrate einer Nachrichtenübertragung zu berücksichtigen, sondern auch die Buslast.

Der Kommunikationsbus MIL-STD-1553 läuft mit Main-Frame-Zeiten von 16 oder 32 Mikrosekunden bei einer möglichen Buslast von 60-70%. Das bedeutet, dass eine enorme Datenmenge zwischen der Kern-CPU und der Simulationskarte des Peripheriebusses ausgetauscht werden muss. Angesichts dieser Anforderungen sind integrierte Lösungen für Echtzeitsysteme, die die Interoperabilität zwischen der zentralen Echtzeitsimulation und der Schnittstellenperipherie sicherstellen, von entscheidender Bedeutung. Dedizierte und gut integrierte schlüsselfertige HIL-Systeme wie dSPACE SCALEXIO erfüllen alle Anforderungen für den Test von vernetzten eingebetteten Systemen, um ausreichende Rechenleistung für die Simulation, fortschrittliche elektronische Schnittstellen zur Emulation der Sensor- und Aktorreaktion sowie zur Simulation des Netzwerkverkehrs bereitzustellen.

In der Vergangenheit war die vorherrschende Netzwerkschnittstelle der Wahl für kommerzielle Flugzeuge ARINC-429, die als Punkt-zu-Punkt-Kommunikation implementiert ist. ARINC429-Transceiver senden Daten in einem 32-Bit-Frame, der aus einem Label und einem Datenfeld besteht, wobei das Labelfeld die spezifische Anwendung der Daten identifiziert. Diese Label sind für den jeweiligen Einsatzzweck standardisiert. Aufgrund der Art dieser Punkt-zu-Punkt-Kommunikation benötigt ARINC429 oft eine hohe Kanalzahl, um die gesamte Busarchitektur emulieren zu können. Zudem verdoppelt sich die Anzahl der für ein Testsystem benötigten Kanäle, wenn eine Fehlereinspeisung zwischen den Knoten zum Testen notwendig ist.

Für die Verteidigungsavionik und -satelliten war das Protokoll MIL-SPEC 1553B in den vergangenen 40 Jahren die dominierende Netzwerkschnittstelle. Das Protokoll basiert auf einem Bus Controller (BC) und beinhaltet bis zu 32 Remote Terminals (RT), bei denen alle Transaktionen auf dem Bus vom BC vorgegeben werden, der einen bestimmten RT anweist, Daten zu senden oder zu empfangen.

Die Bustechnologien ARINC419 und MIL-STD-1553 sind nach wie vor relevant. Sie werden in den unterschiedlichsten Anwendungen eingesetzt und müssen daher von den Testsystemen unterstützt werden.

Heute werden in der Avionik und im Verteidigungsbereich vielfältigere Netzwerkschnittstellen eingesetzt. Protokolle wie SAE AS6802 Time-Triggered Ethernet, das auf IEEE-1394 basierende SAE AS5643 und FlexRay folgen einem ähnlichen Ansatz der synchronen Ablaufplanung von Nachrichten entlang eines Major Frames, um Determinismus zu gewährleisten, indem sie jeder Nachricht einen dedizierten Zeitrahmen für ihre Übertragungen bereitstellen. Zusätzlich zu den Ethernet-Netzwerkschnittstellen vom Typ Backbone erweitern viele kommerzielle Flugzeugzellenhersteller das Backbone-Netzwerk durch verteilte Cluster-Schnittstellen auf Basis von ARINC-825 und dem etablierten automotiven CAN-Protokoll.

Darüber hinaus bieten Shared-Memory-Schnittstellen zwischen den verteilten Steuerungen wie FORM, SCRAMNET und FibreChannel eine Alternative zu Busschnittstellen. Daher sind Testsysteme erforderlich, um eine Vielzahl dieser Schnittstellen zu integrieren.

Der nächste wichtige Faktor, der bei Testsystemen zu berücksichtigen ist, ist der Netzwerkmanagementmechanismus zur Realisierung der Buskonfiguration. Dies kann eine Herausforderung darstellen, da viele Anbieter von Avionikbus-Hardware zwar grafische Benutzeroberflächen anbieten, aber typischerweise für den Einsatz in einer nicht in Echtzeit arbeitenden PC-Umgebung mit Windows oder Linux konzipiert sind. Sie stellen möglicherweise keine Gerätetreiber für QNX oder gleichwertige RTOS zur Verfügung, da der normale Anwendungsfall darin besteht, den erforderlichen Determinismus auf dem Gerät selbst abzubilden. Während dies für einfache statische Open-Loop- oder stimulibasierte Tests ausreichend ist, wird die Notwendigkeit einer dynamischen Simulation im geschlossenen Regelkreis nicht berücksichtigt. Eine enge Kopplung zwischen dem zentralen Echtzeitsystem und der Netzwerk-Emulationshardware ist jedoch sehr wichtig. Die Netzwerkkonfigurationssoftware muss die einfache Konfiguration auf einem PC ermöglichen und das Echtzeitsystem ansteuern können.

Viele Anbieter von Echtzeitsystemen bieten Konfigurationssoftware, die das Netzwerktopologiemanagement mit den Echtzeit-Streckenmodellen verbindet. In vielen Fällen werden Streckenmodelle als mathematische Software-Pakete definiert, die in vielen Formen vorliegen. Die grafische Modellierung physikalischer Komponenten ist in den vergangenen 20 Jahren mit dem Aufkommen fortschrittlicher Simulationswerkzeuge ziemlich populär geworden, weshalb für jedes Software-Testsystem mittlerweile ein Konfigurationswerkzeug vorausgesetzt wird, das in der Lage ist, diese Modellierungsinhalte in sein System zu importieren.

Ebenso wichtig ist es für ein Netzwerkkonfigurationstool, auch mit branchenüblichen Simulationssoftware-Paketen wie NPSS (Numerical Propulsion System Simulation)-Modellen zu arbeiten. Dies kann schwierig sein, wenn solche Modellierungspakete nur in kompilierter Form verfügbar sind und eine spezifische Betriebssystemunterstützung erfordern, die vom Testsystem verlangt, Modelle in Co-Simulation über mehrere CPU-Kerne hinweg auszuführen.

dSPACE Testlösungen mit Mehrkernprozessoren unterstützen das Hosting mehrerer Betriebssysteme über eine einzige Anwendung hinweg für Simulationspakete, die nur unter einer bestimmten Umgebung ausgeführt werden.

Die Konfiguration des Kommunikationsnetzwerks zu definieren, ist ein langwieriger und zeitaufwendiger Prozess. Viele Unternehmen definieren ihre Netzwerktopologie mit Hilfe von Konfigurationsdateien im XML-Format. Spezifische XML-Schemata werden verwendet, um Parameter zu beschreiben, zum Beispiel das spezifische Timing einer Nachricht oder Informationen darüber, wie eine Nachricht codiert und decodiert wird. Testsysteme, die einen Dateiparser zur Konfiguration der Netzwerktopologie implementieren, würden von dieser vordefinierten Konfiguration profitieren. Da diese XML-Schemata nicht standardisiert sind, ist typischerweise ein kundenspezifisches Engineering für die Automatisierung der Buskonfiguration erforderlich. Daher muss überprüft werden, ob Testsysteme über eine offene API für eine solche Automatisierung der Netzwerkkonfiguration verfügen. dSPACE Systeme bieten eine offene API auf Basis von Python, COM, .Net und HIL API auf Basis von ASAM-Standards.

Schließlich müssen Testsysteme für die Avionik eine einfache Implementierung von Testfällen und eine effiziente Verwaltung von Testdaten über die Testsysteme hinweg ermöglichen. ASAM AE-HIL-BS-1-3-API hat sich als Standard in der Automobilindustrie entwickelt, um eine Schnittstelle zwischen Testautomatisierungssoftware und HIL-Testsystemen zu realisieren. dSPACE AutomationDesk und HIL-Testsysteme entsprechen dieser Norm.

Diese Werkzeuge ermöglichen typischerweise die grafische Implementierung von Testfällen, aber viele verfügen auch über eine Python-basierte Scripting-API-Unterstützung. Das Testautomatisierungswerkzeug sollte Mechanismen zur Definition eines Testframeworks beinhalten, das als Grundlage für jeden definierten Testfall verwendet werden kann, zudem eine Art Editor zur Testausführung und zur Verwaltung der Testdatenergebnisse. Zudem sind mitunter Schnittstellen zu Anforderungsmanagement-Werkzeugen erforderlich.

Letztlich erfordert die Spezifikation eines HIL-Testsystems zur Absicherung von Software vernetzter eingebetteter Systeme besondere Überlegungen hinsichtlich der Kriterien für den Echtzeitdeterminismus und der relevanten Netzwerkschnittstellentechnologie. Diese Systeme müssen ein hohes Maß an Genauigkeit bei der Berechnung mathematisch beschriebener Streckenmodelle erreichen, um einen geschlossenen Determinismus zu gewährleisten, und müssen eine enge Kopplung zwischen dem zentralen Echtzeitsystem und den Netzwerkkarten aufweisen. Gleichzeitig sollten derartige Systeme eine einfache Konfiguration und idealerweise – falls vorhanden – den Import von Netzwerkbeschreibungsartefakten ermöglichen. Es ist auch wichtig, Fragen der Testautomatisierung und des Datenmanagements als Teil des Gesamtprozesses zu behandeln.