Integrationstest ohne Hardware

Beschleunigter AUTOSAR-Entwicklungsprozess

AUTOSAR ist eine herstellerübergreifende Initiative mit dem Ziel, eine funktionsorientierte Methodik anzuwenden. EB tresos WinCore beschleunigt dabei den Entwicklungs-prozess, indem es den Funktionstest der AUTOSAR-Software zu einem frühen Zeitpunkt ermöglicht. Ohne Hardware lassen sich die hardware-unabhängigen Software-Kompo-nenten parametrieren, optimieren und testen. Durch die Vergleichsmöglichkeit bei vorhandener Hardware kann im Problemfall die Fehlerursache leicht eingegrenzt werden.

 

Vollbild

Bild 1. Topologie der Automotive Open System Architecture (AUTOSAR).

Schliessen

Bild 1. Topologie der Automotive Open System Architecture (AUTOSAR).

Die aktuelle Entwicklungsmethodik sieht vor, dass spätestens in der Integrationsphase auf einem realen Steuergerät getestet wird. In der Integrationsphase werden die Anwendungsfunktionen (Software-Komponenten) und die AUTOSAR-Basis-Software (BSW) miteinander integriert, das heißt, in dieser Phase ist es erstmalig möglich, das Zusammenspiel zwischen der AUTOSAR-Software und der eigentlichen Applikation zu testen (Bild 1).

Beispielsweise könnte eine Software-Komponente Daten über eine Steuergeräteschnittstelle versenden, z.B. über den CAN-Bus. Ob diese Daten nun wirklich auf dem CAN-Bus ankommen, hängt ab von der korrekten Funktion der Software-Komponente, der korrekten Konfiguration der AUTOSAR-Basis-Software sowie der fehlerfreien Integration dieser beiden Teile.

Beim Integrationstest wird überprüft, ob die Software-Komponente, also die Kundenfunktion, korrekt arbeitet und ob alle Parameter im AUTOSAR-Stack richtig konfiguriert wurden. Nur dann kommt die Nachricht korrekt an der Steuergeräteschnittstelle an. Um das zu gewährleisten, müssen die Software-Komponente richtig mit der Laufzeitumgebung (Run-Time Environment; RTE) verbunden sein und die darunterliegenden Schichten, z.B. der Kommunikations-Stack, der die Nachricht sendet, ebenfalls konsistent konfiguriert sein.

Der Test auf realer Hardware bringt allerdings einige Schwierigkeiten mit sich: Da Hardware- und Software-Entwicklung zumeist parallel verlaufen, wird man für erste Tests in der Regel zunächst mit einem Hardware-Prototyp arbeiten müssen, z.B. einem Evaluierungs-Board des Halbleiterherstellers. Es stellt sich die Frage, ob im Fehlerfall das Evaluierungs-Board falsch arbeitet oder ob ein Fehler im Software-Code ein Problem verursacht. Da sich Evaluierungs-Board und Steuergerät im Hardware-Aufbau unterscheiden, muss ein Teil der hardware-spezi-

fischen Konfiguration des AUTOSAR-Stacks doppelt vorgenommen werden: Zunächst für das Evaluierungs-Board und anschließend, wenn die ersten Prototypen des Steuergerätes verfügbar sind, erneut. Das kostet Zeit und ist fehleranfällig, da zwei unterschiedliche Konfigurationen parallel gepflegt werden müssen.

1. Teil: Beschleunigter AUTOSAR-Entwicklungsprozess
2. Teil: Korrekte Funktion des AUTOSAR-Stacks wird nachgewiesen
3. Teil: Vielfältige Debug- und Trace-Möglichkeiten
4. Teil: Die fehleranfällige Konfiguration von BSW-Modulen entfällt

Weiterführende Links:

• Tool-Kette für den richtigen Umgang mit Timing-Problemen: Zeit für AUTOSAR
• Entwicklung: Produktionsfreigabe von AUTOSAR-Basis-Software
• AUTOSAR leicht gemacht: Modellbasierte Entwicklung in einer AUTOSAR-Werkzeugkette
• Systementwurf: Mehr Funktion durch Echtzeitfähigkeit
• AUTOSAR in Serie: Praktischer Einsatz von AUTOSAR-Anwendungen
• Dritte Offene AUTOSAR-Konferenz in Frankfurt: AUTOSAR-Roll-out-Pläne der Core-Partner
• Vector Informatik: Betriebssystem für AUTOSAR und Multi-Core-Prozessoren
• Turnusmäßiger Wechsel: Neuer AUTOSAR-Sprecher
• Entwicklungspartnerschaft will Ausweitung: AUTOSAR auch für nicht-automotive Bereiche
• AUTOSAR in China: Die AUTOSAR-Werkzeuglandschaft im Reich der Mitte
• 3. Elektronik automotive congress: Software-Entwicklung mit AUTOSAR