Mehrstufiger Softwaretestprozess in der modellbasierten Funktionsentwicklung

Transkript

1 Mehrstufiger Softwaretestprozess in der modellbasierten Funktionsentwicklung Konrad Weber, Karl-Ludwig Krieger DaimlerChrysler AG Mercedesstraße Stuttgart Kurzfassung: Die Komplexität bei der Softwareentwicklung ist über die letzten Jahre enorm gewachsen. Des weiteren hat sich die Zusammenarbeit bei der Softwareentwicklung zwischen Fahrzeug-, Aggregate- und Steuergerätehersteller grundlegend gewandelt. An die Stelle der Entwicklung von Steuergeräten mit isolierten Funktionen ist eine Entwicklung von verteilten Funktionen in einem komplexen, ineinander wirkenden Steuergeräteverbund getreten, an dem unterschiedliche Partner bei der Funktionsentwicklung beteiligt sind. Aufgrund dieser Komplexität ist eine werkzeugtechnische, methodisch und prozedural aufeinander abgestimmte Entwicklungskette für die Funktions- und Softwareentwicklung als auch den Test unabdingbar. Neben einem Überblick zum Softwareentwicklungsprozess und zur eingesetzten Toolkette für die modellbasierte Funktionsentwicklung wird in diesem Beitrag ein mehrstufiger Testprozess zur Validierung der Teilmodule als auch des Gesamtmoduls näher erläutert und die Vor- und Nachteile aufgezeigt. 1 Einleitung In den letzten Jahren ist die Anzahl der neu realisierten und stark erweiterten Fahrzeugfunktionen fortwährend gestiegen. Ziel dieser Fahrzeugfunktionen ist zum einen, dem Kundenwunsch nach sicheren, komfortablen und kostengünstigen Nutzfahrzeugen gerecht zu werden und zum anderen sich aus Sicht des Nutzfahrzeugherstellers durch wettbewerbsdifferenziertes Fahrzeugverhalten am Markt auszuzeichnen. Eine Vielzahl dieser Fahrzeugfunktionen sind heute durch Softwarefunktionalitäten im Steuergerät bzw. Steuergeräteverbund realisiert.

2 Die in den Steuergeräten abgebildeten Funktionalitäten unterliegen einer ständig steigenden Komplexität. Dies ist darin begründet, dass einerseits die etablierten Steuergerätefunktionalitäten stark erweitert, andererseits vollständig neue Funktionalitäten im Zusammenspiel mit anderen Steuergeräten im Verbund realisiert werden. Durch letzteres ergeben sich zahlreiche Abhängigkeiten zwischen früher isolierten und abgegrenzten Steuergerätefunktionen, so dass heute ein komplexes Gesamtsystem mit verteilten Funktionen zu realisieren ist. Darüber hinaus ergibt sich durch die unterschiedlichen Bustopologien im Antriebsstrang von Nutzfahrzeugen in den verschiedenen Märkten der Welt die Notwendigkeit, Funktionen so zu gestalten, dass diese in unterschiedlichen Steuergerätetopologien lauffähig sind. Des weiteren ist die Softwareentwicklung für den automatisierten Antriebsstrang von Nutzfahrzeugen durch das zunehmend enge Entwicklungsgeflecht zwischen Steuergerätelieferanten, Aggregatelieferanten und Fahrzeugherstellern geprägt. Der Fahrzeughersteller bringt Funktionen ein, die das unmittelbare Fahrverhalten beeinflussen, wie z.b. die Festlegung der Schaltzeitpunkte des Getriebes. Der Aggregatelieferant bringt Funktionen ein, die beispielsweise die Aggregatelebensdauer bestimmen. Kernaufgaben des Steuergerätelieferanten werden zunehmend sein, die hardwarenahe Software wie Betriebssystem, Signalkonditionierung, etc. zu erstellen und die Integration aller Softwarekomponenten im Steuergerät sicherzustellen. Darüber hinaus zeichnet sich der Trend ab, dass wettbewerbsunkritische standardisierte Softwarekomponenten von Systemhäusern zum Einsatz kommen, wie beispielsweise CAN-Treiber oder Standarddiagnose. Die daraus resultierenden Entwicklungsgeflechte werden zunehmend komplexer, so dass für eine erfolgreiche Systementwicklung neben einer präzisen Definition von mechanischen und elektrischen Schnittstellen in besonderem Maße das Ineinanderwirken der Softwareschnittstellen spezifiziert werden muss. Dabei kommt dem Softwaretest eine Schlüsselrolle zu. Daher ist bereits in einer frühen Phase der Softwareentwicklung eine weitgehende werkzeugtechnische und methodische Unterstützung bei der Funktions- und Schnittstellenspezifikation erforderlich. Des weiteren besteht die Forderung, die Gesamtentwicklungszeiten möglichst kurz zu halten, was neben der Parallelisierung der Entwicklung der mechanischen und elektronischen Komponenten auch die Parallelisierung der Funktionsentwicklung innerhalb der einzelnen Steuergeräte erfordert. Um die Softwareentwicklung unter diesen Rahmenbedingungen zu beherrschen und wirtschaftlich zu gestalten, ist eine werkzeugtechnisch, methodisch und prozedural aufeinander abgestimmte Entwicklungskette notwendig [1, 2]. Im nachfolgenden wird ein Überblick zum Softwareentwicklungsprozess sowie zur eingesetzten Toolkette gegeben und anschließend näher auf den Testprozess eingegangen.

3 2 Softwareentwicklungsprozess gemäß V-Modell bei der modellbasierten Entwicklung Softwareentwicklungsprozess Der Softwareentwicklungsprozess ist ein Teilprozess des Systementwicklungsprozesses. Diese Prozesse stehen wiederum in Interaktion zur Aggregate-, zur E/E- und zur Triebstrangentwicklung des Fahrzeuges. Begleitet wird der Softwareentwicklungsprozess von Managementprozessen, wie beispielsweise dem Qualitätsmanagement, und den Supportprozessen, wie beispielsweise dem Versions- und Konfigurationsmanagement. Das an das V-Modell angelehnte Vorgehensmodell des Softwareentwicklungsprozesses ist in Abbildung 1 dargestellt [3, 4, 5]. Im Zuge der Gesamtentwicklung wird dieses V mehrfach durchlaufen, man spricht daher auch vom V-Zyklus. Die Schwerpunkte des V-Zyklus verschieben sich je nach Projektfortschritt. In der frühen Phase sind in erster Linie die Designaktivitäten bestimmend, hingegen sind es in der späten Phase des Projektes die Testaktivitäten. Abbildung 1: Vereinfachtes V-Vorgehensmodell [5]

4 Die heutige Entwicklung der Softwarefunktionalitäten für einen automatisierten Triebstrang in Nutzfahrzeugen erfolgt in enger Kooperation mit den Zulieferern und den Fahrzeugbereichen, wobei die Einbindungstiefe der jeweiligen Partner stark funktionsabhängig ist. Dies bedeutet, dass je nach Ausprägung der Entwicklungsaktivitäten des Partners eine jeweils spezifische Form des V-Modells zu realisieren ist. Der Fokus des Getriebebereiches bei der Funktionsentwicklung automatisierter Schaltsysteme in Nutzfahrzeugen liegt auf den Umfängen der Schaltablaufsteuerung, als auch den die Getriebelebensdauer bestimmenden Funktionen und der Gangwahlstrategie, die in enger Abstimmung mit den Fahrzeugbereichen realisiert wird. Dabei werden rein die funktionalen Anteile realisiert. Die Umfänge, wie beispielsweise die Signalaufbereitung und -plausibilisierung etc. liegen weiterhin in der Verantwortung des Systemlieferanten. Diese Teilfunktionalitäten werden als Bibliotheksfunktionen in die Gesamtsoftware integriert und kommunizieren über die als Strukturen definierten Schnittstellen mit dem übergeordneten Programm. Um die Softwareentwicklung bei diesem hohen Grad an Arbeitsteilung beherrschbar zu gestalten, ist ein aufeinander abgestimmter und verzahnter Entwicklungsprozess notwendig. In Abbildung 2 ist eine spezifische Ausprägung des V-Modells mit mehreren beteiligten Entwicklungspartnern dargestellt. Abbildung 2: Beispiel eines projektspezifischen V-Vorgehensmodells

5 Daraus wird schnell ersichtlich, dass eine klare Rollendefinition zwischen den Entwicklungspartnern notwendig ist. Im allgemeinen lassen sich aus den spezifischen Projektaufgaben schnell die Verantwortlichen für die einzelnen System- und Softwarekomponenten benennen. Dabei ist neben der Rollendefinition auch eine klare inhaltliche Aufgabenabgrenzung beim Softwaretest, bei der Softwareintegration als auch bei den entwicklungsbegleitenden softwarequalitätssichernden Maßnahmen notwendig. Wie im V-Modell gefordert, muss die Funktionalität (linker Ast) durch Reviews und Tests (rechter Ast) validiert werden. Toolkette Bei diesem engen Entwicklungsgeflecht zwischen Steuergerätelieferant, Aggregatelieferant und Fahrzeughersteller ist eine präzise Definition von Schnittstellen für eine erfolgreiche Systementwicklung unerlässlich. Daher ist bereits in einer frühen Phase der Softwareentwicklung eine weitgehende werkzeugtechnische und methodische Unterstützung bei der Funktions- und Schnittstellenspezifikation erforderlich. Dies war einer der Gründe, die modellbasierte Funktionsentwicklung auf Basis der Matlab-Produktfamilie in die Serienentwicklung einzuführen. Um die Konsistenz der erstellten Modelle zur Target-Implementierung von der Spezifikationsphase über alle Musterstände bis zur Serienfreigabe zu gewährleisten, wurde entschieden, die zu entwickelnden Modelle nicht nur zur modellbasierten Spezifikation und Funktionsabsicherung einzusetzen, sondern auch für die Target-Implementierung mit Hilfe eines Auto-Code-Generators heranzuziehen. Zielsetzung der modellbasierten Softwareentwicklung ist es, die Funktionalitäten ausgehend von einer ausführbaren Spezifikation über eine frühzeitige Absicherung der Funktionen mit Hilfe von Rapid Prototyping-Techniken im Fahrzeug bis hin zur Integration des automatisch generierten C-Codes im Steuergerät zu realisieren. Des weiteren sind geeignete Testumgebungen als auch Applikationswerkzeuge, die den gesamten Entwicklungsprozess durchgängig begleiten, notwendig. In Abbildung 3 sind die Ablaufkette der modellbasierten Entwicklungsmethodik und die dabei im Nutzfahrzeuggetriebebereich bei DaimlerChrysler eingesetzten Entwicklungswerkzeuge dargestellt [6].

6 Abbildung 3: Modellbasierte Entwicklungsmethodik und Toolkette 3 Vor- und Nachteil des Testprozesses bei der modellbasierten Softwareentwicklung Bei der klassischen Softwareentwicklung in der Programmiersprache C werden die Anforderungen aus der Spezifikation in ein Softwaredesign umgesetzt und anschließend die Funktionen implementiert. Die hardwarespezifischen Anforderungen können parallel oder anschließend implementiert werden. Somit existiert nur eine Implementierung, die getestet wird. Gemäß dem V-Modell erfolgen die Schritte Modultest, Integrationstest und Systemtest. Bei der modellbasierten Softwareentwicklung mit der oben vorgestellten Toolkette existiert ebenfalls nur eine Implementierung, da die hardwarespezifischen Anforderungen ebenfalls parallel oder anschließend zur Funktionalität implementiert werden. Jedoch kann durch die eingesetzten Entwicklungswerkzeuge eine getrennte Betrachtung und Test erfolgen. Durch diese Trennung ist es möglich, die Funktionalität in einem sehr frühen Stadium der Entwicklung zu validieren, ohne auf die Hardwareanforderungen Rücksicht nehmen zu müssen. Dadurch können bereits in einem sehr frühen Stadium der Entwicklung funktionale Fehler erkannt und korrigiert werden. Andererseits ist der Test unvollständig, wenn die Funktionalität validiert, jedoch die hardwarespezifische Umsetzung nicht getestet wurde. Daher ist ein weiterer Testschritt notwendig, bei dem auch die hardwarespezifischen Anforderungen berücksichtigt werden. Zur Absicherung der gewünschten Funktionalität nach der hardwarespezifischen Implementierung ist ein Vergleich der Testergebnisse erforderlich.

7 Der funktionale und implementierungsspezifische Test erfolgt zunächst auf Teilmodulund anschließend auf der Gesamtmodulebene. Im nachfolgenden wird die Vorgehensweise erläutert, wie sie bei der Funktionsentwicklung automatisierter Getriebeschaltsysteme in der Nutzfahrzeugentwicklung bei DaimlerChrysler eingesetzt wird. 4 Erweiterter Entwicklungsprozess mit mehrstufigem Test Der in den vorigen Abschnitten beschriebene Entwicklungsprozess bildet die Testschritte im einzelnen nicht ab. Daher ist eine Detaillierung des Entwicklungsprozesses in Hinblick auf Testabläufe notwendig, wie in Abbildung 4 gezeigt. Die einzelnen Tests sind dabei als parallel verlaufende Prozesspfade dargestellt. Der linke Pfad stellt die hardware-unabhängige Validierung der Funktionalität dar. Der rechte Pfad dient der Absicherung der hardwarespezifischen Belange. System- Anforderungen System- Anforderungen Systementwurf Systementwurf Fahrzeug- und Systemebene Freigabe Freigabe Erprobung Systemintegration Erprobung Systemintegration Applikation Applikation Anford. Anford. Fkt. Fkt. + SW + SW Anford. Anford. Fkt. Fkt. Fkts.- Modell + Sim Software-Ebene Software-Implementierung Software-Implementierung SiL-Test PoL-Test CiL-Test Design Design Systemtest Systemtest Integration Integration Modultest Modultest Modultest Modultest Impl.-Modell Code- + Sim. generierung MoL-Test Abbildung 4: Ausschnitt des detaillierten mehrstufigen Testprozesses im V-Modell Nach der Umsetzung der Funktionen beginnt der Test der Teilmodule durch einen sogenannten Model open Loop -Test (MoL), der vom Entwickler durchgeführt wird. Ziel dieses Tests ist die Überprüfung der geforderten Funktionalität mit vom Entwickler definierten Teststimulis.

8 Darüber hinaus wird mit Hilfe von sogenannten Grenzstimulis die Robustheit des Moduls abgesichert. Dabei wird das auf Matlab basierende Testwerkzeug MTest eingesetzt, das sowohl die Generierung der Testumgebung, als auch die Verwaltung der Testfälle und die automatische Erstellung der Dokumentation übernimmt. Um das Verhalten des Teilmoduls innerhalb des Gesamtmoduls, das wiederum ein Teil der Getriebesteuergerätesoftware ist, abzusichern, wird ein sogenannter Model in the Loop -Test (MiL) durchgeführt. Dazu wurde eine spezifische Simulationsumgebung in Matlab/Simulink erstellt, mit deren Hilfe und hinterlegten charakteristischen Testfällen das Verhalten des Moduls in the Loop analysiert werden kann (siehe Abbildung 5). Damit können insbesondere die Interaktionen zu anderen Teilmodulen frühzeitig getestet werden. Abbildung 5: Model in the Loop -Testumgebung Im nächsten Schritt werden nicht mehr die einzelnen Teilmodule betrachtet, sondern das Verhalten des Gesamtmoduls wird mit Hilfe eines Modulintegrationstests bewertet. Dieser Testschritt wird als Software in the Loop -Test (SiL) bezeichnet. Mit der gleichen Simulationsumgebung, wie beim MiL-Test, kann die Funktionalität des Gesamtmoduls mit charakteristischen Testfällen überprüft werden. Zur Absicherung der hardwarespezifischen Portierung werden im rechten Pfad des erweiterten Prozessmodells analoge Testschritte zu MoL und SiL durchgeführt. Beim Processor open Loop -Test (PoL) werden die Teilmodule auf einem Evaluationboard, das den Zielcontroller enthält, getestet. Dabei werden die gleichen Teststimulis wie beim MoL-Test verwendet. Die Ergebnisse der MoL- und PoL-Tests werden automatisiert verglichen und eventuelle Unterschiede sofort sichtbar.

9 Analog zum SiL-Test wird ein sogenannter Controler in the Loop -Test (CiL) für den Modulintegrationstest auf dem Evaluationboard durchgeführt. Da die Simulation nicht echtzeitfähig ist, wird der CiL-Test nicht in einem echten Loop durchgeführt. Vielmehr werden Teststimuli aus dem SiL-Tests für das Gesamtmodul generiert und als neue Teststimuli open Loop für den Test auf dem Evaluationboard verwendet. Die Testergebnisse werden mit den Ergebnissen des Gesamtmoduls aus dem SiL-Test verglichen. Damit ist die Integration der Teilmodule hin zum Gesamtmodul, das als Library an den Steuergerätehersteller geliefert wird, abgeschlossen. Es folgt die Integration in dem Getriebesteuergerät, die vom Lieferanten durchgeführt wird. 5 Anforderungen aus Sicht der Software-Qualitätssicherung Bei der Software-Qualitätssicherung denkt man primär an die erzeugten Softwareprodukte. Diese sollen den zentralen Forderungen nach Reproduzierbarkeit und Rückverfolgbarkeit genügen. Diese Forderungen gelten ebenso auch für die Ergebnisse des Testprozesses. Beim Einsatz von Versions- und Konfigurationswerkzeugen muss also darauf geachtet werden, dass alle Produkte des Workflows abgelegt werden. Abbildung 6: Statusmodell der Testschritte im Versions- und Konfigurationsmanagement Daneben ist aber entscheidend, dass der im Projekt festgelegte Workflow, der durch Tools zwar unterstützt wird, tatsächlich auch eingehalten wird. Nur so können die Forderungen nach Rückverfolgbarkeit und Reproduzierbarkeit gewährleistet werden. Hierzu wurde ein Statusmodell zur Steuerung und Überwachung der einzelnen Testschritte im Versions- und Konfigurationswerkzeug hinterlegt (siehe Abbildung 6).

10 6 Zusammenfassung und Ausblick Die vorgestellten Prozessschritte für den Modul- und Modulintegrationstest stellen eine Detaillierung des allgemeinen Softwareentwicklungsprozesses (V-Modells) dar. Durch die Trennung des Tests der Funktionalität von dem Test auf der Zielhardware entstehen Vorteile. Da die Testpfade voneinander unabhängig sind, ist eine parallele Testdurchführung möglich. Des weiteren können die einzelnen Testschritte von unterschiedlichen Personen als auch Projektpartnern durchgeführt werden. So kann jeder sein spezielles Wissen bei der Testdurchführung einbringen. Dadurch kann ein Beitrag zu der oft geforderte Verkürzung der Entwicklungszyklen geleistet werden. Da die Funktionalität bereits in einem sehr frühen Stadium eines V-Zyklus getestet wird, lassen sich die funktionalen Fehler frühzeitig feststellen und korrigieren. Entscheidender Vorteil ist, das sich mögliche Fehlerursachen beim nachfolgenden Test auf der Zielhardware weitestgehend auf die hardwarespezifische Portierung zurückführen lassen. Des weiteren hat sich die Vorgehensweise, die Teilmodule zunächst im open Loop hinsichtlich Funktion und Robustheit zu testen und anschließend das Zusammenspiel im Modulverbund im closed Loop zu überprüfen, in der Praxis bewährt. Die bisherigen Erfahrungen in einem Serienprojekt zeigen, dass durch die beschriebene Vorgehensweise beim Test frühzeitig funktionale als auch implementierungsspezifische Fehler aufgedeckt werden konnten und damit ein entscheidender Beitrag zur Produktqualität sowie zum Projekterfolg geleistet werden konnte. 7 Literaturverzeichnis [1] Achim Wohnhaas, Hans-Jürgen Habrock, Szenarien und Schritte bei der Einführung modellbasierter Methoden in der Kfz-Elektronikentwicklung, VDI-Fachtagung Elektronik im Kraftfahrzeug, 2000, Baden-Baden. [2] Klaus Lange, Jürgen Bortolazzi, et.al., Herstellerinitiative Software Kfz- Elektronikentwicklung, VDI-Fachtagung Elektronik im Kraftfahrzeug, 2000, Baden-Baden. [3] A.-P. Bröhl, W. Dörschel, Das V-Modell, R. Oldenburg Verlag München, Wien. [4] V-Modell-Browser, [5] J. Bortolazzi, S. Steinhauer, T. Weber, Entwicklung und Qualitätsmanagement von Steuergerätesoftware, VDI-Fachtagung Elektronik im Kraftfahrzeug, 2000, Baden- Baden. [6] K.-L. Krieger, W. Kok, S. Gast, F. Sager, Modellbasierte Softwareentwicklung für mechatronische Systeme am Beispiel automatisierter Schaltsysteme, 5. Internationales Stuttgarter Symposium Kraftfahrzeugwesen und Verbrennungsmotoren, 2003, Stuttgart.