Ohne modellbasiertes Testen lassen sich höchstkomplexe Autos nicht mehr sinnvoll realisieren.

Ohne modellbasiertes Testen lassen sich höchstkomplexe Autos nicht mehr sinnvoll realisieren. (Bild: Vector Informatik)

Ein großer Teil der Wertschöpfung entfällt in einem modernen Fahrzeug auf die Elektronik- und Softwaresysteme. Fehlfunktionen sind entsprechend risikoreich und insbesondere beim Einsatz in sicherheitskritischen Systemen nicht zu tolerieren. Seit vielen Jahren wird deshalb massiv in den automatisierten Test dieser Systeme investiert. Mit jeder neuen Technologie stellt sich damit auch die Frage nach der richtigen Testmethodik. Wichtig sind hier die Effektivität (ob und wie wir Testziele erreichen) sowie die Effizienz (die Optimierung von Kosten und Aufwand).

Ohne modellbasiertes Testen lassen sich höchstkomplexe Autos nicht mehr sinnvoll realisieren.

Ohne modellbasiertes Testen lassen sich höchstkomplexe Autos nicht mehr sinnvoll realisieren. Vector Informatik

Modellbasierendes Testdesign

Beim modellbasierenden Testen werden Testabläufe und -daten aus Modellen generiert. Diese Modelle können entweder die Steuergerätefunktion abbilden oder die Testfälle selbst modellieren. Ersterem, also dem Ableiten der Testfälle aus Funktionsmodellen, sollte man etwas kritisch gegenüberstehen. Wenn aus dem gleichen Modell sowohl die Generierung der Produktiv-Software als auch der entsprechenden Testfälle erfolgt, verspricht das große Effizienzgewinne, denn der Test fällt in der Entwicklung praktisch ohne Mehrkosten ab. Man sollte sich allerdings auch im Klaren sein, was in einer solchen Konstellation wirklich getestet wird – im Extremfall lediglich der Code-Generator gegen den Testfall-Generator. Außerdem enthält ein Funktionsmodell im Wesentlichen den Gut-Fall, beschreibt also, wie ein Gerät funktionieren soll. Die entsprechenden Betriebssituationen für den Test dieser Funktionen lassen sich aus diesem Modell noch gut ableiten. Schwer bis unmöglich ist es jedoch, aus dem Funktionsmodell auch die mannigfaltigen Fehlerfälle abzuleiten. Gerade diese machen allerdings den Test so wertvoll, denn die meisten Probleme ergeben sich nicht im „Geradeausfall“.

Die Testlösung von Vector arbeitet deshalb mit einem Testmodell. Das heißt, der Designer modelliert systematisch die Situationen, in denen das System-under-Test die korrekte Funktion beweisen muss. Eine grafische Testnotation ermöglicht dabei ein klares und übersichtliches Darstellen des abstrakten Testablaufs (Bild 1 und 2). Aus dieser Highlevel-Beschreibung werden die Testfälle generiert. Varianten sind im Diagramm sichtbar und werden bei der Testfallgenerierung berücksichtigt. Die Testmodelle verbinden Testspezifikation und -implementierung in einer abstrakten und leicht erfassbaren Weise. Dies erleichtert auch die häufig vernachlässigten Qualitätssicherungsmaßnahmen für die Tests selbst, beispielsweise die Reviews durch Entwickler. Abstraktion ermöglicht eine Nutzung derselben Testspezifikationen auf unterschiedlichen Testsystemen und die Wiederverwendung von einmal ausspezifizierten Tests; beides führt zu erheblichen Einsparungen.

HiL-Tests

Bild 1: Testabläufe werden in einer einfachen grafischen Notation modelliert.

Bild 1: Testabläufe werden in einer einfachen grafischen Notation modelliert. Vector Informatik

HiL-Tests (Hardware-in-the-Loop) gelten heute zu Recht als wichtiger Baustein beim Absichern der vollständig integrierten Steuergeräte. Dabei läuft das Steuergerät in einer simulierten Umgebung, die ihrerseits die Aktivitäten des Steuergeräts berücksichtigt. Das Steuergerät bildet mit dem Umgebungsmodell folglich eine geschlossene Schleife. Entsprechend aufwendig fallen oft das notwendige Umgebungsmodell und das echtzeitfähige Simulationssystem aus. Allerdings sind längst nicht alle Steuergeräte so komplex und als Regler ausgelegt wie die Motor- und Fahrdynamiksteuerungen, für die der HiL-Ansatz ursprünglich entwickelt wurde. Für den Test der meisten Steuergeräte im Fahrzeug – vom Außenlicht bis zum Fensterheber – reichen das Stimulieren der Eingänge und das Beobachten der entsprechenden Reaktionen an den Ausgängen völlig aus.

Bekanntlich sind Fehler umso günstiger zu beseitigen, je früher sie gefunden werden. Eine elaborierte Testautomatisierung, aufwendige Modelle und teure Testsysteme führen aber meist dazu, dass Tests erst spät im Entwicklungszyklus erfolgen. Erst in den explizit ausgewiesenen Testphasen stehen die benötigten Ressourcen ausreichend zur Verfügung. Wünschenswert wäre ein agiles Vorgehen schon während der Entwicklung, wo sich mit wenig Einsatz viel Qualität gewinnen lässt.

Auswahl der Testsysteme

Die Kunst bei der Auswahl der Testsysteme besteht letztlich darin, das richtige Maß an Tiefe, Aufwand und Nutzbarkeit zu finden. Vector bietet mit der Soft- und Hardware-Kombination CANoe und VT System ein Testsystem, das vom einfachen Prüfmittel am Entwicklerarbeitsplatz bis zur hochautomatisierten HiL-Umgebung im Testlabor skalierbar ist. Die Kernidee des VT System besteht darin, alle Hardwarefunktionen für das Testen von Steuergeräten in einem modularen und nahtlos in CANoe integrierten System zu vereinen. Die Testhardware legt sich wie eine Hülle um die Ein- und Ausgänge, inklusive Stromversorgung und Netzwerkanschlüsse eines Steuergerätes oder eines Teilsystems (Bild 3). An jedem Pin sind der Pin-Funktion entsprechend Stimulation, Messung, Lastsimulation, Fehleraufschaltung und die Umschaltung zwischen Simulation und Originalsensoren/-aktoren möglich. Diese Funktionen sind so universell ausgelegt, dass ein einmal aufgebautes Testsystem für unterschiedliche Steuergeräte verwendbar ist.

Bild 2a: vTESTstudio stellt verschiedene grafische Testnotationen für die Testmodellierung zur Verfügung.

Bild 2a: vTESTstudio stellt verschiedene grafische Testnotationen für die Testmodellierung zur Verfügung. Vector Informatik

In CANoe können Ingenieure mithilfe entsprechender Matlab/Simulink-Modelle neben der Netzwerkumgebung auch die physikalische Umgebung simulieren. Eine geschlossene HiL-Simulation ist genauso möglich wie eine einfache manuelle Stimulation ohne aufwendige Modelle. Die gleiche Flexibilität bietet CANoe bei der Testautomatisierung. Hier reicht die Palette der Möglichkeiten von den oben beschriebenen grafisch notierten Testmodellen über das Programmieren in verschiedenen Sprachen (CAPL, .NET/C#) bis zum Definieren einfacher Testabläufe in Tabellenform.

Mit der Software vTESTstudio steht dazu ein modernes Autoren-Werkzeug bereit. Auch das manuelle Durchführen von Tests über die grafische Oberfläche von CANoe und selbsterstellten Panels ist möglich. Entscheidend ist, dass für alle Phasen und Benutzergruppen wie Steuergeräte- und Softwareentwickler, Komponenten-, Steuergeräte- und Systemtester ein leistungsfähiges Testwerkzeug mit beherrschbarer Komplexität zur Verfügung steht. All diese Fälle setzen auf der gleichen Basis auf, allerdings in unterschiedlichen Ausbautiefen.

Virtualisierung und Software-in-the-Loop-Tests

Tests in virtuellen Umgebungen versprechen vor allem aus zwei Gründen ein enormes Einsparungspotential: Erstens sind Tests in der Realität sowie mit realen Steuergeräten, Teilsystemen und Fahrzeugen aufwendig, denn hierfür sind reale Prototypen nötig; dazu müssen alle Ein- und Ausgänge sowie physikalischen Effekte durch entsprechende Hardware stimuliert und gemessen werden. Zweitens besteht in virtuellen Welten die Möglichkeit, Systeme früher zu testen, weil Ingenieure weder auf die entsprechende Hardware noch auf die Integration der verschiedenen Komponenten warten müssen. Auch die besonders schwer reproduzierbaren und damit oft teuren Fehler in seltenen Situationen lassen sich mit realen Geräten oft schwer nachstellen. In der Virtualität gelingt dies jedoch problemlos.

Bild 2b: vTESTstudio stellt verschiedene grafische Testnotationen für die Testmodellierung zur Verfügung.

Bild 2b: vTESTstudio stellt verschiedene grafische Testnotationen für die Testmodellierung zur Verfügung. Vector Informatik

Häufig anzutreffen sind virtuelle Systeme, welche die Realität möglichst genau nachbilden. Auch Vector bietet zum Beispiel einen Steuergerätesimulator für Integrationstests von Softwarekomponenten (Autosar SWC) an, der sogar mit originalem Steuergeräte-Code arbeitet. Für andere Anwendungen wie etwa Systemtests empfiehlt sich aber ein modellbasierendes Vorgehen. Wenn es auf den Test der Funktionalität einer SWC ankommt, ist die Konfiguration eines kompletten Autosar-Stacks hinderlich. Hier sollte man auf einer höheren Abstraktionsebene arbeiten können, die zum Beispiel nur das Zeitverhalten des Datenaustauschs zwischen den Komponenten modelliert. Wie die Daten auf konkrete Netzwerke abgebildet werden, interessiert hier nicht. Die Konzentration auf die wesentlichen Aspekte reduziert die Komplexität und erhöht die Effizienz.

Ein anderer Aspekt betrifft die Variationsmöglichkeiten im Test. Was hilft eine möglichst realitätsnahe virtuelle Welt, wenn sich diese Realität immer wieder verändert, zum Beispiel durch den Einsatz einer neueren Basissoftware-Version? Für eine effektive Absicherung ist eine Umgebung, die sich in vielen Parametern variabel einstellen lässt, viel wertvoller. Dies führt zu robuster Software oder hilft im Fehlerfall, schwierige Konstellation sicher nachzustellen und zu identifizieren. Die Software vVIRTUALtarget pro von Vector nutzt diesen Ansatz.

Testen serviceorientierter Kommunikation

In der Automobilvernetzung und der Kommunikation zwischen Fahrzeug und Umgebung ist ein Wechsel zu einer serviceorientierten Kommunikation festzustellen. Treiber dafür war nicht zuletzt die Einführung von Ethernet im Fahrzeug und von OTA-Schnittstellen (Over-the-Air) zum Server-Backend. Dies stellt für die Testsysteme einen bedeutenden Paradigmenwechsel dar, auch wenn die Fahrzeugdiagnose schon lange serviceorientierte Protokolle verwendet. So lässt sich zum Beispiel eine einmal aufgezeichnete Kommunikation nicht einfach wieder ins System einspielen. Im Gegensatz zu signalorientierten Protokollen, die Signale meist durch eine einfache Folge von Botschaften übertragen, ist bei serviceorientierten Protokollen zumindest zum Anmelden von Services zwingend eine Interaktion zwischen Steuergerät und Testsystem notwendig.

Bild 3: Das VT System legt sich wie eine Hülle um das zu testende Steuergerät und bedient alle Ein- und Ausgänge.

Bild 3: Das VT System legt sich wie eine Hülle um das zu testende Steuergerät und bedient alle Ein- und Ausgänge. Vector Informatik

Die bisher verwendeten Fahrzeugsysteme sind statisch aufgebaut. Das heißt, die Kommunikationsstrukturen werden während der Entwicklung festgelegt und nicht mehr verändert. Serviceorientierte Architekturen bieten die Möglichkeit, Dienste dynamisch anzumelden und auf verschiedene Knoten im Netzwerk zu verteilen. Testsysteme müssen dieser Entwicklung Rechnung tragen. Allerdings sollte die Dynamik weder in den Testskripten programmiert werden müssen, noch die Komplexität der Protokolle für den Testersteller sichtbar werden. Mit parametrierbaren Interaction Layern und OEM-spezifischen Modulen für Transportprotokolle, Netzwerkmanagement und Ähnlichem stellt CANoe schon seit langem eine Basis für eine effiziente Simulations- und Testfallentwicklung in den bisherigen, signalorientierten Systemen zur Verfügung. Eine vergleichbare Abstraktionsschicht für die serviceorientierte Kommunikation ist ein wichtiger Teil des weiterentwickelten Konzepts der Vector-Werkzeuge.

Services

Mit diesem Konzept werden Services zum integralen Bestandteil der Simulations- und Testautomatisierungssprachen. Um das Abbilden der Services auf die Netzwerkebene, die verschiedenen Protokolle und die Übertragungsmechanismen kümmert sich das Werkzeug. Der Testautor kann sich so auf die relevanten Elemente konzentrieren: ein explizites und damit aufwendiges und fehleranfälliges Programmieren der Zwischenebenen ist nicht notwendig. Eingriffsmöglichkeiten auf den verschiedenen Ebenen sind trotzdem vorhanden, um für den Test zum Beispiel Fehler im Übertragungsverhalten provozieren zu können. Sind entsprechende Steuergeräte-Schnittstellen vorhanden, dann besteht auch die Möglichkeit, auf die Kommunikation auf Service-Ebene im Steuergerät zuzugreifen.

Softwaretest

Ein weiterer und teilweise mit serviceorientierten Architekturen zusammenhängender Paradigmenwechsel findet derzeit bei der ECU-Software statt. Steuergeräte sind bisher als Embedded-Systeme konzipiert, deren Firmware auf effizientes Verwenden der Hardware getrimmt ist, und die mit einer festen Funktionalität und als komplettes Programmkompilat auf die Geräte geflasht werden. Zukünftig werden viele Funktionen in zentralen Steuergeräten implementiert, die stark an klassischen IT-Systemen orientiert sind. Auf leistungsstarker Hardware arbeiten verschiedene Programme, die sich einzeln austauschen lassen, unter einem aufwendigeren Betriebssystem wie Linux zusammen. Diese Zentralsteuergeräte dienen dabei im Wesentlichen als Rechenknoten, auf denen ein großer Teil der Software läuft. Das Ansteuern der Peripherie, sehr zeitkritische Routinen und vermutlich auch viele sicherheitskritische Funktionen werden nach wie vor die klassischen Steuergeräte übernehmen. Autosar standardisiert beide Systeme und unterteilt sie in Autosar classic und das neue Autosar adaptive, das sich allerdings noch in der Entwicklung befindet.

Eck-daten

Beim modellbasierenden Testen werden Tests aus abstrakten, überschaubaren und wiederverwendbaren grafischen Testmodellen erzeugt. Die richtige Wahl von Abstraktion und Testtiefe ist für den effizienten Einsatz von HiL-Tests von großer Bedeutung. Für den Test serviceorientierter Architekturen sind Tests in virtuellen Umgebungen erfolgsversprechend.

Diese für den Automobilmarkt neuen Software-Ansätze werfen für die Testsysteme und insbesondere die Testmethodik viele Fragen auf. Wie kann ich die Qualität eines Steuergeräts sicherstellen, dessen Software sich über die Lebenszeit aus verschiedenen Programmen zusammensetzt? Der Fokus wird sich in Zukunft vom Gesamtsystem aus Steuergerätehardware und -software auf die einzelnen Softwarefunktionen verlagern. Wo die Ausführung dieser Software erfolgt, wird eine untergeordnete Rolle spielen. Tests werden daher vielfach dort stattfinden, wo die Software gut zu beobachten ist, also in virtuellen Umgebungen.

Dr. Stefan Krauß

(Bild: Vector Informatik)
ist bei Vector Informatik in Stuttgart als Global Product Line Manager für die Produktlinie Networks and Distributed Systems verantwortlich.

(av)

Sie möchten gerne weiterlesen?

Unternehmen

Vector Informatik GmbH

Ingersheimer Str. 24
70499 Stuttgart
Germany