Hardware-unabhängig testen

AUTOSAR ist aus der Automobilindustrie nicht mehr wegzudenken. In nahezu allen Vorentwicklungs-Abteilungen findet man Projekte, welche die Einführung von AUTOSAR vorbereiten sollen. Es werden Werkzeuge ausprobiert, Konzepte erprobt und verglichen und Migrationswege empfohlen. Oft fehlt jedoch das Verständnis, wie weit man die internen Entwicklungsprozesse verändern müsste, um die AUTOSAR-Vorteile tatsächlich spürbar zu machen.

AUTOSAR ist aus der Automobilindustrie nicht mehr wegzudenken. In nahezu allen Vorentwicklungs-Abteilungen findet man Projekte, welche die Einführung von AUTOSAR vorbereiten sollen. Es werden Werkzeuge ausprobiert, Konzepte erprobt und verglichen und Migrationswege empfohlen. Oft fehlt jedoch das Verständnis, wie weit man die internen Entwicklungsprozesse verändern müsste, um die AUTOSAR-Vorteile tatsächlich spürbar zu machen.

Ein wesentlicher Aspekt des AUTOSAR-Standards ist die Hardware-Unabhängigkeit der Applikations-Software. Diese Unabhängigkeit erlaubt die Entkopplung der Hardware- von der Software-Entwicklung und ermöglicht es, Entscheidungen bezüglich der System-Topologie und der Abbildung auf die Ziel-Hardware später im Entwicklungsprozess zu treffen.

Betrachtet man die heutige E/E-Entwicklung, so findet man immer eine Matrix aus Funktions- und Komponenten-Entwicklung. Früher einfache Funktionen werden durch die immer stärker auftauchende Verteilung im System schwieriger zu beherrschen. Die Notwendigkeit zur Kommunikation und Abstimmung zwischen den Entwicklern wächst, weil immer mehr Komponenten von einzelnen Funktionen betroffen sind und umgekehrt immer mehr Teil-Funktionen auf einer einzelnen Komponente implementiert werden. Einheitliche Wege der Spezifikation, wie AUTOSAR sie vorschlägt, helfen hierbei, Missverständlichkeiten auszuräumen. Gerade die Vermehrung der technischen Freiheitsgrade trägt dazu bei, dass der einzelne Entwickler mehr Zeit für die Funktions-Entwicklung aufwenden kann, anstatt sich mit Abstimmungsprozessen zu beschäftigen.

Doch bedeutet das alles für den Software-Entwickler, der eine AUTOSAR-Applikation entwickelt und die Vorteile von AUTOSAR nutzen möchte? Die Hardware-Unabhängigkeit der Applikation verheißt, dass er keine Hardware zum Testen braucht, dass Kenntnisse über Hardware-Treiber unnötig sind und dass die Verteilung der Applikation auf die Steuergeräte für den Funktions-Entwickler irrelevant ist.

Durch die Standardisierung der Spezifikation hat der Software-Entwickler den Vorteil, dass die Schnittstellen-Beschreibungen der benachbarten Funktionen maschinenlesbar in eindeutiger Form vorliegen können. Auch er selbst muss die eigenen Schnittstellen in dieser Form festhalten. Daraus ergeben sich die Anforderungen an eine neuartige Test-Umgebung für in der Entwicklung befindliche Applikationen.

Drei Test-Stufen

Stufe 1, Überwachung der Spezifikation: Mehrdeutige, widersprüchliche und inkonsistente Spezifikationen sorgen seit Beginn der Software-Entwicklung für Probleme. Durch den erheblichen Aufwand, der in das AUTOSAR-Meta-model geflossen ist, können nun komplette Systeme oder auch Teile davon konsistent beschrieben werden. Der Vorteil ist, dass man Werkzeuge bauen kann, die diese Spezifikationen lesen und zu einem gewissen Teil auch verstehen können. Dadurch wird eine werkzeuggestützte Prüfung möglich, die über eine einfache Form-Überwachung hinausgeht: Referenzierung aller Komponenten, Spezifizierung aller Schnittstellen, Einhalten der Timing-Vorgaben.

Stufe 2, Konsistenz zwischen Spezifikation und Software: Eine saubere Spezifikation ist Grundlage für funktionierende Software. Aber selbst bei einer ausgezeichneten Spezifikation kann die Software immer noch erhebliche Mängel aufweisen. Eine Methode, dies zu minimieren, ist die automatische Prüfung, ob die Software tatsächlich der Spezifikation entspricht. Die maschinenlesbare Spezifikation erlaubt es, alle externen und internen Schnittstellen der Software auf Übereinstimmung mit der tatsächlichen Implementierung zu prüfen. Fehler, die bei heutigen Entwicklungsprozessen möglicherweise erst während der Integration beim OEM gefunden werden, können nun schon in der Entwicklungsabteilung beim Zulieferer entdeckt und behoben werden.

Stufe 3, Zeitnaher Test von verteilten Funktionen: Schon heute können Software-in-the Loop- und Model-in-the-Loop-Umgebungen genutzt werden, um sich ein Bild von der Qualität und der Robustheit der Software zu machen. Doch gerade bei verteilten Funktionen bleibt dabei ein kritischer Test auf der Strecke: Das Zusammenspiel der aus dem Source-Code compilierten und gebundenen Software, die auf unterschiedlichen Steuergeräten im Fahrzeug laufen wird. Mit Simulationsumgebungen, die auf detaillierten Verhaltensmodellen basieren, kann ein Test der tatsächlichen Software nicht überflüssig gemacht werden. Zur Vermeidung einer falschen Zuversicht sollte jedes einzelne Zwischenergebnis im Entwicklungsprozess geprüft werden — wenn möglich automatisiert und in kurzen Abständen. Der Entwickler benötigt also eine Test-Umgebung, die in der Lage ist, auch verteilte Funktionen im Verbund auszuführen. Zusätzlich sollten mehrere Funktionen nebeneinander geprüft werden können, um die gegenseitige Einflussnahme zu beobachten.

Die Umsetzung dieser drei Test-Anforderungen bedeutet, dass viele frühe Fehlerquellen im Entwicklungsprozess eine Prüfmethode an die Seite gestellt bekommen, die schnell und zuverlässig die entstehenden Fehler findet und so die Kosten dieser Fehler auf ein Minimum reduziert. Die im klassischen Test-Prozess-Design geforderte Isolierung von Fehler-Klassen in einzelnen Test-Phasen wird durch die mögliche Automatisierung der Prüfungen realistisch. Man braucht sich also in einer späten Test-Umgebung nicht mehr mit einer Vielzahl von Fehler-Klassen herumzuschlagen, etwa mit Schnittstellen-Inkonsistenzen, algorithmischen Fehlern, falschen Adressierungen, Timing-Problemen oder Netzwerk-Fehlern, sondern kann sich auf die Fehler beschränken, die durch die neue Test-Phase erst möglich werden.

zurück zur Übersicht

Kurz vor Veröffentlichung von AUTOSAR 2.0 wurde bei TietoEnator (www.tietoenator.com) mit den Entwicklungs-Arbeiten an der AUTOSAR-Test-Factory (ATF) begonnen. Diese Test-Umgebung implementiert die beschriebenen Test-Anforderungen: Überwachung der Spezifikation, Vergleich der Spezifikation mit der Implementierung und ständige Kontrolle des Verhaltens der Software.

Entsprechend dem AUTOSAR-Standard findet der Software-Entwurf hardwareunabhängig statt: Die Software-Komponenten kommunizieren rein virtuell über den „Virtual Function Bus“ (VFB) miteinander (Bild 1). Hierbei ist der physikalische Weg der Signale für die Applikationskomponenten nebensächlich. Lediglich zeitliche Rahmenbedingungen können den Signalen mitgegeben werden, was Einschränkungen für die Verteilung im System bedeuten kann. Die PC-basierte AUTOSAR-Test-Factory ist eine Nachbildung des VFB. Die Software-Komponenten setzen auf einer Umgebung auf, die den Signalfluss kennt und so alle Software-Komponenten miteinander verbindet. Bei der Aktivierung eines Test-Projekts werden zunächst zwei statische Tests durchgeführt, welche die Implementierung der beiden ersten Test-Anforderungen darstellen. Anschließend wird die Software auf verhaltenstechnische Korrektheit getestet. Hierbei spielt es keine Rolle, auf wie viele Steuergeräten die Software letztlich im Gesamtsystem verteilt wird, die ATF simuliert die Kommunikation auf dem VFB (Bild 2).

Bei genauer Betrachtung wird klar, dass die ATF kein Allheilmittel der Software-Entwicklung darstellt. Die Fehlerklassen können nicht alle durch die ATF adressiert werden. Beim Aufbau von Test-Hardware werden auch künftig umfangreiche Tests durchzuführen sein. Doch Fehler, die ihre Ursache allein in der Applikationsentwicklung haben, werden durch die ATF gefunden und können so spätere Entwicklungs-Phasen nicht mehr stören. Die resultierende Verkürzung der Entwicklungszeit beruht dabei hauptsächlich auf der kürzeren Zeit zwischen Fehlerentstehung und -erkennung.

Nach Erfahrungen von TietoEnator hat die konsequente Umsetzung Hardware-unabhängigen Entwicklung von Applikations-Software das Potential, die Dauer der Test-Aktivitäten um mehr als 50 Prozent zu reduzieren. Die Aufwendungen für Test-Hardware können sogar um mehr als 70 Prozent reduziert werden.

Nutzungs-Szenarien

Die AUTOSAR-Test-Factory ist kein AUTOSAR-Authoring-Tool. Vielmehr ist eine nahtlose Kopplung eines solchen Werkzeugs mit der ATF vorstellbar, um die Konsistenz mit Nachbarsystemen im Fahrzeug kontinuierlich sicherzustellen. So kann die Software-Entwicklungsabteilung eines Zulieferers eine Instanz der ATF betreiben, um die Gesamtheit der eigenen Software regelmäßig gegen die Software-Spezifikation des Herstellers zu prüfen. Der Verbund-Test aller in Entwicklung befindlicher Komponenten könnte Teil des täglichen Build-Prozesses sein. Der Zulieferer kann so sicher sein, dass seine Lieferung tatsächlich dem entspricht, was spezifiziert wurde. Der Hersteller kann gleichzeitig eine oder mehrere Instanzen der ATF betreiben, um die gelieferte Software zu überwachen.

Riediger/Stephan Janouch, Elektronik automotive