Erstellen von austauschbaren Testfällen über eine vielfältige Werkzeugkette und über Plattformen unterschiedlicher Hersteller hinweg

Veröffentlicht: 11.02.2019

Dr. Andreas Himmler, Business Development Manager – Aerospace, dSPACE GmbH

Das Testen ist eine grundlegende Aufgabe, die von Ingenieurteams durchgeführt wird, um die Funktionalität, Zuverlässigkeit und Betriebssicherheit von Produkten zu überprüfen. Viele Branchen, darunter Luft- und Raumfahrt sowie Automobilhersteller und -zulieferer, setzen im Testprozess einen Mix aus verschiedenen herstellerspezifischen Werkzeugen ein. Diese Tools helfen Entwicklern zwar, ein hohes Maß an Produktivität zu erreichen, bringen aber auch Einschränkungen mit sich, die sich auf das Arbeitspensum auswirken. Einer der größten Nachteile ist der, dass es schwierig und in einigen Fällen unmöglich ist, Testfälle zwischen den Tools auszutauschen, da sie nicht die gleiche Sprache sprechen.

Wäre es nicht toll, wenn Testfälle in verschiedenen Entwicklungsstadien nicht nur zwischen verschiedenen Abteilungen, sondern auch zwischen Unternehmen oder Lieferanten frei ausgetauscht werden könnten? Der redundante Aufwand – und insbesondere der Code, der für das Testen generiert werden muss – könnte sicherlich reduziert werden, ebenso wie der Gesamtaufwand für die Durchführung von Tests. Bei größeren komplexen Systemen, die Ausfallsicherheit erfordern, zum Beispiel bei Flugzeugsystemen, könnte diese Art der Freiheit sehr nützlich sein.

Eine Möglichkeit, dieses Problem anzugehen, ist die Standardisierung. Durch die Standardisierung von Schnittstellen zwischen Prüfständen und Automatisierungswerkzeugen und die Standardisierung von Austauschformaten für Testfälle könnte eine herstellerübergreifende Werkzeugkette nicht nur die Wiederverwendung von Testfällen, sondern auch den Austausch von Testfällen zwischen verschiedenen Abteilungen und sogar verschiedenen Unternehmen oder Lieferanten erleichtern. Darüber hinaus könnten die Ingenieure auch ihre vorhandene Werkzeugkette nutzen, um fehlgeschlagene Testvarianten in ihrer vertrauten Umgebung zu untersuchen und zu reparieren.

Zusammen mit meinem dSPACE Kollegen Rainer Rasche und den Geschäftspartnern Volker Meyer von der Airbus Operations GmbH sowie Marco Franke und Klaus-Dieter Thoben vom Bremer Institut für Produktion und Logistik (BIBA) habe ich kürzlich einen Fachartikel mit dem Titel „Interfacing and Interchange – Reusing Real-Time Tests for Safety-Critical Systems“ geschrieben. Wir haben diese Herausforderungen genauer unter die Lupe genommen, und ich freue mich, Ihnen eine Zusammenfassung unserer Ergebnisse zu geben.

Anbindung von Prüfständen und Austausch von Testfällen mit Standards.

Wir haben uns zwei unterschiedliche Ansätze angeschaut, die das Problem lösen könnten. Der erste Ansatz basiert darauf, die Anbindung zwischen Testautomatisierungswerkzeugen und Prüfständen zu ermöglichen. Der zweite Ansatz erleichtert den Austausch, so dass Anwender Testfälle und Definitionen zwischen verschiedenen Testautomatisierungswerkzeugen austauschen können.

Diese Tabelle zeigt die erforderlichen Leistungsmerkmale. Das „x“ markiert die Verfügbarkeit von Leistungsmerkmalen für den jeweiligen Ansatz.

Standardisierte Schnittstellen

Durch die Verwendung standardisierter Schnittstellen zwischen Testautomatisierungswerkzeugen und Prüfständen können Anwender ihre Software und Simulationshardware frei kombinieren. Es gibt ihnen auch die Flexibilität, bei Bedarf Werkzeuge und Prüfstände auszutauschen. Generell gibt es zwei Ansätze: standardisierte Schnittstellen auf Protokollebene und auf API-Ebene. Für Simulationszwecke wird häufiger die Standardisierung auf API-Ebene eingesetzt.

Die Association for Standardisation of Automation and Measuring Systems (ASAM) hat die XIL API als generische Simulatorschnittstelle für die Kommunikation zwischen Testautomatisierungswerkzeugen und Prüfständen entwickelt. Sie ermöglicht es dem Anwender, Produkte frei nach seinen Anforderungen sowie unabhängig vom Hersteller oder der Entwicklungsphase auszuwählen.

XIL API 2.0 ist die neueste Version des Standards. Cross-Tests zwischen verschiedenen Anbietern und ihren Produkten zeigen eine gute Interoperabilität von Prüfständen und Testautomatisierungstools, die XIL API verwenden. Dies ermöglicht es dem Endanwender, die am besten geeignete Testsoftware mit der am besten geeigneten Testhardware zu kombinieren. Der Standard ist technologieunabhängig und kann auf Wunsch leicht auf andere Sprachen wie Java oder C++ erweitert werden.

Standardisierter Austausch

Unternehmen, die unterschiedliche, herstellerunabhängige Testsysteme einsetzen, haben oft einen Mix aus verschiedenen Testablaufsprachen mit eigener Syntax und Semantik. Durch standardisierte Austauschformate können Anwender Testfälle und Definitionen zwischen verschiedenen Automatisierungswerkzeugen austauschen.

Einige gängige Testablaufsprachen sind: Testing and Test Control Notation (TTCN-3), Automatic Test Mark-up Language (ATML) und die Definitionen der Signalbeschreibung in XIL. Die typische Sprache der Testverfahren richtet sich an die Einrichtungsumgebung, beschreibt, wie ein Fehler in das zu testende System eingespeist wird, und definiert potenzielle Fehlerzustände sowie erwartete Ergebnisse (relevant für bestimmte Parameterwertzuweisungen), aber es gibt eine Trennung in der Semantik.

Die Semantik bestimmter Prüfstandfunktionen, zum Beispiel die Protokollierung, wird außerhalb der Testablaufsprache definiert. Dies erschwert den Austausch von Testfällen. Um den Austausch von Prüfstandfunktionen zu ermöglichen, müssen entweder die Semantik aus der prüfstandspezifischen Implementierung extrahiert und im Zustandsdiagramm dargestellt werden oder ähnliche prüfstandspezifische Funktionen zwischen den verschiedenen Prüfständen abgebildet werden. In beiden Fällen ist nicht garantiert, dass die Funktionen eines Prüfstandes auf dem anderen zur Verfügung stehen werden.

Um einen austauschbaren Testvorgang zu erstellen, ist ein zweistufiger Ansatz erforderlich:

  1. Die allgemeine Transformation von Zuständen und Übergängen, zum Beispiel Felddatenintegration, Cross Compiling
  2. Ein Mapping-Mechanismus für das Mapping von Testsystemfunktionen untereinander

Das Ziel beider Methoden ist es, Syntax und Semantik aus einem Format zu extrahieren und in die andere Syntax zu übertragen, die die erforderliche Semantik abdeckt.

Mehr über die beiden Ansätze und die Methoden zur Implementierung dieser Lösungen erfahren Sie in diesen Fachartikel: Interfacing and Interchanging – Reusing Real-Time Tests for Safety-Critical Systems. Dieser Fachartikel enthält eine Machbarkeitsstudie.

  • Interfacing and Interchanging – Reusing Real-Time Tests for Safety-Critical Systems Veröffentlichungen, PDF, Englisch, 690 KB
Weiterführende Informationen

Treiben Sie Innovationen voran. Immer am Puls der Technologieentwicklung.

Abonnieren Sie unser Expertenwissen. Lernen Sie von erfolgreichen Projektbeispielen. Bleiben Sie auf dem neuesten Stand der Simulation und Validierung. Jetzt dSPACE direct und dSPACE direct aeropace & defense abonnieren.

Formularaufruf freigeben

An dieser Stelle ist ein Eingabeformular von Click Dimensions eingebunden. Dieses ermöglicht es uns Ihr Newsletter-Abonnement zu verarbeiten. Aktuell ist das Formular ausgeblendet aufgrund Ihrer Privatsphäre-Einstellung für unsere Website.

Externes Eingabeformular

Mit dem Aktivieren des Eingabeformulars erklären Sie sich damit einverstanden, dass personenbezogene Daten an Click Dimensions innerhalb der EU, in den USA, Kanada oder Australien übermittelt werden. Mehr dazu in unserer Datenschutzbestimmung.