Durchgängiger, plattformunabhängiger Test funktionaler Anforderungen

Tausende Kilometer werden heutzutage in Simulationen und Fahrzeugprototypen

zurückgelegt, um sicherzustellen, dass alle Funktions-, Sicherheits- und Qualitäts-

anforderungen erfüllt werden. Hierbei gilt es, einen ausreichenden Abdeckungsgrad

der unterschiedlichsten Betriebspunkte und Fahrsituationen zu erzielen. Daimler und

QTronic beschreiben ihren gemeinsamen Lösungsansatz für ein effizientes Framework

zur Anforderungsbewertung, das für vielfältige Testplattformen und Anwendungsfälle

wiederverwendet werden kann und so zu einer vollständigen und durchgängigen

Qualitätsprüfung beiträgt. Diese Methode wird derzeit von zahlreichen Projekten

aus der Antriebsstrangentwicklung im Daimler-Konzern übernommen.

© QTronic

Test

AUTOREN

Holger Brückmannist Entwicklungsingenieur bei der

Daimler AG in Stuttgart.

Alexander Waissist Entwicklungsingenieur bei der

Daimler AG in Stuttgart.

Markus Stixist Teamleiter bei der

QTronic GmbH in Stuttgart.

Dr. Ingo Matheisist Teamleiter bei der

QTronic GmbH in Stuttgart.

34

ENTWICKLUNG TEST

HERAUSFORDERUNG

Häufig können Anforderungsmodelle, die für MiL-/SiL-/HiL-Simulationen ent-wickelt wurden, aufgrund ihrer spezifi-schen Umsetzungen nicht für weitere Anwendungsfälle wiederverwendet werden. Beispielsweise sind Ingenieure bei Abnahmefahrten meist gezwungen, auf Papier-Checklisten zurückzugreifen, um sicherzustellen, dass alle vorgesehe-nen Fahrmanöver durchgeführt wurden. Zudem kann ohne eine umgehende und interaktive Rückmeldung der Prüfung nicht sichergestellt werden, dass das Sys-tem die zu testenden Betriebspunkte über-haupt erreicht hat. Dadurch leidet die Voll-ständigkeit iterativer Abnahmefahrten. Weitere wichtige Datenquellen für Sicher-heits- und Qualitätsprüfungen sind Mes-sungen aus Datenloggern von Prüfständen oder Erprobungsfahrten unter Realbedin-gungen. Anforderungen, die mit klassi-schen Testautomatisierungsskripten geprüft werden und entworfen wurden, um lediglich die Systemreaktion im Kon-text eines vordefinierten Teststimulus zu prüfen, können ebenso nicht wiederver-wendet werden. Häufig sind die Konse-quenzen vielfach redundante Anforde-rungsmodelle, die nur schwer mit der l aufenden Entwicklung synchron gehal-ten werden können. Dies verhindert eine durchgängige Anforderungsbewertung und Qualitätskontrolle über den gesamten Entwicklungsprozess hinweg – die Kosten

steigen. Das Ziel ist, alle relevanten und im Folgenden aufgelisteten Anwendungs-fälle mit einer durchgängigen Anforde-rungsbewertung zu be rücksichtigen: – Online-Auswertung von manuellen und automatisierten Tests in der Simulation

– Offline-Auswertung von Messungen aus Datenloggern

– Online-Auswertung während Erpro-bungsfahrten, inklusive Unterstützung des Fahrers zur Abdeckung gezielter Betriebspunkte.

Die folgenden Ziele hinsichtlich Benutzer-freundlichkeit sind nicht minder wichtig: – Die Anforderungsmodelle sollen leicht verständlich sein.

– Die Wartung, das Debugging und der Austausch von Modellen sollen ein-fach handhabbar sein.

– Die Prüfung unterschiedlicher Pro-duktvarianten soll ohne mehrfachen Implementierungsaufwand unterstützt werden.

FORMALE SPEZIFIKATION VON ANFORDERUNGEN

Ein erster Schritt in Richtung plattform-unabhängiger Tests ist die Erkenntnis, dass ein Anforderungsmodell keine Abhängigkeit zu einem bestimmten Teststimulus haben sollte. Vielmehr soll-ten die Anforderungen die betreffenden Betriebszustände bei Eintritt selbststän-dig erkennen und die Prüfung in allen

Situationen auslösen, die den definierten Vorbedingungen entsprechen. Dadurch wird der Teststimulus vom Anforde-rungsmodell getrennt und eine Auswer-tung der Anforderungen für praktisch jede Art von Stimulus ermöglicht.

Die „QTronic Requirement Modelling Language (RML)“, die Teil des Produkts „TestWeaver“ ist, ist eine leistungsfähige Spezifikationssprache, die automatisiert in ausführbaren Code (C/C++) über-setzt werden kann, BILD 1. Die Anwei-sungen stellen dabei logische und zeit-liche Zusammenhänge dar, um auf bestimmte Auslösebedingungen zu warten oder eine erwartete System-reaktion abzuprüfen. Dies geschieht gleichzeitig für alle Anforderungen.BILD 2 zeigt ein Codebeispiel einer sim-

plen RML-Überwachung. Die Anweisung „Message“ dient dem Fahrer als optiona-ler Hinweis zur Erfüllung bestimmter Testbedingungen. RML-Überwachungen können mit allen herkömmlichen Textedi-toren erstellt werden. Jedoch bietet Test-Weaver einen spezialisierten Editor, der Syntax-Highlighting, -Prüfung und -Ver-vollständigung ermöglicht. Die textuelle Darstellung ist mit jedem Dateivergleichs-programm und jeder Versionskontrolle kompatibel. Zusätzlich können Metadaten wie beispielsweise Autor, Beschreibung, Anforderungsidentifikationsnummer und Konfigurationsparameter zur varianten-abhängigen Prüfung aufgeführt werden. Um eine gute Übersicht trotz einer Viel-zahl von Testüberwachungen zu gewähr-leisten, können die Überwachungen in funktionale Kapitel gegliedert werden. Eine RML-Datei entspricht dabei einem Kapitel und kann mehrere RML-Überwa-chungen beinhalten.

PLATTFORMUNABHÄNGIGE TESTS

Zurzeit befinden sich drei Arten von Test-Set-ups bei Daimler im Einsatz: – Online-Tests mit simulierten Steuergerä-tenetzwerken: Silver dient zur Erstellung von virtuellen Steuer geräten (vECUs) und ihrer Co-Simulation mit Strecken-modellen im Regelkreis. Die kompilier-ten RML-Module werden für den Test der virtuellen Fahrzeuge verwendet, der automatisiert nach der Integration neuer Softwarekomponenten angestoßen wird. Hierbei stammt der Teststimulus aus vielfältigen Quellen: vordefinierten Python-Skripten, zuvor aufgezeichneten Fahrmanövern sowie automatisch gene-

RML-Watchersaus *.rml-Dateien

C/C++-Codegenerierung

Code kompiliertzu DLL, FMU,

S-Funktion

Ausführung mitSilver, Simulink,FMU-Simulator

BILD 1 Übersetzungsprozess einer RML-Überwachung (© QTronic)

BILD 2 Codebeispiel einer RML-Überwachung (© QTronic)

Test

ATZ elektronik 01-02|2019 14. Jahrgang 35

rierten Stimuli zur deutlichen Erhöhung der Testabdeckung mit TestWeaver [1, 3].

– Offline-Auswertung von Messdaten: Mithilfe der RML-Watcher können Unmengen an Messdaten aus Datenlog-gern oder Messwerkzeugen nachgelagert und in vielfacher Echtzeit auf einem her-kömmlichen PC bewertet werden. Hier-für werden die RML-Watcher aus der Online-Validierung wiederverwendet.

– Echtzeitdurchführung von Akzeptanz-tests im Fahrzeug: Silver bietet die Mög-lichkeit, die Simulation über eine Hard-ware-Schnittstelle an ein reales Kommu-nikationsnetzwerk (CAN, Lin, Flexray, Ethernet) anzubinden, um die Echtzeit-daten aus dem Netzwerk in der Simula-tion verfügbar zu machen. Dieselben RML-Watcher werden auch hier ausge-führt, um die Systemreaktion in Echtzeit zu prüfen. BILD 3 zeigt die prinzipielle Kopplung.

Alle drei Anwendungsfälle profitieren von der zeitgleichen Prüfung aller Anfor-derungen zu jedem Testzeitpunkt und der dadurch hohen Testdichte. Denn ein geeigneter Stimulus (MDF-Datei, Fahr-manöver etc.) kann bereits die Auswer-tung Dutzender Anforderungen auslö-sen. Ebenso werden bereits bewertete Anforderungen über den gesamten Testverlauf hinweg weiterhin auf ihre Einhaltung geprüft. Dies bietet deutliche Qualitätsvorteile gegenüber einem Test-verfahren mit einem Teststimulus pro Überwachung. Die ersten beiden Test-verfahren finden bereits seit Längerem bei der Daimler AG Anwendung [1, 2, 3].

Die Echtzeitdurchführung von Akzep-tanztests, durch die Wiederverwendung von Anforderungsmodellen anderer Testplattfor-men, ist jedoch erst seit der Einführung von RML möglich. Dieser Anwendungsfall wird im Folgenden näher erläutert.

Ein Excel-basiertes Frontend dokumen-tiert die Testresultate in Echtzeit und gibt dem Fahrer nützliche Hinweise, wie ein zu testender Betriebspunkt durch Fahrer-aktionen erreicht werden kann, BILD 4. Während eines Fahrmanövers werden alle RML-Watcher mit übereinstimmenden Eintrittsbedingungen ausgewertet und melden Erfolg (Success) oder Misserfolg (Failed). Dabei ist es durchaus möglich, dass eine bereits mit Erfolg bewertete Überwachung im weiteren Testverlauf unter geänderten Testbedingungen einen Misserfolg meldet. In beiden Fällen wer-den automatisch Messausschnitte als MDF-Datei gespeichert, um eine nachgela-gerte Analyse durchführen zu können. Das Excel-Dokument wird in Kapiteln pro Arbeitsblatt angelegt, um die abteilungs-übergreifende Entwicklung von Anforde-rungen zu erleichtern. Mithilfe des „Datei pro Kapitel“-Ansatzes, kann der redaktio-nelle Anteil unabhängig durch die verant-wortlichen Testingenieure erledigt wer-den. Die Akzeptanztests werden zunächst

mithilfe der entsprechenden Simulations-umgebung des Fahrzeugs ressourcenscho-nend in Silver entwickelt und getestet.

BERÜCKSICHTIGUNG VARIANTENABHÄNGIGER ANFORDERUNGEN

Die Daimler AG stellt Dutzende unter-schiedlicher Varianten eines Fahrzeug-modells her [2]. Unterschiedliche Varian-tenkonfigurationen zeigen jedoch häufig verschiedenes Verhalten in prinzipiell identischen Funktionen. Dies muss zwangsweise in den Systemanforderun-gen berücksichtigt werden. Die system-zugehörigen Anforderungen sollten, wie das System selbst, konfi gurierbar sein.

Zu diesem Zweck unterstützt RML die Spezifikation von Überwachungen mit Konfigurationsparametern. Beispielsweise wird der Watcher „Change_driving_pro-gram“ aus BILD 2 nur berücksichtigt, wenn das Testsystem dem Getriebetyp DCT oder AT entspricht – siehe „@config Sektion“. Diese Technik kann auch verwendet wer-den, um Überwachungen plattformabhän-gig zu aktivieren, da gegebenenfalls spe-zielle Prüfungen nur im Fahrzeug, jedoch nicht in der Simulation mess- und bewert-bar sind.

BILD 3 Echtzeitdurchführung von Akzeptanztests im Fahrzeug (© QTronic)

BILD 4 Excel-Frontend der Akzeptanztests (© QTronic)

ENTWICKLUNG TEST

36

PRAXISERFAHRUNGEN

Ein Testkatalog bestehend aus circa 120 Anforderungen wurde als Spezifikations-grundlage in der Pilotphase verwendet. Der Katalog konnte in zwei Wochen von einem Testingenieur in RML-Überwachungen überführt und mithilfe der Silver-Simulati-onsumgebung grundlegend getestet wer-den, da der Zugriff auf Versuchsfahrzeuge limitiert und deren Nutzung teuer ist.

Vor der Einführung dieser Testmethode waren systematische Tests im Fahrzeug äußerst zeitintensiv und er zielten häufig unvollständige Test ergebnisse. Seiten-effekte durch Softwareänderungen auf ältere Funktionsumfänge konnten nur bedingt abgetestet werden. Heute wird dies ohne zusätz liche Aufwände kon-trolliert, da bestehende sowie neue RML-Watcher zeitgleich jede Fahrsituation in jedem Zeitpunkt überwachen.

Jedes Mal, wenn ein neuer Software-stand auf dem Buildserver gebaut wird, wird automatisch auch das entsprechende virtuelle Steuergerät erzeugt sowie die

Akzeptanztests in Silver per Co-Simula-tion durchgeführt, noch bevor die Soft-ware auf ein reales Steuergerät übertragen wird. Im Falle einer Auf fälligkeit verhin-dert man so das viel fache Flashen und Analysieren fehler hafter Software auf dem Zielsystem. Intensivere Tests mit deutlich mehr Test abdeckung werden zyklisch oder zu bestimmten Quality Gates durch-geführt. Die generierten Auswertungs-dokumente und Messschriebe werden automatisch archiviert, dienen als Lang-zeitdokumentation der Testaktivitäten und helfen, Nachweispflichten zu erfüllen.

In der Zukunft sollen sowohl die Fahrer-interaktion während der Echtzeittests als auch die abteilungsübergreifende Zusam-menarbeit verbessert werden. Letzteres ist notwendig, da immer mehr Funktionen und ihre Anforderungsmodelle auf meh-rere Steuergeräte verteilt werden, so zum Beispiel das Start-Stopp-System.

ZUSAMMENFASSUNG

Ein plattformunabhängiges Testen ist essenziell, um die Softwarequalität – trotz wachsender Komplexität und Variantenvielfalt – kostengünstig sicher-zustellen. Hierfür sind formale, einfach zu beschreibende und wiederverwend-bare Anforderungsmodelle notwendig, die einen durchgängigen Systemtest mit ausreichender Testabdeckung er -möglichen. Mit der vorgestellten Test-methode kann dies für die Simulation, die Auswertung von großen Messdaten-mengen sowie alle hardwaregetriebenen, messbaren Testsysteme erreicht werden.

LITERATURHINWEISE[1] Brückmann, H.; Strenkert, J.; Keller, U.: Model-based Development of a Dual-Clutch Transmission using Rapid Prototyping and SiL, Intern. VDI Con-gress Transmissions in Vehicles, Germany, 2009[2] Gloss, S.; Slezak, M.; Patzer, A.: Systematische Validierung von über 200 Antriesvarianten. In: ATZelektronik 8 (2013), Nr. 4, S. 34-39[3] Rink, A.; Chrisofakis, E.; Tatar, M.: Automati-scher Test der Steuerungssoftware – Verfahren zur automatischen Testerzeugung. In: ATZelektronik 4 (2009), Nr. 3, S. 52-57

ATZ elektronik 01-02|2019 14. Jahrgang 37

READ THE ENGLISH E-MAGAZINETest now for 30 days free of charge: www.ATZelektronik-worldwide.com

www.iav.com

Von Mobilitätskonzept bis Machine-LearningIntelligente Lösungen für die digitale Mobilität der Zukunft