NI TestStand und ASAM XIL in der Praxis

Autor(en):

Dipl.-Ing.(FH) Jürgen Dodek - MTU Friedrichshafen GmbH

Diese Kundenlösung wurde im Tagungsband 2015 des Technologie- und Anwenderkongresses „Virtuelle Instrumente in der Praxis“ veröffentlicht.

Eingesetzte Produkte: NI TestStand

Die Abbildungen der Kundenlösung finden Sie in der Galerie und im Fließtext. In der Galerie können Sie die Bilder in größerer Auflösung ansehen.

Kurzfassung

Der ASAM XIL ist ein Standard für eine herstellerunabhängige Schnittstelle zwischen Testautomatisierungswerkzeugen und XIL-Systemen. Das „X“ im Namen des Standards ist stellvertretend für die bekannten „In-the-Loop“-Modelle wie HIL, SIL und MIL. Der folgende Beitrag zeigt einen Lösungsansatz der MTU Friedrichshafen GmbH, wie der ASAM-XIL-Standard in die Testautomatisierungsoftware NI TestStand von National Instruments integriert wurde. NI TestStand übernimmt die Ablaufsteuerung des darunterliegenden HIL-Systems, bestehend aus einem proprietären MTU-Motorsimulator und einer Vector-Informatik-CANoe-CAN-Restbussimulation.

Einleitung

Die MTU Friedrichshafen GmbH ist einer der führenden Hersteller von schnell laufenden Dieselmotoren im Leistungsbereich von 75 kW bis 10.000 kW. Zudem entwickelt die MTU in Hard- und Software elektronische Motormanagement-Automatisierungs- und -Überwachungssysteme für diese Motoren. In der Software der Steuergeräte nimmt die Anzahl der Funktionen und Anforderungen und damit die Komplexität stetig zu. Analog dazu steigt der notwendige Aufwand für das Testen der Steuergerätesoftware. Über verschiedene Teststufen, Strategien und Methoden wird versucht, mit einer geringen Anzahl von Testfällen eine möglichst hohe Testabdeckung zu erreichen. Einer der wichtigsten Tests ist der funktionale Blackbox-Systemtest, bei dem geprüft wird, ob die Software auch die spezifizierten Anforderungen erfüllt. Um diese Tests auszuführen, kann ein Motorprüfstand herangezogen werden und das Motorsteuergerät befindet sich in seiner realen Umgebung. Bedenkt man die Leistungsklasse der Motoren, wird schnell klar, dass allein schon wegen der Kosten für den Dieselkraftstoff und der damit verbundenen Emissionen diese Tests auf ein absolutes Minimum zu reduzieren sind. Zudem sind am realen Motorprüfstand nicht alle Betriebszustände, welche das Steuergerät einnehmen kann – speziell im Fehlerfall – darstellbar. Um diese Tests durchzuführen, wird die Umgebung des Motorsteuergerätes mit einem Simulationssystem nachgebildet. Es besteht aus einem proprietären MTU-Motorsimulator, welcher die Motorfunktionalität nachbildet, und einer Vector-Informatik-CANoe-Restbussimulation, die dem Steuergerät alle notwendigen CAN-Netzknotenteilnehmer zur Verfügung stellt. Der Zugriff erfolgt entweder manuell über einen PC-Arbeitsplatz oder automatisiert über NI TestStand. Automatisierte Softwaregerätetests sind seit Jahren fester Bestandteil im Softwareentwicklungsprozess. Die automatischen Regressionstests über Nacht und Wochenende tragen wesentlich zur schnellen Verifikation von Softwareversionen bzw. Ständen bei und helfen, die Testkosten weiter zu senken. Es zeigte sich aber auch, dass gerade bei neuen Softwareversionen deren Konfiguration und Parametrierung nicht immer identisch zum Vorgänger ist. Die Gründe sind zumeist unterschiedliche Applikationsanforderungen und Motorenvarianten. Dies hat für die Testautomatisierung jedoch zur Folge, dass die Testskripte an die Konfiguration angepasst werden müssen, obwohl sich funktional nichts geändert hat. Für die Verwaltung und Pflege der Testprogramme ist dies schlecht, denn es existieren Testskripte gleicher Funktionalität. Jedes einzelne ist im Extremfall nur unter einer Softwarekonfiguration zu gebrauchen. Um eine möglichst große Wiederverwendbarkeit der Testfälle zu erreichen, soll eine Abstraktionsebene zwischen der Testautomatisierung und dem Simulationssystem eingeführt werden. Die Testautomatisierungsschnittstelle muss vollständig vom Simulationssystem entkoppelt sein. Kurz gesagt: Die Testautomatisierung weiß nicht, von wo der Messwert kommt bzw. wohin er geht. Ob er von einem IO-Kanal oder einem CAN-Signal kommt, darf keine Rolle spielen. Über ein konfigurationsabhängiges Mapping soll die Verbindung zur Laufzeit erfolgen. Der Standard ASAM XIL 2.0 schlägt genau diese Brücke.

Standard ASAM XIL 2.0

Die ASAM, Association for Standardisation of Automation and Measuring ist ein deutscher eingetragener Verein. Seine Mitglieder sind hauptsächlich Fahrzeughersteller, Zulieferer und Ingenieurdienstleister der Automobilindustrie, wobei eine Mitgliedschaft nicht auf diesen Industriezweig beschränkt ist. Der Verein koordiniert die Entwicklung von technischen Standards, die in Projektgruppen durch Experten seiner Mitgliedsunternehmen entwickelt werden. Der ASAM verfolgt die Vision, dass sämtliche Werkzeuge einer Entwicklungsprozesskette miteinander verbunden werden können und ein durchgehender Datenaustausch möglich ist. Die Konformität soll das Zusammenspiel von Werkzeugen verschiedener Hersteller ermöglichen. Diese Ideale finden sich im XIL-Standard wieder. Sein Grundgedanke ist die Entkopplung des Testautomatisierungswerkzeugs vom Simulationssystem. Damit soll es möglich sein, Soft- und Hardware unterschiedlicher Hersteller miteinander – ohne großen Integrationsaufwand – zu kombinieren. Ermöglicht wird dies durch eine in C# entwickelte Microsoft-.NET-API, die eine portbasierte Kommunikation zum Steuergerätedialog, Simulationsmodell einschließlich Fehlersimulation und dem Steuergerätenetzwerk anbietet. Bereits der Name des Standards sagt aus, dass er nicht nur auf HIL-Simulationsysteme begrenzt ist. So löste er mit seiner Veröffentlichung 2013 den seit 2009 bestehenden ASAM-HIL-Standard ab. Das „X“ im Name dient hier als Synonym für die gängigen „In-the-Loop“-Modelle wie MIL (Model-in-the-Loop), SIL (Software-in-the-Loop) und HIL (Hardware-in-the-Loop). Der Standard besteht im Wesentlichen aus zwei Ebenen: dem Framework und der Testbench.

Die Testbench ermöglicht die Trennung der Testhardware von der Testsoftware. Dies erlaubt einen standardisierten Zugang zur Hardware. Die API der Testbench enthält die bekannten Ports des ursprünglichen HIL-Standards. Der Model-Access-Port gestattet den Zugriff auf das Simulationsmodell. Der ECUC/M-Port erlaubt den Zugriff auf die Kalibrier- und Messwerte des Steuergeräts. Der EES-Port dient der elektrischen Fehlersimulation und der DIAG-Port verbindet sich mit der Diagnoseschittstelle des Steuergerätes. Zusätzlich wurde der Network-Port aufgenommen. Er liest oder schreibt Signale auf dem jeweiligen Steuergerätenetzwerk. Die zweite Ebene ist das Framework, das grundlegend Neue am XIL-Standard. Sie bietet mit Variable, Acquisition, Stimulation und Watcher standardisierte Zugangspunkte zum Testautomationswerkzeug, dessen Testfälle von nun an virtuell sind. Das Framework entkoppelt sie über XML-Konfigurations- und Mappingdateien vom realen Testsystem. Die Schemata dieser Dateien liegen dem Standard bei. In den Konfigurationen stehen Verweise auf die zur Laufzeit genutzten .NET-Assemblies der Hersteller von Framework und Testbench. Ebenso stehen hier die Pfade zu den Mappingdateien. In ihnen sind die abstrakten Framework- und realen Testbenchportvariablen einschließlich ihrer physikalischen Einheit beschrieben, wie auch ihre Verbindung während der Ausführung.

Aktueller Testaufbau

Der aktuelle XIL-Testaufbau besteht aus der Testautomatisierungssoftware TestStand 2014, einer Vector-Informatik-CANoe 8.5-Feldbus- und -Diagnosesimulation und einem Motorsimulator, welcher eine Eigenentwicklung der MTU ist. Das Unit Under Test ist ein ziviles und baureihenübergreifendes Motorsteuergerät. Da die ASAM-XIL-API eine .NET-Assembly ist, ist deren Integration in NI TestStand sehr einfach. Schon seit der Einführung von .NET existiert ein passender Adapter, der es erlaubt, die Methoden und Eigenschaften der Klassen aus den .NET- Assemblies als NI-TestStand-Schritte zu nutzen. Um hohe Flexibiliät und Wiederverwendbarkeit zu erzielen, wurde in NI TestStand eine XIL-Bibliothek in Form eines SequenceFiles angelegt. Nur vier öffentliche Sequenzen stellen die XIL-Funktionalität nach außen den Testfällen zur Verfügung. Die Sequenz „Init“ übernimmt die Aufgabe, die XIL-API zu initialisieren, alle Frameworkvariablen zu laden, mit den Testbenchports – gemäß Mapping – zu verknüpfen und schließlich die Testbenches mit deren Modellen zu starten. Die Sequenzen „Read“ und „Write“ dienen dem Zugriff auf die über 1.000 abstrakten Variablen des Testaufaufbaus. Zum Abschluss kommt die Sequenz „Close“ zum Einsatz. Sie veranlasst die Beendigung der Simulationen auf den Testbenches und gibt dananch wieder alle Resourcen frei. Das Simulations- und Diagnosewerkzeug CANoe 8.5 unterstützt testbenchseitig den MA- sowie EES-Port. Die Steuerung und Überwachung des MTU-Motorsimulators erfolgt auch über eine .NET-API. Diese verfügte über keine XIL-Testbench-API. Da zum Standard der gesamte Quellcode – einschließlich Beispielen – beigestellt ist, konnte sehr einfach eine MTU-XIL-Testbench-MA-Port-API erstellt werden. Sie kapselt die bestehende .NET-API und stellt jetzt eine standardisierte XIL-MA-Schnittstelle zur Verfügung.

Zusammenfassung

Nach Abschluss des Projekts wurden in einem bestehenden Testszenario die betroffenen Testschritte auf die ASAM-XIL-Framework-API portiert. Die Praxistauglichkeit konnte damit nachgewiesen werden, indem die Ausführung der alten sowie neuen – XIL-basierten – Testschritte dieselben Testergebnisse lieferte. Die abstrakte Trennung der Testautomation vom HIL-System bedeutet jetzt nicht nur, dass die Testfälle besser wiederverwendet werden. Sie möglicht auch, dass Testsysteme, sofern sie die ASAM-XIL-API unterstützen, effizient und einfach in bestehende Testautomationssysteme integriert werden können. Bei korrekter Implementierung muss hierfür keine Zeile Code geändert werden. Mit ASAM XIL ist weiterer Schritt von der Progammierung hin zur Konfiguration von Testautomationssystemen gelungen.