Komplexe elektronische Aerospace-Systeme in der Entwicklung testen

Die kontinuierliche Weiterentwicklung von umfassenden und strukturierten Testmethoden und Testwerkzeugen für elektronisch vernetzte Flugzeug- und Kabinensysteme ist nicht nur aus wirtschaftlichen Gründen notwendig. Neue sicherheitskritische Piloten-Assistenzsysteme wie EFVS (Enhanced Vision Flight System) oder ROPS (Runway Overrun Prevention System) erfordern genauso wie „drahtlose“ Kabinenfunktionen geeignete Teststrategien, die den strengen regulatorischen Vorgaben entsprechen (Konformität mit DO-178C).

Die Aerospace-Branche kann auch Methoden der Automotive-Branche nutzen. Vector Informatik GmbH

Die in Bord- und Bodensystemen genutzte Software ist durch die Normen DO-178C beziehungsweise DE-278 strengen Vorgaben unterworfen. Der höchst sicherheitskritische Anwendungsbereich erfordert erheblichen Analyse- und Arbeitsaufwand für die Verifikation und Validierung dieser Systeme. Tatsächlich verwenden die Unternehmen branchenweit in einem typischen Projekt etwa die Hälfte des Entwicklungsbudgets für strukturelle Softwaretests, um eine Zertifizierung der US-Luftfahrtbehörde FAA nach DO-178C (Level A) zu erhalten. Können diese Systeme automatisiert getestet und simuliert werden, trägt dies massiv zur Reduzierung des Gesamtaufwands und damit auch der Implementierungskosten bei.

Bei der Verifikation und Validierung der in Bord- und Bodensystemen eingesetzten Software lassen sich drei wesentliche Phasen unterscheiden (Bild 1): Modultests, Integrationstests und Systemtests (funktionale Tests). In jeder Phase werden Testfälle aus den jeweiligen Anforderungen abgeleitet, wobei eine vollständige Rückverfolgbarkeit gewährleistet sein muss.

Bild 1: Die drei wesentlichen Phasen der Verifikation und Validierung von Software für Bord- und Bodensysteme. Vector Informatik GmbH

Die Konzepte und Methoden im Bereich der Low-Level-Tests haben sich im Laufe der Zeit relativ wenig verändert. Das verstärkte Aufkommen von vernetzten Systemen auf Basis des AFDX-Protokolls und die Bestrebungen, Code wiederzuverwenden, verlangen innovative Ansätze für das Testen von Software. Bei der Suche nach Lösungen lohnt sich der Blick in Branchen, in denen der Einsatz komplexer vernetzter Systeme bei kurzen Markteinführungszeiten und besonders kritischer Funktionalität bereits jetzt Realität ist. Ein Beispiel hierfür ist die Automobilindustrie. Dort werden Drive-by-Wire-Systeme, Technologien für autonomes Fahren und via CAN/Ethernet vernetzte Plattformen heute schon erfolgreich umgesetzt, und Entwicklungszyklen von 18 bis 24 Monaten sind die Norm.

Aufgrund der Parallelen zwischen diesen Systemen ist es möglich, bewährte Konzepte und Verfahren aus der Automobilindustrie auf die Avionik zu übertragen. Die Ansätze lassen sich analog zu Abschnitt 6.4.3 des DO-178C in drei Stufen gliedern: Low-Level-Test, Software-Integrationstest und Hardware-/Software-Integrationstest. Abschließend lohnt es sich zu überlegen, wie diese in einen Prozess eingebunden werden können, der höhere Agilität und die Einführung eines Shift-Left-Ansatzes in den Entwicklungsprozess ermöglicht. Das Shift-Left-Testing ist ein Ansatz für Softwaretests und Systemtests, bei dem das Testen früher im Lebenszyklus erfolgt und somit auf der Projektzeitleiste eine Verschiebung von rechts nach links erfährt.

Low-Level-Test

Bild 2: Low-Level-Testumgebung für den Test eines isolierten Softwaremoduls, Testumgebung mit Test-Treibern und -Stubs für Abhängigkeiten. Vector Informatik GmbH

In der Teststufe „Low-Level-Test“ testen die Beteiligten die Erfüllung von Anforderungen in einer frühen Phase; dazu zählen üblicherweise verschiedene Software-Komponententests, bei denen einzelne Quellcode-Module isoliert werden. Um ein einzelnes Modul isoliert zu testen, müssen die Ingenieure eine umfangreiche Testumgebung aufbauen, darunter Test-Treiber und -Stubs zur Berücksichtigung von Abhängigkeiten (Bild 2). Im Idealfall geschieht dies automatisch mithilfe eines Tools, das die intuitive und einfache Festlegung von Testszenarien ermöglicht. Auf diese Weise werden die wichtigsten Anforderungen aus Abschnitt 6.4.2 „Anforderungsbasierte Testauswahl“ sowie der Unterabschnitte „Testfälle im Normalbereich“ und „Robustheitstestfälle“ der Norm DO-178C erfüllt. Angesichts des steigenden Bedarfs an wiederverwendbarem Code ist es sehr wahrscheinlich, dass dieselbe Quellcode-Einheit in verschiedenen Konfigurationen zum Einsatz kommt. Daher darf die Definition eines Testfalls nicht starr an den Code gebunden sein, sondern muss genügend Flexibilität für eine Weiterentwicklung der Software im Laufe der Zeit bieten. Die Nutzung einer datengesteuerten Schnittstelle für die Testfalldefinition hat sich auf Dauer als zweckmäßiger erwiesen als eine Definition über den Quellcode.

Stehen Quellcode und Testfälle im Rahmen eines entsprechenden Workflows kontinuierlich bereit, so bietet dieser Ansatz bei Codeänderungen die Möglichkeit, die Testumgebung schnell neu zu generieren und die Testfälle entsprechend neu zuzuordnen. Bei erheblichen Änderungen lassen sich diese für eine zusätzliche Prüfung auswählen und entsprechend kennzeichnen, ohne den automatischen Workflow zu unterbrechen.

Ein solches Verfahren kann beispielsweise mit der Embedded-Software-Testplattform Vectorcast (Eigenschreibweise: VectorCAST) umgesetzt werden, die Testaktivitäten über den gesamten Lebenszyklus der Softwareentwicklung hinweg automatisiert. Die Lösung unterstützt das Testen auf dem Zielgerät oder die Verwendung eines Simulators, den üblicherweise der Compiler-Anbieter zur Verfügung stellt. Die strukturelle Code- Abdeckung aus dem Test von isolierten Komponenten lässt sich mit der Code-Abdeckung aus den vollständigen Integrationstests kombinieren, um eine aggregierte Sicht auf die Code-Abdeckungs- Metriken zu ermöglichen.

Vectorcast-Testfälle werden unabhängig vom Quellcode für einen datengesteuerten Ansatz gepflegt. So besteht die Möglichkeit, vollautomatische Tests auf dem Host, Simulator oder auf dem Embedded-Gerät durchzuführen.

Software-Integrationstest

Bild 3: Beispielhafter Aufbau für die Simulation der LRU-Umgebung. Vector Informatik GmbH

Bei einem Software-Integrationstest prüfen die Beteiligten das Zusammenspiel der Komponenten. Dieses Konzept ist auch als Software-in-the-loop-Simulation bekannt. Der Grundgedanke ist dabei, die verschiedenen Softwarekomponenten unter Außerachtlassung der zugrundeliegenden Hardware zu testen. Besonders wichtig für Softwaretests in dieser Phase ist die Möglichkeit, die Abhängigkeiten und Schnittstellen für das momentan getestete integrierte Modul zu simulieren.

Für die Simulation dieser Software kommt üblicherweise ein Host-basierter Compiler wie Visual Studio, GCC oder MinGW zum Einsatz, um den Code auszuführen. Ab einem gewissen Zuverlässigkeitsgrad findet dann auch der Cross-Compiler Verwendung. Je nach DO-178C-Zertifizierungsstufe (Level C, B oder A) ist eine Zertifizierung unter Umständen nur möglich, wenn die Aktivität mit dem Cross-Compiler und auf der Zielplattform erfolgte.

In der Low-Level-Testumgebung geschieht das Testen der verschiedenen Softwaremodule nach wie vor über die Programmierung von API-Aufrufen. In diesem Fall ist die Verwendung einer Testautomatisierungslösung wie Vectorcast besonders nützlich, da sie automatisch die benötigten Treiber und Stubs für nicht relevante Module erstellt. Zudem lassen sich unter Umständen Testfälle aus dem Low-Level-Test für Module wiederverwenden, die weiter oben in der Aufrufstruktur angeordnet sind. Es ist auch möglich, dass die zu testenden Softwarekomponenten eng mit der zugrundeliegenden Hardware verbunden sind. In diesem Fall ist eine robustere Simulation der Hardware nötig, um die Softwarefunktionalität korrekt zu verifizieren.

Hardware-/Software-Integrationstest

Diese Tests erfolgen in einer späten Phase des Entwicklungsprozesses auf der Zielhardware, wobei die vollständige ausführbare Image-Datei zum Einsatz kommt. Die Herausforderung dieser Teststufe besteht darin, die korrekte Funktionalität der Line Replaceable Units (LRU) durch ausreichende externe Stimulation sicherzustellen. Die externe Simulation kann auf verschiedene Arten erfolgen – unter anderem über logische Pins, ein Avionik-Datennetzwerk oder Modellierwerkzeuge. Aufgrund des komplexen Aufbaus der Netzwerke ist es zudem wichtig, die Simulationsschnittstellen schnell und einfach erweitern oder anpassen zu können.

Ein beispielhaftes System-Setup für die Validierung einer LRU auf dieser Stufe lässt sich mit CANoe und dem VT-System umsetzen (Bild 3). Vector bietet mit der Soft- und Hardware-Kombination CANoe und VT-System ein Testsystem, das vom einfachen Testwerkzeug am Arbeitsplatz bis zur hochautomatisierten HiL-Umgebung im Testlabor skalierbar ist. Die Kernidee des VT-Systems besteht darin, alle Hardwarefunktionen für das Testen von Steuergeräten in einem modularen und nahtlos in CANoe integrierten System zu vereinen. Die Testhardware deckt alle Ein- und Ausgänge einschließlich der Stromversorgung und der Netzwerkanschlüsse einer Steuereinheit oder eines Subsystems ab. An jedem Pin sind der Pin-Funktion entsprechend Stimulation, Messung, Lastsimulation, Fehleraufschaltung sowie die Umschaltung zwischen Simulation und Originalsensoren/-aktoren möglich. Diese Funktionen sind so universell ausgelegt, dass ein einmal aufgebautes Testsystem für unterschiedliche LRUs verwendbar ist.

Neben der Netzwerkumgebung besteht in CANoe auch die Möglichkeit, die physikalische Umgebung mithilfe entsprechender Matlab-/Simulink-Modelle zu simulieren. Eine geschlossene HiL-Simulation ist genauso möglich wie eine einfache manuelle Stimulation ohne e Modelle. Die gleiche Flexibilität bietet CANoe bei der Testautomatisierung. Mit der Software Vteststudio (Eigenschreibenweise: vTESTstudio) steht dazu ein adäquates Autorenwerkzeug bereit. Hier reicht die Palette der Möglichkeiten vom Programmieren in verschiedenen Sprachen (etwa der Vector-eigenen Sprache CAPL sowie .NET/C#) über das Definieren einfacher Testabläufe in Tabellenform bis hin zu grafisch notierten Testmodellen. Die Software ermöglicht das Definieren von Testabläufen und die flexible Kombination der verschiedenen Eingabemethoden. Die fertigen Testabläufe werden als Testeinheiten gespeichert und dann in CANoe ausgeführt. Nach jedem Testlauf erstellt CANoe einen detaillierten Bericht. In der Testdatenverwaltung laufen schließlich von der Test- und Ausführungsplanung bis zur Ausführungsdokumentation alle Fäden zusammen. So ist stets eine gute Rückverfolgbarkeit gewährleistet.

Das Ziel: eine schlanke Continuous-Integration-Pipeline

Bild 4: Change-Based-Testing verkürzt die Testdauer deutlich und gewährleistet die Testvollständigkeit. Vector Informatik GmbH

Alle Beteiligten sollten es unbedingt vermeiden, unbeabsichtigte Fehler oder Probleme über den Entwicklungszyklus eines Systems weiter zu geben. Diese Probleme lassen sich häufig schon in einer frühen Entwicklungsphase erkennen, bleiben aber häufig unentdeckt, weil adäquate Verifikations- und Validierungsmaßnahmen fehlen. Als mögliche Antwort auf diese Herausforderung nennen die Experten häufig Shift-Left-Ansätze – Vorgehensweisen, bei denen Tests bereits in einer früheren Entwicklungsphase erfolgen. Der Zeitaufwand für ein erneutes Durchlaufen aller Low-Level-Tests, Software- Integrationstests und Hardware-/Software-Integrationstests kann allerdings sehr hoch sein. Mitunter nimmt das vollständige Durchlaufen aller Testfälle einen Zeitraum von drei Wochen bis zu zwei Monaten in Anspruch. Damit Entwickler zeitnahes Feedback zu Problemen erhalten, die unter Umständen schon beim Programmieren der Software entstanden sind, muss diese Zeitspanne deutlich verkürzt werden.

Abhilfe verspricht das Change-Based-Testing (CBT). Dieses schnelle und intelligente Testverfahren beruht darauf, dass jede Code-Änderung mit allen Testfällen abgeglichen wird, um zu ermitteln, welche Untermenge der Tests von der Änderung betroffen ist (Bild 4). Dadurch, dass nur diese Testuntermenge durchlaufen wird, lässt sich der Zeitaufwand für die Ausführung der Tests deutlich reduzieren. Die Entwickler erhalten ein unmittelbares Feedback zu den Auswirkungen ihrer Änderungen. So besteht die Möglichkeit, Softwarefehler direkt nach ihrer Entstehung zu beheben – und nicht erst Wochen später im Rahmen eines vollständigen Testlaufs.

Durch das Verwenden einer Testautomatisierungsplattform wie Vectorcast wird die strukturelle Code-Abdeckung von allen Testebenen wie Low-Level, Software-Integration und Hardware/Software-Integration, erfasst. Die Möglichkeit, die Berichterstattung für die Code-Abdeckung in Tools für die Software- beziehungsweise Software-/Hardware-Integration wie CANoe und VT-System einzubinden, bietet eine einheitliche Darstellung der aggregierten Code-Abdeckung des Systems und der Anteile der einzelnen Tests an der gesamten Code-Abdeckung. Wenn also eine Änderung an der darunter liegenden Software erfolgt, ermittelt Vectorcast, welche Tests auf den verschiedenen Stufen betroffen sind und weist diese entsprechend an, selbst wenn CANoe oder VT-System den Test ausführen. Nur eine Untermenge von Tests auszuführen bedeutet eine erhebliche Zeitersparnis. Die Auswirkung einer erfolgten Änderung lässt sich innerhalb weniger Stunden mit hoher Zuverlässigkeit bestimmen.

(av)

(av)