Die Shared Mobility gilt aktuell als eines der wichtigsten Trendthemen in der Automobilindustrie. Wie alle urbanen Mobilitätskonzepte der Zukunft erfordert sie eine enge Anbindung an die gesellschaftliche Zukunftsforschung. Hinsichtlich neuer Fahrzeugkonzepte des Carsharings ergibt sich daraus die Aufgabe, sämtliche kostenverursachende Faktoren zu erfassen und sie bezüglich ihres Einflusses auf die Wirtschaftlichkeit und Fahrzeugkonstruktion zu analysieren. FEV, share2drive und die FH Aachen arbeiten gemeinsam an der zukünftigen Fahrzeugklasse der Personal Public Vehicles (PPV) als Beförderungsmittel und Schnittstelle zwischen öffentlichem und individuellem Verkehr.

>> BIS 2030 WERDEN MINDESTENS ZEHN PROZENT DER FAHRZEUGE WELTWEIT IN MOBILITÄTSDIENSTEN GENUTZT

Wenn es im Kontext der Shared Mobility darum geht, relevante Formen von städtischen Mobilitätsdienstleistungen aus Sicht des individuellen Mobilitätsbedürfnisses zu beschreiben und Geschäftsmodelle mit speziellen Fahrzeugkonzepten zu bewerten, kommt das sogenannte Urban Mobility Trait (UMT) zum Einsatz (Abbildung 1).

Hieraus erschließt sich etwa, dass die Mobilitätsdienstleistung beim Free-Floa­ting-Carsharing aus dem Teilen von Fahrzeugen besteht, die von Unternehmen für ihre Kunden bereitgestellt werden. Letztere wiederum fungieren dabei als Fahrzeugführer. Generell wird beim Free-Floating Carsharing nur eine geringe Anzahl an Personen befördert und die Fahrstrecke liegt meist bei weniger als acht Kilometern. Anders sieht es beim sogenannten Ride Selling aus, zu dem beispielsweise die Unternehmen Uber oder Lyft zählen. Hierbei bieten Privatpersonen mit ihren eigenen Fahrzeugen Chauffeurdienstleistungen an. Letztlich entscheiden die Nutzungsbedürfnisse der Kunden darüber, welche Mobilitätsdienstleistung sie in Anspruch nehmen. Relevant ist hierbei neben den Kosten der Fahrt auch die Zeit die benötigt wird, bis Nutzer ihr Ziel erreichen können. Ebenfalls von Bedeutung sind die Einfachheit der Dienstleistung gepaart mit Komfort und potenziellem Zusatznutzen, den die Nutzer durch sie erfahren – beispielsweise, die Fahrtzeit für private oder berufliche Aufgaben nutzen zu können (Abbildung 2).

Es sind also neue Ansätze bei der Transportdienstleistung gefragt. Die share2drive GmbH mit Sitz in Aachen folgt genau diesem innovativen Ansatz. Sie ist ein junges Unternehmen, das als Spin-off aus der FH Aachen hervorging. Der Unternehmenszweck ist die Bereitstellung fortschrittlicher Mobilitätskonzepte im Umfeld des Carsharings. Einer der wesentlichen Bestandteile des Geschäftsmodells ist dabei das PPV – ein Fahrzeug, das in Kooperation mit FEV und ihren Tochterunternehmen speziell für die Nutzung im Carsharing entwickelt wird.

Marktfähige Fahrzeuge für die Shared Mobility

Neue Mobilitätsdienstleistungen im Kontext des UMT haben einen disruptiven Einfluss auf die bestehende Wertschöpfungsstruktur innerhalb des Automobilsektors, da Akteure aus der IKT- und Energiebranche neben etablierten Mobilitätsdienstleistern verstärkt mit neuen Geschäftsmodellen auf den Mobilitätsmarkt drängen. Gleichzeitig orientieren sich insbesondere die großen Tier 1 Supplier in der Automobilzulieferindustrie neu, um auf Marktveränderungen, etwa durch neu erscheinende Fahrzeughersteller, zu reagieren. Was neben der weiteren Diversifizierung von Fahrzeugmodellen für Endkunden außerdem erwartet werden kann ist, dass verstärkt auch Fahrzeuge für Mobilitätsdienstleister in den Fokus der OEMs rücken [1]. So prognostizieren diverse Studien, dass bis 2030 mindestens zehn Prozent der Fahrzeuge weltweit in Mobilitätsdiensten genutzt werden [2].
Der Wettlauf um Fahrzeugmodelle für diesen Sektor hat also begonnen. Und damit auch die mit dem UMT einhergehende Differenzierung, ob sogenannte Purpose Vehicles im Sinne von „Sharing a Vehicle“ oder in der Bedeutung von „Sharing a Ride“ sowie „Driver on Board“ oder „Be the Driver“ konzipiert werden. Denn nur solche Fahrzeugkonzepte sind marktfähig, die einer soliden Marktdurchdringung bei gleichzeitig attraktiver Total-Cost-for-Ride-Betrachtung entsprechen. Für ein neues Fahrzeugkonzept bedeutet dies, dass alle kostenverursachenden Faktoren erfasst und analysiert werden müssen. Dazu zählen unter anderem die Fahrzeuge, deren Wartung, die Aufwendungen für Infrastruktur und IKT sowie der eigentliche Betrieb. Diese Kosten müssen sich in einem wirtschaftlichen Geschäftsmodell abbilden und es gilt, den Einfluss der Fahrzeugkonstruktion für jeden der genannten Faktoren zu berücksichtigen.

Das PPV als neuer Ansatz bei Shared Cars

Die bislang in städtischen Mobilitätsdienstleistungen genutzten (Elektro-) Fahrzeuge erfüllen nur bedingt ihren Einsatzzweck, da sie originär auf eine Endkundennutzung ausgelegt sind. Dabei werden von den Flottenbetreibern nur geringfügige Modifikationen, insbesondere im Bereich der Zugangsmöglichkeiten, an den Fahrzeugen selbst vorgenommen. Im Zuge der Verwendung in einem urbanen, auf dem Teilen beruhenden Mobilitätskonzept rücken jedoch sehr spezielle Anforderungen der Betreiber als auch der Fahrzeugnutzer zunehmend in den Fokus. Gleichzeitig müssen Fahrzeuge in neuen Mobilitätsdienstleistungen und in einer multimodalen Welt als „Rolling Devices“ verstanden werden. Daraus folgt, das Anforderungsprofil eines „perfekten“ Sharing-Fahrzeugs nicht wie sonst üblich über eine konventionelle Kundenanalyse, sondern aus dem Mobilitätskonzept sowie einem Geschäftsmodell zu entwickeln. Entsprechende Anforderungen aus dem Carsharing-Betrieb sind in gemeinsamer Forschung der FH Aachen und Cambio Aachen sowie aus Veröffentlichungen des Bundesverbands CarSharing e. V. entstanden (Abbildung 3).

Der Gedanke bei der Konzeption des PPV ist es, ein realistisches Fahrzeug zu entwickeln, das nicht dem aktuellen Trend „schwereloser“ Showcars folgt, sondern sich als eine zeitnahe Antwort auf Shared-Mobility-Anforderungen der Zukunft versteht. Das für das PPV 1.0 erstellte Fahrzeuglastenheft adressiert eine europäische Homologation. Der Entwicklungsprozess folgt im Package-Engineering einer einheitlichen Darstellung der Package-Informationen gemäß der ECIE-Norm (European Car Manufacturers Information Exchange Group).
Dies ermöglicht einen herstellerübergreifenden Vergleich des ergonomischen und technischen Fahrzeug-Packages. Während der Konzeptentwicklung wird zusätzlich in Hardware eine modulare, leicht änderbare Innenraum-Sitzkiste für die Verifizierung der anspruchsvollen Innenraumvorgaben verwendet. Die Absicherung der funktionalen Ziele (zum Beispiel für den Crashfall) erfolgt durch entsprechende Simulation nach der Finite-Elemente-Methode mit dem Programm LS-Dyna.

Maße und Aufbau: Die größte Herausforderung stellt sich durch die Mobilitätsvorgabe, ein Fahrzeug in der M1-Klasse zu konzipieren. In dieser Klasse sind nur Fahrzeuglängen von unter 2,5 m (Quereinparken erlaubt) und einer Breite von circa 1,7 m zulässig. Gleichzeitig müssen, um 95 Prozent aller denkbaren Fahrten zu bedienen, drei Personen im PPV 1.0 Platz finden. Die Vorgabe, dass der Innenraum ein freundliches, großzügiges Innenraum­angebot bieten soll, erschwert die Konzeption zusätzlich. Das PPV schafft diesen Spagat mit einem One-Box-Design mit Dreier-Sitzbelegung (1+2-Sitzer) in einer Reihe. Der Antriebsstrang wird hochintegrativ und package-effizient mit der Bodengruppe abgestimmt. Ein neuartiges Rohbaukonzept erlaubt eine weit nach vorne platzierte Windschutzscheibe. Ein wichtiges Konzeptmerkmal ist hierfür die zurückversetzte A-Säule und sehr große Glasflächen. Ein weiterer Bestandteil des Aufbaukonzepts stellt die Fahrertür dar. Ein neuartiges Schwenk-Schiebetür-Konzept gewährleistet eine Best-in-Class-Türöffnung selbst in engen Parklücken, ohne dabei im geöffneten Zustand über das sehr kurze Fahrzeug hinauszuragen.

Designentstehung: Vor der eigentlichen Designentwicklung wird in einer interdisziplinären Entwicklungsgruppe eine Design-DNA des PPV 1.0 definiert. Hierfür werden zunächst sehr unterschiedliche urbane Assoziationswelten geschaffen und auf deren Grundlage circa 250 Designentwürfe entwickelt.

Die Entwürfe, die im nächsten Schritt auf zwei grundsätzlich unterschiedliche Konzepte des bevorzugten Assozia­tionsraums verdichtet werden, führen anschließend zur finalen Konzeptentscheidung. Ab dieser Stufe folgt die Designentwicklung in einem typischen digitalen CAS-Prozess (Computer-aided-Styling), ehe die anvisierte Design-DNA im finalen Design umgesetzt werden kann. Zusammengefasst lässt sich der PPV als der kleinste Selbstfahrerbus der Welt bezeichnen.
Das Interieurkonzept unterscheidet sich in der Designsprache deutlich vom Exterieur und nimmt sehr stark die reduzierte Kommunikations-DNA aus dem Busbau und der IT-Welt auf. Die Anzahl der Bedien­elemente hat man beim PPV 1.0 auf ein absolutes Minimum reduziert und die intuitive Bedienung in den Vordergrund gestellt. Der Fahrerplatz zeichnet sich durch eine moderne, digitale Benutzeroberfläche aus, das Klimatisierungskonzept orientiert sich eher an der Denkweise urbaner Räume und nicht am klassischen Fahrzeugbau. Ein auf die Kosten einer jeden Fahrt optimiertes Reinigungskonzept des Innenraums, sinnvolle Variabilitäten durch die Zweier-Sitzbank, Weglassen verdreckender Fugen, Oberflächen aus dem Bootsbau, ein Sprühboden aus dem Schienenfahrzeugbau sowie der konsequente Wegfall „überflüssiger“ Ablageflächen charakterisieren den Innenraum als echten Carsharing-Nutzraum.

>> DAS KONZEPT HINTER DEM PPV IST, EIN REALISTISCHES FAHRZEUG ZU ENTWICKELN, DAS EINE ZEITNAHE ANTWORT AUF SHARED-MOBILITY-ANFORDERUNGEN DARSTELLT

Der Antrieb: Das Antriebskonzept des PPV 1.0 setzt im Wesentlichen auf die 400-V-Technik, die einerseits sehr gut entwickelt und für ein elektrisch betriebenes, urbanes Stadtfahrzeug absolut geeignet ist. Die technischen Daten sind mit 45 kW Antriebsleistung in der Front, einer maximalen Geschwindigkeit von 120 km/h und einem Batteriepack von knapp 20 kW/h absolut konkurrenzfähig. Die Reichweite liegt – selbst unter extremen Bedingungen – bei 80 km und ist auf einen speziell entwickelten Carsharing-Zyklus verifiziert. Gemäß dem share2drive-Geschäftsmodell werden damit die täglich geforderten circa zwei Stunden Betrieb zuverlässig erreicht. Zudem ist die Sicherstellung der kabellosen Ladevorgänge im sogenannten Flex – Share von share2drive gewährleistet. Die Konzeptentscheidung einer Tandem-Elektromotor-Anordnung mit zwei, im Durchmesser kleinen elektrischen Maschinen im Vorderwagen, beruht auf den Vorteilen in der Crashauslegung sowie dem Anspruch, ein agiles Stadtfahrzeug zu liefern.

Sicherheitsanspruch: Neben einer Vielzahl an Maßnahmen zur Unfallvermeidung zeichnet sich das PPV 1.0 durch eine hohe Crashsicherheit aus (Abbildung 3).
Die besondere Herausforderung liegt bei der Konzeptentwicklung vor allem in der Auslegung der Frontalcrash-Anforderungen. Der sehr kurze Vorderwagen zwingt die Entwicklung in eine radikale Strukturauslegung mit vier Lastpfadebenen und sehr kontrolliertem Deformationsverhalten. Bei einer Gesamtverformung von circa 350 mm wird ein mittlerer Crashimpuls von 31 g bei circa 60 mm Spritzwandeindringung erreicht. Beim Seitenaufprall werden die Deformationen von der zentral angeordneten Batteriestruktur ferngehalten. Für den Dacheindrücktest gemäß der FMVSS (Federal Motor Vehicle Safety Standards) 216 wird die Crashfestigkeit mit knapp 60 kN erfüllt.

>> DIE HOHE RESONANZ AUF DAS PPV 1.0, DAS EINE ANTWORT AUF ZUKÜNFTIGE MOBILITÄTSBEDÜRFNISSE IN EINER SHARED ECONOMY BIS 2020 DARSTELLT, HAT BEREITS DAS PPV 2.0 „SVEN“ INS LEBEN GERUFEN

Produktionsvorteile: Beim Rohbau handelt es sich um den sogenannten FlexBody, einen Karosseriebaukasten, der den Bau von profillastigen Leichtbaukarosserien in Mischbauweise für Fahrzeugprojekte mit weniger als 10.000 Fahrzeugen pro Jahr ermöglicht. Durch einen standardisierten Prozess sowie die stringente Aufteilung der Profile und Knoten können mit dem FlexBody Karosseriestrukturen in sehr kurzer Zeit entwickelt und für die Produktion vorbereitet werden (Abbildung 4).

Der größte Vorteil liegt in den sehr geringen Investitionen. Beim FlexBody des PPV 1.0 werden in der Bodengruppe vorrangig Bauweisen mit stahlintensiven, hoch- und höchstfesten Werkstoffen eingesetzt. Im Vorderwagen und im Aufbau dominieren vorrangig Aluminiumlösungen. Ein sogenannter Ladder-integrated Frame nimmt die zentral angeordnete Batterie schützend auf. Die statische Torsionssteifigkeit der 140 kg schweren Karosserie ist mit einer Leichtbaugüte von circa drei auf hohem Niveau. Die Fertigung des Rohbaus erfolgt in sogenannten „Innofix Single-shot Fixtures“ und ist auf den Einsatz eines neuentwickelten Injektionsklebverfahrens ausgelegt. Die Fertigung der jährlich 7.000 geplanten PPVs erfolgt im Zweischichtbetrieb.

Das PPV als Lösung für die Mobilität von morgen

Die Marktentwicklung zu neuen Mobilitätslösungen bietet ein interessantes Potenzial für Konzepte, bei denen Mobilitätsbedürfnisse, neue Geschäftsmodelle und der Fahrzeugbau zusammenwachsen. Die hohe Resonanz auf das PPV 1.0, das als spezielle Fahrzeuglösung eine Antwort auf zukünftige Mobilitätsbedürfnisse in einer Shared Economy bis 2020 bietet, hat bereits das PPV 2.0 „SVEN“ ins Leben gerufen.

Im klassischen Fahrzeugbau punktet die rasant fortschreitende Entwicklung des autonomen Fahrens mit den Kundenvorteilen Komfort und Sicherheit. In einer Shared-Mobility-Welt hingegen verstehen sich autonome Fahrfunktionen weit darüber hinaus. Sie ermöglichen im städtischen Raum die Mobilität der Bevölkerung und ihre logistische Umsetzbarkeit.

LITERATURHINWEISE
[1] Kaas, H.W.; et al.: Automotive Revolution – Perspective Towards 2030. How the Convergence of Disruptive Technology Driven Trends Could Transform the Auto Industry. McKinsey & Company, 2017
[2] McKinsey & Company: Carsharing & Co.: 2030 über zwei Billionen Dollar Umsatzpotenzial. Pressemitteilung vom 09.03.2017
[3] Anthrakidis, A.; Jahn, R.; Ritz, T.; et al.: Urbanes eCarSharing in einer vernetzten Welt. Steinbeis Edition, 2013

Klaus Wolff

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

Für die Funktionale Sicherheit (FuSi) von in Serie produzierten Straßenfahrzeugen definiert die Norm ISO26262 einen umfangreichen Entwicklungsprozess vom Konzept bis zur Produktion. Für Prototyp- und Demonstratorfahrzeuge gibt es dagegen keine normativen Vorgaben, und die Anwendung der ISO26262 wäre viel zu aufwändig für den Umfang einer Prototypentwicklung. Trotzdem ist die Berücksichtigung der Funktionalen Sicherheit auch bei Prototypen notwendig, um den Fahrer, die Mitfahrer und die Personen in der Nähe des Fahrzeugs vor Schäden zu schützen, die durch eine Fehlfunktion verursacht werden könnten. Die Dokumentation der FuSi-Aktivitäten ist essentiell, da nur auf diese Weise belegt werden kann, dass Funktionale Sicherheit berücksichtigt wurde und Sicherheitsmechanismen implementiert wurden.
Daher wurde bei FEV ein maßgeschneiderter FuSi-Prozess für Prototypen entwickelt, der auf den wesentlichen Schritten der in der ISO26262 beschriebenen Konzeptphase basiert, dies jedoch in vereinfachter Form. Die Schritte bestehen aus der vorläufigen Systemdefinition, einer vereinfachten Gefahren- und Risikoanalyse (GuR), sowie der Definition von Sicherheitsmaßnahmen, die im Prototyp-Fahrzeug umzusetzen sind. Darüber hinaus beinhaltet der Prozess eine Überarbeitungs-Schleife, um das verbleibende Risiko in Kombination mit den Sicherheitsmaßnahmen zu bewerten (Abbildung 1).

Vorläufige Systemdefinition

In diesem Artikel wird die Umwandlung eines konventionellen Antriebsstrangs in einen P2-Hybrid-Antriebsstrang als Beispiel für die Prototypanwendung betrachtet. Neben der Integration eines Hochvolt-Bordnetzes ist auch die Modifikation des Antriebsstrangs selbst ein sicherheitsrelevanter Aspekt, wie anhand einer seiner Hauptfunktionen gezeigt wird, dem elektrischen Fahrbetrieb.

Die vorläufige Systemdefinition beschreibt alle Funktionen, Betriebsarten, Schnittstellen und Betriebsbedingungen des zu betrachtenden Systems, also in unserem Beispiel des P2-Hybridsystems. Diese Informationen sind entscheidend für die Bestimmung potentieller Risiken, die durch Fehlfunktionen des Systems verursacht werden können.

Vereinfachte Gefahren- und Risikoanalyse

Die wesentlichen Schritte für die Gefahren- und Risikoanalyse (GuR) sind die Auswahl der relevanten Betriebssituationen für das Prototyp-Fahrzeug, die Funktionale Gefahrenanalyse (FGA) und die Risikobewertung der resultierenden Gefahrensituationen.
Die FGA weist jeder Funktion standardisierte Fehlfunktionen zu (kein, zu viel, zu wenig, falsche Richtung/Verteilung, ungewollt, hängengeblieben). In Kombination mit der jeweiligen Betriebssituation ergeben sich im nächsten Schritt die Gefahrensituationen. Ein Beispiel für die Funktion „Elektrisches Fahren“ des Prototyp-Fahrzeugs gliedert sich wie folgt:

• Funktion: Elektrisches Fahren
• Betriebssituation: Fahrzeug steht an Ampel oder Kreuzung
• Fehlfunktion: Ungewolltes Drehmoment
• Gefahrensituation: Ungewollte Fahrzeugbewegung, die zu einer Kollision mit einem vorbeifahrenden Fahrzeug führt.

Die Risikobewertung einer solchen Gefahrensituation basiert auf drei Kriterien, die in der ISO26262 definiert werden. Exposition (E = Exposure) steht für die Häufigkeit der Betriebssituation – nicht der Gefahrensituation. Die Schadensschwere (S = Severity) ist die Bewertung der gesundheitlichen Schäden, die jemandem zugefügt werden. Und die Kontrollierbarkeit (C = Controllability) ist ein Maß für die Fähigkeit des Fahrers, den Schaden durch sein Eingreifen zu vermeiden. Da die genaue Bestimmung dieser Parameter recht zeitaufwändig ist, wird ein vereinfachter, konservativer Bewertungskatalog für die Prototyp-Anwendung benutzt, und anstelle des in ISO26262 definierten Automotive Safety Integrity Level (ASIL) wird eine Risikostufe ermittelt (Abbildung 2).

Die initiale Bewertung für das oben genannte Beispiel lautet:

• Exposition für stehendes Fahrzeug an Ampel oder Kreuzung: E = 3
• Schadensschwere für Kollision mit vorbeifahrendem Fahrzeug: S = 3
• Kontrollierbarkeit für ungewollte Fahrzeugbewegung: C = 2

Die C-Bewertung hängt von einigen Randbedingungen ab. Im Beispiel ist das maximal an den Antriebsrädern anliegende Drehmoment, das der Elektromotor erzeugen kann, niedriger als das Bremsmoment, das der Fahrer durch Treten des Bremspedals aufbringen kann. Wenn eine solche Randbedingung nicht erfüllt wird oder nicht sichergestellt werden kann, muss eine konservativere Bewertung vorgenommen werden.
Mit E + C = 5 und S = 3 ergibt sich ein „Mittleres Risiko“, welches Sicherheitsmaßnahmen erforderlich macht, wie im folgenden Abschnitt beschrieben wird.

Herleitung von Sicherheitsmaßnahmen

Um die Risikostufe “Akzeptabel” zu erreichen, sind Sicherheitsmaßnahmen vorzusehen (Abbildung 3).

Für das vorangegangene Beispiel kann das “Mittlere Risiko” in mehreren Schritten auf ein “Akzeptables Risiko” reduziert werden. Als erstes wird ein Notaus-Schalter installiert, der das elektrische Antriebssystem ausschaltet. Der Fahrer ist in der Bedienung dieses Schalters zu schulen, zum Beispiel durch Einleitung des Fehlers auf der Teststrecke. Nur geschulte Fahrer werden autorisiert, das Fahrzeug im Stadtverkehr zu bewegen, was beispielsweise durch ein Fahrtenbuch zu dokumentieren ist. Durch diese Maßnahme wird die C-Bewertung von 2 auf 1 reduziert. Dies führt gemäß Abbildung 2 zur Risikostufe „Niedrig“, so dass weitere Maßnahmen nötig sind. Beispielsweise kann der Betrieb des Prototyp-Fahrzeugs auf Fahrzyklen eingeschränkt werden, in denen das Fahrzeug in weniger als ein Prozent der Betriebszeit an Ampeln oder Kreuzungen steht. Dadurch sinkt die E-Bewertung von 3 auf 2, und es ergibt sich die Risikostufe „Akzeptabel“.

Da das Beispiel in diesem Beitrag nur eine Situation aus vielen möglichen Szenarien beschreibt, könnten für diese Fahrzeuganwendung andere Risiken mit der Stufe „Hoch“ bewertet werden und daher weitere Sicherheitsmaßnahmen wie zum Beispiel Überwachungsfunktionen erfordern. Solche Maßnahmen könnten dann auch für die Minderung von niedriger bewerteten Risiken verwendet werden, so dass Beschränkungen der Fahrzyklen oder der Fahrzeugbedienung vermieden würden.
Für die Vervollständigung des vereinfachten FuSi-Prozesses ist es wichtig, dass die spezifizierten Sicherheitsmaßnahmen umgesetzt und getestet werden, bevor die eigentlichen Untersuchungen am Prototypfahrzeug starten. Dies kann durch Checklisten und Fahrzeugtests auf der Teststrecke sichergestellt werden.

Neben der Erfüllung technischer Ziele ist eine strikte Einhaltung eines sicherheitsbezogenen Entwicklungs- und Freigabeprozesses auch für Prototype-Anwendungen erforderlich. FEV hat dafür den beschriebenen Prototyp-Prozess entwickelt und bereits in mehreren Projekten erfolgreich angewendet.

Dr. Bastian Holderbaum