Schnelle Bereitstellung von Softwarefunktionen

Moderne Fahrzeuge sind komplexe Systeme, die von sich weiterentwickelnden Softwarefunktionen und vernetzten Architekturen bestimmt werden. Kürzere Entwicklungszyklen und steigender Kostendruck machen neue Ansätze für die Bereitstellung sicherer und erschwinglicher Mobilitätslösungen erforderlich. In diesem Artikel wird das Thema durch die Verschmelzung bekannter Techniken der Informatik mit hochmodernen Methoden der Maschinen- und Elektrotechnik angegangen: Die Systementwicklung erfolgt konsequent in vier Schichten, während gleichzeitig agile Effizienz beibehalten wird. Modellbasierte Anforderungen ersetzen schriftlichen Text. Dieser Ansatz ermöglicht zusätzlich zur Kostensenkung durch pflegbare und wiederverwendbare Dokumentation die teilautomatisierte Ableitung von Testfällen und reduziert so den Prüfaufwand. Die Effizienz- und Qualitätsziele für die Entwicklung von BMWs elektrifizierten Antriebsstrang der nächsten Generation können erreicht werden. So können die Ziele in den Bereichen Kosten, Qualität und Anpassbarkeit gleichzeitig erfüllt werden.

Evolution der System- und Software-Geschäftsmodelle

Der Entwicklung von Automobilsystemen stehen auf der einen Seite widersprüchliche Anforderungen und auf der anderen Seite Marktbedingungen gegenüber. Kunden fordern eine schnellere Reaktion der Produktentwicklung auf neue technische Trends. Dies führt zu kürzeren Markteinführungszeiten, die von durchschnittlich fünf Jahren in den 1980er Jahren auf drei Jahre im 21. Jahrhundert gefallen sind [1]. Werden Aufwertungen und Modellpflege in die Betrachtung miteinbezogen, fällt diese Zahl sogar auf ein Niveau von ein bis zwei Jahren. Kunden wollen mit jedem Systemupgrade mehr Funktionen zu einem vergleichbaren Preis sehen. Wird die Inflation berücksichtigt, macht dies eine Kostensenkung von vier Prozent pro Jahr erforderlich, was verfügbare Entwicklungsbudgets auf beständig niedrigere Niveaus drückt [2].
Eine Fokussierung auf Kosteneffizienz kann aber den zu schließenden Kompromiss nicht umgehen: Individuelle mechanisch angetriebene Fahrzeuge werden durch integrierte Mobilitätssysteme abgelöst, die den elektrifizierten Antriebsstrang, fahrzeugweite Funktionen, Benutzererfahrungen und vielfältige Verkehrsszenarien umfassen. Die Integration wird mittels komplexer Softwaresysteme umgesetzt. Werden diese Systeme mit den gleichen Methoden und Prozessen wie in den letzten Jahrzehnten entwickelt, steigt der Verifizierungs- und Validierungsaufwand sprunghaft an. So führt beispielsweise die Migration von einer modernen adaptiven Geschwindigkeitsregelungsfunktion zu einem Autopiloten zu einer Steigerung des Validierungsaufwands um einen Faktor von 100.000 [3]. Prüfaufwand und Prototypfahrzeuge und damit auch Validierungskosten sprengen die erwähnten Budgetgrenzen. Infolgedessen wird die Qualitätssicherung risikobasiert durchgeführt.
Dadurch haben eingegangene Risiken zu einem sprunghaften Anstieg der Software-Rückrufe in den letzten zehn Jahren geführt [4]. Um die richtigen Gegenmaßnahmen ergreifen zu können, müssen die Schwachstellen in der aktuellen Systementwicklung analysiert werden (Abbildung 1). Zu Beginn der Entwicklung neuer Funktionen gestaltet sich die vollständige Top-down-Definition der Systemanforderungen und -architektur schwierig – in der Regel werden sie während Prototypsitzungen mit einem Bottom-up-Ansatz zur Identifizierung eines gewünschten Verhaltens ausgearbeitet. Es fehlen jedoch Beschreibungsmethoden, um alle im System aufzunehmenden Aspekte für alle späteren Phasen zweifelsfrei zu dokumentieren. Folglich wird die gesamte Systemarchitektur unvollständig beschrieben und ist somit nicht haltbar. Eine unvollständige oder sogar fehlende Systemarchitektur führt natürlich zu schwachen Anforderungen auf Systemebene. Es müssen Bottom-up-Anforderungen auf Funktionsebene ohne Berücksichtigung konsistenter Systemschnittstellen definiert werden. Das zieht mehrere Abstimmungsschleifen für die Anforderungen sowie eine frühzeitige Verzögerung von Projektmeilensteinen nach sich. Dadurch werden Einheitstests auf Softwareebene ohne konsistente System- und Funktionsanforderungen festgelegt, was zu zusätzlichen, durch Objektcode-Diskrepanzen verursachten Integrationsschleifen führt. Die Testfälle sind auf Komponentenebene nicht vollständig, was ähnliche Integrationsprobleme auf Fahrzeugebene verursacht. Diese werden durch die Verwendung großer Fahrzeugflotten mit intensiver Personalbeteiligung gemindert: Die Fehlererkennungszeit steigt durch nur auf System­ebene stattfindende Fehlererkennung an; Kostenbegrenzungen machen eine Priorisierung von Testmanövern erforderlich.

Modellbasierte System­entwicklung auf Grundlage der Softwareentwicklung

Eine Hauptstrategie zur Behebung der erwähnten Konflikte zwischen Markteinführungszeit, Kostensenkungen, auftretenden Qualitätsproblemen und der gestiegenen Validierungszeit auf Fahrzeugebene ist das Frontloading. Das heißt, dass die Anstrengungen in frühen Entwicklungsschritten wie Anforderungsentwicklung, Funktions- und Architekturdesign gesteigert werden müssen [5]. Frontloading ist genau genommen keine neue Idee und soll die Aufwandsreduzierung für die kostenaufwändigen Verifizierungs- und Validierungsaufgaben auf HiL(Hardware in the Loop)- oder Fahrzeugebene unterstützen. Zahlreiche Normen wie ISO/IATF 16949 und ISO 26262 empfehlen das Frontloading. Es kann allerdings nicht einfach angewendet werden, da es einen interdisziplinären Ansatz verlangt, bei dem Methoden von bekannten Techniken aus der Maschinen- und Elektrotechnik sowie Ansätze aus der Informatik kombiniert werden. Die modellbasierte Systementwicklung konzentriert sich auf eine sich beständig weiterentwickelnde, auf Modellen basierende Architektur- und Anforderungsentwicklung [6, 7, 8, 9]. Auch wenn eine systematische und semiformelle Darstellung von Anforderungen in einem ersten Schritt aufwändiger ist, zeigt die Erfahrung aus großen Softwareprojekten eine gesteigerte Produktqualität. Die bessere Qualität der aus Frontloading-Aktivitäten resultierenden Dokumente reduziert die Folgekosten für Validierungen erheblich. Qualitativ hochwertige Modelle senken den Kommunikationsaufwand, die Inkonsistenzen zwischen Anforderungen und die Anzahl an Defekten und Fehlern, die sonst erst in späteren Verifizierungsstufen entdeckt werden würden. Im Zusammenhang mit großen Teams, interdisziplinärem Austausch und Kooperationen mit externen Partnern und internen Abteilungen (alles im Automobilbereich übliche Aspekte) ist eine einfachere Kommunikation besonders wichtig. Die „System Modeling Language“ (SysML, System-Modellierungssprache) ist aus der in den 1990er Jahren eingeführten Unified Modeling Language (UML, vereinheitlichte Modellierungssprache) [10, 11] abgeleitet. Sie stellt eine große Zahl von Struktur- und Verhaltensdiagramm-Sprachen zur Spezifizierung von Systemen aus unterschiedlichen Perspektiven auf unterschiedlichen Abstraktionsniveaus bereit, jedoch keinen konkreten Prozess oder detaillierte Richtlinien dafür, welche Diagrammarten in welcher Reihenfolge oder für welche Abstraktionsniveaus verwendet werden sollten. BMW hat einen EAST-ADL [12] ähnlichen modellbasierten Systementwicklungsansatz namens SMArDT („Specification Method for Architecture, Design and Test“, Spezifikationsmethode für Architektur, Entwicklung und Tests) mit vier Ebenen vorgeschlagen: Anforderungs-, Funktionsdesign-, Architektur- und Hardware- bzw. Softwaredesign-Ebene (EAST-ADL: Fahrzeug-, Analyse-, Design- und Implementierungsebene), siehe Abbildung 2.

SMArDT kombiniert einen systematischen vertikalen Verfeinerungsansatz von Schicht zu Schicht mit einer horizontalen hierarchischen Zusammensetzung von dem gesamten Motor hin zu spezifischen Modulen. Zusätzliche Anforderungen werden von Schicht zu Schicht identifiziert und – wo angemessen – von Anforderungen höherer Ebenen abgeleitet, um eine vollständige Nachverfolgung (wie von Normen wie CMMI oder ISO 26262 gefordert) zu etablieren [13, 14]. Eine erste Trennung zwischen Hardware- und Software-Aspekten wird auf der technischen Ebene durchgeführt, diese werden dann auf der vierten Ebene implementiert.
SMArDT unterstützt aufgrund der vier Abstraktionsschichten eine systematische, schrittweise, modellbasierte Anforderungs- und Funktionsspezifikation [15, 16]. Folglich werden die bereitgestellten Anforderungen und Konzepte auf allen Ebenen neu beurteilt und beschrieben, was – im Hinblick auf das Frontloading – eine äußerst frühzeitige Verifizierung und Validierung der laufenden Aktivitäten gewährleistet. Natürlich sind diese Schritte relativ zeitaufwändig, bieten jedoch auch qualitativ hochwertige Artefakte, die zur erheblichen Beschleunigung des gesamten Entwicklungsprozesses verwendet werden können. Die erwähnten Abstraktions­schichten werden für die strukturierte Dokumentation angewendet, wobei der angewandte Prozess agil sein soll [17].
Im Zusammenhang dieses Artikels betrachten wir eine der verschiedenen neuen Möglichkeiten, die durch eine qualitativ hochwertige Reihe semiformeller Modelle bereitgestellt werden: die halbautomatische Erstellung von Testfällen [18, 19].

Halbautomatische Erstellung von Testfällen

Die durch Aktivitäts-, Zustands- und interne Blockdiagramme in der zweiten Schicht umgesetzten Funktionsmodelle stellen bereits ausreichend Informationen zur automatischen Erstellung von Testfällen für Verifizierungszwecke bereit.
Abbildung 3 illustriert einen entsprechenden Prozess. Aktivitäts- und Statusdiagramme werden während der Funktionsspezifikation auf Basis von in der ersten Schicht definierten Kundenmodellen wie Anwendungsfällen und Kontextdiagrammen definiert.

Diese Funktionsmodelle werden von Spezifizierer und Prüfer gemeinsam definiert, damit auch Funktionsaspekte wie die richtige Fehlerbehandlung enthalten sind. Ausgehend von diesen Modellen aus der Funktionsschicht können Testfälle automatisch zur Erfüllung der Pfadüberdeckungskriterien C2c erstellt werden [20]. Zusätzlich kann der Prüfer bestimmte Aspekte des Modells, wie spezifische Eingabeparameter oder Entscheidungen, konfigurieren, um die Testfallerstellung für kontextbezogene Bedürfnisse anzupassen.
In Abbildung 4 werden Beispiele für Aktivitätsdiagramme, die zur Erstellung von Testfällen verwendet werden, gezeigt.

Unterschiedliche Aktivitäten oder Entscheidungsknoten können zur Anpassung der Testfallerstellung für bestimmte Bedürfnisse (zum Beispiel Ausführzeit/Kosten für Testschritt, Anforderungen, Entscheidungsüberdeckung) klassifiziert werden. Da das Aktivitäts- und interne Blockdiagramm der Funktionsschicht Verfeinerungen des Anwendungsfalls und der Kontextdiagramme der Kundenwert-Schicht (siehe Abbildung 2) sind und das Aktivitätsdiagramm auf der mit dem Blockdiagramm beschriebenen Funktionsarchitektur basiert, repräsentieren die erstellten Testfälle alle in beiden Schichten definierten Aspekte. Zur Erstellung von Testfällen aus Aktivitäts- oder Zustandsdiagrammen ist neben der richtigen Verwendung der SysML-Sprache die eindeutige Definition erwarteter Ergebnisse auf abstrakter Ebene erforderlich. Während das bei Zustandsdiagrammen üblich ist, wurden die Aktivitätsdiagrammformulierungen zur Erfüllung dieser Bedürfnisse angepasst. Außer diesen technischen Anforderungen sind qualitativ hochwertige, semiformelle Modelle, die eine abstrakte aber klare Funktionsbeschreibung darstellen, zur Erstellung von Testfällen erforderlich, die zur Verifizierung eines Systems anhand von definierten Anforderungen verwendet werden können. Diese Modelle werden durch die von SMArDT zur Verfügung gestellten Prozesse und Richtlinien bereitgestellt. Während der Systemanforderungs- und Funktionsspezifikationsphase werden Kennzeichnungen aus einer Schlüsselwort-Datenbank zur Definition von Schnittstellen und Bedingungen wiederverwendet. Diese Schlüsselwörter werden konkreten, plattformspezifischen Signalen und deren spezifischer Testausführung zugeordnet. Während der Implementierung im Datenlexikon wird für jedes Schlüsselwort (und die zugehörigen Signale) eine konkrete Testsequenz zur automatischen Durchführung der Initialisierung und Beurteilung implementiert.
Wird die Zuordnung zwischen Schlüsselwort- und Signaldatenbank (und ihre Testimplementierung) mit der halbautomatischen Erstellung von Testfällen kombiniert, wird der Aufwand für die Definition, Einrichtung und Ausführung von Verifizierungstests erheblich reduziert.
Darüber hinaus können die erstellten Testfälle aufgrund der Neutralität der Kunden- und Funktionsmodelle für verschiedene Plattformen wiederverwendet werden.

Anwendung: Projekt „MTSF“

SMArDT und der Ansatz für die halbautomatische Erstellung von Testfällen werden derzeit in einem laufenden Serienentwicklungsprojekt zur Definition von BMWs neuer Generation elektrischer Antriebe verwendet. In Zusammenarbeit mit der FEV Europe GmbH und dem Lehrstuhl für Informatik der Rheinisch-Westfälischen Technischen Hochschule (RWTH) Aachen wurden zusätzliche Modellierungsrichtlinien für Funktionsmodelle ermittelt, um eine halbautomatische Erstellung von Testfällen zu ermöglichen, was als „Model-based Testing of Software-based Functions“ (MTSF, modellbasiertes Testen softwarebasierter Funktionen) bezeichnet wird.
Der Aufwand wurde zur Beurteilung, ob die vorgeschlagenen Erwartungen erfüllt werden, im Verlauf der Entwicklung systematisch überwacht. In Abbildung 4 ist eine erste Beurteilung verschiedenen Funktionen dargestellt, die den zusätzlichen Aufwand zur Ableitung von Testfällen auf Funktionsspezifikationsebene für den Spezifizierer und Tester herausstellt. Entsprechend der Komplexität der Funktion nehmen sowohl der Aufwand als auch die Zahl der erstellten Testfälle zu.
Bei Funktion A handelt es sich um die erste gemessene Funktion, einschließlich Diagnose- und Sicherheitsaspekten, die die zusätzlichen Vorteile in diesen Bereichen hervorhebt. Da eine pfadbasierte Testfallerstellung logische Verzweigungen zur Steigerung der Testfallanzahl benötigt, erhöhen Mechanismen zur Fehlererkennung und -behandlung das Potenzial für eine automatische Testfallerstellung erheblich.
Im Hinblick auf den gemessenen Aufwand muss berücksichtigt werden, dass die zusätzlichen Richtlinien für die Testfallerstellung zum ersten Mal in einem ernsthaften Entwicklungskontext angewendet wurden. Daher dürfte mit einem Rückgang des Aufwands gerechnet werden, sobald der Ansatz etabliert ist. Dank der semiformellen Natur der eingeführten Richtlinien kann daher nicht nur der Aufwand reduziert, sondern auch die Modellqualität gesteigert werden. Wird der gemessene Aufwand mit der laufenden, traditionellen Entwicklung verglichen, können die Erwartungen bereits als erreicht betrachtet werden, da der reduzierte Aufwand für Anforderungsauslegung und Verifizierungsaufgaben den zusätzlichen Aufwand auf Funktionsspezifikationsebene bereits ausgleicht; siehe Abbildung 5.

Ausgehend von den aktuellen Erfahrungen wurden bereits weitere Verbesserungen bei der Testerstellungskonfiguration zur weiteren Steigerung der Qualität der resultierenden Testfälle ermittelt. Der Gesamtprozess wird durch eine integrierte Toolchain. Zur Aufrechterhaltung der fortgesetzten Industrialisierung wird eine reibungslose Verbindung zwischen den Tools DOORS, PTC, ECU Test und HPQC eingerichtet.

Zusammenfassung und Ausblick

Der MTSF-Ansatz für die Systementwicklung geht die gegenwärtige Konfliktlage zwischen der Definition von soliden Anforderungen, Testfällen und Architektur für komplexe Systeme und dem Kosten- und Zeitdruck aufgrund von Mobilitätsmarktbedingungen an. Die Methode basiert auf einer modellbasierten Beschreibung von Systemfunktionen mittels klar definierter Abstraktionsebenen. Eine semiformelle Beschreibung macht eine effiziente Anforderungsabstimmung und halbautomatische Erstellung von Testfällen möglich.
Das Design auf den höheren Abstraktionsebenen war in diesem Artikel auf den Austausch von Anwendungserfahrungen für die nächste Generation von BMWs elektrifizierten Antriebssträngen ausgerichtet. Zum ersten Mal wurde eine modellbasierte Spezifikation für eine Entwicklung von automobilen Serienprodukten auf Systemebene angewendet. Mehr als 50 Funktionen spiegeln – getrieben durch eine systematische Definition der Funktionsarchitektur – das konzipierte Verhalten in den Bereichen Energiemanagement, Laden und Bereitstellung von Drehmoment wider. Testfälle wurden halbautomatisch unter Berücksichtigung von Überdeckungskriterien, Testkosten und Ausführungszeit für definierte Modellpfade abgeleitet. Am Ende des Workflows wurden automatisch ausführbare Testsequenzen erstellt.
Der Gesamtentwicklungsaufwand konnte bei gleichzeitiger Einhaltung von vorgegebenen Markt- und Produktmeilensteinen reduziert werden. Noch wichtiger ist, dass die Systemqualität gesteigert wurde: Es werden mehr Testfälle definiert, die Test­überdeckung kann frühzeitig bestimmt und Fehler können in früheren Designphasen identifiziert werden. Zudem können Anforderungen, Testfälle und Entwicklungsartefakte einfach abgestimmt und zweifelsfrei nachverfolgt werden.
Als nächstes steht die Fortführung der Systementwicklung auf niedrigeren Abstraktionsebenen an. Es werden sich Qualitätsgewinne zeigen – wenn die Fahrzeugtestebene erreicht wird, dürfte eine erhebliche Reduktion der Prototypen und Fehlerbehebungsphasen eintreten. Die MTSF-Methode wird auf Anwendungsebene neben dem Antriebsstrang auf andere Bereiche der Fahrzeugentwicklung ausgeweitet. Zudem wird eine Fehler­baumanalyse für beispielsweise Sicherheitsanwendungen ermöglicht. Die nächsten Schritte der Methodenentwicklung konzentrieren sich auf die Industrialisierung für große, dezentralisierte und unternehmensübergreifende Entwicklungsteams. Insbesondere in dieser Hinsicht kann davon ausgegangen werden, dass weiter an der Überbrückung etablier­ter Entwicklungskulturen der Bereiche Informatik und Ingenieurwissenschaft gearbeitet wird.

Referenzen
[1] Prasad, B., Analysis of pricing strategies for new product introduction
Pricing Strategy and Practice,
Vol. 5 Issue: 4, pp.132-141
Bingley (UK), 1997
[2] Mohr, D. et al., The road to 2020 and beyond: What’s driving the global automotive industry? Mc Kinsey & Company, Inc., Stuttgart, 2013
[3] Hübner, H.-P., Automatisiertes Fahren – Wohin geht die Fahrt?
Proc. 18. Kongress Fortschritte in der Automobilelektronik
Ludwigsburg, 2014
[4] Steinkamp, N., 2016 Automotive Warranty & Recall Report: Industry Insights for the Road Ahead, Chicago, 2015
[5] Kriebel, Stefan, Economic High Quality Software for Automotive Systems, 3d Congress on Real Time, INCHRON; Braunschweig 2011
[6] Wymore, A. Wayne, Model-Based Systems Engineering CRC Press, Inc. USA, 1993
[7] Estefan, Jeff A.; Survey of Model-Based Systems Engineering (MBSE) Methodologies, Incose MBSE Focus Group 2007
[8] Grönniger, Hans et al., View-Centric Modeling of Automotive Logical Architectures, In: Tagungsband des Dagstuhl-Workshop MBEES: Modellbasierte Entwicklung eingebetteter Systeme IV. Informatik-Bericht 2008-02, CFG-Fakultät, TU Braunschweig, 2008
[9] Kriebel, Stefan, Timing propagation in the development of software-based automotive systems 4th Symtavision NewsConference on Timing Analysis, Braunschweig, 2010
[10] Weilkiens, Tim, Systems Engineering with SysML/UML: Modeling, Analysis, Design Morgan Kaufmann, USA, 2008
[11] Rumpe, Bernhard, Agile Modeling with UML: Code Generation, Testing, Refactoring, Springer International
Germany, 2017
[12] Cuenot, D. et al., Managing Complexity of Automotive Electronics Using the EAST-ADL, 12th IEEE International Conference on Engineering Complex Computer Systems 2007
[13] Paulk, Mark, Capability Maturity Model for Software, John Wiley & Sons, 2002
[14] Hillebrand, Martin, Funktionale Sicherheit nach ISO 26262 in der Konzeptphase der Entwicklung von Elektrik/Elektronik Architekturen von Fahrzeugen KIT Scientific Publishing, Germany, 2012
[15] Grönniger, Hans et al., View-Centric Modeling of Automotive Logical Architectures, 4th European Congress ERTS – Embedded Real Time Software, Toulouse, 2008
[16] Grönniger, Hans et al., In: Proceedings of the Object-oriented Modelling of Embedded Real-Time Systems (OMER4) Workshop, Paderborn, 2007
[17] Linz, Tilo, Testen in Scrum-Projekten Leitfaden für Softwarequalität in der agilen Welt dpunkt.verlag, 2. Auflage 2016
[18] Pretschner, Alexander et al.
Model-based testing for real. STTT 5(2-3): 140-157, 2004
[19] Philipps, Jan et al., Model-Based Test Case Generation for Smart Cards., Electronic Notes in Theoretic Computer Science 80: 170-184, 2003
[20] Liggesmeyer, Peter, Software-Qualität: Testen, Analysieren und Verifizieren von Software Spektrum Verlag 2009

Dieser Beitrag ist ein Auszug aus der Veröffentlichung: „1. Kriebel, S., Richenhagen, J., et al.: High Quality Electric Powertrains by model-based systems engineering.
Erschienen in: Proc. 26th Aachen Colloquium Automobile and Engine Technology (2017), Vol. 1, pp. 211-222, ISBN 978-3-00-054182-7 „

Dr. Johannes Richenhagen