Tests im AGS-Projekt

im Auftrag der BMW AG Projekt 23.

Die unten beschriebenen Tests werden im Rahmen des langjährigen AGS-Projekts eines Herstellers der Automobilindustrie, BMW AG, entwickelt. Sie dienen der Verifizierung und Validierung eines Softwaremoduls, das in EGS- Steuergeräten eingebettet ist und das Getriebe von Automatik-Fahrzeugen steuert.

Es soll unter keinem Umstand der Eindruck entstehen, dass die unten erwähnten Tests, der Gesamtmenge aller Tests entspricht, die durchgeführt werden, bevor ein Steuergerät zuletzt freigegeben wird - bzw. in Serienfahrzeuge eingebaut wird. Diese Einschränkung gilt auch noch, wenn nur Tests in Simulationsumgebung betrachtet werden.

  1. Modul und System- Test mit dem ECU-Testtool

    Zur Durchführung vieler Tests - darunter Modul-, System- und Layer- Test - wird das Steuergerät mit der zu testenden Software an einen HiL-Prüfstand angeschlossen, welcher alle weiteren nötigen Fahrzeugkomponenten simuliert. Zum Starten der HiL-Simulation ruft der Operateur am Prüfstandrechner eine Bedienoberfläche - die HiL-GUI - auf, die nicht nur mit der Hardware - HiL-Schrank, Steuergerät - verbunden ist, sondern auch über TCP-IP mit den APIs von verschiedenen Tools - je nach Zweck und Schwerpunkt der HiL-Simulation.

    In diesem Teilprojekt werden folgende Tools herangezogen:

    • Je nach Zielfahrzeug wird auf dem HiL-Prüfstand ein Simulationsmodell aufgerufen, das über eine geeignete Anwender-Schnittstelle bedient wird: CONTROLDESK, NOVASIM

    • Das Diagnose-Tool greift auf den Fehlerspeicher des Steuergeräts zurück.

    • Das INCA-Tool zur Messung und Kalibrierung der embedded Software greift auf den Datenbereich des Steuergerätes zurück.

    • Das ECU-Testtool (ECUTT) von TraceTronic.
      Anhand einer proprietären Skriptsprache - deren Funktionalität mit Hilfe von python- Prozeduren nach Belieben erweitert werden kann - ist es möglich, die HiL-Simulation zu steuern: Einen gewünschten Zustand des Fahrzeuges (die Vorbedingung) herbeizuführen, den Test durchzuführen (Bedingungen zu prüfen bzw. Sollwerte und Istwerte zu vergleichen) und einen vorgegebenen Zustand danach (die Nachbedingung) einzustellen - als Initialzustand für den nächsten Testschritt.

    Manch ECUTT-Skript dient der Verifizierung nach White-Box-Verfahren: Es wird sichergestellt, dass Software-Pfade korrekt aktiviert werden. Manch anderes dient der Validierung nach Black-Box-Verfahren: Es wird sichergestellt, dass allgemeine Steuerungsmechanismen greifen .

  2. Modultest mit TESSY

    Es kommt das TESSY-Testtool zum Einsatz. Mit TESSY kann der Testentwickler 'Modultests' schreiben. Jedes zu testende 'Modul' entspricht einer C-Funktion, deren Quelltext dem Testentwickler bekannt ist. Daraus wird eine Reihe von Tests nach dem White-Box-Verfahren erstellt. Das heißt, der Testentwickler definiert die Testfälle, um bestimmte Softwarepfaden zu aktivieren.

  3. Layer-Test

    Er zielt auf externe Schnittstellen der AGS-Software - im Gegensatz zu Modultests, welche auf interne C-Funktionen abzielen. Das Lastenheft der Schnittstellen ist gut dokumentiert: Die Entwicklungsteams wollen vermeiden, Internalia der jeweiligen Implementierungen preiszugeben.

    • LayerIn-Tests
      beziehen sich auf Eingabedaten der AGS-Software, welche als CAN-Bus-Signale von anderen ECUs an das EGS gesendet werden. Das Ziel ist zu prüfen, ob die untere (vom Zulieferer entwickelte) Softwareschicht des EGS, Signale korrekt aufnimmt, umrechnet und an die Applikationsschicht (AGS-Software) weiterleitet.
      (Anm.: Einige wenige Eingabedaten werden direkt von der unteren Softwareschicht gespeist: Die zugeordneten Testfälle werden anders generiert.)

    • LayerOut-Tests
      beziehen sich auf Ausgabedaten der AGS-Software, Berechnungsergebnisse. Dazu gehört die Empfehlung der AGS-Software hinsichtlich der Gangschaltung, welche von der unteren Software-Schicht umgesetzt wird.

    Der LayerIn-Test bildet den Schwerpunkt der Testaktivität. Wie beim Systemtest wird er mit Hilfe des ECUTT durchgeführt, mit einigen Besonderheiten:

    • System- und Modul- Tests werden manuell geschrieben und gepflegt - was aufwändig ist, da jede Änderung der Variablenbezeichnungen im AGS-Quelltext in den darauf zurückgreifenden ECUTT-Skripten nachgezogen werden muss.

    • Die LayerIn-Tests werden automatisch in zwei Schritten generiert (vgl. unveröffentlichte Fortbildungsunterlagen des Herstellers TraceTronic).

      1. Ein Muster-Testskript für das ECU-Testtool wird manuell erstellt, das den allgemeinen Rahmen bzw. das Schema des Testszenarios festlegt. 'Symbolische' Variablen werden manipuliert.

      2. Dieses Grundmuster wird an die Bedingungen der jeweiligen Schnittstellen bzw. der CAN-Bus-Signale verknüpft. Vereinfacht gesagt, alle 'symbolischen' Variablen werden durch 'reale' Variablen ersetzt. Dieser Mapping-Vorgang lässt sich gut automatisieren: Dies geschieht anhand eines Perl -Programms, das nötige Merkmale des zu testenden Signals aus einer Datenbank liest. Die Testfälle werden nach dem Black-Box-Verfahren entworfen: Grenzwert-Analyse, Äquivalenzklassen. Nur wenige Sonderfälle liegen außer Reichweite des Testgenerators.