Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen [1. Aufl.] 978-3-658-26307-2;978-3-658-26308-9

Table of contents :
Front Matter ....Pages I-XVIII
Einleitung (Thies Filler)....Pages 1-7
Stand der Technik (Thies Filler)....Pages 9-34
Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen (Thies Filler)....Pages 35-84
Anwendungsbeispiel (Thies Filler)....Pages 85-109
Zusammenfassung (Thies Filler)....Pages 111-113
Fazit (Thies Filler)....Pages 115-116
Ausblick (Thies Filler)....Pages 117-119
Back Matter ....Pages 121-133

Citation preview

AutoUni – Schriftenreihe

Thies Filler

Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen

AutoUni – Schriftenreihe Band 139 Reihe herausgegeben von/Edited by Volkswagen Aktiengesellschaft AutoUni

Die Volkswagen AutoUni bietet Wissenschaftlern und Promovierenden des Volkswagen Konzerns die Möglichkeit, ihre Forschungsergebnisse in Form von Monographien und Dissertationen im Rahmen der „AutoUni Schriftenreihe“ kostenfrei zu veröffentlichen. Die AutoUni ist eine international tätige wissenschaftliche Einrichtung des Konzerns, die durch Forschung und Lehre aktuelles mobilitätsbezogenes Wissen auf Hochschulniveau erzeugt und vermittelt. Die neun Institute der AutoUni decken das Fachwissen der unterschiedlichen Geschäftsbereiche ab, welches für den Erfolg des Volkswagen Konzerns unabdingbar ist. Im Fokus steht dabei die Schaffung und Verankerung von neuem Wissen und die Förderung des Wissensaustausches. Zusätzlich zu der fachlichen Weiterbildung und Vertiefung von Kompetenzen der Konzernangehörigen ­fördert und unterstützt die AutoUni als Partner die Doktorandinnen und Doktoranden von vielfältige Volkswagen auf ihrem Weg zu einer erfolgreichen Promotion durch ­ Angebote – die ­Veröffentlichung der Dissertationen ist eines davon. Über die Veröffentlichung in der AutoUni Schriftenreihe werden die Resultate nicht nur für alle Konzernangehörigen, sondern auch für die Öffentlichkeit zugänglich. The Volkswagen AutoUni offers scientists and PhD students of the Volkswagen Group the opportunity to publish their scientific results as monographs or doctor’s theses within the “AutoUni Schriftenreihe” free of cost. The AutoUni is an ­international scientific educational institution of the Volkswagen Group Academy, which produces and disseminates current mobility-related knowledge through its research and tailor-made further education courses. The AutoUni’s nine institutes cover the expertise of the different business units, which is indispensable for the success of the Volkswagen Group. The focus lies on the creation, anchorage and transfer of knew knowledge. In addition to the professional expert training and the development of specialized skills and knowledge of the Volkswagen Group members, the AutoUni supports and accompanies the PhD students on their way to successful graduation through a variety of offerings. The publication of the doctor’s theses is one of such offers. The ­publication within the AutoUni Schriftenreihe makes the results accessible to all Volkswagen Group members as well as to the public. Reihe herausgegeben von/Edited by Volkswagen Aktiengesellschaft AutoUni Brieffach 1231 D-38436 Wolfsburg http://www.autouni.de

Weitere Bände in der Reihe http://www.springer.com/series/15136

Thies Filler

Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen

Thies Filler AutoUni Wolfsburg, Deutschland Zugl.: Dissertation, Leibniz Universität Hannover, 2019 Die Ergebnisse, Meinungen und Schlüsse der im Rahmen der AutoUni – Schriftenreihe veröffentlichten Doktorarbeiten sind allein die der Doktorandinnen und Doktoranden.

AutoUni – Schriftenreihe ISBN 978-3-658-26307-2 ISBN 978-3-658-26308-9  (eBook) https://doi.org/10.1007/978-3-658-26308-9 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen National­ bibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informa­ tionen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Danksagung Zunächst danke ich Frau Prof. Dr.-Ing. Helena Szczerbicka für ihr Engagement und die investierte Zeit im Rahmen der wissenschaftlichen Betreuung meiner Arbeit. Besonders die fachlichen Diskussionen und das wertvolle Feedback waren mir eine große Unterstützung. Des Weiteren gilt mein Dank meinem Betreuer bei der Volkswagen AG. Er stand während meiner gesamten Bearbeitungszeit stets mit Engagement für Fragen und fachliche Diskussionen zur Verfügung und gab wertvolle Denkanstöße und Hinweise. Mein Dank gilt zudem meinen Kolleginnen und Kollegen in der Abteilung. Über die Abteilung hinaus unterstützten mich insbesondere die Kollegen aus dem Fachbereich der Fahrwerksentwicklung mit fachlichem Austausch. Bedanken möchte ich mich ebenfalls bei meinen früheren Masteranden, die mit großer Begeisterung an der Umsetzung von Inhalten dieser Arbeit mitgewirkt haben. Zudem danke ich Mitarbeitern von der Firma Model Engineering Solutions für die Durchführung von modellbasierten Tests und Mitarbeitern von der Firma Tesis für die Unterstützung bei der Durchführung von Simulationen. Überdies danke ich meiner Familie und meinen Eltern, die mir das Studium der Informatik ermöglicht und mich bei meiner Dissertation unterstützt haben. Schließlich danke ich noch meiner Freundin, die mir während der Bearbeitung dieser Arbeit mit Rat und Tat zur Seite stand. Thies Filler

Kurzfassung deutsch Eingebettete Systeme spielen im Alltag eine immer wichtigere Rolle. Dabei steigen sowohl die Leistungsfähigkeit als auch die damit einhergehende Komplexität immer weiter an. Dies spiegelt sich in der Automobilindustrie durch eine steigende Anzahl an Fahrassistenz-, Sicherheitsund Komfortfunktionen für den Kunden wider. Realisiert werden solche Kundenfunktionen oft mithilfe einer Vielzahl von Steuergeräten, die über Bussysteme miteinander kommunizieren. Neben Kundenfunktionen, die sich auf einzelnen Steuergeräten befinden, gibt es zudem vernetzte Kundenfunktionen, deren Bestandteile sich auf verschiedene Steuergeräte verteilen. Darüber hinaus ermöglichen neue Steuergerätearchitekturen, wie beispielsweise AUTOSAR, die Verteilung einzelner Funktionsteile auf verschiedene Steuergeräte. Im Zuge des automatisierten Fahrens nehmen sowohl die Anzahl als auch die Komplexität von vernetzten Kundenfunktionen im Fahrzeug immer mehr zu und führen zu einem hohen Testaufwand. Für die Beherrschung des Aufwands sollen Tests von Kundenfunktionen zukünftig verstärkt mithilfe von Simulationen durchgeführt werden. Hier werden einzelne Funktionsteile wie z. B. physikalische Bauteile durch Simulationsmodelle abstrahiert, die im Allgemeinen von verschiedenen Zulieferern und Fachabteilungen entwickelt werden. Diese verteilte Entwicklung erschwert den Aufbau von Gesamtmodellen und sie führt dazu, dass die Simulation von vernetzten Kundenfunktionen nicht immer effizient ist. Herausforderungen bestehen beispielsweise darin, dass Simulationsmodelle für spezifische Fragestellungen erstellt werden. Dennoch ist eine Wiederverwendung dieser Modelle sinnvoll, da sie z. B. für die Beantwortung verschiedener Fragestellungen bzgl. des Bauteilverhaltens genutzt werden können. Darüber hinaus bietet ein Test im frühen Entwicklungsstadium insofern einen Mehrwert, als die Fehlerbehebungskosten geringer ausfallen als zu einem späteren Zeitpunkt. Im Rahmen der vorliegenden Arbeit wird eine Methode zur durchgängigen Integration von Simulationsmodellen für die Entwicklung vernetzter Kundenfunktionen dargestellt. Die Methode ermöglicht, dass die Modellintegration robuster und effizienter gestaltet werden kann. Sie ist auf die Automobilindustrie zugeschnitten, wobei sich viele Aspekte auf Landmaschinen, Lastkraftwagen oder auch auf die Luft- und Raumfahrttechnik übertragen lassen. Der Fokus dieser Arbeit liegt auf der Spezifizierung von Anforderungen, Randbedingungen und Modelleigenschaften für verschiedene Testanforderungen von vernetzten Kundenfunktionen. Es wird untersucht, welche Verfahren und Kopplungsmethoden für welche Testanforderungen geeignet sind. Die Arbeit stellt darüber hinaus benötigte Eigenschaften für eine durchgängige Berechnung von Modellen im gesamten Entwicklungsprozess dar, sodass diese z. B. früh auf PCs und später auf Prüfständen mit Echtzeitanforderungen wiederverwendet werden können. Sowohl für die Definition als auch für die Prüfung von Modelleigenschaften werden geeignete Werkzeuge vorgestellt. Die Verwendbarkeit der Forschungsergebnisse wird abschließend anhand einer vernetzten Kundenfunktion nachgewiesen.

VIII

Kurzfassung deutsch

Beleuchtet wird in der Arbeit insbesondere die Verwendung der Simulation für die Funktionsentwicklung, da sie als Schlüsseltechnologie für komplexe Kundenfunktionen im Fahrzeug, wie z. B. das automatisierte Fahren, gilt. Die in dieser Arbeit neu entwickelten Strukturierungen bieten die Grundlage für schnellere und effizientere Simulationen von vernetzten Kundenfunktionen.

Kurzfassung englisch Embedded systems, i.e. as part of a larger system including hardware and mechanical parts, are becoming increasingly important. Within the automotive industry, such systems are found within driver assistance, safety and comfort functions. They are implemented using many electrical control units which communicate using bus systems. Apart from functions which are implemented in a single electrical control unit, there is now a trend towards complex and networked functions, which comprise of multiple electrical control units. Furthermore, new control device architectures - for instance, the AUTOSAR architecture - have emerged that distribute multiple parts of functions to different electrical control units. As we strive towards automated driving, the number of embedded systems and their complexities continue to grow and this requires substantial resources for testing. It is essential that such embedded systems will have to be tested using simulations, often with real-time computing constraints. Simulation models are developed and provided by a multitude of suppliers, subcontractors and subdivisions. The diversity of the origins and the uncoordinated development is afflicted with a risk for inefficient simulation testing. For example, specific simulation models have been developed only for one purpose or specific functions, whereas a modular structure aiming at a multitude of future test applications would be preferential. It is important to study not only the function of such a system, but also the functioning of the various components. Simulation testing during the development of the components is also preferable as such an approach will reduce the costs for diagnosing errors and malfunctions of complex systems. This thesis focuses on the integrated simulation models for different testing requirements of complex and networked integrated embedded systems. Various solutions are presented to improve the integration of the systems with the goal to enhance their robustness and efficacy. The method is specifically designed for the automotive industry; however, the concepts can be generalized and used for agricultural machines, trucks, and the aerospace sector. This thesis treats the exact definitions of the requirements, confounding conditions, and model characteristics for networked embedded systems. Moreover, this work focuses on a modular approach of the use of components of such simulation systems for embedded networked systems, including the use of personal computers and tests benches. The work also focuses on the testing of model characteristics with appropriate tools. The applicability of the research results is validated on a specific networked function.

Inhaltsverzeichnis Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

XIV XV XVII

1

Einleitung . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivation . . . . . . . . . . . . . . . . . . . . 1.2 Problemstellung . . . . . . . . . . . . . . . . . 1.3 Lösungsansatz . . . . . . . . . . . . . . . . . . 1.3.1 Vorgehensweise . . . . . . . . . . . . . 1.3.2 Ziele der Arbeit . . . . . . . . . . . . . 1.4 Bezug und Abgrenzung zu verwandten Arbeiten 1.5 Aufbau der Arbeit . . . . . . . . . . . . . . . .

. . . . . . . .

1 1 2 3 4 5 6 7

2

Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Entwicklungsprozess mechatronischer Systeme . . . . . . . . . . . . . . . 2.2 Steuergeräte im Fahrzeug . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Steuergeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Steuergerätearchitekturen . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Steuergerätevernetzung im Fahrzeug . . . . . . . . . . . . . . . . . 2.2.4 Entwicklungsprozess von Steuergeräten . . . . . . . . . . . . . . . 2.3 Grundlagen der Simulation im Kontext der virtuellen Funktionsabsicherung 2.4 Eigenschaften von einzelnen Simulationsmodellen . . . . . . . . . . . . . 2.5 Co-Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Durchführung von funktionalen Tests und Testverfahren . . . . . . . . . . . 2.7 Begriffe im Kontext der Fahrdynamiksimulationen . . . . . . . . . . . . .

9 9 11 11 12 14 15 20 22 25 30 32

3

Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen 3.1 Begriffsdefinitionen für eine durchgängige Funktionsentwicklung . . . . . 3.1.1 Strukturgebende Begriffsdefinitionen . . . . . . . . . . . . . . . . 3.1.2 Aufbau von Simulationen . . . . . . . . . . . . . . . . . . . . . . 3.2 Analyse der aktuellen Funktionsentwicklung . . . . . . . . . . . . . . . . . 3.2.1 Reifegrade von Funktionen im Entwicklungsprozess . . . . . . . . 3.2.2 Eigenschaften verschiedener XiL-SW-Elemente . . . . . . . . . . . 3.2.3 Erkenntnisse und Potentiale . . . . . . . . . . . . . . . . . . . . . 3.3 Testphasen von Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Herleitung der Testphasen . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Schnittstellentest . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 (Vor-)Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Variantentest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Bauteilauslegung . . . . . . . . . . . . . . . . . . . . . . . . . . .

35 36 36 38 42 42 43 46 47 47 48 50 51 51

XII

Inhaltsverzeichnis

3.3.6 3.3.7

3.4

3.5

Abnahmetest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gesamtdarstellung der Testphasen und Ableitung geeigneter Testmethoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anforderungen an Simulationsmodelle im Entwicklungsprozess . . . . . . 3.4.1 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Kriterien zur Klassifizierung von Modellen . . . . . . . . . . . . . 3.4.3 Klassifizierung von Modelleigenschaften . . . . . . . . . . . . . . 3.4.4 Validierung vernetzter Modelle . . . . . . . . . . . . . . . . . . . . Unterstützende Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Testsystemkonfigurator (TSK) . . . . . . . . . . . . . . . . . . . . 3.5.2 Modellanalysewerkzeug (MAW) . . . . . . . . . . . . . . . . . . .

52 52 57 57 59 64 68 71 72 83

4

Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Die vernetzte Funktion Driver Steering Recommendation (DSR) . . . . . . 4.2 Manöverbeschreibung der DSR-Funktion . . . . . . . . . . . . . . . . . . 4.3 Simulationsaufbau für die DSR-Funktion . . . . . . . . . . . . . . . . . . 4.4 Messaufbau und Beschreibung der im Fahrversuch durchgeführten Manöver 4.5 Modellkonfiguration beim Durchlauf der Testphasen . . . . . . . . . . . . 4.6 Schnittstellentest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Darstellung der verwendeten Modelle . . . . . . . . . . . . . . . . 4.6.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Zusammenfassung des Schnittstellentests . . . . . . . . . . . . . . 4.7 Variantentest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Darstellung der verwendeten Modelle . . . . . . . . . . . . . . . . 4.7.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.3 Zusammenfassung des Variantentests . . . . . . . . . . . . . . . . 4.8 Bauteilauslegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Darstellung der verwendeten Modelle . . . . . . . . . . . . . . . . 4.8.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.3 Zusammenfassung der Bauteilauslegung . . . . . . . . . . . . . . . 4.9 (Vor-)Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.1 Darstellung der verwendeten Modelle . . . . . . . . . . . . . . . . 4.9.2 Zusammenfassung der (Vor-)Applikation . . . . . . . . . . . . . . 4.10 Abnahmetest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Zusammenfassung des Anwendungsbeispiels . . . . . . . . . . . . . . . . 4.12 Auswertung der Methodik . . . . . . . . . . . . . . . . . . . . . . . . . .

85 85 86 87 88 90 92 92 93 95 95 95 96 98 99 99 100 104 105 105 106 106 106 107

5

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

111

6

Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

115

7

Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

117

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

121

Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

129

Abbildungsverzeichnis 1.1

Durchgängiger Entwicklungsprozess für vernetzte Funktionen . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11

V-Modell . . . . . . . . . . . . . . . . . . . . . . . . . Regelkreis . . . . . . . . . . . . . . . . . . . . . . . . . Autosar . . . . . . . . . . . . . . . . . . . . . . . . . . V-Modell mit dem Fokus auf der Softwareentwicklung . In-the-Loop-Test einer Implementierung . . . . . . . . . Co-Simulationen und Schrittweiten . . . . . . . . . . . . FMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . Co-Simulationen . . . . . . . . . . . . . . . . . . . . . Unterscheidung zwischen Open- und Closed-Loop-Tests Open-Loop-Test für die Funktion ABS . . . . . . . . . . Bewegungen eines Fahrzeugs . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

10 12 13 16 17 25 26 28 31 31 33

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22

Aufbau des Kapitels . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufbau einer Simulation . . . . . . . . . . . . . . . . . . . . . . . . Simulationsmodul am Beispiel der Lenkung . . . . . . . . . . . . . . Analyse der aktuellen vernetzten Funktionsentwicklung . . . . . . . . Austausch eines XiL-SW-Elements mit Integrationsstufenmanagement Modellbasierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenfassung der Testphasen . . . . . . . . . . . . . . . . . . . V-Modell mit Testphasen . . . . . . . . . . . . . . . . . . . . . . . . Workflow Testprozess . . . . . . . . . . . . . . . . . . . . . . . . . . Gegenüberstellung von Kopplungsverfahren . . . . . . . . . . . . . . Detaillierungsgrade von Modellen . . . . . . . . . . . . . . . . . . . Validierung vernetzter Module . . . . . . . . . . . . . . . . . . . . . Vorteil bei Verwendung der Werkzeuge . . . . . . . . . . . . . . . . Use-Case-Diagramm TSK . . . . . . . . . . . . . . . . . . . . . . . Funktionsweise des TSKs . . . . . . . . . . . . . . . . . . . . . . . . Modellverwalteroberfläche Testsystemkonfigurator . . . . . . . . . . Testsystemkonfigurator . . . . . . . . . . . . . . . . . . . . . . . . . Input hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modellvernetzung im TSK . . . . . . . . . . . . . . . . . . . . . . . Beispielhafter Bremsdruckverlauf im TSK . . . . . . . . . . . . . . . Beispielhafter Lenkwinkelverlauf im TSK . . . . . . . . . . . . . . . Ablauf der automatisierten Prüfung . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

35 38 39 44 45 49 53 54 56 61 64 68 71 73 74 75 76 77 78 81 82 84

4.1 4.2 4.3 4.4

Simulationsaufbau für DSR-Tests . . . . . . . . . . . . . . . . . . . . Verwendete Modelle für den Schnittstellentest am Beispiel der Lenkung Modellbasierter Testfall des DSR-Zustands der Lenkung . . . . . . . . Verwendete Modelle für den Variantentest . . . . . . . . . . . . . . . .

. . . .

. . . .

87 93 94 95

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

4

XIV

Abbildungsverzeichnis

4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

Lenkradwinkel mit verschiedenen Reibwerten . . . . Gierrate mit verschiedenen Reibwerten . . . . . . . . Lenkradwinkel bei verschiedenen Geschwindigkeiten Bremsdruck bei verschiedenen Geschwindigkeiten . Verwendete Modelle für die Bauteilauslegung . . . . μ-Split-Bremsung Radgeschwindigkeit vorne rechts . μ-Split-Bremsung Bremsdruck vorne links . . . . . . μ-Split-Bremsung Bremsdruck vorne rechts . . . . . μ-Split-Bremsung Längsbeschleunigung . . . . . . . μ-Split-Bremsung Lenkradwinkel . . . . . . . . . . Verwendete Modelle für die Vorapplikation . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

96 97 97 98 99 101 101 102 103 104 106

6.1

Testphasen ermöglichen schnellere Iterationsschleifen . . . . . . . . . . . .

115

7.1

Einsatz der Simulation im Entwicklungsprozess . . . . . . . . . . . . . . .

117

Tabellenverzeichnis 2.1

Bussysteme im Automobilbereich . . . . . . . . . . . . . . . . . . . . . .

14

3.1 3.2

Streckenmodelle für Testphasen . . . . . . . . . . . . . . . . . . . . . . . Merkmale für die Signalgenerierung . . . . . . . . . . . . . . . . . . . . .

67 80

Abkürzungsverzeichnis ABS ACC ACORTA ACOSAR Adams ADTF AEV AUTOSAR ASAM BCM DDS DIS DSR EPS ESC FOH FMEA FMI FMU FTire GRAL HiL HLA ICOS IS MAW MCDC MiL MKS

Antiblockiersystem Adaptive Cruise Control Advanced Co-Simulation Methods for Real-Time-Applications Advanced Co-Simulation Open System Architecture Automatic Dynamic Analysis of Mechanical Systems Automotive Data and Time-Triggered Framework Audi Electronic Venture GmbH Automotive Open System Architecture Association for Standardization of Automation and Measuring Systems Body Control Module Data Distribution Service Distributed Interactive Simulation Driver Steering Recommendation Electric Power Steering: Elektromechanische Servolenkung Electronic Stability Control: Fahrdynamikregelung First Order Hold: Kopplung erster Ordnung Failure Mode and Effects Analysis Functional Mockup Interface Functional Mockup Unit Flexible Structure Tire Model Graphing Library; eine freie Bibliothek zum Anzeigen von Plots in der Programmiersprache Java Hardware-in-the-Loop High Level Architecture Independent Co-Simulation Integrationsstufe Modellanalysewerkzeug Modified Condition/ Decision Coverage Model-in-the-Loop Mehrkörpersystem

XVIII

MVC OEM PiL SiL SOH SW TSK UML ViL XCP XiL XML ZOH ε f Abtast f max ω(t) ωΔT ΔT (t)

Abkürzungsverzeichnis

Model View Controller; Ein Softwarearchitekturmuster, bei dem Datenmodell, graphische Oberfläche und die Programmsteuerung voneinander getrennt sind. Original Equipment Manufacturer: Erstausrüster Processor-in-the-Loop Software-in-the-Loop Second Order Hold: Kopplung zweiter Ordnung Software Testsystemkonfigurator Unified Modeling Language; eine graphische Modellierungssprache zur Beschreibung und Konstruktion von Software und Systemen Vehicle-in-the-Loop Universal Measurement and Calibration Protocol beliebiges Testobjekt in-the-Loop Extensible Markup Language; ein Textdateiformat für die plattform- und implementierungsunabhängige Speicherung von hierarchischen Daten Zero Order Hold: Kopplung nullter Ordnung Das Skalar ε definiert eine erlaubte Abweichung Abtastrate eines Signals Maximal enthaltende Frequenz eines Signals Normierte maximale Frequenz eines Koppelsignals Übertragungsverhalten einer Kopplungsmethode eine Makroschrittweite

1 Einleitung In der Automobilindustrie bieten Kundenfunktionen wie Assistenzsysteme oder Komfort- und Sicherheitsfunktionen einen Nutzen für den Fahrer1 und seine Umgebung. Folgende Erkenntnis von Aristoteles verdeutlicht allerdings, dass das Zusammenspiel einzelner Teile komplex ist: „Das Ganze ist mehr als die Summe seiner Teile.“ [25] Teile stellen in diesem Kontext einzelne Bestandteile einer Kundenfunktion im Fahrzeug dar, wobei ihr Verhalten miteinander betrachtet mehr als die Summe der Einzelteile darstellt. Komplexität entsteht demnach, wenn die Teile zusammengebracht werden.

1.1 Motivation Kundenfunktionen2 werden in Fahrzeugen zunehmend durch den Einsatz von Software verwirklicht. In der Automobilindustrie sind solche Funktionen somit einer der Innovationstreiber. So bieten aktuelle Kundenfunktionen wie Abstands- oder Spurhalteassistenten bereits heute einen großen Mehrwert für den Kunden. Dies ist der Grund dafür, dass die Anzahl von Softwarefunktionen und der dafür benötigte Softwareumfang im Fahrzeug stetig ansteigen [94, siehe S. 18]. Zukünftig wird sich der Funktionsumfang vor dem Hintergrund des autonomen Fahrens für Fahrzeuge noch weiter erhöhen, denn Fahrzeuge unterstützen den Fahrer immer mehr bei der Steuerung des Fahrzeugs. Zur Realisierung der Funktionen befindet sich in Fahrzeugen eine Vielzahl an Steuergeräten sowie dazu benötigte Sensoren und Aktoren. Hierbei kommunizieren die Steuergeräte bzw. die Funktionsteile zunehmend miteinander, da sich Funktionsteile in immer stärkerem Maße über mehrere Steuergeräte verteilen. Die Entwicklung dieser sogenannten vernetzten Funktionen ist besonders aufwändig, da Funktionsteile verschiedener Steuergeräte für den Test benötigt werden. Erschwerend kommt hinzu, dass Funktionsteile oft von unterschiedlichen Zulieferern entwickelt werden. Zusätzlich zur steigenden Anzahl und Komplexität von Softwarefunktionen stellen größere Produktpaletten, eine größere Anzahl an Fahrzeugderivaten3 und kürzere Entwicklungszeiten besondere Herausforderungen für die Entwicklung neuer Fahrzeuge dar. Es werden daher effiziente Entwicklungsmethoden und -prozesse benötigt, um den Aufwand zu reduzieren. Dabei besteht das Ziel, bereits im frühen Entwicklungsstadium Aussagen über Funktionen im Fahrzeug treffen zu können. Im aktuellen Entwicklungsprozess wird zwischen Erprobungen im realen Fahrzeug, der Simulation von Steuergeräten auf Prüfständen und rein virtuellen Simulationen unterschieden. Im 1 2 3

Für eine bessere Lesbarkeit wird im Rahmen dieser Arbeit stellvertretend für alle Geschlechter stets die männliche Form verwendet. Siehe Unterkapitel 3.1.1 für eine Begriffsdefinition. Variante eines Fahrzeugs, die auf einem anderen Fahrzeug basiert.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9_1

2

1 Einleitung

letzteren Fall läuft eine zu testende Software nicht auf dem finalen Steuergerät, sondern z. B. auf einem PC. Im Unterschied zu Tests auf Prüfständen wird somit kein Objekt der Simulation als Hardwarekomponente verwendet. Traditionell werden Funktionen schwerpunktmäßig im Fahrversuch getestet. Durch den steigenden Aufwand kann dies jedoch zukünftig im Fahrversuch nicht wirtschaftlich effizient abgebildet werden, da der Testumfang wegen der Vernetzung4 außerhalb des Fahrzeugs weiter stark steigen wird. Für eine ausreichende Testabdeckung sind daher virtuelle Entwicklungsmethoden in Form von Simulationen notwendig. Diese sorgen zudem für eine Qualitätssteigerung in der Entwicklung, da Fehler schneller gefunden werden können und Fragestellungen, die sonst erst im Fahrversuch untersucht werden, zusätzlich bereits frühzeitig in der Simulation beurteilt werden können. In Bezug auf das autonome Fahren manifestiert sich der Eindruck, dass die Simulation ein essentielles Werkzeug für den Test ist. Derzeitige Untersuchungen ergeben, dass mit jedem Softwarestand eines autonomen Fahrzeugs drei Milliarden Testkilometer gefahren werden müssten, ohne dass es zu einer Falschauslösung kommen darf [110, S. 933]. Derartige Testumfänge können künftig wohl nur in rein virtuellen Simulationen bewältigt werden. Die Basis dafür bilden entsprechende Methoden, Werkzeuge und geeignete Simulationsmodelle. Zusätzlich zu Softwarefehlern können in Steuergeräten Hardwarefehler auftreten. Diese können auch zukünftig nicht vollständig mit virtuellen Simulationen gefunden werden. Hierfür eignen sich Testmethoden, bei denen das Steuergerät in Hardware vorliegt.5

1.2 Problemstellung Im Zuge der Digitalisierung, in der durchgängiges Systems Engineering und die modellbasierte Entwicklung im Mittelpunkt stehen, rücken zunehmend virtuelle Methoden für den Test von vernetzten Kundenfunktionen in den Fokus. Vor dem Hintergrund der virtuellen Homologationen6 und dem hochautomatisierten Fahren stehen Entwickler vor folgenden Herausforderungen: • Fehlende Reife von Software bei der Inbetriebnahme in einer frühen Entwicklungsphase. • Der Test von Softwareänderungen oder Applikationen können nur bedingt parallelisiert werden, da Softwareänderungen auf einzelnen Funktionsteilen Einflüsse auf andere Funktionsteile oder Funktionen haben können. • Die Genauigkeit von Simulationen reicht nicht aus, damit auch Tests, die eine hohe Übereinstimmung zwischen Versuch und Simulation erfordern, in die Simulation verlagert werden können. • Es können nicht kontinuierlich alle Varianten7 während der Entwicklung getestet werden, da die Anzahl von Prüfständen und Versuchsfahrzeugen nicht ausreicht. 4 5 6 7

Fahrzeuge kommunizieren z. B. zunehmend mit dem Internet und untereinander. Hierfür eignen sich die Testmethoden HiL und PiL, vgl. Abschnitt 2.2.4. Überstaatliches System für die Zulassung von Fahrzeugen oder Fahrzeugteilen. Z. B. Ausstattung eines Fahrzeugs, verschiedene Parametrisierungen einer Funktion, verschiedene Manöver, lernende Funktionen, etc.

1.3 Lösungsansatz

3

• Die aktuelle Entwicklung von Kundenfunktionen im Fahrzeug fokussiert auf Bauteile und einzelne Steuergeräte. Eine strukturierte Systemsimulation wird benötigt. Die Simulation von softwarebasierten Funktionen ist komplex, denn im Entwicklungsprozess existieren unterschiedliche Fragestellungen in den Entwicklungsphasen einer Kundenfunktion. Für den Test von vernetzten Softwarefunktionen mit mechatronischen Systemen greifen zudem verschiedene Domänen8 ineinander, sodass eine übergreifende Abstimmung zwischen Entwicklungspartnern erforderlich ist. Hier bestehen die größten Herausforderungen bzgl. der verwendeten Simulationsmodelle. Wenn diese beispielsweise für verschiedene Fragestellungen wiederverwendet werden, sind sie in Bezug auf bestimmte Aspekte ungeeignet und müssen deshalb ggf. neu erstellt werden. Ein Simulationsmodell, das Aussagen über die auftretenden Kräfte beim Hochfahren eines Bordsteins zulässt, ist z. B. nicht unbedingt für Schwingungsanalysen beim Bremsen geeignet, da hierfür andere Teile des Realsystems untersucht werden müssen. Es besteht aktuell kein systematisches Vorgehen, das Eigenschaften von Simulationsmodellen für verschiedene Testanforderungen definiert. Die Modelle sind jedoch notwendig, um die oben genannten Testziele erfüllen zu können. Die folgenden Eigenschaften von Simulationsmodellen fassen die Herausforderungen zusammen: • Simulationsmodelle sind nicht für alle benötigten Anwendungsbereiche geeignet und können somit nicht für alle Tests verwendet werden. • Die Kopplung von Modellen führt zu numerischen Problemen. • Die Teilmodelle bilden nicht alle benötigten Teile eines Realsystems ab. • Die Teilmodelle bilden nicht benötigte Teile eines Realsystems ab. • Die Teilmodelle eines Gesamtmodells bilden das Realsystem in unterschiedlicher Detaillierung ab. • Eine Wiederverwendung von Modellen für PCs auf Prüfständen ist nur bedingt möglich. • Die Vernetzung von Teilmodellen zu einem Gesamtmodell erfolgt manuell und ist daher fehleranfällig. In der Praxis besteht meist einerseits die Anforderung, dass die gleichen Funktionen in verschiedenen Domänen und Kontexten simuliert werden können. Andererseits werden für verschiedene Domänen Modelle mit unterschiedlichen Eigenschaften benötigt. Beispielsweise lassen sich mechanische Schwingungsanalysen nur bedingt mit einem Modell durchführen, das für die Verwendung auf Prüfständen vereinfacht wurde.

1.3 Lösungsansatz Im Rahmen der Dissertation wird eine Methodik entwickelt, die es erlaubt, Soft- und Hardwarekomponenten durchgängig in allen Phasen des Entwicklungsprozesses einzubinden, in denen ein Test durch Simulation zum Einsatz kommt9 . Hierdurch können Tests gezielt in die Simulation 8 9

Elektrik, Hydraulik und Mechanik. Z. B. Schnittstellentests oder Tests auf Prüfständen.

4

1 Einleitung

vorgelagert werden und es resultiert eine Qualitätssteigerung in der Entwicklung. Die entwickelte Methodik wird anhand eines konkreten Beispiels in die Praxis überführt. Indem ein neuer Ansatz entwickelt wurde, lassen sich die Eigenschaften von Simulationsmodellen für den Test nun systematisch beschreiben und prüfen. Das Ziel liegt in einem durchgängigem Simulationsaufbau, bei dem virtuelle Steuergeräte flexibel durch Hardwarekomponenten ersetzt werden können. Der neu entwickelte Ansatz besteht darin, Testanforderungen im Entwicklungsprozess systematisch zu strukturieren. Anhand dessen werden benötigte Modelleigenschaften definiert, damit sichergestellt wird, dass Simulationsmodelle für Tests verwendet werden können. 1.3.1 Vorgehensweise Eine allgemeine Vorgehensweise für einen durchgängigen Simulationsaufbau ist systematisch in Abbildung 1.1 skizziert. Die Vernetzung besteht hier beispielhaft aus einem Lenkungs- und einem Bremsensteuergerät sowie einem Fahrdynamikmodell10 . Hardware

Virtuell

Software

Hardware

Hardware

Virtuell

Software

Hardware

Hardware

Virtuell

Software

Hardware

Modell

Modell

Modell

Modell

Modell

Modell

Abbildung 1.1: Durchgängiger Entwicklungsprozess für vernetzte Funktionen nach [52, S. 3]

In der Abbildung links ist eine rein virtuelle Simulation11 dargestellt. Des Weiteren werden Mischbetriebe mit Steuergeräten in Hardware und mit virtuellen Steuergeräten abgebildet. Als drittes sind gekoppelte Prüfstände visualisiert. Dieser Simulationsaufbau entspricht dem maximalen Hardwareumfang im Vergleich zum Fahrversuch. Generell werden die verschiedenen Testanforderungen zunächst mithilfe von Testphasen strukturiert. Hierbei bestehen unterschiedliche Testanforderungen zu verschiedenen Zeitpunkten in der Entwicklung, siehe Unterkapitel 3.3.

10 11

In einem Fahrdynamikmodell werden mechanische Eigenschaften für die Darstellung der Quer-, Längs- und Vertikaldynamik eines Fahrzeugs dargestellt, siehe Unterkapitel 2.7 für weitere Informationen. Zu testende Software läuft nicht auf dem finalen Chip, sondern z. B. auf einem PC oder Server.

1.3 Lösungsansatz

5

Damit ein bedarfsgerechter Aufbau von Simulationsumgebungen geschaffen werden kann, müssen zudem Modelleigenschaften wie z. B. Gültigkeitsbereiche und Schnittstellen abteilungsübergreifend abgestimmt und festgelegt werden, siehe Unterkapitel 3.4. Dies ist die Basis dafür, dass ein kontinuierlicher und durchgängiger Simulationsaufbau von vernetzten Steuergeräten geschaffen werden kann. Darüber hinaus reduziert sich der Änderungsbedarf an Modellen auf ein Minimum. 1.3.2 Ziele der Arbeit Das Ziel dieser Arbeit besteht darin, eine Methodik zu entwickeln, die einen effizienten Simulationsaufbau innerhalb des Fahrzeugs ermöglicht. Hierbei sollen Lösungsvorschläge für die genannten Herausforderungen beim Test von hochautomatisierten Fahrfunktionen vorgestellt werden. Das wissenschaftliche Ziel der Arbeit ist die Definition von Anforderungen und Modelleigenschaften, die eine Wiederverwendbarkeit von Simulationsmodellen in verschiedenen zu definierenden Testphasen sicherstellen, wobei eine stabile Kopplung zwischen einzelnen Modellen gewährleistet werden soll. Hierfür sollen zunächst verschiedene Testphasen für die Entwicklung vernetzter Funktionen spezifiziert werden. Aus den Testphasen sollen wiederum dafür benötigte Modelleigenschaften abgeleitet werden. Ein Aspekt dabei ist, dass Modelle in verschiedenen Abteilungen der technischen Entwicklung und im Entwicklungsprozess wiederverwendet werden können. Die Wiederverwendbarkeit ist notwendig, da modulare Simulationsmodelle den Neuaufbau einer Gesamtsimulation erheblich erleichtern. Die kontinuierliche Verbesserung einzelner Modelle erlaubt so eine genauere Aussage über die Güte der Modelle. Zukünftig könnten darauf aufbauend auch statistische Quantifizierungen durchgeführt werden, die die Qualität im Entwicklungsprozess sicherstellen. Eine Abdeckung der gesamten Anforderungen soll dabei mit einer möglichst geringen Anzahl von Simulationsmodellen ermöglicht werden. Ein weiteres Ziel der Arbeit besteht in der Definition von Voraussetzungen, die Simulationsmodelle bezüglich der Wiederverwendbarkeit aufweisen müssen. Dabei liegt eine Schwierigkeit z. B. darin, dass Prüfstände Echtzeitanforderungen im niedrigen Millisekundenbereich besitzen. In der rein PC-basierten Offline-Simulation ohne reale Hardware können Modelle hingegen langsamer oder schneller als in der Realität laufen. In beiden Fällen kann es zusätzlich zu numerischen Problemen durch die Kopplung kommen, die im Rahmen der Arbeit aufgezeigt und behandelt werden. Diese Arbeit soll darüber hinaus Möglichkeiten beschreiben, die Lücken beim Test durch Simulationen im Entwicklungsprozess zu schließen. Hierfür werden benötige Anforderungen und Eigenschaften von Simulationsmodellen definiert und bewertbar gemacht. Auf diese Weise können die erforderlichen Modelleigenschaften mithilfe von neu entwickelten und hier vorgestellten Werkzeugen automatisiert definiert und überprüft werden. Damit soll die Verwirklichung einer durchgängigen Methodik für vernetzte Funktionen ermöglicht werden, wobei unterschiedliche Modelleigenschaften die Durchführbarkeit der Simulation für verschiedene Testanforderungen im Entwicklungsprozess sicherstellen. Die entwickelte Methode soll dazu führen, dass der finanzielle und zeitliche Aufwand für den Testaufbau mithilfe von Simulationen deutlich reduziert wird, damit eine Funktionsentwicklung

6

1 Einleitung

mithilfe der Simulation ermöglicht werden kann. Hierbei sollen insbesondere die damit einhergehenden Fragestellungen bzgl. der Anforderungen an Simulationsmodelle gelöst werden. Es wird berücksichtigt, dass die Genauigkeit für die benötigten Testphasen unterschiedlich sein kann, wobei keine zusätzlichen Abweichungen durch die Kopplung entstehen.

1.4 Bezug und Abgrenzung zu verwandten Arbeiten Nach eingehender Betrachtung bisheriger Veröffentlichungen kann festgestellt werden, dass in der Literatur bereits einige Forschungsergebnisse zu durchgängigen Simulationsprozessen dokumentiert sind. In [114] wurde beispielsweise ein Prozess für die frühe Produktentstehung definiert. Ferner behandelte die Arbeitsgruppe Fidelity Implementation Study Group Eigenschaften von Simulationsmodellen, siehe [60]. Für die Kopplung von Prüfständen mit PCs und Prüfständen gibt es bereits Methoden, die Auswirkungen durch Totzeiten in der Kommunikation sowie Datenverluste und Rauschen kompensieren bzw. unterdrücken können [34]. Darüber hinaus wurde ein durchgängiges Validierungsframework für die Fahrzeugentwicklung entwickelt, das auf eine Gesamtarchitektur mit Einbeziehung des Fahrers und der Umwelt fokussiert, vgl. [46]. Überdies gibt es Ansätze, die unterschiedliche Entwicklungszyklen für verschiedene Funktionsarten aufzeigen, so dass Basis- oder Sicherheitsfunktionalitäten langsamer entwickelt werden als z. B. Funktionen im Infotainment, vgl. [81]. Für den Test von vernetzten Funktionen wird ein durchgängiges Simulationsmodell mit austauschbaren Teilkomponenten vorgeschlagen. Der Fokus des letzten Ansatzes liegt auf der kontinuierlichen Integration von Hardware und einfacheren Modellen12 im Kontext von Integrationstests, da hierdurch die Funktionsabsicherung effizienter gestaltet werden kann. Bzgl. eines durchgängigen Simulationsprozesses für Softwaretests kann zusammengefasst werden, dass bestehende Ansätze nicht für die Funktionsentwicklung von vernetzten Fahrfunktionen geeignet sind. Hier müssen heterogene Simulationsmodelle miteinander gekoppelt werden. Im Gegensatz zu allen vorgestellten Forschungsergebnissen in der Literatur fokussiert diese Arbeit außerdem auf detaillierte Modelle und verschiedene Anforderungen beim Test von Software durch Simulation, da diese für z. B. für die virtuelle Homologation von Softwarevarianten benötigt werden. Es besteht zudem der Anspruch auf die Wiederverwendung von Modellen. Dafür müssen die benötigten Eigenschaften von Simulationsmodellen für die verschiedenen Anforderungen bei Funktionstests definiert werden. Die Kommunikation zwischen Steuergeräten, Hardware und Simulationsmodellen beschränkt sich im Rahmen dieser Arbeit auf diskrete, quasi-kontinuierliche und kontinuierliche Signale in Zusammenhang auf physikalische Modelle von Bauteilen. Event-basierte Austauschmechanismen und die Umfeldsensorik wie z. B. Radar- oder Kameramodelle, die ggf. über den Austausch von Objektlisten kommunizieren, stehen nicht im Fokus der Arbeit. Hier besteht zusätzlicher Forschungsbedarf, der im Rahmen der vorliegenden Arbeit nicht betrachtet werden kann. Die entwickelte Methodik ist nicht domänenspezifisch, wobei die Anwendungsfälle im Hinblick auf die Herausforderungen bei der Entwicklung von Fahrfunktionen schwerpunktmäßig aus dem Bereich der Steuergeräteentwicklung im Fahrwerk gewählt wurden. Im Folgenden wird auf den Aufbau der Arbeit eingegangen. 12

Z. B. Restbusmodelle.

1.5 Aufbau der Arbeit

7

1.5 Aufbau der Arbeit Um in das Thema einzuführen, wird in Kapitel 2 zunächst der Stand der Technik im Kontext der Entwicklung von Steuergeräten im Fahrzeug aufgezeigt. Der Schwerpunkt liegt neben der Entwicklung und den Testinstanzen von Steuergeräten auf der Simulation. In Kapitel 3, dem Hauptteil der Arbeit, wird zunächst eine klare Begriffsdefinition für diese Arbeit im Kontext der Steuergerätesimulation geschaffen. Anschließend werden Eigenschaften von Steuergeräten und Funktionen im Entwicklungsprozess analysiert. Das nachfolgende Unterkapitel 3.3 zeigt unterschiedliche Testanforderungen auf. Hier werden Strukturierungen in Form von Testphasen vorgenommen und anschließend Zusammenhänge zwischen Testphasen beleuchtet. Unterkapitel 3.4 klassifiziert mithilfe verschiedener Eigenschaften und Anforderungen benötigte Simulationsmodelle auf Basis der Testphasen. Darauf aufbauend werden Weiterentwicklungen von Modellen sowie ein Validierungskonzept für vernetzte Funktionen vorgestellt. Für eine automatisierte Einhaltung der Eigenschaften und Anforderungen werden in Unterkapitel 3.5 Werkzeuge für die Definition und Prüfung von Modelleigenschaften vorgestellt. In Kapitel 4 wird die Methode für die durchgängige Integration von Hardware und Softwaremodellen in die Praxis überführt, worauf in Kapitel 5 die Zusammenfassung folgt. Anschließend beinhaltet das Fazit in Kapitel 6 eine Darstellung, inwiefern die Ziele erfüllt wurden. Zum Schluss wird auf weitere Forschungsfelder und mögliche weiterführende Arbeiten hingewiesen.

2 Stand der Technik In diesem Kapitel wird der Stand der Technik in Bezug auf die Simulation von vernetzten Funktionen dargestellt. Hierfür wird zunächst der Entwicklungsprozess beschrieben. Daraufhin werden generelle Funktionsweisen von Steuergeräten aufgezeigt und auf deren Vernetzung untereinander eingegangen. Anschließend werden Grundlagen der Simulation in Bezug auf vernetzte Funktionen aufgezeigt. Da für solche Funktionen stets verschiedene Simulationsmodelle bzw. Prüfstände gekoppelt werden, gibt es zudem einen Überblick über Kopplungsmethoden13 . Abgeschlossen wird das Kapitel mit einer Vorstellung aktueller Testmethoden und Grundlagen der Fahrdynamik. Bisherige Entwicklungsansätze für Fahrzeuge gehen vom Gesamtsystem aus und es werden anschließend Anforderungen an einzelne Bauteile definiert. Ein neuer Ansatz bei der Entwicklung von Fahrzeugen stellt hingegen nicht die einzelnen Bauteile, sondern die Funktion für den Kunden in den Fokus14 . Solche Fahrzeugfunktionen werden zunehmend mithilfe von mechatronischen Systemen umgesetzt. Diese werden im folgenden Unterkapitel erläutert.

2.1 Entwicklungsprozess mechatronischer Systeme Ein mechatronisches System besteht aus mechanischen, elektrischen Bauteilen und einem Steuergerät mit der darauf laufenden Software. Bei der Entwicklung solcher Systeme wird in der Automobilindustrie gewöhnlich nach dem von Barry Boehm im Jahre 1979 vorgestellten V-Modell vorgegangen. Hierbei stellen Phasenergebnisse verpflichtende Vorgaben für darunterliegende Schritte dar. Abbildung 2.1 veranschaulicht die dreistufige Entwicklungsvorgehensweise für mechatronische Systeme. Hierbei werden zunächst Anforderungen auf der Systemebene definiert. Darauf aufbauend erfolgt der Entwurf auf Systemebene. Anschließend werden Anforderungen auf der Subsystemebene erhoben und es folgt der Entwurf auf Subsystemebene. Auf Komponentenebene erfolgt die Ausarbeitung bzw. Verfeinerung und die Fertigung bzw. Implementierung der verschiedenen Physik-, Hardware- und Softwarekomponenten. Der Begriff Physik ist als Obermenge für hydraulische, mechanische und elektrische Komponenten zu verstehen. Nach der Durchführung von Komponententests werden die Software-, Hardware15 - und Physikkomponenten schrittweise wieder zusammengesetzt, was auf der rechten Seite des V-Modells dargestellt ist. Zuletzt erfolgt die Integration in das Gesamtsystem.

13 14 15

Beschreibung von Möglichkeiten und Methoden, wie Modelle oder Prüfstände miteinander verbunden werden können. Die funktionsorientierte Entwicklung existiert bereits. Sie stellt jedoch die Entwicklung der Funktion in den Fokus und nicht den Test einer Funktion mithilfe von Simulationen. Z. B. Prozessor und Speicher eines Steuergeräts.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9_2

10

2 Stand der Technik

6\VWHP

6XEV\VWHP

.RPSRQHQWHQ Abbildung 2.1: Dreischichtiges V-Modell eines mechatronischen Systems

Jeder Kompositionsschritt auf der rechten Seite des V-Modells wird anhand der entsprechenden Anforderungen auf der linken Seite validiert16 bzw. verifiziert17 . Als Weiterentwicklung des V-Modells wurde das V-Modell-XT vorgestellt, vgl. [29]. Das XT steht dabei für Xtreme Tailoring. Tailoring bedeutet, dass das V-Modell projektspezifisch angepasst werden darf und ggf. Entwicklungsschleifen innerhalb des V-Modells durchgeführt werden dürfen. Hierbei wird zwischen statischem18 und dynamischem Tailoring19 unterschieden. Dies ermöglicht, dass der Auftraggeber in größerem Maße in den Entwicklungsprozess eingebunden wird, indem stärker und schneller auf seine Anforderungen eingegangen werden kann. Darüber hinaus soll die Kommunikation zwischen den Beteiligten verbessert werden. So ergeben sich eine Vielzahl von Vorteilen, einerseits die Minimierung von Projektrisiken, andererseits die Gewährleistung der Qualität und darüber hinaus die Eindämmung der Gesamtkosten [29, S. 6]. Die jetzigen Entwicklungsprozesse beziehen sich nach aktuellem Stand stets auf Bauteile. Neuere Ansätze wenden das V-Modells XT für die Fahrzeugentwicklung an, vgl. [45]. Im Gegensatz zum bisher etablierten, bauteilorientierten Ansatz sollten Prozesse zukünftig schrittweise in

16 17 18 19

„Die Bestätigung durch objektiven Nachweis, dass die Anforderungen für eine bestimmte Anwendung oder einen bestimmten Gebrauch erfüllt sind“ [17, Abschnitt 3.8.5]. „Bestätigung durch einen objektiven Nachweis, dass Anforderungen erfüllt werden“ [17, Abschnitt 3.8.4]. Tailoring nur während der Projektinitialisierung. Tailoring im weiteren Projektverlauf.

2.2 Steuergeräte im Fahrzeug

11

funktionsorientierte Entwicklungen ausgerichtet werden. Dieser Ansatz bietet die Grundlage der vorliegenden Arbeit und wird in Abschnitt 3.2.1 wieder aufgegriffen.

2.2 Steuergeräte im Fahrzeug In Landmaschinen, Lastkraftwagen, Flugzeugen und besonders aber in der Automobilindustrie spielen Steuergeräte eine immer wichtigere Rolle, denn neue Fahrerassistenz-, Sicherheits-und Komfortfunktionen sind aktuelle Innovationstreiber. Im folgenden Abschnitt werden Eigenschaften sowie der generelle Aufbau von Steuergeräten dargestellt. 2.2.1 Steuergeräte Steuergeräte sind elektrische Module, die im Regelfall die Aufgabe haben, die Steuerung oder Regelung einer zugrunde liegenden Maschine, Anlage oder eines technischen Prozesses durchzuführen. Ein Motorsteuersteuergerät regelt beispielsweise die Verbrennungsprozesse eines Motors20 , ein Lenkungssteuergerät unterstützt mithilfe eines Servomotors die Lenkwünsche des Fahrers21 . Steuergeräte arbeiten im Allgemeinen nach dem EVA22 -Prinzip, einem Grundprinzip der Datenverarbeitung. Mithilfe von Sensoren23 werden zunächst Eingangsdaten erfasst. Anschließend werden diese vom Steuergerät verarbeitet. Darauf aufbauend steuern neu ermittelte Regelungsoder Stellgrößen mithilfe von Aktoren24 den zu regelnden Prozess. In einigen Fällen hat ein Steuergerät keine spezifische regelungstechnische Aufgabe, sondern es ist lediglich ein Datenlieferant für andere Steuergeräte. Dies kann beispielsweise bei einem Steuergerät eines Kamera- oder Radarsensors der Fall sein, wenn Objektlisten oder Abstände ermittelt werden, die als Eingangsdaten von anderen Steuergeräten benötigt werden. In vielen Fällen liegt einem Steuergerät ein mechanisches25 , elektrisches26 oder hydraulisches27 System zugrunde. Das EVA-Prinzip ist in diesen Fällen Teil eines Regelkreises. Ein Regelkreis besteht im einfachsten Fall aus einem Regler und einer Regelstrecke. Der Regler berechnet eine Stellgröße, die auf die Strecke wirkt. Aus der Strecke wird wiederum eine Regelgröße zurück zum Regler geführt. Abbildung 2.2 zeigt ein erweitertes Blockschaltbild. Es sind zusätzlich zu Strecke und Regler noch Stell- und Messglieder aufgeführt, die im Fahrzeug in Form von Aktoren bzw. Sensoren vorhanden sind. Zu einem Steuergerät gehören außer der Regelstrecke alle Bestandteile des vorgestellten Regelkreises. Der Regler befindet sich gewöhnlich als Software auf dem Steuergerät selbst. Weiterhin gehören Mess- und Stellglieder zum Steuergerät. Bei einem Bremssteuergerät sind dies z. B. Ventile sowie Lage- und Geschwindigkeitssensoren. Die Regelstrecke ist in diesem Fall das 20 21 22 23 24 25 26 27

Bei Fahrzeugen mit Verbrennungsmotoren. Bei elektrischen Lenksystemen. Eingabe, Verarbeitung, Ausgabe. Ein Bauteil, das physikalische oder chemische Eigenschaften in ein elektrisches Signal umformt. Ein Bauteil, das elektrische Signale in physikalische Größen wie z. B. Druck umwandelt. Z. B. aktives Lenksystem im Fahrzeug. Z. B. Servomotor einer Lenkung. Z. B. hydraulisches Bremssystem.

12

2 Stand der Technik

5HJHO DEZHLFKXQJ )KUXQJVJU|‰H ZW 

HW

5HJOHU

6WHOOJU|‰H XW

6WHOOJU|‰H XVW

6WHOOJOLHG

5FNIKUXQJ\PW

6W|UJU|‰H GW

5HJHOVWUHFNH

5HJHOJU|‰H \W

0HVVJOLHG

Abbildung 2.2: Blockschaltbild Regelkreis, nach Bildquelle: [67]

Fahrzeug, das mithilfe des hydraulischen Bremssystems beeinflusst wird, indem der Druck der Bremsbelege an den Rädern gestellt wird. Die Regelung eines Bremssystems hängt zusätzlich noch von Eingriffen und Zuständen anderer Funktionen wie beispielsweise Fahrassistenzsystemen für Anhängerstabilisierungen, Parkassistenten oder ACC28 ab. Dies zeigt, dass der Test von Steuergeräten eine große Herausforderung darstellt. Für jeweilige Tests müssen viele äußere Faktoren berücksichtigt werden und es existieren Regelkreise, die wiederum weitere Regelkreise steuern. 2.2.2 Steuergerätearchitekturen In diesem Abschnitt werden Architekturen von Steuergeräten erläutert, da dieses Wissen für den Test von vernetzten Funktionen von Bedeutung ist. Die bekannteste Steuergerätearchitektur ist AUTOSAR [3], es existieren aber auch andere Vorschläge für Steuergerätearchitekturen, vgl. [69]. AUTOSAR wurde von OEMs, Zulieferern und Softwareherstellern im Rahmen einer gleichnamigen Entwicklungspartnerschaft definiert, die im Jahr 2003 gegründet wurde. Zu einem Steuergerät gehören hardwareseitig zusätzlich zu Sensoren, Aktoren und Steuerchips beispielsweise auch Kommunikationsschnittstellen zu Bussystemen. Softwareseitig werden unter anderem Regelalgorithmen, Diagnosedienste, Hardwaretreiber sowie ein Echtzeitbetriebssystem benötigt. AUTOSAR definiert jegliche Schnittstellen bezüglich der Software und modularisiert die Bestandteile, siehe Abbildung 2.3. AUTOSAR schreibt hierbei eine strikte Trennung von steuergeräteabhängiger Basissoftware und steuergeräteunabhängiger Applikationssoftware vor, damit die Softwareteile in größerem Maß entkoppelt werden. Zur Applikationssoftware gehören die verschiedenen Regelfunktionen. Die gesamte Applikationssoftware setzt sich aus verschiedenen Applikationssoftwarekomponenten zusammen. Die Basissoftware verfügt über die benötigten Bestandteile, um die Applikationssoftware zu betreiben. Hierzu gehören die Kommunikationsdienste, das Betriebssystem oder auch Hardwaretreiber, welche die Ansteuerung der zugrundeliegenden Hardware erlauben.

28

Adaptive Cruise Control ist eine Geschwindigkeitsregelanlage, die den Abstand des vorausfahrenden Fahrzeugs miteinbezieht.

2.2 Steuergeräte im Fahrzeug

$SSOLFDWLRQ 6RIWZDUH &RPSRQHQW

13

$SSOLFDWLRQ 6RIWZDUH &RPSRQHQW

$SSOLFDWLRQ 6RIWZDUH &RPSRQHQW

$8726$56RIWZDUH

«

$SSOLFDWLRQ 6RIWZDUH &RPSRQHQW

$8726$50LGGOHZDUH

$8726$55XQWLPH (QYLURQPHQW57(

6HUYLFHV

&RPPXQLFDWLRQ

(&8 $EVWUDFWLRQ

2SHUDWLQJ 6\VWHP %DVLF6RIWZDUH

0LFURFRQWUROOHU $EVWUDFWLRQ

&RPSOH[ 'HYLFH 'ULYHUV

(&8+DUGZDUH Abbildung 2.3: Steuergerätearchitektur AUTOSAR, nach Bildquelle: [27]

Der größte Vorteil dieser Architektur besteht darin, dass Applikationssoftwarekomponenten gekapselt und unabhängig von der Hardware vorliegen. Dies ermöglicht ein Verschieben von Funktionsteilen zwischen verschiedenen Steuergeräten. Verwirklicht wird dies durch das Kernstück von AUTOSAR, der Runtime Environment. Diese fungiert zur Laufzeit als virtueller Bus, der eine korrekte Kommunikation zwischen Applikationssoftwarekomponenten untereinander und der Basissoftware sicherstellt. Hinzu kommt, dass die Trennung zwischen Basis- und Applikationssoftware zu einer höheren Portierbarkeit29 und Wiederverwendbarkeit der Applikationssoftware führt. Ein Nachteil stellt jedoch der verhältnismäßig hohe Aufwand dar, einen bestehenden in einen AUTOSAR-konformen Code umzuwandeln. Vor dem Hintergrund, dass heutige Fahrzeuge mehr als 100 Millionen Codezeilen haben können, ist die Wiederverwendung von Code zwingend erforderlich. Es ist finanziell und vom Aufwand her nicht möglich, alle Codeteile für ein spezifisches Fahrzeug neu zu implementieren. Etablierte Codeteile werden daher oft wiederverwendet und erfordern teilweise eine spezifische Soft- und Hardwarearchitektur. Dies führt dazu, dass ein bestehender Code neu geschrieben oder angepasst werden muss, damit er in eine spezifische Architektur integriert werden kann. Es existieren oft firmenspezifische Steuergerätearchitekturen. Die Steuergerätearchitektur AUTOSAR kommt aufgrund der Vorteile dennoch immer häufiger zum Einsatz und wird zunehmend von OEMs gefordert.

29

Beschreibt den benötigten Aufwand, um Code für andere Zielplattformen zu kompilieren.

14

2 Stand der Technik

2.2.3 Steuergerätevernetzung im Fahrzeug Moderne Fahrzeuge können über mehr als 100 Steuergeräte verfügen [38], die durch ihre Verbindungen ein komplexes Netzwerk von Funktionen bilden. Hierbei hängt die Funktionsweise eines einzelnen Steuergeräts oft von anderen ab. Dies zeigt sich z. B. beim Starten eines Autos; hier starten einzelne Steuergeräte andere in einer definierten Reihenfolge, die sich zuvor in einem stromsparenden Betriebszustand befinden. Beim Ausschalten des Autos schalten einzelne Steuergeräte andere analog wieder ab30 . Es steigt in aktuellen Fahrzeugen nicht nur die Anzahl von Funktionen, sondern auch die Komplexität in der Vernetzung nimmt immer mehr zu, da die Funktionsteile zunehmend interagieren. So greift ein Navigationssysteme beispielsweise auf Radgeschwindigkeiten des Bremssteuergeräts zurück, um genauere Daten zur Fahrzeugposition zu berechnen. Die Vernetzung von verschiedenen Steuergeräten erfolgt im Fahrzeug über standardisierte Bussysteme. Nach aktuellem Stand sind die in Tabelle 2.1 aufgeführten Bussysteme im Automobilbereich etabliert. Tabelle 2.1: Bussysteme im Automobilbereich [90][115]

Bussystem

Eigenschaften

LIN CAN CAN-FD Flexray MOST Automotive Ethernet

maximale Datenrate [Mbit/s] 0.0104 1 8 10 24.8 100

Arbitrierung

Topologie

zentral dezentral dezentral zentral und dezentral zentral dezentral

Feldbus Stern, Linie Stern, Linie Stern, Bus Ring Stern, Linie, Cluster

In den Tabellenzeilen sind die verschiedenen Bussysteme aufgeführt, in den Spalten befinden sich Informationen über die Eigenschaften dieser Bussysteme. Heutige Fahrzeuge setzen sich aus mehreren getrennten Bussystemen zusammen, die über sogenannte Gateways miteinander verbunden werden [115, S. 32]. Somit können auch busübergreifend Daten ausgetauscht werden. Eine wichtige Eigenschaft eines Bussystems ist die Datenrate. Typischerweise haben Bussysteme mit niedrigerer Datenrate sowohl geringere Kosten bei der Beschaffung als auch in der Entwicklung, da sich die Konfiguration einfacherer Bussysteme mit geringerem Datenvolumen simpler gestaltet. Hierzu zählt beispielsweise der LiN-Bus. Für sicherheitskritische Anwendungen wie Brems- oder Lenksysteme wird in der Regel der CAN-Bus oder der deterministische Teil von Flexray31 verwendet. Der Nachfolger des CAN-Buses, CAN-FD, besitzt eine höhere Datenrate als der CAN-Bus. Er eignet sich daher, wenn größere Datenmengen als auf dem CAN-Bus übertragen werden müssen. 30 31

Dieser Prozess nennt sich Nachlauf, vgl. [109]. Flexray hat einen deterministischen Anteil, in dem jedes Steuergerät in einem bestimmten Zeitfenster Daten sendet.

2.2 Steuergeräte im Fahrzeug

15

Für Multimedia-Anwendungen eignen sich eher MOST, Ethernet sowie der nichtdeterministische Teil von Flexray32 . Die zweite Spalte der Tabelle gibt Aufschluss über die Arbitrierung. Eine Arbitrierung bestimmt den Entscheidungsmechanismus, welches Steuergerät wann welche Daten senden darf. Bei zentraler Arbitrierung gibt ein Steuergerät oder zentrales Modul eine Taktrate oder feste Sendezeitfenster für alle Teilnehmer vor. Bei dezentraler Arbitrierung existiert keine zentrale Steuereinheit, sondern die Sendezeit der Nachrichten wird mithilfe der Teilnehmer über die Botschaften selbst bestimmt. Dies kann dazu führen, dass einzelne Teilnehmer nicht senden können, wenn höher priorisierte Nachrichten den Bus blockieren. Hier schafft eine geringere Auslastung eines Bussystems Abhilfe. Ein sehr weit verbreitetes Busprotokoll ist der CAN-Bus; die Arbitrierung erfolgt dezentral und es können alle Steuergeräte gleichzeitig senden und empfangen. Höher priorisierte Nachrichten werden dabei zuerst gesendet. Beim Busprotokoll Flexray gibt es ein zentral gesteuertes Zeitfenster, in dem bestimmte Botschaften gesendet werden. Zudem existiert ein dezentral gesteuertes Zeitfenster, das von der Funktionsweise her dem CAN-Bus ähnelt. In der dritten Spalte sind die verschiedenen Topologievarianten aufgeführt. In Fahrzeugen ist aktuell die Linienstruktur weit verbreitet, denn für eine zentrale Arbitrierung wird ggf. zusätzliche Hardware benötigt. Der Aufbau der Gesamtarchitektur von vernetzten Steuergeräten ist Gegenstand aktueller Forschungs- und Entwicklungsarbeiten. Beispielsweise existieren beim Automobilhersteller Audi Aktivitäten in Form einer zusätzlichen Abstraktionsschicht, indem ein Steuergerät33 eine zentrale Sensordatenfusion durchführt [26]. Das Steuergerät verarbeitet und führt alle Sensordaten zusammen, um andere Steuergeräte mit passenden Daten zu versorgen. An dieser Stelle soll lediglich ein Einblick in die komplexe Vernetzung eines Fahrzeugs gegeben werden, da sie für den Test und für das allgemeine Verständnis von vernetzten Funktionen eine wichtige Rolle spielt. Wenn Funktionalitäten anderer Steuergeräte für einen Test benötigt werden, müssen sie in geeigneter Art und Weise zur Verfügung stehen. Welche Funktionsteile anderer Steuergeräte gebraucht werden, hängt letztlich vom Testfokus ab. Bei der Entwicklung einer Funktion können verschiedene Testinstanzen durchlaufen werden. Diese werden im Folgenden vorgestellt. 2.2.4 Entwicklungsprozess von Steuergeräten Aktuelle Steuergeräte werden oft von Zulieferern entwickelt, die wiederum Dienstleister und weitere Zulieferer haben können. Es gibt zudem eigenentwickelte Steuergeräte und Mischformen; im letzten Fall werden einzelne Funktionen beim OEM entwickelt. Diese eigenentwickelten Funktionen oder Funktionsteile werden gewöhnlich zur Integration auf ein Steuergerät an Zulieferer weitergegeben. Es wird deutlich, dass verschiedene Entwicklungspartner zusammenarbeiten, wobei insbesondere Tests sowohl beim OEM als auch beim Zulieferer stattfinden können. Im Folgenden werden die bekanntesten Entwicklungsphasen von Funktionen aufgezeigt. Der Fokus 32

33

Im nicht-deterministischen Teil können längere bzw. zusätzliche Daten gesendet werden, wenn der deterministische Teil nicht ausreicht. Hier kann es länger dauern, bis ein Steuergerät die Nachricht verschicken kann, wenn viele höher priorisierte Nachrichten existieren. ZFAS: das zentrale Fahrerassistenzsystem.

16

2 Stand der Technik

liegt dabei auf der rechten Seite des V-Modells, um darzustellen, inwiefern sich der Testaufbau unterscheidet. Auf der linken Seite des V-Modells entstehen auf verschiedenen Ebenen Anforderungen an ein Steuergerät, vgl. Abbildung 2.4. Nach der Implementierung beginnt auf der rechten Seite des V-Modells der Test.

7HVW

$QIRUGHUXQJHQ

,PSOHPHQWLHUXQJ Abbildung 2.4: V-Modell mit dem Fokus auf der Softwareentwicklung

Anforderungen Für ein Steuergerät werden auf verschiedenen Ebenen Anforderungen definiert. So entstehen auf Systemebene Anforderungen für die gesamte Funktion, die neben der Physik auch Steuergeräte betreffen. Auf Steuergeräteebene entstehen wiederum Anforderungen für Hardware und Software. Für die Software gibt es auch eine Architektur, wodurch Softwareanforderungen für einzelne Schnittstellen zwischen Softwaremodulen entstehen. Das Anforderungsmanagement ist sowohl bei der Funktions- als auch bei der Steuergeräteentwicklung ein zentraler Aspekt, da von der Qualität der Anforderungen zudem die Qualität von Tests abhängt. Für die Definition von Anforderungen existieren geeignete Normen und Prozesse, vgl. [21][104]. Implementierung Nach der Definition von Anforderungen und dem Entwurf auf höheren Ebenen, siehe Abbildung 2.1, wird ein geeignetes Funktionskonzept erstellt und schließlich umgesetzt. Für den Entwurf eines Reglers oder einer Funktion können dazu verschiedene Kriterien verwendet werden,

2.2 Steuergeräte im Fahrzeug

17

vgl. [103, S. 43-44]. Die Entwicklung einer Funktion für ein Fahrzeug findet ggf. direkt als Softwarecode oder in einem spezifischen Modellierungswerkzeug statt, siehe Unterkapitel 2.3. Hierfür müssen aus Lastheften gegebene Zustandsmaschinen und Schnittstellen beachtet werden. Oft werden auch bereits bestehende Codeteile wiederverwendet und erweitert. Der nachfolgende zentrale Aspekt in der Entwicklung ist die Verifikation und Validierung einer Funktion. Test Die Verifikation und Validierung geschieht in verschieden Arten, wobei eine Funktion häufig mit einer Strecke in-the-Loop, d. h. in einer Schleife, getestet bzw. entwickelt wird. Grundlage ist stets eine Implementierung, die ggf. in einer geschlossenen Schleife mit einer Strecke zusammen getestet wird, vgl. Abbildung 2.5. Informationen, die für den Test relevant sind, lassen sich mithilfe einer Umgebung wie z. B. einem Streckenmodell austauschen. Hierbei kann die Funktion in unterschiedlicher Ausprägung vorliegen, oft wird hierbei auch von Testinstanzen oder Testmethoden gesprochen.

6WUHFNH 1DFKJHELOGHWH8PJHEXQJ

,PSOHPHQWLHUXQJ ]%0L/6L/+L/ Abbildung 2.5: In-the-Loop-Test einer Implementierung

Die folgenden Begriffe befassen sich mit Methoden zur Verifikation und Validierung von Anforderungen, die auf der linken Seite des V-Modells entstehen. Model-in-the-Loop (MiL) Bezieht man den Begriff MiL auf die Steuergerätearchitektur AUTOSAR, dann besteht eine MiL-Element lediglich aus der Applikationssoftware oder aus Teilen davon. Hier wird eine Regelstrategie oder Steuerfunktion zunächst entwickelt und ggf. mit der simulierten Strecke des Bauteils getestet. In der Regel wird MiL auf einem normalen PC durchgeführt. Software-in-the-Loop (SiL) Bei der Testmethode SiL werden Teile der Basissoftware zur Applikationssoftware hinzugefügt, siehe [66]. Dieses können zum Beispiel Diagnosedienste sowie Mess-und Kalibrierdienste für interne Variablen sein. Die Bestandteile eines SiL-Elements werden in [50, S. 29-34] und [53] genauer analysiert. Im Extremfall kann ein SiL Element den gesamten Steuergerätecode eines Steuergeräts enthalten, wobei der Prozessor zudem emuliert34 werden kann [78]. Im Fall 34

Emulatoren sind Programme, die in diesem Fall einen Prozessor eines Steuergeräts nachbilden. Diese ermöglichen es, denselben Code auszuführen, der sonst auf dem Steuergerät läuft.

18

2 Stand der Technik

des kompletten Steuergerätecodes muss ein zusätzliches Modell ggf. elektrische Steuergrößen auf physikalische Größen zurückrechnen, damit ein identisches Streckenmodell wie bei MiL verwendet werden kann. Gegenüber MiL ist ein SiL-Element dem realen Steuergerät vom Verhalten her ähnlicher. Es können z. B. gleiche Tools und Formate wie bei Steuergeräten in Hardware verwendet werden [79] und die Vernetzung von Applikationssoftwarekomponenten entspricht gewöhnlich der Vernetzung im Steuergerät. SiL-Tests können einerseits auf einem PC durchgeführt werden, andererseits kann ein Steuergerätecode auch auf Prüfständen verwendet werden, siehe 2.4. SiL-Elemente werden im Folgenden als virtuelles Steuergerät bezeichnet. Processor-in-the-Loop (PiL) Bei der Testmethode PiL gilt es zu gewährleisten, dass ein entwickelter Steuergerätecode zuverlässig auf einem jeweiligen Zielprozessor läuft. Steuergeräte haben heute aufgrund der wachsenden Anforderungen mehrere Rechenkerne, Scheduling-Mechanismen35 und Speicherbereiche. Der Code muss daher bzgl. der Verwendung auf einem bestimmten Prozessor getestet werden. Ferner können bei der Portierung Überlauffehler oder bei Konvertierungen Typenumwandlungsfehler auftreten, die mit verschiedenen Entwicklungsumgebungen getestet werden können, siehe [87]. In dieser Testphase steht nicht die Funktion oder Regelung, sondern die korrekte Integration des Codes auf das Steuergerät im Fokus. Hardware-in-the-Loop (HiL) Die Testmethode HiL ist neben dem Fahrversuch die am meisten verbreitete Testmethode. Hier wird ein reales Steuergerät ggf. mit weiteren Komponenten36 getestet, indem es an einen sogenannten HiL-Simulator angeschlossen wird. Bei einem HiL-Simulator handelt es sich um einen Echtzeitrechner. Die Eigenschaften eines solchen Rechners werden in Unterkapitel 2.4 beschrieben. Der Rechner simuliert in Echtzeit die Umgebung des Steuergeräts37 und sorgt mit Hilfe von entsprechenden Verbindungen dafür, dass Steuergeräte sich auf dem Prüfstand38 ähnlich wie im Fahrversuch verhalten. Im Gegensatz zu den bereits vorgestellten Testinstanzen können die Sensoren und Aktoren als Hardwareteile zusammen mit dem jeweiligen Steuergerät getestet werden. Zudem können ganze Teile des Autos oder auch alle Steuergeräte in eine HiL-Simulation integriert werden. Bei einer HiL-Simulation müssen generell Signale konditioniert werden39 und es müssen relativ aufwändig Sensoren und Aktoren des Prüfstands mit der Hardware verbunden werden. Eine Übersicht, bei welchen Fragestellungen eine HiL-Simulation den Fahrversuch sinnvoll unterstützen bzw. ergänzen kann, ist unter [71] zu finden. 35 36 37 38 39

Scheduling regelt die zeitliche Ausführung von Prozessen. Für ein Lenkungssteuergerät können beispielsweise der Servomotor, das Lenkgestänge und ggf. weitere physikalische Komponenten an einem HiL-Prüfstand betrieben werden. Z. B. ein virtuelles Fahrzeug mit einer Restbussimulation. Unter einem Prüfstand wird im Rahmen dieser Arbeit der gesamte Aufbau der Testumgebung verstanden, d. h. Steuergeräte, Echtzeitsimulator, Verdrahtungen, Bauteile, usw. Umrechnung von physikalischen und elektrischen Signalen.

2.2 Steuergeräte im Fahrzeug

19

Function-in-the-Loop (FiL) Eine FiL-Simulation ähnelt vom Grundprinzip einer HiL-Simulation. Der Steuergerätecode wird auf dem Zielprozessor ausgeführt und außerdem simuliert ein Echtzeitrechner die Umgebung des Steuergeräts. Im Gegensatz zur Testinstanz HiL sind im Steuergerät jedoch spezifische Funktionsteile softwareseitig freigeschnitten. Das bedeutet, dass bestimme Signale im Steuergerät direkt von außen gesetzt und gelesen werden können. Auf diese Weise können einzelne Funktionsblöcke oder ganze Teile des Steuergeräts betrieben werden, ohne das reale Sensoren oder Aktoren des Steuergeräts genutzt werden müssen.40 Der Vorteil besteht darin, dass die aufwändige Signalkonditionierung entfällt. Die Funktionsteile im Steuergerät werden durch Mess-und Kalibrierprotokolle41 direkt vom Prüfstand aus angesprochen. Bei einer geeigneten Schnittstelle können identische Streckenmodelle wie bei den Testinstanzen MiL oder SiL verwendet werden. Bypassing und Rapid Prototyping Bypassing kann als ein inverses FiL betrachtet werden. Hier werden alle Codeteile des finalen Steuergeräts außer einem freigeschnittenen Funktionsteil vom finalen Steuergerät verwendet. Die freigeschnittene Funktion wird auf einem weiteren Steuergerät, einem Echtzeitrechner oder einem PC ausgeführt. Im Steuergerät wird der vorhandene Code somit durch eine externe Funktion überbrückt. Diese Methode wird in der Regel im Fahrzeug verwendet, um neue Varianten einer Funktion zu testen, die auf diese Weise flexibler und einfacher konfiguriert werden können. Die bestehende Software im Steuergerät muss dadurch nicht ständig verändert werden. Beim Rapid Prototyping läuft eine Funktion hingegen komplett auf einer Echtzeithardware. Das primäre Einsatzgebiet ist ebenfalls der Fahrversuch. Der Unterschied zum Bypassing liegt darin, dass die errechneten Größen nicht ins Steuergerät zurückgeführt werden. Die Echtzeithardware ersetzt hier ein komplettes Steuergerät und die Signale werden ggf. direkt mit dem jeweiligen Fahrzeugbus ausgetauscht. Vehicle-in-the-Loop (ViL) Bei ViL-Tests sind jegliche Steuergeräte in einem Fahrzeug verbaut. Hier werden im Gegensatz zur Versuchsfahrt mit realen Verkehrsteilnehmern jedoch Teile der Fahrzeugumgebung simuliert. Dafür werden Eingänge von Sensoren wie z. B. Kamerabilder oder Objektlisten durch Simulationen ersetzt. Dies hat den Vorteil, dass Testaufbauten einfacher variiert werden können und keine Schäden an Prototypen auftreten können42 . Driver-in-the-Loop (DiL) In einer Simulation eines kompletten Fahrzeugs wird stets ein Fahrer benötigt, der ein bestimmtes Manöver43 fährt. Bei DiL wird ein simulierter Fahrer durch einen Menschen ersetzt. Dieser 40

41 42 43

Bei einem Steuergerät einer Bremse kann z. B. direkt vom Prüfstand aus ein gewünschter Bremsdruck eines Rades aus der Software ausgelesen oder gesetzt werden, ohne dass das Ventile der Hydraulik dafür genutzt werden. Z. B. über das von ASAM[2] standardisierte XCP-Protokoll[96]. Ein typisches Beispiel ist der Test einer Park- oder Notbremsfunktion. Fahrmanöver wie z. B. Geradeausfahrt oder Kreisfahrt werden durch Messgrößen oder Fahrereingaben vorgegeben.

20

2 Stand der Technik

kann in einem Fahrsimulator sitzen und so auch das im Modell berechnete Verhalten des Fahrzeugs sehen44 und z. B. fühlen45 . Hierbei lassen sich z. B. konkurrierende Konzepte oder neue Funktionen in der Simulation erleben. Fahrversuch Der Fahrversuch bietet den maximalen Grad der Realität, denn es wird in einem realen Fahrzeug in realer Umgebung getestet. Es werden alle Steuergeräte und Sensoren in realer Hardware verbaut und Funktionen können kundennah oder im Grenzbereich bewertet werden. Nachteile des Fahrversuchs sind vergleichsweise hohe Kosten sowie ein geringerer Grad der Reproduzierbarkeit gegenüber der Simulation, da z. B. schwankende Wettereinflüsse oder andere Verkehrsteilnehmer den Versuch beeinflussen können. Nachdem der Entwicklungsprozess beleuchtet wurde, befasst sich das folgende Unterkapitel mit den Grundlagen der Simulation im Kontext der virtuellen Funktionsabsicherung.

2.3 Grundlagen der Simulation im Kontext der virtuellen Funktionsabsicherung Simulation Der Begriff Simulation stammt vom lateinischen Wort simulare, was sich mit abbilden, darstellen oder nachbilden übersetzen lässt. Simuliert wird generell Systemverhalten, das aufgrund der Komplexität nicht analytisch oder theoretisch behandelt werden kann. Grundlage einer Simulation sind stets Modelle. Diese bilden relevante Aspekte, über die eine Aussage getroffen werden soll, hinreichend genau in abstrahierter Form ab. Die Simulation zeichnet sich dadurch aus, dass am Modell Experimente durchgeführt werden, um Erkenntnisse über das reale System zu gewinnen. Unterteilen lässt sich der Begriff in Simulationen mit und ohne Rechner46 . Die Simulation ohne Rechner steht nicht im Fokus dieser Arbeit, daher wird unter dem Begriff im Folgenden stets die Simulation mit Rechnern verstanden. Die Vorgehensweise bei diesen Simulation wird nun genauer erläutert, da sie beim Steuergerätetest genutzt wird. Die Simulation mit Rechnern zeichnet sich dadurch aus, dass in einer Modellierungssprache, in der Regel in einem spezifischen Simulationswerkzeug47 oder direkt in C-Code, Modelle von Systemen erstellt werden, an denen anschließend Experimente durchgeführt werden können. Modelle können sich über die Modellierungssprache hinaus bzgl. der Bestandteile unterscheiden. So können Modelle z. B. aus einfachen Gleichungen, komplexen Differentialgleichungen, Kennfeldern, Zustandsautomaten, angelernten neuronalen Netzen oder einer Kombination bestehen. Im Folgenden wird näher auf signalflussorientierte Modellierungssprachen eingegangen. 44 45 46 47

Bildschirme zeigen die Fahrzeugumgebung. Z. B. Ansteuerung des Fahrerplatzes über z. B. Hexapoden. Z. B. Auto-Crashtests im Fahrversuch: Während ein reales Fahrzeug verwendet wird, werden z. B. Unfallgegner und Insassen durch Modelle wie Puppen, Plakate o. Ä. ersetzt. Werkzeuge, wie z. B. MATLAB (proprietäre Sprache) oder Dymola (Modelica), die darauf zugeschnitten sind, Systeme zu modellieren.

2.3 Grundlagen der Simulation im Kontext der virtuellen Funktionsabsicherung

21

Signalflussorientierte Modellierungssprachen Für die virtuelle Steuergeräteabsicherung werden primär signalflussorientierte Modellierungssprachen verwendet, am häufigsten wird hierfür MATLAB48 SIMULINK49 genutzt. Ein weiteres kommerzielles Simulationswerkzeug des Herstellers ETAS ist beispielsweise ASCET [86]. In signalflussorientierten Modellierungssprachen werden Teile eines Systems als Blockschaltbild abgebildet. Hierfür können Blöcke aus Bibliotheken entnommen, parametriert und mit anderen Blöcken verbunden werden. Darüber hinaus ist es möglich, Funktionsblöcke mit anderem Code zu integrieren50 . Die Modellierung der Verbindungen erfolgt kausal51 und es lassen sich mehrere Blöcke für eine bessere Übersichtlichkeit als Subsysteme kapseln. Bei größeren Modellen gewinnt die Struktur an Wichtigkeit, damit Modelle wartbar bleiben und Teile des Realsystems im Modell wiedererkannt werden können52 . Die Programme sind in Industrie und Wissenschaft etabliert, wobei insbesondere für MATLAB viele Zusatzprogramme und Bibliotheken existieren. Bei der modellbasierten Softwareentwicklung findet oft der Entwurf eines Reglers in einem signalflussorientierten Simulationswerkzeug statt. Es lassen sich aber auch Gleichungen oder Kennlinien modellieren, die als Streckenmodell dienen. Für die Lösung der enthaltenen Gleichungen eines zugrunde liegenden Modells können geeignete Lösungsverfahren gewählt werden; dieser Aspekt wird in Unterkapitel 2.4 noch einmal aufgegriffen. Der folgende Abschnitt befasst sich zunächst mit symbolorientierten Simulationswerkzeugen. Symbolorientierte Modellierungssprachen In symbolorientierten Modellierungssprachen werden Teile eines Systems ebenso als Blockschaltbilder modelliert. Diese Blöcke werden hierbei gewöhnlich sehr ähnlich zum realen System aufgebaut. Blöcke in Bibliotheken können so auch ganze Bauteile53 repräsentieren. Der größte Unterschied zur signalflussorientierten Simulation liegt in der akausalen Modellierung. Verbindungen zwischen Bauteilen entsprechen dem physikalischen Zusammenhang im Realsystem und somit wird dem Nutzer die Bestimmung der Kausalität abgenommen. Dies wird realisiert, indem vorhandene Differentialgleichungen in Blöcken bereits die benötigten Informationen enthalten, die für die Vernetzung notwendig sind. Auch bei dieser Art der Modellierung müssen passende Lösungsverfahren vom Nutzer gewählt werden, wobei die akausalen Verbindungen vom Simulationswerkzeug automatisiert aufgelöst werden. Generell werden symbolorientierte Simulationswerkzeuge schwerpunktmäßig für die Modellierung von komplexen physikalischen Zusammenhängen verwendet. Bekannte symbolorientierte

48 49 50 51 52 53

Ein mathematisch-orientiertes Simulationswerkzeug der Firma MathWorks, in dem neben anderen Programmiersprachen hauptsächlich die gleichnamige proprietäre Programmiersprache verwendet wird. Ein signalflussorientiertes Simulationswerkzeug, was MathWorks für MATLAB anbietet. Z. B. MATLAB oder C-Code. Die Verbindungen zwischen Blöcken sind gerichtete Kanten, d. h. der Signalfluss ist definiert. Im Modell sollte z. B. erkennbar sein, welche Sensoren zu einem Steuergerät gehören oder mit welchem Fahrzeugbus ein Steuergerät Daten austauscht. Z. B. Kondensator eines Kühlkreislaufs.

22

2 Stand der Technik

Simulationswerkzeuge sind beispielsweise Dymola54 und Simscape55 . Im Bereich der Fahrdynamik wird z. B. die Mehrkörpersimulation56 „Adams“57 verwendet58 Das nächste Unterkapitel beschreibt Eigenschaften von Simulationsmodellen, da sie für die Durchführung von Simulationen relevant sind.

2.4 Eigenschaften von einzelnen Simulationsmodellen Nachdem verschiedene Arten der Modellierung vorgestellt wurden, folgen nun Modelleigenschaften für einzelne Simulationsmodelle. Beim Steuergerätetest ist es in der Regel notwendig, verschiedene einzelne Modelle mithilfe einer Co-Simulation miteinander zu koppeln. Es besteht hierbei die Schwierigkeit, dass einzeln getestete Modelle bei der Kopplung instabil werden können, wenn z. B. ein Modell ein anderes mit unerwarteten Frequenzen anregt. Eine zusätzliche Schwierigkeit dabei ist, dass einzelne Modelle in der Regel kompiliert oder geschützt vorliegen. Somit ist der Inhalt nur sehr bedingt einsehbar und es eigen sich deshalb keine Verfahren zur Integration, die eine Kenntnis der enthaltenen Gleichungen erfordern, vgl. [40]. Die Co-Simulation wird in Unterkapitel 2.5 genauer beschrieben. Zuvor werden verschiedene Eigenschaften einzelner Modelle dargestellt, die im Hinblick auf die Co-Simulation von Bedeutung sind. Hierzu zählen Aspekte wie Know-How-Schutz, Zielplattformen und Austauschformate. Maßgeblich für das korrekte Verhalten eines Modells für einen Anwendungsfall sind der verwendete Solver und die Schrittweiten. Hierbei wird auf die kontinuierliche Simulation von Systemen fokussiert, da diese im Rahmen dieser Arbeit hauptsächlich relevant ist. Beispiele für diskrete und kontinuierliche Modellierungen von Systemen mit mathematischen Definitionen können in der Literatur nachgelesen werden [59, S.7]. Solver und Schrittweiten Bei der Simulation eines Modells sind vor allem die verwendeten Solver und die verwendeten Schrittweiten wichtig. Der Solver löst Gleichungen eines zugrunde liegenden Modells. Dabei wird zwischen Solvern mit variablen und festen Schrittweiten unterschieden. Solver mit festen Schrittweiten lösen ein zugrunde liegendes Modell stets mit einer vorher definierten Länge für jeden Simulationsschritt. Solver mit variablen Schrittweiten passen sich hingegen zur Laufzeit den Eigenschaften eines Modells an. Das bedeutet, dass die Schrittweite verkleinert wird, wenn es große Änderungen nach der Berechnung einer Gleichung gibt. Hingegen vergrößert sie sich, wenn nur kleine Änderungen bei der Berechnung einer Gleichung vorliegen. Es entsteht somit ein Kompromiss zwischen Simulationszeit und Genauigkeit der berechneten Lösung, wobei in der Regel maximale und minimale Schrittweiten vorgegeben werden können.

54 55 56 57 58

Ein symbolorientiertes Simulationswerkzeug aus dem Hause Dassault, das auch Modelica anbietet. Ein symbolorientiertes Simulationswerkzeug, was MathWorks für MATLAB anbietet. Die Bewegung zwischen unverformbaren Körpern wird durch idealisierte Gelenke abgebildet. Adams, ein MKS-Simulationswerkzeug der Firma MSC Software, wird für die Modellierung und Simulation von mechanischen Systemen verwendet. Im Vergleich zu signalflussorientieren Simulationswerkzeugen ist der Aufwand für die Modellierung des Verhaltens von detaillierten mechanischen Systemen in „Adams“ geringer.

2.4 Eigenschaften von einzelnen Simulationsmodellen

23

Die einzelnen Lösungsverfahren59 unterscheiden sich zudem in Berechnungsaufwand und Genauigkeit, für eine detaillierte Darstellung vgl. [24, S. 41-63][35][84]. Ferner ist die Art der zugrunde liegenden Gleichungen für die Auswahl des Solvers von Bedeutung, da nicht alle Solver jede Art von Gleichungen lösen können. Beispielsweise ist nicht jeder Solver in der Lage, partielle Differentialgleichungen lösen. Eine Übersicht, unter welchen Umständen sich welcher Solver am besten eignet, ist z. B. unter [98, S. 1-22] zu finden. Generell muss der verwendete Solver jedoch für ein zugrunde liegendes Modell geeignet sein. Wenn ein Solver nicht für ein Modell geeignet ist oder verwendete Schrittweiten zu groß sind, kann das zugrunde liegende Gleichungssystem eines Modells zu einem bestimmtem Zeitpunkt ggf. nicht gelöst werden oder es entstehen größere Fehler. Auf der anderen Seite können sehr kleine Schrittweiten wiederum dazu führen, dass die Co-Simulation instabil wird. Die Wahl der Schrittweite und des Solvers sind daher von großer Bedeutung. Die nächste Eigenschaft beschreibt, inwiefern Modelle einsehbar sind. White-Box, Gray-Box und Black-Box Bei einem Modellaustausch zwischen OEM und Zulieferer oder auch firmenintern werden Modelle wegen des benötigten Know-How-Schutzes oft in kompilierter Form ausgetauscht. Um ein solches Modell ausführen zu können, muss es auf der jeweiligen Plattform lauffähig sein60 . Ein Modell wird zunächst in einem spezifischen Simulationswerkzeug erstellt und liegt dort als sogenanntes White-Box-Modell vor. Das bedeutet, dass die Modellteile offen einseh- und veränderbar sind. Wenn ein solches Modell weitergegebenen werden soll, ist beim firmenübergreifenden Modellaustausch der Know-How-Schutz wichtig, denn das Know-How über die internen Inhalte und die genaue Modellierung soll innerhalb der jeweiligen Firma bleiben. Ein Modell wird daher oft in kompilierter Form ausgetauscht, d. h. lediglich die Ein-und Ausgänge sowie die benötigten Parameter des Modells sind einseh- und veränderbar. Hier spricht man von einem Black-Box-Modell. Eine zweite Partei, die das Modell verwendet, benötigt entsprechende Informationen über die Schnittstellen und das Verhalten des Modells. Eine Mischform existiert bei einem ausgetauschten Steuergerätecode. Hier sind analog zum Fahrzeug zusätzlich interne Signale oder Parameter über Mess-und Kalibrierprotokolle61 les- und veränderbar. Dies entspricht einer Gray-Box. Im Folgenden wird der Aspekt der Zielplattform behandelt, da diese Grundlage für die Ausführung von Modellen ist. Zielplattform Ein wichtiger Punkt bei der Integration von Modellen ist die Zielplattform. Diese bestimmt im Allgemeinen die Ausführungsumgebung von kompiliertem Code. Beispiele sind z. B. eine Windows-Umgebung oder das Betriebssystem eines HiL-Prüfstands. Kompilierte Modelle sind stets plattformabhängig, d. h. ein Modell, das für einen Windows PC mit 64 Bit erstellt worden ist, kann nicht direkt auf Linux oder HiL-Prüfstand verwendet werden. Modelle ohne kompilierte 59 60 61

Es wird zwischen impliziten und expliziten Verfahren unterschieden. Z. B. Windows, Linux oder Hardwarearchitektur des Echtzeitrechners, 32 oder 64 Bit. Z. B. über das von ASAM[2] standardisierte XCP-Protokoll[96].

24

2 Stand der Technik

Modellteile und Bibliotheken können hingegen oft auf anderen Plattformen verwendet werden. Um dies zu ermöglichen, müssen das Simulationswerkzeug sowie die im Modell verwendeten Bibliotheken dafür geeignet sein. Daraus ergibt sich, dass für kompilierte Modelle im Vorhinein abgestimmt werden muss, auf welcher Plattform sie verwendet werden sollen. Für die Verwendung von Modellen auf HiL-Prüfständen muss zudem die Echtzeitfähigkeit eines Modells sichergestellt werden. Echtzeitfähigkeit Ein Aspekt, der bei der Modellintegration beachtet werden muss, ist die Echtzeitfähigkeit eines Modells. Hierfür wird zunächst der Begriff Echtzeit definiert. Die DIN-Norm 44300 liefert folgende Definition für den Begriff des Echtzeitbetriebs: „Echtzeitbetrieb ist ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind“ [23]. Wenn ein Modell auf einem Echtzeitrechner verwendet wird, trifft diese Definition zu, denn ein Modell muss zu einem definierten Zeitpunkt rechtzeitig die passenden Daten bereitstellen. Als Schrittweite wird bei HiL-Simulatoren im Bereich der Fahrdynamik gewöhnlich eine Millisekunde verwendet. Hier liegt die vom Modell benötigte Rechenzeit für eine Millisekunde Simulationszeit somit unter einer Millisekunde in realer Zeit. Es wird in der Literatur zwischen harten, festen und weichen Echtzeitbedingungen unterschieden [113, S. 332]. Bei harten Echtzeitbedingungen darf keine Zeitüberschreitung vorkommen, da ein Schaden droht.62 Bei festen Echtzeitbedingungen wird bei einer Überschreitung eine durchgeführte Aktion wertlos und bei weichen Echtzeitbedingungen dürfen Zeitüberschreitungen in einem kleinen Toleranzrahmen vorkommen. In weiterer Literatur wird lediglich zwischen weichen und harten Echtzeitbedingungen unterschieden, vgl. [54]. Bei weichen Echtzeitbedingungen reicht es aus, wenn das Echtzeitkriterium im Mittel erfüllt wird. Wenn einzelne Echtzeitverletzungen vorhanden sind, kann der betreffende Zeitschritt abgewartet oder durch Extrapolation63 erzeugt werden. Analog zu bestehenden Definitionen wird im Rahmen dieser Arbeit lediglich zwischen harten und weichen Echtzeitbedingungen unterschieden. Auf einem Computer ohne Echtzeitbedingungen können Modelle beliebig langsamer oder schneller rechnen. Geringere Rechenzeit benötigen in der Regel einfachere und damit weniger rechenintensive Modelle. Aufwändige Modelle wie z. B. Modelle für die Berechnung komplexer mechanischer Zusammenhänge als MKS-Simulation erfüllen unter Umständen keine Echtzeitbedingungen. Bei höherer Genauigkeit kann die Rechenzeit für eine Millisekunde eines Modells somit um ein Vielfaches einer Millisekunde in Realzeit ansteigen. Das nächste Unterkapitel befasst sich damit, wie sich unterschiedliche separat vorliegende Komponenten mithilfe einer Co-Simulation miteinander koppeln lassen. 62 63

Ein Schaden könnte z. B. drohen, wenn ein Motorprüfstand bei zu hoher Temperatur nicht sofort heruntergefahren wird, da in einem ein Modell zu gegebenem Zeitpunkt noch nicht alle Daten berechnet wurden. Bei der Extrapolation werden bei der Simulation benötigte Eingangsdaten für die Berechnungs eines Zeitschritts mathematisch vorhergesagt, falls diese (noch) nicht vorliegen.

2.5 Co-Simulation

25

2.5 Co-Simulation Aufgrund der steigenden Anforderungen mechatronischer Systeme existieren bereits Möglichkeiten, Modelle, virtuelle Steuergeräte und Prüfstände in einer Co-Simulation miteinander zu koppeln. „Unter dem Begriff Co-Simulation versteht man die Verbindung bzw. Kopplung von separat modellierten Teilmodellen zu einem Gesamtmodell. Grundsätzlich kann bei der Co-Simulation im Kontext der virtuellen Steuergeräteabsicherung zwischen verschiedenen Arten unterschieden werden“ [52, S. 105]. In der Literatur wird zwischen diskreter eventbasierter und kontinuierlicher Co-Simulation unterschieden, vgl. [59]. Diskrete eventbasierte Co-Simulationen fokussieren auf Zustandsänderungen zu diskreten Zeitpunkten im System64 . Kontinuierliche Co-Simulationen werden hingegen im Bereich der physikalischen Kopplung verwendet. Hier tauschen Teilmodelle kontinuierlich Daten aus. Es wird zwischen der sogenannten starken Kopplung einer Simulation mit einem Solver und der schwachen Kopplung mit mehreren Solvern unterschieden, vgl. [56, S. 572–576]. Abbildung 2.6 zeigt den Aufbau einer Co-Simulation mit schwacher Kopplung.

Mikroschrittweite

Makroschrittweite

Modell 1 Austausch und Extrapolation von Signalen

Co-Simulationsplattform Austausch und Extrapolation von Signalen

Modell 2 Abbildung 2.6: Mikro- und Makroschrittweiten bei einer Co-Simulation nach [52, S. 5]

Dargestellt sind zwei Modelle, die mit einem eigenem Solver und mit einer eigenen Schrittweite, der sogenannten Mikroschrittweite, gelöst werden. Zu definierten Zeitpunkten, den Makroschritten, werden Daten mit dem jeweils anderen Modell ausgetauscht. Hierbei können Mikro- und Makroschrittweiten auch gleich groß sein. Die eckig umrahmten Mikroschritte werden jeweils mit neuen Werten des anderen Modells berechnet. Modelle können hierbei sequentiell oder parallel ausgeführt werden. Bei sequenziellen Berechnungen wird das erste Teilmodell mit den Eingangsdaten des zweiten Modells aus dem 64

Z. B. eine Ampelschaltung mit den Zuständen grün, gelb und rot.

26

2 Stand der Technik

vorherigen Simulationsschritt gelöst. Danach wird das zweite Modell berechnet, das die berechneten Ausgangsdaten des ersten Modells als Eingangsdaten aus dem aktuellen Simulationsschritt verwendet. Bei der parallelen Berechnung werden beide Modelle mit den Ausgangsdaten des vorherigen Simulationsschritt vom anderen Modell berechnet. Es entsteht in beiden Fällen ein Kopplungsfehler, der in Abschnitt 3.4.2 näher beschrieben wird. Wichtig ist bei beiden Verfahren, dass eine korrekte Ausführungsreihenfolge sichergestellt wird. Hierfür müssen einzelne schnellere Teilmodelle ggf. auf andere warten, um zu gewährleisten, dass Variablen beim Zugriff mehrerer Tasks zu verschiedenen Zeitpunkten stets konsistent sind. Damit Modelle zwischen verschiedenen Entwicklungspartnern zu einer Co-Simulation vereint werden können, ist das verwendete Austauschformat von Bedeutung. Ein Modell, das in einem bestimmten Modellierungssprache entwickelt wird, liegt zunächst in einem proprietären Format vor. Eine Modellweitergabe ist in der Regel möglich, wenn dasselbe Simulationswerkzeug verwendet wird. Ferner sollte das verwendete Softwarerelease mindestens so neu sein wie das bei der Modellerstellung verwendete Softwarerelease65 . Falls das Simulationsmodell als Black-Box d. h. mit Know-How-Schutz, ausgetauscht werden soll, existieren zwischen Tools proprietäre Formate wie z. B. die S-Function in Matlab [77], wobei ggf. Releaseabhängigkeiten auftreten können. Eine Standardisierung für den Austausch von Simulationsmodellen wurde im Rahmen des EUProjekts Modelisar [13] in Form des FMI Standards definiert. Seit Ende des Modelisar Projekts im Jahr 2011 findet die Weiterentwicklung des Standards im Rahmen eines Modelica Association Projekts statt. Der Standard ermöglicht es, Modelle vereinheitlicht zwischen verschiedenen Simulationswerkzeugen auszutauschen, indem Modellinhalte in der Programmiersprache C in kompilierter oder unkompilierter Form ausgetauscht werden. Die Modelle liegen hierbei in einer gekapselten Archivdatei als sogenannte FMU mit einer dazugehörigen Schnittstellenbeschreibung vor, vgl. [6]. Im Standard wird zwischen Model Exchange und Co-Simulation unterschieden, siehe Abbildung 2.7.

FMI für Model Exchange Simulationsprogramm Solver

FMU Model

FMI für Co-Simulation Simulationsprogramm

FMU Model Solver

Abbildung 2.7: Unterschied zwischen Model Exchange und Co-Simulation, nach Bildquelle [49]

65

Voraussetzung: Das verwendete Simulationswerkzeug kann abwärtskompatibel mit gespeicherten Modellen umgehen.

2.5 Co-Simulation

27

Bei FMI für Model Exchange liegen Modelle ohne Solver vor, d.h. die zugrunde liegenden Gleichungen eines Modells werden vom Solver des Simulationswerkzeugs gelöst. Bei FMI für Co-Simulation löst ein in der FMU integrierter Solver das Modell eigenständig und die FMU tauscht zu definierten Zeitpunkten lediglich Ein- und Ausgangsdaten sowie ggf. Parameter mit der FMU aus. Der Standard bietet viele Vorteile und wird zunehmend von vielen Werkzeugen unterstützt, vgl. [5]. Es existieren bereits verschiedene Anwendungsbeispiele, die zeigen, in welchen Bereichen FMI bereits angewendet wird, vgl. [51]. Bei einer Integration einer FMU für Model Exchange ist es wichtig, einen zum Modell passenden Solver zu wählen. Kopplungsverfahren lassen sich allgemein aufgrund auftretender Latenzen in die PC-basierte CoSimulation und in die Co-Simulation mit Echtzeitsystemen unterteilen. Bei der Co-Simulation mit Echtzeitsystemen finden Protokolle mit deterministischem Übertragungsverhalten und Protokolle mit nichtdeterministischem Übertragungsverhalten Verwendung. Bei der PC-basierten Simulation entstehen in der Regel keine Totzeiten oder Datenverluste durch die Kommunikation, daher findet hier keine Unterteilung bzgl. der verwendeten Protokolle statt. PC-basierte Co-Simulation In rein virtuellen Umgebungen gibt es bereits die Möglichkeit, verschiedene Simulationsmodelle und Simulationswerkzeuge miteinander zu koppeln. Eine Übersicht mit der Darstellung der Vor-und Nachteile der verschiedenen Verfahren ist in Abbildung 2.8 dargestellt. Einige Simulationswerkzeuge wie z. B. „Adams“ und MATLAB Simulink verfügen über die Möglichkeit einer proprietären direkten Kopplung66 . Hier kommunizieren die Simulationswerkzeuge über eine direkte Schnittstelle miteinander. Zudem können Simulationsmodelle im gleichen Simulationswerkzeug im jeweiligen proprietären Format ausgetauscht werden, hier muss ggf. eine Modellierung im gleichen Simulationswerkzeug stattfinden. Darüber hinaus existieren kommerzielle Co-Simulationsplattformen für die Kopplung verschiedener Simulationswerkzeuge wie ICOS [30], CosiMate [42] oder TISC [102]. Von den jeweiligen Herstellern werden Adapter für die jeweiligen unterstützten Simulationswerkzeuge bereitgestellt, die für den Datenaustausch und die Simulationssteuerung verwendet werden können. Zudem können gekapselte Modelle z. B. mithilfe des bereits vorgestellten FMI Standards genutzt werden. Hier werden Modelle zunächst aus Simulationswerkzeugen exportiert und anschließend in andere Simulationswerkzeuge importiert. Für die Co-Simulationsplattform ICOS existiert bereits die Möglichkeit zur Anbindung von Echtzeitrechnern, wobei hier die rein PC-basierte Co-Simulation verlassen wird. Eine offene Entwicklungsumgebung stellt ADTF dar. ADTF ist auf die Entwicklung von Fahrerassistenzfunktionen spezialisiert und steht für Automotive Data and Time-Triggered Framework [48]. ADTF wurde ursprünglich von der AEV entwickelt und wird aktuell von der Digitalwerk GmbH kommerziell vertrieben. Das Ziel von ADTF besteht darin, einzelne Reglerfunktionalitäten freizuschneiden, um den Entwicklern die Möglichkeit zu geben, sich auf eigene Funktionen zu konzentrieren. Hierfür können Daten oder Datenströme im Fahrzeug mitgeschnitten und in 66

Der Hersteller MSC stellt hierfür die „Adams“ Controls Schnittstelle bereit.

28

2 Stand der Technik

Direkte Kopplung von Simulationsprogrammen • Direkte Schnittstellen erforderlich • Support aufwändig Modellierung in einem Simulationsprogramm • Einfache Kopplung • Einheitliche Entwicklungsumgebung erforderlich • Identische Solvereinstellungen benötigt • Keine Spezialsoftware verwendbar Co-Simulationsplattform • Kopplung mit einer Middleware (z. B. CosiMate, ICOS, TISC) • Hoher Grad an Modularität und Flexibilität • Eigene Entwicklungsumgebung bleibt erhalten • Echtzeitanbindung verfügbar

FMU

Austausch gekapselter Modelle • Export gekapselter Modelle mit oder ohne Solver • Proprietäre Formate können zu Releaseabhängigkeiten führen • Standardisierung in Form des FMI Standards vorhanden

Abbildung 2.8: Verschiedene Arten der Co-Simulation nach [52, S. 5-7]

Prüfstands- oder PC-Umgebungen eingespielt werden. Die Basis von ADTF bietet eine offen gelegte Gesamtarchitektur, wobei einzelne Teilbibliotheken, sogenannte Filter, kompilierte Modelle oder Codeteile sind, die durch festgelegte Zugriffe angebunden werden. Hersteller von HiL-Systemen wie z. B. dSPACE bieten für ihre Systeme Schnittstellen für ADTF an [92]. Hier besteht also auch die Möglichkeit, ADTF als Protokoll mit einem Echtzeitsystem zu verwenden. Solange Simulationen lediglich auf PCs bzw. Servern durchgeführt werden, ergibt sich jeweils ein identisches Ergebnis, solange eine deterministische Ausführungsreihenfolge einzelner Simulationen durchgeführt wird. Steuergeräte oder Co-Simulationen mit nichtdeterministischen Protokollen können Simulationsergebnisse hingegen beeinflussen. Co-Simulation mit Echtzeitrechnern Der Test von Steuergeräten unter Echtzeitbedingungen ist im Allgemeinen etabliert. Für vernetzte Funktionen besteht außerdem bereits die Möglichkeit, Prüfstände gleicher Hersteller miteinander zu koppeln. Zudem können Prüfstände mithilfe von Co-Simulationsplattformen mit PC-basierten Simulationen verbunden werden, siehe Abbildung 2.8. Um den Aufwand für den Aufbau von Simulationen zwischen Prüfständen oder Prüfständen und PCs zukünftig signifikant zu reduzieren, wird im Rahmen des EU-Projekts ACOSAR[1] eine Standardisierung eines Protokolls für Co-Simulationen mit Echtzeitrechnern und PCs angestrebt. Im Bereich des Militärs entstanden außerdem ein Standard für den Datenaustausch und die Simulationssteuerung in Form von DIS [10]. Darauf aufbauend wurde eine objektorientierte Simulationsarchitektur in Form der HLA standardisiert [11].

2.5 Co-Simulation

29

Für die Kopplung von Echtzeitrechnern mit PCs oder Echtzeitrechnern untereinander können verschiedene Protokolle für den Datenaustausch verwendet werden. Zunächst werden die Protokolle mit nichtdeterministischem Übertragungsverhalten vorgestellt. Protokolle mit nichtdeterministischem Übertragungsverhalten Eine Möglichkeit für die Kopplung von Prüfständen besteht in der Verwendung von Protokollen, die kein deterministisches Verhalten bei der Übertragung aufweisen. Das bedeutet, dass versendete Datenpakete früher oder später als zu einem erwarteten Zeitpunkt beim Empfänger ankommen können. Ferner können Datenverluste auftreten, d. h. einzelne Pakete können verloren gehen. Ein nichtdeterministisches Protokoll ist beispielsweise das in Abschnitt 2.2.3 vorgestellte CAN-Protokoll, vgl. [18]. Das Protokoll ist im Bereich der Automobilindustrie etabliert und eignet sich primär wegen der hohen Verfügbarkeit für Echtzeitkopplungen, da Prüfstände in der Regel über mehrere CAN-Schnittstellen verfügen. Für PCs stehen von den Firmen Vector oder Peak Systems Möglichkeiten bereit, PCs mit einem CAN-Bus zu verbinden [16][22]. Ein weiteres nichtdeterministisches Protokoll, das für die Kopplung von Prüfständen verwendet werden kann, ist das verbreitete Ethernet-Protokoll [9]. Für die Übertragung von Paketen wird zwischen TCP und UDP unterschieden, wobei UDP verbindungslos ist und nicht garantiert, dass Pakete beim Empfänger ankommen. Hierdurch ergeben sich anwendungsspezifische Vorund Nachteile, siehe [70]. UDP und TCP sind hardwaretechnisch einfach einsetzbar, denn PCs verfügen standardmäßig über Ethernet-Schnittstellen. Außerdem können Prüfstände, falls nicht bereits vorhanden, gewöhnlich um Ethernet-Schnittstellen erweitert werden. Für die Kopplung von Prüfständen besteht bei der Verwendung von Ethernet zudem der Vorteil, dass vorhandene Netzwerke in Firmen verwendet werden können, ohne dass zusätzliche Hardware notwendig ist oder neue Verbinden zwischen Prüfständen geschaffen werden müssen. Bei der Co-Simulation mit nichtdeterministischen Protokollen kann es zu Datenverlusten, Rauschen und kommunikationsbedingten Totzeiten kommen. Hierfür werden im Rahmen des Projekts ACORTA Methoden entwickelt, welche die genannten Probleme behandeln bzw. deren Auswirkung auf das Simulationsergebnis kompensieren, siehe [34]. Protokolle mit deterministischem Übertragungsverhalten Deterministische Protokolle gewährleisten, dass Daten in der richtigen Reihenfolge zu definierten Zeitpunkten ankommen. Hierfür gibt ein Master in der Regel fest definierte Sendefenster vor, in dem einzelne Teilnehmer senden bzw. empfangen dürfen. Grundsätzlich ist die Verwendung von Protokollen mit deterministischen Übertragungsverhalten für die Kopplung von Prüfständen verbreiteter. Hier werden sowohl offene als auch proprietäre Lösungen verwendet. Ein weiteres offenes Protokoll ist z. B. DDS, die Kurzform für Data Distribution Service [82]. Der von der Object Management Group spezifizierte Standard beschreibt, wann und wie verschiedene Teilnehmer in einem Netzwerk Daten untereinander austauschen. Eine Implementierung von DDS ist beispielsweise RTI Connext DDS, das in [37] als Möglichkeit beschrieben wird, um Prüfstände verschiedener Hersteller zu koppeln. Es existieren darüber hinaus verschiedene Implementierungen für echtzeitfähiges Ethernet wie z. B. Ethercat [12].

30

2 Stand der Technik

Hier handelt es sich um eine Master-Slave-Architektur mit Mechanismen, die eine korrekte Reihenfolge und Zeitpunkte von Datenpaketen sicherstellen. Neben standardisierten Protokollen existieren proprietäre Lösungen von verschiedenen Herstellern. Beispielsweise bietet die Firma dSPACE eine Lösung zur Kopplung ihrer Prüfstände über Glasfaserleitungen mithilfe eines Gigalink Moduls [47]. Andere Lösungen zur Kopplung von Prüfständen sind auch von weiteren Herstellern verfügbar, vgl. [80, S. 5]. Zeitsynchronisation Ein weiterer Aspekt bei der Kopplung von Prüfständen ist die Zeitsynchronisation. Unter Zeitsynchronisation wird im Rahmen dieser Arbeit das Angleichen von Echtzeituhren verschiedener Simulatoren verstanden. In der Regel stellt dabei ein System eine Uhr bereit, nach der sich weitere Teilnehmer richten. Ein Standard für die Synchronisation ist das Precision Time Protocol, dass in IEEE 1588 [8] definiert wurde und in IEC 61158[12] übernommen wurde. Einige Simulationsaufbauten können sich auch physikalisch synchronisieren, sodass verschiedene Simulatoren nicht zwingend komplett zeitsynchron betrieben werden müssen. Weitere Aspekte für die Kommunikation in der Entwicklung verteilter Echtzeitsysteme werden in [36] vorgestellt.

2.6 Durchführung von funktionalen Tests und Testverfahren Nachdem Begriffe und Prüftechniken im Kontext der Steuergeräteabsicherung erklärt wurden, beschreibt dieses Unterkapitel Methoden, mit denen Steuergerätetests in der Simulation durchgeführt werden. Testinfrastruktur und Testfalldefinitionen Im rechten Ast des V-Modells wird aus einem Entwicklungsstand von Steuergeräten ein Qualitätsprodukt geformt. Wie in Unterkapitel 2.1 beschrieben, werden hierfür Validierungen und Verifizierungen von Software durchgeführt. Dies entspricht durchzuführenden Tests und Nachweisen in jedem Kompositionsschritt. Ein wichtiger Faktor für eine effiziente Durchführung dieser Tests ist die Infrastruktur. Ein Instrument zur schrittweisen Optimierung des Testprozesses ist das sogenannte Test Process Improvement, vgl. [99]. Hier werden neben der Testfallspezifikation auch Aspekte wie Rollen, Metriken, Zeitpunkte, Dokumentationen, Büroausstattungen, Mitarbeitermotivation und Kommunikationswege behandelt. Wie aus Anforderungen strukturiert Testfälle definiert werden können, wurde bereits von verschiedenen Arbeiten und Forschungsgruppen dargelegt. Beispielsweise wird die Auswahl von Tests, der Testprozess, der Werkzeugsatz und die Adaptivität eines Testprozesses in [68] behandelt. Die Testfalldefinition ist nicht Thema der vorliegenden Arbeit. Dennoch muss für die Simulation erläutert werden, inwiefern sich Tests von vernetzten Funktionen bzgl. des Simulationsaufbaus unterscheiden.

2.6 Durchführung von funktionalen Tests und Testverfahren

31

Unterscheidung zwischen Open- und Closed-Loop-Tests Softwaretests lassen sich im Kontext der virtuellen Steuergeräteabsicherung in Open- und ClosedLoop-Tests unterteilen. Bei Open-Loop-Tests wird ein Testobjekt mit Testdaten stimuliert. Am Ausgang des Testobjekts werden anschließend die generierten Daten mit erwarteten Daten verglichen, d. h. die am Ausgang ermittelten Daten haben keinen Einfluss auf die Eingangsdaten. Es entfällt somit die Rückführung der Daten von der Strecke zum Regler. Bei Closed-Loop-Tests wird ein Testobjekt in einer geschlossenen Schleife getestet, d. h. das Objekt steuert oder regelt ein System. Die Auswahl des Verfahrens lässt sich durch den Testfokus definieren. Die Unterschiede sind noch einmal in Abbildung 2.9 verdeutlicht.

&ORVHG/RRS7HVW

2SHQ/RRS7HVW 9HUJOHLFKPLW 6ROO:HUWHQ

7HVWVWLPXOXV

6WUHFNHQPRGHOO

)XQNWLRQ

)XQNWLRQ

Abbildung 2.9: Unterscheidung zwischen Open- und Closed-Loop-Tests

Bei der Bestimmung eines Bremsweges mit dem Steuergerät einer Bremse und einem Fahrdynamikmodell handelt es sich z. B. um einen Closed-Loop Test. Das Bremssteuergerät bestimmt den Bremsdruck an den einzelnen Rädern, der wiederum abhängig vom Fahrzeugverhalten ist. Um diesen realitätsnah testen zu können, benötigt das Steuergerät plausible Daten für Raddrehzahlen und Beschleunigungen, die in Abbildung 2.9 aus einem Streckenmodell stammen. Bezogen auf den Bremsweg wäre ein Open-Loop-Test eine Stimulusvorgabe von Bremspedalstellungen, Raddrehzahlen und Beschleunigungen mit der Erwartung, dass bestimmte Bremsdrücke an den Rädern aufgebaut werden.

2SHQ/RRS7HVWIUGLH)XQNWLRQ$%6 7HVWVWLPXOL

9HUJOHLFKPLW6ROO:HUWHQ

5DGGUHK]DKOHQ4XHU XQG /lQJVEHVFKOHXQLJXQJHQ*LHUUDWH

%UHPVGUXFN$%66WDWXVHWF

+\GUDXOLNV\VWHP

$%6)XQNWLRQ Abbildung 2.10: Open-Loop-Test für die Funktion ABS mit Hydrauliksystem

Die Definitionen für Open- und Closed-Loop werden im Rahmen dieser Arbeit stets auf die zu testende Funktion bezogen, obwohl es sein kann, dass beteiligte andere Funktionen Closed-Loop

32

2 Stand der Technik

betrieben werden, vgl. Abbildung 2.10. Bezogen auf den Bremsweg ist eine Stimulusvorgabe von Inputdaten des Fahrzeugs ein Open-Loop-Test. Das Bremssteuergerät regelt das Hydrauliksystem jedoch als Closed-Loop, denn beteiligte Funktionsteile für den Bremsdruckaufbau werden mit dem Hydrauliksystem zusammen in einer Closed-Loop betrieben. Bezogen auf die konkrete Funktion ABS67 ist dieser Simulationsaufbau im Folgenden ein Open-Loop-Test, obwohl einige beteiligte Funktionsteile Closed-Loop betrieben werden. Durch die Komplexität eingebetteter Systeme besteht nach wie vor Forschungsbedarf für beide Testverfahren, da die Herausforderung besteht, einen großen Testraum mit möglichst wenigen Testfällen effizient abzudecken. Für Open-Loop Tests existiert z. B. der modellbasierte Test, der in der Literatur unterschiedlich definiert ist. Im Rahmen dieser Arbeit wird unter einem modellbasierten Test ein Vergleich von Zuständen zwischen einem Verhaltensmodell, z. B. einem nachmodellierten Zustandsautomaten des Realsystems, und dem Realsystem selbst verstanden. Aus dem Verhaltensmodell lassen sich Testfälle auch automatisch generieren. Anschließend werden das Testmodell und das zu testende System mit den Testfällen stimuliert und die Ergebnisse verglichen. Weiterhin gibt es das Gebiet des evolutionären Testens. Hier werden Eingangsparameter für Tests mithilfe von naturanalogen Algorithmen ermittelt, da eine analytische Ermittlung von Eingangsparametern zu aufwändig werden kann [91]. Eine weitere Methode rückt den Test des Zeitverhaltens von Echtzeitsystemen in den Fokus [107]. Darüber hinaus gibt es aktuelle Forschungsaktivitäten, den modellbasierten Test für große Zustandsräume mit dem evolutionären Test zu kombinieren [73]. In Bezug auf diese Arbeit ergibt sich die Anforderung, dass sich bei Tests die Eingangsparameter ändern können und verwendete Modelle dafür geeignet sein müssen. Diese Aspekte werden in Abschnitt 3.3.4 wieder aufgegriffen.

2.7 Begriffe im Kontext der Fahrdynamiksimulationen Zum Abschluss dieses Kapitels werden kurz einige bekannte Begriffe der Fahrdynamik im Kontext der virtuellen Steuergeräteabsicherung dargestellt, da sie im Zusammenhang der vorgestellten Testfunktion benötigt werden. Eine vollständige Definition mit Formeln und Anwendungen lässt sich beispielsweise unter [62, S. 73 ff.] nachlesen. Fahrzeugbewegungen lassen sich mithilfe von drei translatorischen Bewegungen beschreiben, siehe Abbildung 2.11. Die Bewegungen bzw. deren Dynamik werden in der Regel durch den Weg, die Geschwindigkeit und die Beschleunigung beschrieben. Die Längsdynamik beschreibt die Vorwärts- und Rückwärtsbewegung eines Fahrzeug, die z. B. durch Bremseingriffe oder dem Antreiben eines Fahrzeugs durch einen Motor beeinflusst wird. Die Längsdynamik beschreibt somit die Bewegung eines Fahrzeugs entlang der Längsachse. Die Querdynamik spielt eine Rolle, wenn ein Fahrzeugs z. B. eine Kurve fährt. Hier findet eine Bewegung entlang der Querachse eines Fahrzeugs statt.

67

Ein ABS-System wirkt beim Bremsen einem Blockieren von Rädern entgegen.

2.7 Begriffe im Kontext der Fahrdynamiksimulationen

33

Hochachse Querachse Nicken

Gieren Längsachse Wanken

Abbildung 2.11: Trans- und rotatorische Bewegungen eines Fahrzeugs68

Die dritte translatorische Bewegung ist die Vertikaldynamik. Diese wird z. B. für Komfortbetrachtungen oder bei Hügelabfahrten beobachtet. Hier bewegt sich das Fahrzeug entlang der Hochachse. Zusätzlich zu den translatorischen Bewegungen lassen sich drei rotatorische Bewegungen beobachten, die im Folgenden beschrieben werden. Rotiert ein Fahrzeug um seine Querachse, spricht man vom „Nicken“. Dies passiert z. B. bei einer starken Bremsung auf trockenem Asphalt und man beobachtet, dass sich durch die Bremskraft z. B. der vordere Teil des Fahrzeugs absenkt. Wenn ein Fahrzeug um die Längsachse rotiert, wird dies als „Wanken“ bezeichnet. Dies tritt z. B. bei schnellen Spurwechseln mit hoher Querbeschleunigung auf. Die dritte rotatorische Bewegung findet um die Hochachse des Fahrzeugs statt. Hier spricht man vom „Gieren“ eines Fahrzeugs. Bei Bremsungen mit unterschiedlichen Reibwerten links und rechts auf der Fahrbahn ergeben sich zusätzlich zum beschriebenen Nicken beispielsweise Bewegungen um die Hochachse. Hier wird das Fahrzeug auf der Fahrbahn zur Seite gezogen, was sich durch eine Gierrate in die entsprechende Richtung zeigt. Es wird zusammenfassend deutlich, dass die Modularität einzelner Modelle im Entwicklungsprozess zielführend ist. Bekannte Verfahren befassen sich bis jetzt jedoch getrennt mit Modelleigenschaften, numerischen Verfahren zur Kopplung oder mit Testanforderungen. Es bleibt unbeantwortet, welche Modelle für welche Tests geeignet sind, welche im Entwicklungsprozess wiederverwendbar sein sollten und was diesbezüglich zu beachten ist. Hierfür fehlen einerseits Darstellungen, wie die Funktionsentwicklung von mechatronischen Systemen in verschiede-

34

2 Stand der Technik

nen Phasen des V-Modells durch Simulation unterstützt werden kann. Um diese Simulation durchzuführen, ist nach aktuellem Stand andererseits unklar, welche Eigenschaften Modelle für verschiedene Testanforderungen erfüllen müssen. Dazu zählt die Definition von Detaillierungsgraden und die Analyse, für welche Fragestellung welche Modelle wiederverwendbar sein sollten. Diese Punkte werden im folgenden Kapitel adressiert.

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen Dieses Kapitel stellt den Hauptteil der vorliegenden Arbeit dar. Es beschreibt die entwickelte Methode, um einen durchgängigen und flexiblen Aufbau von Simulationsumgebungen für Fahrfunktionen zu verwirklichen.

%HJULIIVGHILQLWLRQHQ

*UXQGODJHIUGLH $QDO\VHGHU )XQNWLRQVHQWZLFNOXQJ

]HLJW1RWZHQGLJNHLWIU 7HVWSKDVHQ

VWHOOHQ $QIRUGHUXQJHQDQ 6LPXODWLRQVPRGHOOH

ZHUGHQHLQJHKDOWHQGXUFK 8QWHUVWW]HQGH :HUN]HXJH Abbildung 3.1: Aufbau des Kapitels

In Abbildung 3.1 ist der Aufbau des Kapitels skizziert. Zunächst werden einheitliche Begriffe für die Simulation von vernetzten Funktionen definiert. Dies ist die Grundlage für eine Analyse der aktuellen Funktionsentwicklung, welche die Notwendigkeit für die anschließend dargestellten Testphasen zeigt. Aus den entwickelten Testphasen erfolgt die Definition von Anforderungen im Entwicklungsprozess mit der Klassifizierung von Modelleigenschaften. Da für die Einhaltung der Anforderungen spezielles Wissen erforderlich ist, werden zum Abschluss dieses Kapitels Werkzeuge vorgestellt, die Beteiligte bei der Prüfung und Definition von Modelleigenschaften unterstützen.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9_3

36

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

3.1 Begriffsdefinitionen für eine durchgängige Funktionsentwicklung Bei einer verteilten Entwicklung69 ist es wichtig, dasselbe Verständnis von Begriffen für eine Thematik zu haben. Dieses Unterkapitel führt die im Rahmen dieser Arbeit verwendeten Begrifflichkeiten für das Themengebiet der Steuergerätesimulation im Fahrzeug ein. Daraufhin wird die Verwendung der Begriffe anhand einer Steuergerätevernetzung beispielhaft dargestellt. Die Definitionen für Systeme, Komponenten, Zustandsvariablen und Module sind strukturgebend und teilen das Fahrzeug als Gesamtsystem auf. Die Begriffe Modellumfang, Genauigkeit und Gültigkeitsbereich behandeln hingegen Eigenschaften von Simulationsmodellen in Bezug auf ein Realsystem. 3.1.1 Strukturgebende Begriffsdefinitionen Im Folgenden werden strukturgebende Begriffsdefinitionen im Hinblick auf das Fahrzeug beschrieben. Diese Definitionen orientieren sich nicht daran wie entwickelt wird70 , sondern es werden mögliche Implementierungen und Systeme gemäß eines Systems Engineerings71 aus „Kundenanforderungen“ abgeleitet. Zunächst wird der Begriff der Funktion definiert. Funktion Folgende Definition einer allgemeinen technischen Funktion ist in der Literatur zu finden, vgl. [88, S. 56]: „Eine Funktion ist eine am Zweck orientierte, lösungsneutrale, als Operation beschriebene Beziehung zwischen Eingangs- und Ausgangsgrößen eines Systems.“ Im Rahmen dieser Arbeit wird der Begriff der Funktion ein Stück weit eingeschränkt. Bezieht man die genannte Definition im Automobilbereich auf Fahrzeugfunktionen, dann kann unter einer Funktion ein beobachtbares Verhalten eines Fahrzeugs verstanden werden, dessen Beziehung zwischen Eingangs- und Ausgangsgrößen lösungsneutral72 beschrieben wird. Diese Funktion wird aus Sicht des Nutzers beschrieben und orientiert sich nicht an einer möglichen technischen Umsetzung. Einige Beispiele für Funktionen sind z. B. ACC, ABS oder auch ein Parklenkassistent. Die Regelung der Funktion ABS befindet sich lediglich auf einem einzigen Steuergerät. Es gibt jedoch auch sogenannte vernetzte Funktionen, die auf mehrere Steuergeräte aufgeteilt sind. Vernetzte Funktion Vernetzte Funktionen werden mithilfe mehrerer Steuergeräte realisiert, d. h. dass sich nicht alle Softwareteile einer Funktion auf einem Steuergerät befinden. 69 70 71 72

An einer Funktion arbeiten mehrere Entwicklungspartner, die sich an verschiedenen Standorten befinden. Dies können z. B. unterschiedliche Zulieferer oder Fachabteilungen sein. Z. B. modellbasiert oder agil. Vgl. [108] für nähere Informationen. Die Anforderungen an Funktionen orientieren sich nicht an möglichen Umsetzungen, d. h. sie können mithilfe verschiedener Steuergeräte oder Bauteile realisiert werden.

3.1 Begriffsdefinitionen für eine durchgängige Funktionsentwicklung

37

Sie verteilen sich stattdessen auf verschiedenen Steuergeräten im Fahrzeug und realisieren mit der beteiligten Hardware eine Funktion. Für eine Realisierung der Funktion ACC können sich z. B. Softwareteile auf Motor-, Bremsenund Radarsteuergeräten wiederfinden. Die Verteilung der Funktionsteile kann fahrzeugspezifisch stattfinden, was dann zum Begriff des Systems führt. System In der genannten Begriffsdefinition einer Funktion wird der Begriff System bereits verwendet. Für den Begriff des Systems wird in [100, S. 8] folgende Definition angegeben: „Als System bezeichnen wir eine willkürlich abgegrenzte Gesamtheit von Elementen, die zueinander, zum Ganzen und in der Regel auch zur Umwelt in Beziehung stehen.“ Im Rahmen dieser Arbeit wird ein System funktionsspezifisch abgegrenzt, d. h. unter einem System wird eine Realisierung oder Umsetzung einer Funktion in einem spezifischen Fahrzeug verstanden. Im Gegensatz zur Beschreibung einer Funktion ist die Beschreibung eines Systems nicht lösungsneutral. Funktionsteile können sich für verschiedene Realisierungen, d. h. in verschiedenen Fahrzeugprojekten und somit anderen Systemen, auf unterschiedlichen Steuergeräten befinden. Die Systembeschreibung liefert somit eine eindeutige Realisierung, d. h. eine Verteilung von Funktionsteilen einer Funktion in einem Fahrzeugprojekt. Die vernetzte Funktion DSR 73 gibt dem Fahrer z. B. situationsabhängig Lenkempfehlungen zur Stabilisierung des Fahrzeugs. In einem konkreten Fahrzeug wird diese Funktion von einem bestimmten System realisiert. Zum System gehören die Steuergerätekomponenten Bremse und Lenkung sowie deren Schnittstellen. Hinzu kommen die physikalischen Komponenten Lenkung, Bremse und benötigte Hardwarekomponenten wie z. B. die Lage- und Raddrehzahlsensoren des Bremsensteuergeräts und entsprechende Sensoren und Aktoren der Lenkung. Der Servomotor und andere Systemteile, die für die Umsetzung der Lenkempfehlung genutzt werden müssen, können auch von anderen Funktionen wie z. B. einem Parklenkassistent verwendet werden. Komponente Ein System besteht im Fahrzeug aus mehreren Komponenten wie verschiedenen Steuergeräten, Sensoren und physikalischen Bauteilen. Dies können bei einer Lenkung beispielsweise das Steuergerät, das Lenkgetriebe, die Sensoren und der Servomotor sein. Die Gesamtheit aller Komponenten bildet das zugrunde liegende System. Zustandsvariable Komponenten eines Realsystems haben verschiedene Eigenschaften. Eigenschaften, die sich ändern können, werden als Zustandsvariablen bezeichnet [100, S. 18]. Eine Lenkung kann z. B. aus den Komponenten Servomotor, Lenkgestänge und Lenkwinkelsensoren bestehen. Jede dieser Komponenten kann wiederum Zustandsvariablen wie z. B. Steifigkeiten, Sensorauflösungen74 73 74

Siehe Unterkapitel 4.1 für eine detaillierte Funktionsbeschreibung. Ein Sensor hat eine bestimmte Genauigkeit und kann eine physikalische Eigenschaft nicht beliebig fein abtasten.

38

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

oder Reibwerte und Trägheiten haben. Der Zustand eines Systems ist durch die Werte aller Zustandsvariablen definiert. Sequenzen von Zuständen beschreiben wiederum die Dynamik in einem System [100, S. 19 ff.]. Nachdem das Gesamtsystem Fahrzeug beschrieben wurde, erfolgt die Beschäftigung mit Begriffen, die für den Aufbau einer Simulation eines Systems benötigt werden. 3.1.2 Aufbau von Simulationen Mit der Definition für die Beschreibung von allgemeinen Modelleigenschaften hat sich bereits die Arbeitsgruppe „Fidelity Implementation Study Group„ befasst, siehe [60]. Die folgenden Definitionen lehnen sich teilweise an den bereits existierenden Definitionen an, sie müssen im Rahmen der vorliegenden Arbeit jedoch genauer eingegrenzt bzw. verfeinert werden und können daher nicht vollständig übernommen werden, da sie für diese Arbeit nicht spezifisch genug definiert sind. Abbildung 3.2 zeigt exemplarisch einen Aufbau einer Gesamtsimulation für die bereits beschriebene Funktion DSR. Die Simulation besteht aus den Steuergeräten einer Lenkung, einem Modul EPS

Zahnstangenkraft

Streckenmodell

K1

K2

K3

Zahnstangengeschwindigkeit, Zahnstangenweg, Drehstabverdrehung

Modul FahrdynamikStreckenmodell

K11

Physikalische Signale

K12

Entwicklungsgegenstand Bus-Signale Umgebungsmodell

XiL-SW

K4

Modul EBKV Streckenmodell

K5

K6

Raddrehzahlen, Längs- und QuerBeschleunigungen, Gierrate,

Bremsdruck Volumenstrom

Bremsdrücke an Rädern Modul ESC

Streckenmodell

K8

K9

XiL-SW

XiL-SW

K7

K10

Abbildung 3.2: Aufbau einer vernetzten Simulation von Steuergeräten nach [52, S. 4]

elektrischen Bremskraftverstärker und einem Bremsensteuergerät. Die Steuergeräte werden zusammen mit anderen physikalischen Komponenten des Systems simuliert. Im Folgenden werden Simulationsmodelleigenschaften und Begriffe in Bezug auf ein Realsystem definiert. Eine Anwendung der Begriffe wird beispielhaft in Abschnitt 3.1.2 anhand Abbildung 3.2 vorgestellt. Streckenmodell Es sind nicht immer alle Zustandsvariablen von Komponenten eines Systems für einen Test relevant, daher können in der Simulation Hardwarebauteile oder ganze Steuergeräte durch ver-

3.1 Begriffsdefinitionen für eine durchgängige Funktionsentwicklung

39

einfachte Ersatz- bzw. Streckenmodelle ersetzt werden. Diese Streckenmodelle bilden lediglich Eigenschaften des Realsystems ab, die für den Test relevant sind. Ferner können mehrere Komponenten vereinfacht in einem Modell zusammengefasst werden. Ein Streckenmodell ersetzt in einer Simulation somit ein oder mehrere Komponenten eines realen Systems. Aus Sicht der Regelungstechnik umfasst dies gewöhnlich die Regelstrecke eines Reglers, siehe Abbildung 2.2. Bezogen auf ein Beispiel der Lenkung kann ein Streckenmodell z. B. ein Ersatzmodell des Elektromotors aufweisen. Auch die Fahrdynamik stellt ein Streckenmodell dar, wobei hier sehr viele verschiedene Komponenten des Systems wie z. B. Reifen oder Achsen in einem Streckenmodell zusammengefasst werden. XiL-SW-Elemente Wie bereits in Abschnitt 2.2.4 beschrieben, liegen Elemente von zu testenden Funktionen für die Testmethoden MiL, SiL, PiL, FiL und HiL in verschiedenen Arten vor. Als Oberbegriff wird im Folgenden der Begriff XiL-SW oder XiL-SW-Element für das Testobjekt verwendet. Das „X“ steht dabei für eine der aufgezählten Testmethoden, vgl. Abschnitt 2.2.4. Abhängig von den Anforderungen kann z. B. ein SiL-SW-Element für einen SiL-Test oder HiL-SW-Element für einen HiL-Test vorliegen. Module Zur besseren Übersichtlichkeit werden verschiedene Streckenmodelle und XiL-SW-Elemente zu einer größeren Einheit zusammengefasst. Diese werden im Rahmen dieser Arbeit als Simulationsmodule, kurz Module bezeichnet. Module werden signalorientiert gekoppelt, d. h. ein Modul hat Inputs und Outputs und ggf. Parameter und interne Variablen. Ein Modul ist z. B. eine XiL-SW-Funktion der Lenkung mit den dazugehörigen physikalischen Komponenten. Eine Komponente gehört somit genau zu einem Modul. In Abbildung 3.3 ist ein Beispiel eines Moduls zu sehen:

6LPXODWLRQVPRGXO 'UHKVWDEYHUGUHKXQJ =DKQVWDQJHQNUDIW

=DKQVWDQJHQZHJ =DKQVWDQJHQJHVFKZLQGLJNHLW &$16LJQDOH

,QWHUQH=XVWDQGVYDULDEOHQ &$16LJQDOH

Abbildung 3.3: Simulationsmodul am Beispiel der Lenkung

Modellumfang Für verschiedene Simulationen sind nicht alle Zustandsvariablen von Komponenten von Bedeutung. Beispielsweise wird für geringe Lenkwinkeleingriffe keine genaue Modellierung des mechanischen Endanschlags der Lenkung benötigt. Unter dem Begriff Modellumfang soll die

40

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Auswahl von Zustandsvariablen einer Komponente verstanden werden, die in einem Streckenmodell repräsentiert wird. Genauigkeit Die Genauigkeit ε definiert, wie genau ein Simulationsmodell eine Zustandsvariable des Realsystems reproduziert. Die Formel 3.1 beschreibt die absolute Genauigkeit für eine Zustandsvariable in Bezug auf die definierten Begriffe: |Zustandsvariablei,Modell − Zustandsvariablei,reale Komponente | < ε absolut,i

(3.1)

Ein relatives Maß für die Abweichung wird in Formel 3.2 dargestellt. Hier wird die Größe der Abweichung auf den Wertebereich der Zustandsvariable des Realsystems bezogen, um eine prozentuale Abweichung zu erhalten. |

Zustandsvariablei,Modell − Zustandsvariablei,reale Komponente | ∗ 100% = ε relativ,i Zustandsvariablei,reale Komponente

(3.2)

Aus der letzten Formel kann darüber hinaus ein Maß für die Genauigkeit eines Modells bestimmt werden. Hierfür wird die maximale prozentuale Abweichung für alle Zustandsvariablen eines Modells verwendet, siehe Formel 3.3. max(ε relativ,1 , ..., ε relativ,n ) = ε Modell

(3.3)

Generell sollte die Genauigkeit möglichst gut zum Anwendungsfall passen. Das bedeutet, dass die Genauigkeit in einer frühen Entwicklungsphase ggf. geringer ausfallen darf als zu einem spätem Zeitpunkt. Außerdem wird für Vergleiche zwischen verschiedenen Simulationen75 in der Regel eine geringere Übereinstimmung als für Tests gegen feste Messgrößen76 benötigt. Wie genau eine Zustandsvariable für eine Aussage sein muss, hängt letztendlich von Anwendungsfall ab. Da es sich um eine Simulation handelt, sind stets Abweichungen zwischen Realsystem und Modell zu erwarten, wobei aufgrund von äußeren Bedingungen auch in der Realität Abweichungen auftreten können. Wenn ε Modell eine geeignete Genauigkeit hat, ist das Modell für einen bestimmten Test einer Fahrzeugfunktion geeignet. Gültigkeitsbereich Der Gültigkeitsbereich definiert die Wertebereiche min, max ∈ R sowie die Frequenzbereiche f min , f max ∈ R von Inputs eines Streckenmodells. Der Wertebereich kann auf Basis von Manövern bestimmt werden und er beschreibt, welchen Wertebereich ein Input eines Modells für die Simulation eines Manövers annimmt. Die Frequenzen beschreiben die Dynamik zwischen Streckenmodellen in Bezug auf bestimmte Inputs eines Modells. Wenn zwischen Modellen eine hohe Dynamik vorliegt, existieren auch hohen Frequenzen in auszutauschenden Signalen. Der Frequenzbereich beschreibt somit, wie schnell sich Werte eines Eingangs innerhalb des Wertebereichs ändern.

75 76

Variante A verhält sich anders als Variante B. Eine Absolutaussage könnte z. B. sein, dass ein Bremsweg bei bestimmten Bedingungen unter 35 Metern liegt.

3.1 Begriffsdefinitionen für eine durchgängige Funktionsentwicklung

41

Im definierten Gültigkeitsbereich muss ein Modell eine ausreichende Genauigkeit für einen Test vorweisen. Das Modell kann auch in anderen Werte- oder Frequenzbereichen simulierbar und für bestimmte Tests genau genug sein. Dennoch sollte der Gültigkeitsbereich möglichst klein gehalten werden, damit sich die Validierung für den Modellersteller weniger aufwändig gestaltet. Beispielsweise werden in einem Streckenmodell andere Zustandsvariablen des Fahrzeugs für niedrige oder hohe Geschwindigkeiten benötigt77 . Der Gültigkeitsbereich kann als eine Abstimmung von Testanforderungen bzgl. eines Modells zwischen Modellverwender und -ersteller verstanden werden. Wenn Modelle in einem Frequenzband f min , f max genau sind, müssen sie ggf. trotzdem ab einer f min von Null simuliert werden können, da Manöver ggf. im Stillstand starten. Einsatzzweck von Streckenmodellen und XiL-SW-Elementen Eine weitere Frage bei Streckenmodellen und XiL-SW-Elementen stellt sich beim Verwendungszweck. Diese Unterscheidung ist sinnvoll, da Modelle im Entwicklungsprozess möglichst wiederverwendet werden sollten. Streckenmodelle von Komponenten und XiL-SW-Elemente können Entwicklungsgegenstand sein oder als Umgebungsmodell für ein Test- oder Entwicklungsgegenstand dienen. Wenn beispielsweise in einer frühen Phase einer Fahrzeugentwicklung Konzeptbewertungen für die Komponente „Achse“ mithilfe der Simulation getroffen werden sollen, wird hierfür ein entsprechendes Simulationsmodell aufgebaut. Dieses Modell ist Entwicklungsgegenstand, da an diesem Modell frühzeitig Erkenntnisse über das Verhalten der Achse gewonnen werden sollen. Ein Umgebungsmodell ist hingegen eine Komponente, die für einen plausiblen Test in der Simulation benötigt wird, aber nicht Testgegenstand ist. Wenn später im Entwicklungsprozess eine Funktion entwickelt wird, für die eine detaillierte Abbildung der Achsen von Bedeutung ist, kann das bereits erstellte Modell als Umgebungsmodell verwendet werden. Hier wäre der Entwicklungsgegenstand beispielsweise das XiL-SW-Element der Funktion; die Achsen im Fahrzeug stellen in diesem Fall lediglich ein Umgebungsmodell dar. Wann es sich bei einem Streckenmodell oder XiL-SW-Element um einen Entwicklungsgegenstandoder um ein Umgebungsmodell handelt, ist demnach anwendungsspezifisch. Ein Streckenmodell kann zudem auch lediglich als Umgebungsmodell erstellt werden. Anwendung der Begriffe Die Simulation in Abbildung 3.2 setzt sich aus den Modulen EPS, EBKV, ESC und einem Fahrdynamikmodell zusammen. Hierbei bilden die verschiedenen Streckenmodelle jeweils Komponenten des Realsystems ab. Außerdem wird deutlich, dass die jeweiligen XiL-SW-Elemente ebenfalls als Komponenten zu verstehen sind. Die physikalischen Verbindungen zwischen Streckenmodellen sind in Grün dargestellt. Darüber hinaus kommunizieren die Module EPS, eBKV78 und ESC im Fahrzeug über einen CAN-Bus miteinander. Diese Vernetzung wurde in der Abbildung zugunsten einer besseren Übersichtlichkeit nicht abgebildet. Entwicklungsgegenstand sind in diesem Fall die XiL-SW-Elemente von Lenkung und Bremse, da hier der Testfokus liegt. Die weiteren Streckenmodelle sind zusammen mit dem eBKV Umgebungsmodelle, die für einen plausiblen Test benötigt werden. 77 78

Z. B. kann der Windwiderstand eines Fahrzeugs bei niedrigen gegenüber hohen Geschwindigkeiten vernachlässigt werden. Ein elektrischer Bremskraftverstärker verringert die benötigte Betätigungskraft einer Bremse, indem der Bremsdruck elektrisch verstärkt wird, um eine benötigte Bremskraft aufzubauen.

42

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Nachdem die wichtigsten Begriffe erläutert wurden, werden im nächsten Unterkapitel aktuelle Entwicklungsprozesse von Steuergeräten und Funktionen analysiert.

3.2 Analyse der aktuellen Funktionsentwicklung Auf Basis von Analysen mit verschiedenen Experten und Funktionsentwicklern der Technischen Entwicklung bei Volkswagen wird in diesem Unterkapitel ein Überblick über die aktuelle Funktionsentwicklung dargestellt. Da verschiedene Reifegrade von Funktionen im Entwicklungsprozess existieren, ergeben sich zudem Unterschiede in den XiL-SW-Elementen. Zum Abschluss dieses Unterkapitels wird auf resultierende Potentiale und Erkenntnisse eingegangen. 3.2.1 Reifegrade von Funktionen im Entwicklungsprozess Im Entwicklungsprozess gibt es verschiedene Ausprägungen von Steuergeräten und unterschiedliche Reifegrade von Funktionen. Wie bereits in Unterkapitel 2.1 beschrieben, erlaubt das V-Modell XT Entwicklungsschleifen, die Tailoring genannt werden. Dies spiegelt sich in der Entwicklung von Funktionen in der Automobilindustrie bzgl. XiL-SW-Elementen durch den Austausch verschiedener Entwicklungsstände von Software im Prozess wider. Viele OEMs entwickeln Fahrzeuge nach dem Baukastenprinzip, vgl. [106]. Die verschiedenen Fahrzeuge, die auf einem solchen Baukasten basieren, werden allgemein Hut genannt. Komponenten eines Fahrzeughuts, die auf einem Baukasten basieren, ähneln sich somit in verschiedenen Fahrzeugen. Andere Komponenten werden hingegen spezifisch für einen Hut angepasst. In Bezug auf Software bedeutet dies, dass Code für verschiedene Fahrzeugprojekte wiederverwendet wird. Es werden demnach nicht für jedes Fahrzeugprojekt alle Funktionen neu entwickelt oder neue Zulieferer benannt. Im Entwicklungsprozess von XiL-SW-Elementen äußert sich das Tailoring durch sogenannte Integrationsstufen, vgl. [45]. Diese Stufen sind bestimmte Zeitpunkte im Entwicklungsprozess. Hier müssen Funktion eine bestimmte Reife vorweisen und es kommen später ggf. weitere Funktionen hinzu. Außerdem wächst die Reife von bereits vorhandenen Funktionen. Die Stufen werden im Entwicklungsprozess funktionsspezifisch festgelegt. Für neue und bereits bestehende Funktionen existieren unterschiedliche Anforderungen. Für neu entwickelte Funktionen oder wenn größere Änderungen in der Softwarearchitektur eines Steuergeräts auftreten, müssen Anforderungen mit Zustandsautomaten sowie Schnittstellen der Software genau definiert werden. Wenn eine Funktion in einer bereits bestehenden Architektur hingegen bereits vorhanden ist, fällt der Aufwand für die Anforderungsanalyse in der Regel geringer aus, da auf bestehende Konzepte zurückgegriffen werden kann. Darauf aufbauend existieren fahrzeugspezifische Entwicklungsstränge79 . Nach der Implementierung einer Funktion findet in der Entwicklung eine fahrzeugspezifische Parametrierung der steuergeräteinternen Parameter statt. Hierbei wird getestet, ob das Fahrzeug für verschiedene 79

Fahrzeuge können auf demselben Baukasten basieren, aber dennoch unterschiedliche Funktionsumfänge im Steuergerät vorweisen.

3.2 Analyse der aktuellen Funktionsentwicklung

43

Manöver den Anforderungen aus Sicht des Kunden entspricht. Außerdem werden markenspezifische Eigenschaften von Funktionen sichergestellt, sodass sich eine Funktion einer Marke in verschiedenen Fahrzeugen und Implementierungen für den Kunden gleich verhält. Die Bewertung von markenspezifischen Charakteristika ist meist subjektiv, dennoch existieren erste Arbeiten, die sich damit beschäftigen, die Charakteristika mit objektiven Kennzahlen messbar zu machen [112]. Sowohl beim Zulieferer als auch beim OEM finden Funktionstests in den verschiedenen Testinstanzen statt. Wird beim OEM ein Fehler gefunden, kann ein längerer Zeitraum vergehen, bis der Fehler beim Zulieferer reproduziert und eine Änderung umgesetzt wird. Ferner können komplexe Prozessketten die Lieferungen von neuen Softwareständen verzögern. Wenn es sich um vernetzte Funktionen handelt, muss der Fehler zudem sehr genau eingegrenzt werden können. Abbildung 3.4 stellt die Entwicklung einer vernetzten Funktion nach aktuellem Stand dar. Nach dem Systementwurf beginnen die Zulieferer der beteiligten Steuergeräte jeweils unabhängig voneinander mit einer Anforderungsanalyse. Im zweiten Schritt werden Software und Hardware entworfen. Nach der Implementierung und dem Modultest folgen weitere Kompositionsschritte. Für ein Steuergerät werden zunächst verschiedene Softwareteile integriert. Anschließend folgt die Integration auf das jeweilige Steuergerät. Um sicherzustellen, dass der Code zuverlässig auf dem Steuergerät läuft, werden HiL- bzw. PiL-Tests durchgeführt. Anschließend werden verschiedene Steuergeräte auf Systemebene integriert. Dies findet schwerpunktmäßig im Fahrversuch oder ggf. an einem Integrations-HiL-Prüfstand80 statt. Wenn z. B. ein Fehler in der Software auftritt, müssen viele Integrationsschritte wiederholt werden. Die Entwicklung ist demnach ein iterativer Prozess mit vielen Entwicklungsschleifen, wobei das Ziel verfolgt wird, Fehler möglichst früh zu finden, denn je früher ein Fehler gefunden wird, desto niedriger sind die Fehlerbehebungskosten [111]. Wird ein Fehler im äußersten Fall erst beim Kunden entdeckt, kann es außerdem zu Rückrufen kommen. Wenn ein Fehler erst auf Systemebene gefunden wird, kann bis zur Behebung einige Zeit vergehen, da Fehler einerseits identifiziert und andererseits sehr genau eingegrenzt werden müssen. Zudem durchlaufen Zulieferer Prozesse und Entwicklungsschleifen vor einer Neuauslieferung eines Softwarestands, die einen erneuten Test verzögern können. Hier besteht daher Potential, die Tests in Simulationen vorzulagern, um Fehler frühzeitig zu finden und somit die Fehlerbehebungskosten zu minimieren und eine Funktion kann schneller serienreif werden. Im Folgenden werden zunächst Ausprägungen von XiL-SW-Elementen beleuchtet, da je nach Testanforderung und Zeitpunkt im Entwicklungsprozess verschiedene Ausprägungen verwendet werden können. 3.2.2 Eigenschaften verschiedener XiL-SW-Elemente Bezieht man die Ausprägungen von XiL-SW-Elementen auf die Reifegrade von Funktionen im Entwicklungsprozess, dann ergeben sich nicht nur Unterschiede zwischen Ausprägungen. Es existieren auch Unterschiede in XiL-SW-Elementen einer gleichen Steuergeräteausprägung im Entwicklungsprozess.

80

Ein Prüfstand, an dem alle Steuergeräte eines Fahrzeugs im Verbund getestet werden.

44

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

,QWHJUDWLRQV+L/

6\VWHP

[PDO

6WHXHUJHUlWH

.RPSRQHQWHQ+L/

.RPSRQHQWHQ6L/

Abbildung 3.4: Analyse der aktuellen vernetzten Funktionsentwicklung mithilfe von SiL- und HiLSimulationen

Im Vergleich zwischen frühen und späten Integrationsstufen wächst z. B. die Menge der integrierten Software, da neue Funktionen hinzukommen. XiL-SW-Elemente können sich aber auch hinsichtlich des integrierten Codes unterscheiden. Bei HiL-Tests oder im Fahrversuch wird stets der gesamte, aktuell verfügbare Code verwendet. Für MiL- oder insbesondere SiL-Elemente gilt es hingegen zu spezifizieren, welche CodeUmfänge für einen Test vorhanden sein müssen, vgl. Abbildung 3.5. Sie zeigt, dass sich in SiL-Elementen zu verschiedenen Integrationsstufen unterschiedlich viele integrierte Softwareteile befinden können. Für MiL-Simulationen wird beispielsweise lediglich die Funktion selbst benötigt, die nicht auf der finalen Hardware getestet wird. Wenn jedoch Teile des Betriebssystems oder hardwarespezifische Codeteile seitens des OEMs getestet werden sollen, dann sollte das XiL-SW-Element als SiL-Element vorliegen. Hier müssen entsprechende Codeteile in das SiL-Element integriert werden. Falls nicht alle dieser Komponenten integriert werden, sollte ebenso spezifiziert werden, welche Applikationssoftwarekomponenten benötigt werden, damit alle für den Test relevanten Komponenten zur Verfügung stehen. Da die Anzahl von Funktionen pro Steuergerät wächst, vgl. [94, S. 18], gewinnt auch der Test der Vernetzung von Applikationssoftwarekomponenten im Steuergerät z. B. durch die AUTOSAR Middleware an Bedeutung. Die Vernetzung sollte daher insbesondere bei Integrationstests zwischen Softwarekomponenten wiederverwendet werden. Ein weiterer Aspekt besteht darin, zu definieren, ob Teile der Basissoftware wie die Diagnosesoftware getestet werden sollen. Dies kann z. B. mithilfe eines Diagnose-Dienstes im SiL-Steuergerät analog zum Steuergerät in Hardware realisiert werden.

3.2 Analyse der aktuellen Funktionsentwicklung

$XVWDXVFKYRQ;L/6:(OHPHQWHQ 0L/ ,6

6L/ 0L/ ,6

6L/

6L/ ,6

+L/ 6L/ ,6

+L/ Abbildung 3.5: Austausch eines XiL-SW-Elements mit Integrationsstufenmanagement

45

46

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Außerdem können interne Parameter eines Steuergeräts81 ggf. auch in SiL-Simulationen modifiziert oder gelesen werden können. Dieser Abschnitt zeigt, dass XiL-SW-Elemente keine fest definierte Struktur darstellen. Bei einem Austausch von z. B. SiL-Elementen sollte daher genau festgelegt werden, welche Bestandteile des Steuergerätecodes benötigt werden. Je nach Architektur kann es sinnvoller sein, mehr oder weniger zusätzliche Codeteile für den Test zu integrieren. Grundsätzlich müssen für Tests alle benötigten Codeteile zur Verfügung stehen. Im Folgenden werden die Potentiale der verschiedenen XiL-SW-Elemente dargestellt, da nicht immer eindeutig ist, welche Ausprägung sich für welche Tests eignet. 3.2.3 Erkenntnisse und Potentiale Das Ziel im Entwicklungsprozess besteht dabei darin, Fehler möglichst früh zu finden, da dadurch die Fehlerbehebungskosten geringer ausfallen, vgl. [111]. Hierfür bieten sich insbesondere die Testinstanzen SiL und HiL an. Mit HiL-Tests kann der Fahrversuch sehr gut unterstützt werden, da der Versuchsaufbau bei HiL-Tests der Realität in hohem Maß ähnelt. SiL-Tests stellen ein großes Potential dar, da keine spezielle Hardware notwendig ist, um die Software auszuführen. Darüber hinaus können SiL-Elemente beliebig kopiert werden, um eine Skalierbarkeit der Simulation z. B. auf Rechenclustern zu gewährleisten. Es eignen sich zusammenfassend primär Tests mit hohem softwaretechnischen Fokus für eine Verlagerung in die virtuelle Simulation82 . Hardwarespezifische Tests wie z. B. Spannungstests können hingegen nur bedingt mit SiL-Elementen durchgeführt werden. Hier rentiert sich der Zusatzaufwand für eine detaillierte Nachbildung der benötigten Komponenten nur bedingt, da die Erstellung und der Test solcher Modelle sehr aufwändig sind. Dennoch werden Emulationen von Chips im Bereich der Steuergeräteentwicklung z. B. für Integrationstests zukünftig wohl mehr in den Fokus rücken, da nur hier der originale Code mit der gesamten Basissoftware skalierbar getestet werden kann. Im Rahmen der funktionsorientierten Entwicklung stehen Funktionen und die dafür relevanten Kundenanforderungen im Fokus. Diese Anforderungen sind unabhängig von der Software, der Hardware und möglichen Implementierungen. Damit Kundenwünsche und Funktionen schneller in einem spezifischen System umgesetzt werden können, zeigt sich bereits heute der Bedarf, Tests in die Simulation zu verlagern. Darüber hinaus besteht Potential für die Einsparung von Fahrversuchen und benötigten Prototypen, indem Testumfänge in SiL- und HiL-Umgebungen verlagert werden. Vor dem Hintergrund des automatisierten Fahrens wird die Nutzung der Simulation unabdingbar, da nur auf diese Weise effizient und kontinuierlich neue Softwarestände und Funktionen getestet werden können. Für die Darstellung der verschiedenen Modellanforderungen für die Tests wird zunächst eine Strukturierung in Form von Testphasen benötigt, da die Reife einer Funktion im Rahmen der funktionsorientierte Entwicklung wächst. Das grundsätzliche Vorgehen in dieser Arbeit besteht darin, aus identifizierten Testanforderungen auf Testmethoden83 zu schließen und dafür geeignete Streckenmodelleigenschaften zu definieren. 81 82 83

Dies kann bei einem virtuellen Steuergerät z. B. ähnlich wie bei einem Steuergerät mithilfe eines XCP-Servers realisiert werden [85]. Simulation mit SiL-Elementen ohne spezielle Hardware. Bei den Testmethoden liegt Code als MiL-, SiL-Element oder als reales Steuergerät vor.

3.3 Testphasen von Funktionen

47

Das nächste Unterkapitel befasst sich mit den verschiedenen Testphasen von vernetzten Funktionen.

3.3 Testphasen von Funktionen Der Test von vernetzten Funktionen mithilfe von Streckenmodellen gestaltet sich in der Simulation aktuell noch aufwändig. Dies liegt primär daran, dass die unterschiedlichen Funktionen spezifische Anforderungen an Streckenmodelle von Komponenten aufweisen. Die Modelle werden von verschiedenen Entwicklungspartnern zugeliefert und die verschiedenen Anforderungen an die Modelle sind nicht immer bekannt. Dennoch besteht hier großes Potential für frühzeitigere Fehlerfindung in der Software, daher werden die Anforderungen in dieser Arbeit genau betrachtet. Aufgrund der genannten Gründe ist die Simulation von vernetzten Funktionen nur effizient durchführbar, wenn alle benötigten Komponenten und Prozesse aufeinander abgestimmt sind. Hierfür ist es zunächst notwendig, Tests in verschiedene Phasen in den Entwicklungsprozess einzuordnen, um anhand dessen benötigte Anforderungen an Streckenmodelle definieren zu können. Für die Ableitung von Tests anhand der Anforderungen und deren Durchführung existieren bereits Normen aus dem Bereich der Funktionalen Sicherheit [19], Methoden wie das Time Partition Testing [72] oder die FMEA84 -Analyse [63]. Das Time Partition Testing umfasst eine systematische Definition der Testdatenauswahl und deren Automatisierung. Bei der FMEAAnalyse werden während der Entwicklung bereits mögliche Produktfehler bzgl. der Bedeutung für den Kunden, der Auftrittswahrscheinlichkeit und der Entdeckungswahrscheinlichkeit identifiziert und bewertet. Auf Grundlage des V-Modells XT befasst sich diese Arbeit damit, wie Tests von vernetzten Funktionen im Tailoring bei einer Fahrzeugvariante mit dem Ziel einer durchgängigen Entwicklungsmethode definiert werden können und wie sich der Testaufbau mit den dazu benötigten Modellen daraufhin verändert. Dies ist ein zentraler Aspekt der Arbeit, vgl. Abschnitt 1.3.2. Es handelt sich um fünf Testphasen, die nacheinander vorgestellt werden. Bevor diese detailliert dargestellt werden, erfolgt eine Erläuterung, wie diese Strukturierung entwickelt wurde. 3.3.1 Herleitung der Testphasen Auf der Basis verschiedener Testanforderungen wurde ein Konzept mit mehreren Iterationsschleifen85 für Funktionen innerhalb des V-Modells entwickelt. Dies sind Testphasen, die identifizierte Testanforderungen für Funktionen innerhalb der Entwicklung abdecken. Sie beantworten zielgerichtet Fragestellungen im Fahrversuch und entlasten bestehende HiL-Tests mit virtuellen Simulationen. Hierbei besteht das Ziel, schnellere Iterationsschleifen innerhalb des V-Modells zu realisieren. Daraus resultiert einerseits die Qualität in der Entwicklung von vernetzten Funktionen zu steigern, indem die Simulation als zusätzliches Bewertungsmittel zur Verfügung steht, 84 85

Failure Mode and Effects Analysis. Fehler werden gewöhnlich vom Tester an die Softwareentwickler weitergeleitet. Die Schleife liegt darin, dass Fehler zunächst gefunden, anschließend übermittelt und darauffolgend behoben werden müssen. Danach wird der Test erneut durchgeführt.

48

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

und andererseits durch vorgelagerte Simulationen früher eine höhere Reife von Funktionen zu ermöglichen. Das erarbeitete Konzept basiert auf Analysen mit Experten aus verschiedenen Abteilungen der Technischen Entwicklung. Diese Experten teilten mit, wie Funktionen in Fahrversuchen getestet werden. Es wurde der Fragestellung nachgegangen, welchen Mehrwert die Simulation für die Funktionsentwicklung bietet. Des Weiteren wurden bestehende Tests im XiL-Umfeld analysiert. Aus diesen gewonnenen Erkenntnissen wurde das im Folgenden vorgestellte Konzept der Testphasen als der Teil der Ergebnisse der Doktorarbeit entwickelt, mit dem die identifizierten Anforderungen an Simulationen erfüllt werden. Nach der Fertigstellung des Konzepts erfolgten weitere Abstimmungen mit Experten, die ergeben haben, dass die Anforderungen aus den Fahrversuchen und den HiL-Tests vollständig abgebildet werden. Darüber hinaus kann der Nutzen der Testphasen anhand von selbst durchgeführten Pilotprojekten nachgewiesen werden, vgl. Kapitel 4. Die Durchführbarkeit der Testphasen wird wiederum durch festgelegte Modelleigenschaften sichergestellt. Bei der ersten erarbeiteten Testphase handelt es sich um den Schnittstellentest. 3.3.2 Schnittstellentest In dieser Phase gilt es, zu testen, ob ein XiL-SW-Element die im Lastenheft definierten Anforderungen bezüglich einer Funktion erfüllt. Hierbei werden die einzelnen Funktionsteile von verschiedenen Steuergeräten zunächst unabhängig voneinander getestet. Der Schnittstellentest umfasst im Rahmen dieser Arbeit zwei Aspekte. Hierbei handelt es sich zum einen um den Test aller Zustände von XiL-SW-Elementen und zum anderen um die funktionale Prüfung der Umsetzung von Anforderungen. Bei einer vernetzten Funktion existieren in der Regel verteilte Zustandsautomaten, die sich auf verschiedenen Steuergeräten befinden. Die Funktionsteile agieren unter verschiedenen Bedingungen und Zuständen unterschiedlich. Außerdem existieren Zeitbeschränkungen und Bedingungen für Zustandsübergänge86 sowie Fehlerzustände87 . Die Zustände können gewöhnlich über die Bus-Schnittstellen der jeweiligen Funktion getestet werden, wobei ggf. plausible Daten am XiL-SW-Element anliegen müssen, damit sich verschiedene Zustände einstellen. Probleme können bei der Integration z. B. auftauchen, wenn die Wechsel der Zustände von verschiedenen Teilsystemen nicht aufeinander abgestimmt sind. Dies kann z. B. passieren, wenn Anforderungen im Lastenheft nicht eindeutig sind88 oder Fehler in der Umsetzung existieren. Der Zustandstest ermöglicht hier, die Software vor der Integration effizient und ggf. automatisiert zunächst einzeln zu testen. Hierbei wird der Fahrversuch gezielt unterstützt, da Fehler in Zuständen oder Übergängen schneller und bereits vor der Integration gefunden werden können. Fehler, wie z. B. die Fortpflanzung von Fehlern über mehrere Funktionsteile, können jedoch erst in späteren Testphasen bei der Integration gefunden werden. 86 87 88

Z. B. kann der Fahrer einen Beschleunigungsvorgang beim ACC durch die Betätigung des Bremspedals abbrechen. Ein Fehlerzustand ist z. B. eine gestörte Kommunikation zwischen Steuergeräten. Z. B. eindeutiger Startzustand.

3.3 Testphasen von Funktionen

49

Einerseits kann der Test manuell erfolgen, andererseits können auch automatisierte modellbasierte Testmethoden verwendet werden, siehe Abbildung 3.6. Beim zunächst vorgestellten automatisierten Test liegen neu entwickelte Aspekte auf der Fragestellung, wie der modellbasierte Tests auf vernetzte Funktionen angewendet werden kann. Für modellbasierte Tests wird aus den Anforderungen einer Teilfunktion ein Testmodell erstellt, welches das Verhalten und die Übergänge der Zustände einer Teilfunktion abbildet. Aus diesem Testmodell können anschließend Testfälle generiert werden, die auf dem XiL-SW-Element und dem Testmodell ausgeführt werden. Die Resultate des XiL-SW-Elements werden anschließend mit den Resultaten des Testmodells verglichen. In einer modellbasierten Entwicklung kann das Verhaltensmodell auch als Implementierungsgrundlage genutzt werden. In diesem Fall eignet sich die modellbasierte Testfallerzeugung auch, um zu verifizieren, dass Kompositionsschritte in der Entwicklung89 nicht zu einem anderen Verhalten eines Funktionsteils führen. In diesem Fall wäre das Modell der Zustände in Abbildung 3.6 ein MiL-SW-Element einer Funktion, das als White-Box zur Verfügung steht. Die testende Implementierung wäre ein SiL- oder HiL-SW-Element des Funktionsteils. Hierdurch wird geprüft, ob sich durch einen Sprung von z. B. einem MiL-SW-Element zu einem SiL-SW-Element Änderungen beim Test des Verhaltens der Software ergeben. Durch diese Werkzeugkette wird darüber hinaus sichergestellt, dass alle Zustände des Testmodells erreichbar sind und die Beschreibung der Anforderungen im Lastenheft eindeutig ist. Für neue Funktionen bietet es sich daher an, die Testmodelle für die Funktionsteile vor der Implementierung von Teilfunktionen zu erstellen.

(QWZXUIGHV;L/6:(OHPHQWV

;L/6:(OHPHQW =XWHVWHQGH ,PSOHPHQWLHUXQJ

9HUJOHLFK

7HVWIlOOH

7HVWPRGHOO 5HTXLUHPHQWV

(QWZXUIGHV7HVWPRGHOOV

0RGHOOGHU=XVWlQGH

Abbildung 3.6: Ablauf eines modellbasierten Tests für einen Funktionsteil eines Steuergeräts

Die Durchführung von automatisierten modellbasierten Tests gestaltet sich für zeitinvariante90 Funktionsteile einfacher. Bei zeitvarianten Systemen kann es aufwändig werden, wenn viele Vorbedingungen und Anfangsbedingungen erfüllt werden müssen. Abhilfe schaffen hier separat 89 90

Z. B. von SiL zu HiL. Eine zeitliche Verschiebung der Eingabe bewirkt lediglich eine entsprechende Verschiebung der Ausgabe.

50

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

testbare Funktionsteile oder Eingriffspunkte im Steuergerätecode, so dass Vorbedingungen entsprechend direkt gesetzt werden können91 . Darüber hinaus sollen funktionale Anforderungen in dieser Phase getestet werden. Es kann z. B. eine geschwindigkeitsabhängige Regelung getestet werden, indem eine Stellgröße bei verschiedenen Geschwindigkeiten verglichen wird. Diese Stellgrößen sind idealerweise im Systementwurf festgelegt und können bzgl. einer Implementierung überprüft werden. Auch diese Tests können automatisiert oder händisch durchgeführt werden. Für eine automatisierte Prüfung bieten sich formalisierte Anforderungen an [95]. Hier werden Anforderungen mathematisch beschrieben und können anschließend in allen Testfällen automatisiert überprüft werden. Zusammenfassend lässt sich festhalten, dass in dieser Testphase definierte funktionale Anforderungen und Zustandsbeschreibungen möglichst vollständig getestet werden sollten. Der Testfokus liegt nicht auf der korrekten Regelung, sondern auf der Prüfung von definierten Zuständen, Übergängen und funktionalen Anforderungen in beteiligten Teilfunktionen. Wichtig ist hierbei, dass die zu testenden Anforderungen aus der Systemanalyse für Tests geeignet sind. Die Eignung für Zustands- oder funktionale Tests kann im Vorhinein durch entsprechende Reviews verifiziert werden. Nachdem eine Verifikation der Software gegenüber festgelegten Anforderungen durchgeführt wurde, werden die verschiedenen Module für die folgenden Testphasen zusammengekoppelt. Hierdurch können das Verhalten und das Zusammenspiel der Funktion optimiert und getestet werden. 3.3.3 (Vor-)Applikation Bei der Applikation handelt es sich generell um Anpassungen von steuergeräteinternen Parametern. Oft wird eine Applikation erst im Fahrversuch durchgeführt, die bei der Entwicklung vernetzter Funktionen durch vorgelagerte Simulationen in dieser Phase unterstützt werden soll. Für eine Applikationen im Fahrversuch werden in der Regel bestimmte Fahrmanöver genutzt, die in einer Vorapplikation in der Simulation entsprechend übertragen werden können. Für diese Manöver soll eine Funktion in definierter Weise eingreifen. Bei der Applikation kann zwischen verschiedenen Arten von Parametern unterschieden werden. Einige Implementierungen von Funktionen regeln modellbasiert, d.h. es existieren im Steuergerätecode interne Streckenmodelle eines zu regelnden Systems, die für die Regelung miteinbezogen werden. Wenn sich das zu regelnde System ändert, etwa bei der Entwicklung eines neuen Fahrzeugs mit anderer Fahrzeughöhe oder anderem Radstand, müssen interne Parameter angepasst werden. Darüber hinaus existieren Regelungs- und Diagnoseparameter, die ggf. angepasst werden müssen. Die Anpassung kann teilweise analytisch erfolgen. Sie erfordert jedoch stets Expertenwissen bzgl. der Funktion und der verwendeten Regelungskonzepte. Diese werden hier nicht im Detail betrachtet, da sie funktionsspezifisch durchgeführt werden sollten und nicht allgemeingültig automatisiert werden können. Dies liegt primär daran, dass Regler Stabilitätsgrenzen besitzen und eine manöverspezifische Anpassung von Parametern Auswirkungen auf andere 91

Z. B. dass ein Bremssteuergerät bei einem DSR-Testfall eine μ-Split-Bremsung erkannt hat. Alternativ müssen Raddrehzahlen, Querbeschleunigung, Gierrate usw. entsprechend vorgegeben werden, damit vom XiL-SWElement eine μ-Split-Bremsung erkannt wird.

3.3 Testphasen von Funktionen

51

Betriebsbereiche oder sogar andere Funktionen haben kann. Eine automatisierte Optimierung für ein Manöver bzgl. bestimmter Resultate92 ist daher nur bedingt durchführbar. Das grundsätzliche Ziel dieser Testphase besteht darin, vor dem Fahrversuch geeignete Parametervarianten durch Simulationen zu ermitteln. Der Vorteil liegt darin, dass bei den ersten Fahrversuchen bereits geeignete Parametervarianten zur Verfügung stehen und damit weniger Parametervarianten im Fahrversuch untersucht werden müssen. 3.3.4 Variantentest In dieser Testphase wird getestet, ob eine Funktion unter allen kundenrelevanten Bedingungen korrekt funktioniert. Hier besteht in der Simulation der Vorteil, dass im Vergleich zum Fahrversuch eine deutlich größere Anzahl von Varianten getestet werden kann. Darunter fallen sowohl Szenarien- oder Manövervarianten als auch Fahrzeugausstattungsvarianten. In der vorherigen Phase, der Vorapplikation, wird eine Applikation für eine beschränkte Anzahl von Manövern durchgeführt. In dieser Phase soll darauf aufbauend sichergestellt werden, dass die Funktion auch für weitere Manöver und Betriebsbereiche die Anforderungen erfüllt. Hierfür bietet die Simulation einige Vorteile. Durch entsprechende Automatisierungen kann beispielsweise das Verhalten bei unterschiedlichen Geschwindigkeiten, verschiedenen Fahrern, unterschiedlichen Reifen, Fahrzeugmassen oder Untergründen reproduzierbar getestet werden. Im Versuch gestaltet sich die Änderung der Umgebungsbedingungen hingegen relativ aufwändig. So werden z. B. Gewichte ins Auto geladen, um das Fahrzeuggewicht zu erhöhen. Ferner werden verschiedene Geschwindigkeiten gefahren oder die Straße wird befeuchtet, um das Verhalten einer Funktion bei verschiedenen Umgebungsbedingungen zu testen. Zusätzlich bestehen für Fahrzeuge verschiedene Ausstattungsvarianten93 , die für eine schnelle Durchführung von Tests automatisiert und skalierbar auf PCs untersucht werden können [58]. In Kombination mit jeweils verschiedenen Manövern wird der Testraum auch für SiL-Simulationen sehr groß, weshalb solche Tests für eine schnellere Durchführung auch parallelisiert94 werden können. Das Ziel in dieser Testphase besteht darin, den Test von Funktionen durch Simulationen unter den verschiedenen relevanten Kundenbedingungen zu unterstützen. Im Unterschied zum Fahrversuch können in der Simulation deutlich schneller und günstiger verschiedene Varianten getestet werden. 3.3.5 Bauteilauslegung In dieser Phase findet eine feinere Applikation von steuergeräteinternen Parametern für bestimmte Manöver statt. Hierbei spielen detaillierte Eigenschaften von zu regelnden Komponenten eine wichtige Rolle. Im Rahmen der Entwicklung werden beispielsweise auftretende Kräfte, Schwingungen und ggf. Vibrationen von Bauteilen untersucht. Diese werden neben den physikalischen Eigenschaften des untersuchten Bauteils auch von der Regelung beeinflusst. Da hierfür sehr genaue Modelle benötigt werden, ist eine Simulation in Echtzeit nicht oder nur bedingt möglich. 92 93 94

Z.B. Bremsweg. Z. B. Fahrzeug mit oder ohne Parklenkassistent. Auslagerung von Testfällen auf mehrere Rechner oder Server.

52

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Ggf. können die Regelung und spezifische Eigenschaften von Bauteilen auch direkt aufeinander abgestimmt werden. Je nachdem welche Zustandsvariable untersucht werden soll, können unterschiedliche Streckenmodelle benötigt werden. Wenn z. B. eine Bremsung ohne Lenkeingriff untersucht wird, sind die Eigenschaften der Querdynamik des Fahrzeugs von geringer Bedeutung. Wenn allerdings ein Manöver mit starker Übersteuerung ohne Bremsen gefahren wird, dann werden hauptsächlich die Eigenschaften bzgl. der Querdynamik für das Manöver benötigt. Für eine genauere Applikation müssen diese Eigenschaften fahrzeugspezifisch sehr genau betrachtet werden. Grundsätzlich können in dieser Testphase sowohl in der Regelung als auch in der Parametrierung des Bauteils relevante Parameter angepasst und aufeinander abgestimmt werden. Dies kann einerseits für Komfortbewertungen wie z. B. auftretende Vibrationen geschehen. Andererseits können Tests im Grenzbereich durchgeführt werden wie beispielsweise auftretende Belastungen auf Bauteile bei starken Anregungen. Im Unterschied zu vorherigen Testphasen sind die Streckenmodelle jedoch bzgl. bestimmter Zustandsvariablen genauer. Aufgrund der benötigten Genauigkeit kann dies dazu führen, dass Streckenmodelle nicht mehr in Echtzeit simulierbar sind. Außerdem können Streckenmodelle kleinere Makroschrittweiten als bei HiL-Simulation benötigen. Auch mit sehr detaillierten Modellen können jedoch nicht immer alle Testanforderungen aus dem Fahrversuch vollumfänglich in der Simulation bewertet werden. Für subjektive und markenspezifische Funktionseigenschaften werden wohl immer Fahrversuche notwendig sein. Durch diese sehr genauen Modelle soll der Fahrversuch jedoch bestmöglich unterstützt werden. 3.3.6 Abnahmetest Schließlich folgt die letzte Testphase, der Abnahmetest in der Simulation. Hierfür sollen Versuche und Abnahmetestfälle, die sonst im Fahrversuch durchgeführt werden, in benötigter Genauigkeit simuliert werden können. Hierbei kann es sich um gesetzliche Vorgaben oder um herstellerspezifische Komfortbewertungen handeln. Dies sind z. B. Euro-NCAP-Tests95 und Funktionsprüfungen. Hier handelt es sich wiederum um zuvor bekannte Manöver. Die hier verwendeten Manöver können bereits für die Vorapplikation genutzt worden sein. 3.3.7 Gesamtdarstellung der Testphasen und Ableitung geeigneter Testmethoden Die Testphasen werden in Abbildung 3.7 noch einmal zusammenfassend dargestellt. Hierzu ist in der Abbildung für jede Testphase eine kurze Beschreibung vorhanden. In der Abbildung wird außerdem aufgeführt, mit welcher Testmethode sich welche Testphase empfiehlt. Für den Schnittstellentest kommen MiL, SiL, FiL und HiL infrage. Hier können funktionale Anforderungen und Zustände geprüft werden, die hauptsächlich die Applikationsschicht betreffen. Hier entsteht ein direkter Vorteil, wenn frühzeitig Fehler entdeckt werden. Formalisierte Anforderungen können ggf. in weiteren Testphasen wiederverwendet werden96 . 95 96

Z. B. dass beim Fußgängerschutz bei definierter Geschwindigkeit ein bestimmter Geschwindigkeitsabbau erreicht wird. Z. B. können im Variantentest die Anforderungen weiterhin geprüft werden, um zu untersuchen, ob Anforderungen auch für andere Stimuli erfüllt bleiben.

3.3 Testphasen von Funktionen

6FKQLWWVWHOOHQWHVW

53

6WLPXOXVWHVW JJIPRGHOOEDVLHUW  Æ 0L/6L/)L/+L/ Æ $XWRPDWLVLHUWHU7HVWDOOHU=XVWlQGHPLWhEHUJlQJHQ Æ )XQNWLRQDOHU7HVWYRQ$QIRUGHUXQJHQ

9RU $SSOLNDWLRQ

Æ 0L/6L/ 9RUDSSOLNDWLRQPLWEHVWLPPWHQ6WLPXOL Æ (UPLWWOXQJYRQ)XQNWLRQVSDUDPHWHUQLQ6LPXODWLRQ

9DULDQWHQWHVW

Æ 9LUWXHOOH$EVLFKHUXQJGXUFK7HVWYLHOIDOW 0DQ|YHU*HZLFKW8QWHUJUXQG$XVVWDWWXQJHWF

%DXWHLODXVOHJXQJ

Æ ,QWHUDNWLRQ]ZLVFKHQ5HJHOXQJXQG%DXWHLO Æ 0L/6L/ 3DUDPHWHUYDULDWLRQHQLQ%DXWHLOHQXQG6WHXHUJHUlWHQ

$EQDKPHWHVW

Æ %HZHUWXQJYRQJHVHW]OLFKHQ9RUJDEHQXQG.RPIRUW Æ +L/

Æ 6L/+L/

Abbildung 3.7: Zusammenfassung der Testphasen

Bei der Vorapplikation empfiehlt sich MiL, damit erste Tests durchgeführt werden, um zu untersuchen, ob sich die Funktion in Verbindung mit dem Fahrzeug wie erwartet verhält. Danach kann überprüft werden, welche Parameter das Funktionsverhalten wie beeinflussen. Darauf aufbauend kann die Vorapplikation schwerpunktmäßig mit SiL durchgeführt werden, da z. B. Teile der Basissoftware und Fehlerspeichereinträge von Relevanz sein können. Außerdem kann ein applizierter Funktionsteil mit anderen Funktionsteilen auf einem Steuergerät interagieren, sodass dies eine Vorapplikation beeinflussen kann. SiL bietet zudem den Vorteil, dass Applikationsdaten durch gleiche Protokolle und Toolketten sehr ähnlich zum Fahrversuch genutzt werden können. Für den Variantentest empfiehlt sich einerseits die Steuergeräteausprägung SiL, damit ein ähnliches Verhalten zum Steuergerät gewährleistet wird und trotzdem eine Skalierbarkeit der Simulation ermöglicht werden kann. Andererseits eignen sich HiL-Tests, da wie im Fahrzeug die reale Hardware von Bauteilen sowie das Steuergerät Verwendung finden kann. Tests, die auf die Software im Steuergerät abzielen, eignen eher für SiL-Tests97 . Es existieren jedoch auch Tests, bei denen der Fokus neben der Software auf Hardwarebauteilen liegt. Dies sind z. B. Spannungstests, Tests für Ventilansteuerungen oder Belastungstests, die mit SiL-Simulationen nicht sinnvoll abzubilden sind. Für die Bauteilauslegung können wiederum die Ausprägungen MiL und SiL verwendet werden. HiL kommt nicht infrage, da Echtzeitanforderungen in der Regel nicht eingehalten werden können. Hier kann im Gegensatz zur Vorapplikation je nach Anwendungsfall auch MiL genutzt werden, da die Basissoftware für das Zusammenspiel mit Bauteilen weniger relevant ist. Für einen Abnahmetest eignet schließlich ein Steuergerät in Hardware auf einem Prüfstand, da sichergestellt werden sollte, dass sich die Software auch auf der Hardware korrekt verhält. Im Allgemeinen ist diese Simulation von Abnahmetests auf Prüfständen bereits heute etabliert. Die 97

Z. B. Bremsungen mit verschiedenen Geschwindigkeiten und Reibwerten auf der Straße.

54

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Nutzung der Simulation für die Entwicklung von Funktionen98 im Sinne einer funktionsorientierten Entwicklung für mechatronische Systeme ist hingegen eine neue Herangehensweise. Die Testphasen müssen nicht zwingend für alle Funktionen durchlaufen werden. Des Weiteren müssen sie nicht genau in der dargestellten Reihenfolge abgearbeitet werden. Wenn die Hardwareentwicklung z. B. vor der Softwareentwicklung stattfindet, kann auch mit einer Vorgängerversion der Software eine Bauteilauslegung durchgeführt werden. Es werden stattdessen alle benötigten Simulationsaufbauten anhand von Testanforderungen unterschieden. Abbildung 3.8 verdeutlicht, wie sich die Phasen in das zuvor beschriebene V-Modell einordnen lassen, falls alle Phasen nacheinander ausgeführt werden.

6\VWHP

6WHXHUJHUlWH

Abbildung 3.8: Funktionsorientierte Entwicklung mit Testphasen ermöglicht schnellere Iterationsschleifen bei auftretenden Fehlern und Änderungen

Wichtig ist hierbei, dass auftretende Fehler früher und schneller gefunden werden. Dies wird mithilfe schnellerer Iterationsschleifen in der Entwicklung durch die Simulation ermöglicht. Hierdurch sollen verhindert werden, dass Fehler erst auf System-Integrationsebene gefunden werden. Die Voraussetzung dafür ist, dass stets benötigte Module für die Simulation zur Verfügung stehen. Der Schnittstellentest sollte zunächst auf SW-Modulebene stattfinden. Wenn ein Modul anschließend in bestehende Software integriert wird, bietet es sich an, den Schnittstellentest auf SiL und HiL-Ebene erneut durchzuführen. Falls ein FiL-Element verwendet wird, kann auch hier der 98

Testphasen 2 bis 4.

3.3 Testphasen von Funktionen

55

Schnittstellentest angewendet werden. Hierdurch kann nachvollzogen werden, ob sich durch Integrationsschritte99 Änderungen ergeben. Dieser Test wird unter anderem durch die Norm ISO26262 [19] gefordert. Das in Abbildung 3.9 dargestellte UML-Aktivitätsdiagramm veranschaulicht die sukzessive Anordnung aller Testphasen. Der Test einer Software startet mit dem Schnittstellentest. Falls hier Fehler gefunden werden, kann dies direkt an die Entwickler zurückgemeldet werden. Infolgedessen können die Entwickler die Fehler beheben und der Schnittstellentest wird erneut mit einem neuen Softwarestand durchgeführt. Wenn der Schnittstellentest bestanden wurde, kann mit der Vor-Applikation begonnen werden. Im Fall, dass eine Vorapplikation nicht möglich ist, kann ebenfalls von einem Fehler ausgegangen werden. Falls sich nach einer Fehlerbehebung nichts am Zustandsverhalten ändert, kann anschließend auch direkt wieder eine Vorapplikation durchgeführt werden. Auf eine erfolgreiche Vorapplikation folgt der Variantentest. Hierbei wird zunächst der Fall beleuchtet, dass ein Fehler bei der Vorapplikation aufgetreten ist. Hier muss eine Applikation ggf. erneut durchgeführt werden, wobei ein Manöver dieses Mal bei der Vorapplikation berücksichtigt wird. Die Parametrierung wird bei einer erneuten Vorapplikation somit zusätzlich auf ein Manöver ausgelegt, bei dem es zuvor zu einem Fehler kam. Wenn das Manöver bereits vorhanden ist, sollte eine Bauteilauslegung durchgeführt werden. Falls dies nicht möglich ist, kann es sich z. B. um einen Softwarefehler handeln oder aber es liegt eine zusätzliche Anforderung vor, die in der Software noch nicht berücksichtigt wurde. Ferner kann bereits eine Bauteilauslegung durchgeführt worden sein. Falls dies der Fall ist, werden Fehler oder Anforderungen entsprechend gemeldet und es entsteht ein neuer Softwarestand. Falls eine Bauteilauslegung durchführbar ist, wird mithilfe von Simulationen untersucht, inwiefern Bauteile und Regelung aufeinander abgestimmt werden können. Falls dies erfolgreich war, kann zurück zum Variantentest gesprungen werden. Ansonsten sind zusätzliche Änderungen erforderlich und die Software muss angepasst werden. Nach einem korrekt durchlaufenen Variantentest folgt der Abnahmetest. Falls dieser ebenfalls erfolgreich ist, wurden alle Testphasen durchlaufen. Wird in Testphase 5 hingegen ein Fehler gefunden, werden ggf. erneut die Testphasen 2, 3 und 4 durchlaufen. Die gezeigten Beispiele beziehen sich hauptsächlich auf den Bereich der Fahrdynamik und Streckenmodelle von Bauteilen im Fahrzeug. Dennoch gelten die Testphasen auch bei vielen mechatronischen Systemen in anderen Domänen. So können Vorapplikationen bei einer Klimatisierung eines Innenraums z. B. bestimmte Lastfälle für Innenraumkühlung oder -heizvorgänge auf bestimmte Temperaturen sein. Bei einer Regelung für Scheinwerfer können dies beispielsweise bestimmte Winkeländerungen bei Kurvenlicht oder Abblendvorgängen sein.Auch hier kann eine Funktion vorappliziert, im Variantentest variiert und im Bauteiltest mit detaillierter Darstellung beteiligter Komponenten entsprechend feinabgestimmt werden. Das nächste Unterkapitel befasst sich damit, wie die gezeigten Anforderungen mit Modellen abgedeckt werden können.

99

Z. B. MiL zu SiL bzw. einem Modell zum generierten C-Code.

56

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

act Testphasen

Start

Erneuter Zustandstest

1. Schnittstellentest

neue Lieferung Durchführung

Fehler melden

Fehler gefunden

Schnittstellentest bestanden

direkt zur Vorapplikation Steuergerätefehler

2. (Vor-) Applikation

Stimulus hinzufügen

Durchführung Applikation nicht möglich Stimulis bereits vorhanden

Alles i.O. Fehler gefunden

3. Variantentest

Steuergerätefehler Bauteilauslegung durchführbar

Applikation erfolgreich Durchführung

4. Bauteilauslegung

Durchführung

Fehler gefunden Alles i.O. Alles i.O. Fertig

Durchführung

5. Abahmetest

Abbildung 3.9: Workflow für den gesamten, durchgängigen, integrierten Testprozess

3.4 Anforderungen an Simulationsmodelle im Entwicklungsprozess

57

3.4 Anforderungen an Simulationsmodelle im Entwicklungsprozess Bei der Vernetzung von XiL-SW-Elementen existieren bereits standardisierte Schnittstellen und Busprotokolle, hier kann die Vernetzung und Simulation verschiedener Komponenten daher auch in der Simulation effizient umgesetzt werden. Herausforderungen beim Aufbau und bei der Durchführung vom Simulationen zeigen sich jedoch bei den Streckenmodellen, da hier spezifisches Wissen bzgl. Anforderungen an verwendete Modelle erforderlich ist. In diesem Unterkapitel wird eine Spezifizierung und Klassifizierung von Anforderungen an benötigte Streckenmodelle anhand der vorgestellten Testphasen durchgeführt. Zunächst folgen Erläuterungen bzgl. Schnittstellen von Streckenmodellen, die für eine Austauschbarkeit von Modulen festgelegt werden müssen. Anschließend werden Kriterien dargestellt, die zur Klassifizierung berücksichtigt werden müssen. Danach wird erläutert, wie die verschiedenen Testanforderungen in der Entwicklung mit einer möglichst geringen Anzahl von Streckenmodellen abgedeckt werden können. 3.4.1 Schnittstellen Neben der Steuergerätevernetzung auf Bussystemebene existieren im Fahrzeug physikalische Abhängigkeiten, die in der Simulation nachgebildet werden müssen, siehe 3.1.2. Die Basis für einen kontinuierlichen Simulationsaufbau bieten feste Schnittstellen zwischen Modulen. Diese ermöglichen es, dass Modelle mit unterschiedlicher Genauigkeit bzgl. bestimmter Zustandsvariablen und anderen Gültigkeitsbereichen miteinander ausgetauscht werden können. In größeren Unternehmen ist die Abstimmung und Einhaltung von festen Schnittstellen sehr aufwändig. Folgende Fragestellungen können die Wahl einer Schnittstelle erleichtern: • Wie sieht die Schnittstelle im Fahrzeug aus? • Wer verantwortet im Fahrzeugprojekt welche Komponenten? • Wie müssen die Schnittstellen definiert werden, damit numerische Probleme minimiert werden können? • Welche Schnittstelle wird für die detaillierteste Simulation benötigt? • Wie groß ist der Aufwand für die Validierung100 an einer Schnittstelle? • An welcher Schnittstelle sind Modelle beim Austausch voneinander unabhängig? Generell sollten sich Schnittstellen von Streckenmodellen an der Umsetzung im Fahrzeug orientieren. Somit sollten z. B. Eingangssignale für Steuergeräte in der Simulation an der Stelle entnommen werden, wo auch die Sensoren im Fahrzeug verortet sind. Beispielsweise liegen Lagesensoren eines Bremsensteuergeräts in der Regel im Motorraum und nicht in der Fahrzeugmitte. Ein anderes Beispiel ist ein Lenkwinkelsensor, der sich oft nicht am Lenkrad des Fahrers, sondern näher an der Zahnstange befindet.

100

Vergleich von Simulationsdaten mit Messdaten, siehe 3.4.4.

58

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Darüber hinaus sollten Modellschnittstellen so definiert werden, dass sie die Verantwortlichkeit im Fahrzeugprojekt spiegeln. Wenn ein Zulieferer für bestimmte Komponenten eines Systems zuständig ist, dann sollte dieser auch die dazugehörigen Modelle bereitstellen. Der Grund dafür liegt darin, dass Verantwortliche in der Regel das Fachwissen besitzen, eine benötigte Modellgenauigkeit mit möglichst geringem Aufwand zu erreichen. Ein weiterer Aspekt besteht darin, dass möglichst niederfrequente Schnittstellen gewählt werden sollten. Es zeigen sich bei den beschriebenen Simulationsaufbauten101 bestimmte Anforderungen an die Konfiguration der Kopplung. Durch die unterschiedliche Dynamik der Teilsysteme entstehen entsprechende Signale, die fehlerfrei übertragen werden müssen. In Abschnitt 3.4.2 wird dargestellt, welche Voraussetzungen auszutauschende Signale erfüllen müssen, um dies realisieren zu können. Es sollte somit berücksichtigt werden, dass niederfrequente Schnittstellen numerische Instabilitäten bereits eindämmen können. Überdies sollte beachtet werden, dass verschiedene Komponenten für detaillierte Fragestellungen ggf. direkt in einem Simulationsprogramm modelliert werden sollten. Es können sich z. B. Vibrationen oder Schwingungen direkt über aneinander gekoppelte Bauteile übertragen. Bei Mehrkörpersimulationen kann es daher sinnvoll sein, ein Lenksystem vom Lenkrad bis zu den Rädern komplett in einem Werkzeug zu modellieren, denn über eine rein signalbasierte Kopplung können ggf. Informationen wie partielle Ableitungen verloren gehen102 . Für eine effiziente Fehlerfindung und Validierung vernetzter Modelle sollten Schnittstellen so gewählt werden, dass Ein- und Ausgangsgrößen von Modellen im Fahrversuch oder auf Prüfständen ohne größeren Aufwand mit einer geeigneten Software mitgemessen werden können. Dies ermöglicht, dass Validierungen vernetzter Modelle mithilfe von Messdaten des entsprechenden Fahrzeugs an den jeweiligen Schnittstellen einfacher durchgeführt werden können. Auf diese Weise lässt sich ein Gesamtmodell stückweise aufteilen und wieder zusammensetzen, wobei für jede Schnittstelle dazugehörige Messdaten für die Validierung zur Verfügung stehen können. Ein geeignetes Validierungskonzept wird in Abschnitt 3.4.4 detaillierter beschrieben. Schließlich sollten Schnittstellen in diesem Kontext derart gewählt sein, dass ein Austausch eines Modells keine Änderungen bei anderen Modellen zur Folge hat. Wenn eine wirkende Trägheit z. B. abhängig vom verwendeten Elektromotor ist, kann die Schnittstelle grundsätzlich dazwischen liegen. In diesem Fall sollte jedoch ein Signal vorliegen, das bestimmt, wie groß die wirksame Trägheit für einen jeweiligen Motor auf ein entsprechendes Bauteil ist. Somit wird ermöglicht, dass gekoppelte Modelle nicht variantenspezifisch angepasst werden müssen. Der Wert kann z. B. während der Initialisierung eingelesen und entsprechend berücksichtigt werden, ohne dass sich Nutzer von Modellen darum kümmern müssen. Die Abstimmung der Schnittstellen ist ein wichtiger und essentieller Punkt, damit ein effizienter Modellaufbau verwirklicht werden kann. Der initiale Aufwand zahlt sich jedoch aus, damit aufwändige Modellanpassungen im Nachhinein vermieden werden können. Letztendlich müssen bei der Auswahl einer Schnittstelle die dargestellten Fragestellungen gegeneinander abgewo101 102

Vgl. 3.1.2. In einer signalbasierten Kopplung werden oft lediglich die Signalwerte im Zeitbereich übertragen. Partielle Ableitungen entfallen hier, obwohl sie Einfluss auf die Simulation haben können. Sie können z. B. mithilfe des FMI-Standards ausgetauscht werden, jedoch unterstützen dies nicht alle Simulationsprogramme. Wenn die Schnittstelle an einer Stelle liegt, wo die Ableitungen eine untergeordnete Rolle spielen, bleiben die partielle Ableitungen erhalten, da keine Kopplung zwischen Simulationsprogrammen stattfindet.

3.4 Anforderungen an Simulationsmodelle im Entwicklungsprozess

59

gen werden, wobei sich Schnittstellen bei größeren Hardwareänderungen auch ändern können. Wichtig ist, dass Schnittstellen nicht nur syntaktisch103 , sondern auch semantisch104 beschrieben werden. Wenn z. B. eine Kraft auf ein Bauteil wirkt, wird einerseits die Syntax wie z. B. der Wertebereich einer Schnittstelle festgelegt. Wichtig ist jedoch andererseits, in welche Richtung eine Kraft wirkt. Die Semantik bestimmt in diesem Fall das Koordinatensystem bzw. Richtungen, wohin sich ein Bauteil bei negativer bzw. positiver Kraft bewegt. Ähnlich verhält es sich auch bei Stromrichtungen oder Beschleunigungen. Nach der Abstimmung von Schnittstellen können Gültigkeitsbereiche und Modellumfänge testspezifisch auf Basis von Manövern festgelegt werden. Nur auf diese Weise kann sichergestellt werden, dass Modelle sowohl für die verschiedenen Einsatzgebiete geeignet sind, als auch im Sinne der Wirtschaftlichkeit nur die benötigten Zustandsvariablen abdecken, siehe Abschnitt 3.4.2. Modelle, die sich für alle Anwendungsfälle eignen und alle Zustandsvariablen genau abbilden, können in der Praxis nicht verwendet werden, da sich die Modellerstellung in der Regel zu aufwändig gestaltet. Im folgenden Abschnitt werden entwickelte Kriterien für die Klassifizierung von Modellen vorgestellt. 3.4.2 Kriterien zur Klassifizierung von Modellen Neben der Definition und Einhaltung von Schnittstellen sollten weitere Aspekt für die Erstellung und Integration von Streckenmodellen beachtet werden. Für eine durchgängige Integration von Streckenmodellen wird ein algorithmischer entwickelter Beitrag vorgestellt, der in Form von zu berücksichtigenden identifizierten Kriterien vorgestellt wird. Auf Basis dieser Kriterien erfolgt in Abschnitt 3.4.3 die im Rahmen der Arbeiten entwickelten Klassifizierung benötigter Modelle für die vorgestellten Testphasen. Im Folgenden werden die identifizierten Kriterien Echtzeitzeitfähigkeit, Integrationsfähigkeit bzgl. der Stabilität der Kopplung, Zeitpunkt der Verfügbarkeit und Aufwand für die Bedatung dargestellt, da sie für einen durchgängigen Integrationsprozess berücksichtigt werden müssen. Echtzeitfähigkeit Ein wichtiges Kriterium zur Klassifizierung von Streckenmodellen ist die Echtzeitfähigkeit, da nur diese Modelle für die Verwendung auf Prüfständen geeignet sind. Für den Betrieb von Modellen für Simulationen in Echtzeit müssen, wie bereits dargestellt, bestimmte Anforderungen erfüllt werden, vgl. Unterkapitel 2.4. Wenn Modelle den beschriebenen Echtzeitanforderungen nicht entsprechen, können sie nicht auf Prüfständen verwendet werden. Für eine durchgängige Integration von Modellen sollten viele Modelle auf Prüfständen verwendbar sein. Die Simulationsschrittweite auf Prüfständen im Bereich der Fahrdynamik beträgt gewöhnlich eine Millisekunde, wobei die reine Berechnungszeit eines Modells für einen Simulationsschritt in der Regel unter einer halben Millisekunde liegen sollte. Die weitere halbe 103 104

Merkmale, die Eigenschaften eines Eingangs eindeutig beschreiben. Wie ist die Schnittstelle zu interpretieren?

60

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Millisekunde sollte für den Datenaustausch und die Signalkonditionierung vorgehalten werden. Bei größerer Makroschrittweite kann die Berechnungszeit entsprechend höher ausfallen105 . Zusammenfassend muss für Echtzeitsimulationen sichergestellt werden, dass alle benötigten Daten bis zu einem jeweiligen Makroschritt rechtzeitig zur Verfügung stehen. Integrationsfähigkeit bezüglich der Stabilität der Kopplung Für eine durchgängige und skalierbare Simulation ergibt sich bzgl. der Integration von Modulen die Herausforderung, dass nicht alle Modelle in einem Simulationsprogramm oder auf einer Zielplattform simuliert werden können. Für eine durchgängige Integration von Modulen ergibt sich die Anforderung, dass Modelle von Prüfständen auf andere Hardware wie z. B. weitere Rechenkerne oder PCs ausgelagert werden können. Einerseits ergibt sich der Vorteil, dass auf PCs Modelle verwendet werden können, die nicht exportiert106 werden können. Anderseits besteht die Möglichkeit, Modelle mit variablen Mikroschrittweiten zu betreiben. Ein weiterer Vorteil liegt in der Skalierbarkeit der Simulation107 . Es ergibt sich somit die Anforderung, einzelne Modelle modular zu verteilen, um sie nach Bedarf zu einem Gesamtsystem zu integrieren. Da hierfür das Gesamtsystem verändert wird, können sich Instabilitäten durch die eingebrachte Totzeit in der Kommunikation ergeben. Ein weiteres Kriterium für die Klassifizierung von Modellen ist daher die Integrationsfähigkeit bzgl. der Stabilität der Kopplung. Hierfür müssen zunächst verschiedene Arten von Signalen unterschieden werden. Es existieren wertdiskrete108 , wertkontinuierliche 109 und teilweise wertkontinuierliche Signale110 . Für die Gewährleistung einer stabilen Kopplung können grundsätzlich zwei Möglichkeiten genutzt werden. Auf der einen Seite kann die Makroschrittweite verkleinert werden. Dies ist nur bis zu einem bestimmten Grad möglich, da dies keine Auswirkung mehr hat, wenn die Makroschrittweite kleiner wird als die kleinste Simulationsschrittweite der Teilmodelle. Außerdem kann der zusätzliche Datenaustausch bei kleiner Makroschrittweite dazu führen, dass die Gesamtsimulation nicht mehr echtzeitfähig ist. Der Grund liegt darin, dass sich die benötigte Berechnungszeit für den Datenaustausch und die Synchronisation111 signifikant erhöhen kann. 105 106

107 108 109

110 111

Bei einer Makroschrittweite von z. B. 5.0 Millisekunden könnte eine Berechnungsdauer somit bis zu 4,5 Millisekunden betragen. Exportieren bedeutet in diesem Fall, dass Modelle z. B. mithilfe des FMI Standards in anderen Simulationsprogrammen oder auf Zielplattformen betrieben werden können, ohne dass das ursprüngliche Simulationsgramm dafür benötigt wird. Modelle können z. B. nicht exportierbar sein, wenn die exportieren Gleichungen nicht für ein Betriebssystem eines Prüfstands kompilierbar sind oder ein Simulationswerkzeug keinen Export eines Modells zulässt. Auf einem Prozessor können nicht beliebig viele Modelle in Echtzeit gerechnet werden. Signal nimmt nur bestimmte diskrete Werte an. Wenn ein System z. B. die Zustände null oder eins, dann ist das entsprechende Ausgangssignal immer null oder eins und z. B. nicht 0,53 oder zwei. Signal kann in einem definierten Wertebereich beliebige Werte annehmen. Der Wertebereich und die Genauigkeit sind abhängig von der Zahlendarstellung und der verwendeten Anzahl von Bits. Die meisten physikalischen Signale wie z. B. Lenkwinkel sind kontinuierlich. Ein Signal ist teilweise kontinuierlich und teilweise diskret. Dies kann zum Beispiel bei einem Gangwechsel im Getriebe auftreten. Modelle müssen ggf. auf Ergebnisse anderer Modelle warten, bis ein nächster Simulationsschritt berechnet werden kann.

3.4 Anforderungen an Simulationsmodelle im Entwicklungsprozess

61

Auf der anderen Seite besteht die Option, höherwertige Kopplungsverfahren zu verwenden. Für wertdiskrete und teilweise kontinuierliche Signale sollte ausschließlich eine Extrapolation nullter Ordnung verwendet werden, da es bei diskreten Signalen oder Signalabschnitten durch Extrapolationen höherer Ordnung zu größeren Fehlern kommen kann. Bei einer Extrapolation nullter Ordnung wird jeweilig der Wert vom letzten Makroschritt gehalten, vgl. Abbildung 3.10. Unbekannte Inputs werden bei Zero-Order-Hold(ZOH) im zu extrapolierenden Intervall somit als konstant angenommen. Das bedeutet die extrapolierte Größe für einen Makroschritt ΔT (t + 1) ist identisch zum letzten bekannten Wert beim Zeitschritt ΔT (t). Wenn ein diskretes Signal z. B. von null auf eins springt, kann der extrapolierte Schritt bei einer Extrapolation erster Ordnung (FOH) für den nächsten Simulationsschritt hingegen zwei sein. Hier wird aus mindestens zwei Werten ein Polynom erster Ordnung berechnet. Bei einer Second-Order-Hold-Extrapolation (SOH) wird entsprechend ein Polynom zweiter Ordnung gebildet. Eine detailliertere mathematische Gegenüberstellung der Kopplungsverfahren ZOH, FOH und SOH befindet sich unter [32].

\W



62+

              

)2+

([WUDSRODWLRQ

¨7W

=2+

6LPXODWLRQV]HLW

0DNURVFKULWWH Abbildung 3.10: Gegenüberstellung von Kopplungsverfahren nach [44, S. 29]

Für wertdiskrete Signale sollte lediglich ZOH verwendet werden, da dies der Charakteristik von diskreten Signalen entspricht. Generell gilt für alle Kopplungsverfahren, dass ein Signal fein genug abgetastet werden muss, damit es mithilfe der Kopplung korrekt zu anderen Teilmodellen übertragen werden kann. Je nach Anregung ergibt sich zusammen mit der Dynamik von Teilmodellen eine unterschiedliche Dynamik in auszutauschenden Signalen zwischen Streckenmodellen. Die Dynamik eines Kopplungssignals kann mithilfe der enthaltenen Frequenzen mathematisch untersucht werden. Das Übertragungsverhalten eines Kopplungsverfahrens bestimmt wiederum, ob eine bestimmte Signalfrequenz bei gegebener Makroschrittweite korrekt112 übertragen werden kann. Es folgt daher eine Beschreibung des Übertragungsverhaltens von Kopplungsverfahren. Ohne umliegende Module oder Streckenmodelle, d. h. für sich betrachtet, lässt sich ein Kopplungsverfahren als ein lineares, zeitinvariantes System darstellen, daher kann das Verhalten mithilfe von Transferfunktionen beschrieben werden[31]. Transferfunktionen charakterisieren das Übertragungsverhalten zwischen Ein- und Ausgängen eines Systems im Frequenzbereich. Das Ziel bei der Co-Simulation ist, dass Signale sich durch die Übertragung von einem zum 112

D. h. ohne Phasenverzug oder Amplitudenverstärkung.

62

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

anderen Teilmodell nicht oder nur marginal verändern, d. h. es ergibt sich durch die Übertragung kein Phasenverzug und keine Amplitudenveränderung. Für kontinuierliche Signale besteht ein direkter Zusammenhang zwischen den auszutauschenden Signalfrequenzen, der verwendeten Kopplungsmethode113 und der Makroschrittweite. Hierdurch kann eine stabile Kopplung gewährleistet werden, siehe Formel 3.4: ω(t)
2*fmax .

80

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Tabelle 3.2: Merkmale für die Signalgenerierung

Merkmal Startwert Zielwert Zielzeit Zurückgehzeit Rückkehrzeit Pause Phase Sinusförmig

Auswirkung auf Signal Verschiebung des Startwerts auf der Y-Achse Maximal zu erreichender Wert auf Y-Achse Zeitpunkt auf der X-Achse, auf dem Zielwert angenommen wird Zeitpunkt, an dem Zielwert verlassen wird Zeitpunkt, an dem wieder der Startwert erreicht wird Ruhezeit zwischen hintereinander folgenden Stimuli auf Startwert Phasenverzug auf X-Achse vor erstem Stimulus Manöver verläuft abwechselnd auf negativer und positiver Y-Achse

Im TSK wurde zum anderen eine Möglichkeit umgesetzt, Manöver mit wenigen Nutzereingaben direkt im TSK vorzugeben. Durch entsprechende Werteeingaben an Eingängen kann der Anwender Sprünge oder auch sinusförmige Verläufe mit wenigen Eingaben direkt beschreiben. Benötigte Nutzereingaben werden hierfür eingangsspezifisch unterschieden, denn einzelne Signale haben bestimmte Signaleigenschaften. Beispielsweise steigt ein Bremsdruck bei einer Bremsung auf einen bestimmten Druck an und fällt wieder ab, wenn keine Verzögerung des Fahrzeugs mehr notwendig ist oder der Fahrer vom Bremspedal geht. Ein Lenkwinkel kann wiederum negative und positive Werte annehmen. Um den Nutzer hierbei zu entlasten, wurde im Rahmen dieser Arbeit identifiziert, dass lediglich Merkmale abgefragt werden müssen, die für den jeweiligen Eingang relevant sind. Ein Signal wird daher nur durch eine Auswahl der in Tabelle 3.2 dargestellten Merkmale beschrieben. Aus vorgegebenen Werten für die verschiedenen Merkmale kann anschließend ein Manöververlauf berechnet werden. Hierfür werden konstante, sinus- und cosinusförmige Signalabschnitte erstellt, skaliert und stückweise zusammengesetzt. Im TSK werden hierbei mehrere Manöver hintereinander erstellt, damit es nicht zum bereits beschriebenen Leakage-Effekt kommt. Aus der Sicht des Modellverwalters wird für jeden Input beschrieben, welche Merkmale vom Nutzer abgefragt werden, siehe Abbildung 3.16. Der Anwender bekommt nach Auswahl eines Inputs anschließend eine entsprechende Liste angezeigt. Beim Klick auf Plot erstellen wird ein Plot des jeweiligen Signals erzeugt. Beispielhaft wird in Abbildung 3.20 der Verlauf des Bremsdrucks gezeigt. Wie in Abbildung 3.16 dargestellt werden dafür lediglich die Werte Zielwert, Zielzeit, Zurückgehzeit, Rückkehrzeit und Pause benötigt. Ein weiteres Beispiel für ein Manöver Übersteuern befindet sich Abbildung 3.21. Es zeigt noch einmal die Funktionsweise für die verbleibenden Merkmale. Hier wurde ein 30-GradSinuslenken mit einer Phasenverschiebung von einer Sekunde am Anfang des Signals umgesetzt. Nach Erreichen des Zielwerts wird direkt wieder zum Startwert zurückgekehrt. Mithilfe des Buttons Eingabe prüfen kann der Anwendet überprüfen, ob eine Manövervorgabe für die Testphasen 2, 3 und 5 den Anforderungen entspricht. Hierfür wird die maximale Frequenz des erzeugten Signals ermittelt und darauffolgend mit der maximal übertragbaren Hertzzahl bei einer Makroschrittweite von einer Millisekunde verglichen134 . 134

Es wird ab einer Frequenz von 8 Hertz eine Fehlermeldung ausgegeben.

3.5 Unterstützende Werkzeuge

81

Abbildung 3.20: Beispielhaft dargestellter Bremsdruckverlauf im TSK

Für eine bereits bestehende Vernetzung kann im Nachhinein, also wenn Modelle z. B. bereits beauftragt sind, die Gültigkeit eines Manövers geprüft werden, siehe Abbildung 3.19. Hierfür erscheint eine Maske zur Eingabe von Merkmalen. Für Variantenmodelle wird geprüft, ob die Werte-und Frequenzbereiche jeweils im Wertebereich der erstellten Streckenmodelle für die Vernetzung liegen. Für Auslegungs- und Vorapplikationsmodelle werden jeweils die Signalmerkmale auf Ähnlichkeit geprüft. Bei einer geringen Abweichung der verschiedenen Merkmale135 werden Manöver in diesem Zusammenhang als identisch angesehen. Der Nutzer bekommt nach der Eingabe seiner Daten eine Rückmeldung, ob die Modellvernetzung für das eingegebene Manöver geeignet ist. Zustandsvariablen und Export von Modelleigenschaften Eine weitere Funktionalität des TSKs ist die Pflege von Zustandsvariablen. Die letzte Spalte in Abbildung 3.16 ermöglicht es dem Modellverwalter, die verfügbaren Zustandsvariablen von Modulen zu pflegen. Dies sind in seinem Fall alle verfügbaren Zustandsvariablen jedes Moduls. In der Spalte der Streckenmodelle kann der Anwender im nächsten Schritt aus der Liste aller Zustandsvariablen auswählen, welche Zustandsvariablen für sein spezifisches Manöver benötigt werden. Nachdem alle Daten eingepflegt wurden, können die Modelleigenschaften exportiert werden. Hierfür existiert der Reiter „Modellliste“, der die Eigenschaften aller Streckenmodelle in eine Textdatei exportiert. Für Variantenmodelle werden hierfür die ermittelten Werte- und Frequenzbereiche aller Ein- und Ausgänge von allen Manövern berechnet. Für Auslegungs- und Vorapplikationsmodelle werden die Merkmale der Manöverbeschreibung exportiert. Zusätzlich werden jeweils die Zustandsvariablen angegeben. Für Auslegungs- und Vorapplikationsmodelle werden darüber hinaus Modelle miteinander verglichen, um zu signalisieren, welche Modelle sich ähneln. 135

Bis 2 Prozent.

82

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Abbildung 3.21: Beispielhaft dargestellter Lenkwinkelverlauf im TSK

Die Ähnlichkeit wird dabei bzgl. der Übereinstimmung von Zustandsvariablen geprüft und es werden die Merkmale von Eingängen aller Streckenmodelle von jeweiligen Modul vergleichen. Ein Auszug eines Beispiels der exportierten Streckenmodelleigenschaften befindet sich im Anhang, siehe Seite 129. Darüber hinaus wird ein Klassendiagramm des TSKs im Anhang vorgestellt, vgl. Seite 131. Hier befinden sich darüber hinaus konkretere Details zur Implementierung des TSKs. Zukünftig wäre es auch denkbar, direkt aus dem TSK werkzeugspezifische Tests für Module oder Streckenmodelle zu exportieren. Nachdem die Eigenschaften an Streckenmodelle strukturiert aufgestellt worden sind, gilt es nun, gelieferte Modelle hinsichtlich dieser Eigenschaften zu prüfen.

3.5 Unterstützende Werkzeuge

83

3.5.2 Modellanalysewerkzeug (MAW) Das MAW ist ein entwickeltes Werkzeug, mit dem die zuvor definierten Modelleigenschaften für die Testphasen überprüft werden können. Infolge der systematischen Festlegung der Modelleigenschaften in Form von Werte- und Frequenzbereichen an Ein- und Ausgängen jedes Modells wird mithilfe des MAWs die Untersuchung des Streckenmodellverhaltens bzgl. der Integrationsfähigkeit und der Echtzeitfähigkeit behandelt. Relevante Betriebsbereiche eines Modells werden analysiert, indem ein Modell im benötigten Wertebereich angeregt wird. Dabei werden resultierende Signalverläufe an den Ausgängen bewertet. Die vollautomatisierte Umsetzung der Analyse erfolgte im Rahmen einer Masterarbeit, die im Rahmen der vorliegenden Arbeit betreut wurde [97]. Das Vorgehen wurde bereits veröffentlicht, vgl. [52, S. 9]. Das Grundkonzept bilden die Simulation der Modelle mit verschiedenen Eingangssignalen und eine anschließende Analyse der resultierenden Ausgangssignale. Für jeden Modellausgang wird der Signaltyp identifiziert und für kontinuierliche Signale zusätzlich das Frequenzband ermittelt. Auf Basis dieser Informationen kann eine Vorhersage der Kopplungsfehler getroffen werden und somit die Integrationsfähigkeit der Modelle bewertet werden. Im ersten Schritt gilt es dazu, Stichprobenwerte für eine effiziente Anregung der Modelleingänge zu erzeugen, d. h. der Betriebsbereich wird mit möglichst wenigen Simulationsdurchläufen abgedeckt. Hierfür eignen sich Sampling-Strategien aus dem Bereich der globalen Sensitivitätsanalyse [93], die eine Variation der Werte- und Frequenzbereiche von Eingangssignalen über Simulationsdurchläufe ermöglichen. Darauf aufbauend können diskrete und kontinuierliche Eingangssignale generiert werden. Neben Sinussignalen mit fester und variabler Frequenz werden in diesem Kontext Signaltypen verwendet, die mehrere Frequenzen zeitgleich anregen. Hierfür werden geeignete Ansätze für die Signalgenerierung aus der Systemidentifikation [64] verwendet. Mit den unterschiedlichen Eingangssignalen aus der Signalgenerierung erfolgt die Durchführung der Simulation. Dabei werden in jedem Simulationsschritt die Ausgangssignale aufgezeichnet und die benötigte Simulationszeit gemessen. Dieses Vorgehen erlaubt anschließend eine Analyse der resultierenden Ausgangssignale und eine Bewertung der rechnerspezifischen Echtzeitfähigkeit eines Modells. Im Rahmen der Signalanalyse wird jedes Ausgangssignal in Teilsegmente eingeteilt, um anschließend jedes einzelne Segment im Zeit- und Frequenzbereich zu analysieren. Die Kombination dieser beiden Ansätze ermöglicht die eindeutige Identifizierung der maximalen Frequenzanteile sowie eine eindeutige Ermittlung des Signaltyps. Nach der Analyse aller Simulationsdurchläufe stehen alle benötigten Informationen für eine abschließende Bewertung des Modells zur Verfügung. Durch den Vergleich dieser Ergebnisse mit dem Übertragungsverhalten der unterschiedlichen Kopplungsalgorithmen kann ermittelt werden, ob und mit welchen Algorithmen eine stabile Kopplung möglich ist. Zusätzlich werden die Laufzeitmessungen aller Durchläufe analysiert, um die Echtzeitfähigkeit zu bewerten. Nachdem die Funktionsweise der Überprüfung detailliert vorgestellt wurde, folgt nun eine Erläuterung, wie das Vorgehen auf andere Modellformate angewendet werden kann.

84

3 Durchgängiger Aufbau von Simulationsumgebungen für vernetzte Funktionen

Modellintegrationswerkzeug

FMU

Echtzeitrechner Echtzeitrechner/PC PC/PC Vorgaben zur Konfiguration der Kopplung

Vorgaben zur Anregung (Werte- und Frequenzbereich)

Sampling

Signalgenerierung

Simulation

Analyse

Bewertung

Generierung von Stichprobenwerten für eine effiziente Anregung

Generierung kontinuierlicher und diskreter Eingangssignale für einen Simulationsdurchlauf

Generierung der Ausgangssignale inkl. Laufzeitmessungen

Ermittlung von Signaltypen und maximalen Frequenzanteilen der Signale

Bewertung der Echtzeitfähigkeit und Vorgaben für eine Kopplungsempfehlung für Modellausgänge

1…N

Abbildung 3.22: Ablauf der Automatisierten Prüfung

Falls Modelle als FMU für Co-Simulation vorliegen, kann die Prüfung mithilfe des MAW vollautomatisiert durchgeführt werden. Für Modelle, die in einem proprietären Format wie z. B. einer S-Function vorliegen, können die Modelle händisch im jeweiligen Tool untersucht werden. Hierfür wurden die vorgestellten Ansätze der Signalgenerierung in Matlab umgesetzt und als FMUs exportiert, so dass Modelle weitgehend toolunabhängig untersucht werden können. Hier entfällt jedoch die automatisierte Untersuchung der rechnerspezifischen Echtzeitfähigkeit und die Analyse geschieht nicht vollautomatisiert. Ferner findet die automatische Ermittlung der Signaltypen nicht statt, da diese lediglich im MAW umgesetzt wurde. Diese Signaltypen können hier ggf. händisch direkt im jeweiligen Tool analysiert werden. Nachdem der methodische Teil der Arbeit vollständig beschrieben wurde, folgt im folgenden Kapitel die Anwendung der Forschungsergebnisse.

4 Anwendungsbeispiel In diesem Kapitel wird ein Anwendungsbeispiel für die hergeleitete durchgängige Integration von Hardware und Softwaremodellen in Simulationsumgebungen vorgestellt. Die Methode wurde anhand eines Praxisbeispiels einer vernetzten Funktion umgesetzt, wobei alle Testphasen einmal durchlaufen wurden. Für die Umsetzung dient die vernetzte Funktion DSR, die bereits in aktuellen Fahrzeugprojekten Verwendung findet.

4.1 Die vernetzte Funktion Driver Steering Recommendation (DSR) Im Folgenden wird die Funktion DSR genauer beschrieben, um die später vorgestellten Ergebnisse besser beurteilen und interpretieren zu können. Die Funktion DSR gibt dem Fahrer Lenkempfehlungen zur Stabilisierung des Fahrzeugs. Hierbei existieren drei Situationen, in denen die Funktion bei definierten Eingriffbedingungen das Lenken unterstützt. Es handelt sich um μ-Split-Bremsungen, Übersteuern des Fahrzeugs und die Anhängerstabilisierung. In einigen Fällen wird die Funktion auch als Gegenlenkunterstützung bezeichnet. In diesem Anwendungsbeispiel wird schwerpunktmäßig auf μ-Split-Bremsungen eingegangen. Dies sind Bremsmanöver, bei denen an Reifen rechts und links vom Fahrzeug unterschiedliche Reibwerte vorliegen. Dies kann im Extremfall z. B. eine Eisfläche an den rechten Reifen gegenüber angerautem Asphalt an den linken Reifen sein. Die Funktion greift jedoch auch bei geringeren Reibwertunterschieden ein, wenn z. B. eine Hälfte der Straße nass und die andere Hälfte der Straße trocken ist. Ziele der Eingriffe sind, dass das Fahrzeug stabil und kontrollierbar bleibt. Außerdem muss der Fahrer durch die Lenkunterstützung weniger Lenkmoment aufbringen und der Bremsweg verringert sich. Für die Umsetzung der Lenkempfehlung sind im spezifischen Fahrzeugprojekt zwei Steuergeräte maßgeblich beteiligt: ein Lenkungs- und ein Bremssteuergerät bzw. die Module EPS und ESC. Das Bremssteuergerät erkennt auf Basis verschiedener Größen eine der beschriebenen Situationen. Anschließend übermittelt das Bremssteuergerät eine Lenkmomentanforderung über den Fahrzeug-Bus an die Lenkung. Nach einer erfolgreichen Plausibilisierung setzt die Lenkung das angeforderte Moment um. Die Errechnung einer Lenkmomentanforderung ist komplex, da sie sich je nach Situation unterscheidet. Während einer Bremsung erkennt das Bremssteuergerät auf Basis verschiedener Größen, dass eine μ-Split-Bremsung vorliegt. Für die Erkennung werden unter anderem Raddrehzahl-, Gierraten- und Querbeschleunigungssensoren sowie das aktuelle Lenkmoment interpretiert. Letzteres stammt per Bus-Kommunikation vom Lenkungssteuergerät. Wenn bei einer Bremsung Eingriffbedingungen für eine μ-Split-Bremsung erfüllt werden, berechnet das Bremssteuergerät eine geschwindigkeitsabhängige Lenkmomentanforderung. Diese

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9_4

86

4 Anwendungsbeispiel

soll darauffolgend vom Lenkungssteuergerät umgesetzt werden. Das angeforderte Moment wird zyklisch erneut berechnet und ggf. angepasst. Dieses Vorgehen ermöglicht, dass sich die Regelung dynamisch an die Gegebenheiten der Straße und dem Verhalten des Fahrzeugs anpasst. Zusätzlich zu gültigen Eingriffen existieren verschiedene Abbruchkriterien und Fehlerzustände, die von Statusinformationen anderer Steuergeräte und internen Bedingungen abhängen. Im Folgenden werden Manöver beschrieben, die für die Validierung der DSR-Simulationen verwendet werden.

4.2 Manöverbeschreibung der DSR-Funktion Für die DSR-Funktion existiert ein Katalog von Testfällen. Bei diesen Testfällen werden unter anderem Geschwindigkeiten oder auch Lenkwinkel variiert. Darüber hinaus existieren sogenannte Hands-Off -Manöver. Bei diesen Manövern werden die Hände vom Lenkrad genommen. Das Fahrzeug stabilisiert sich hier ohne Einflüsse vom Fahrer, d. h. ein Gegenlenken wird lediglich durch die physikalischen Eigenschaften des Fahrzeugs und die Eingriffe der Steuergeräte verwirklicht. Für die Validierung mit dem Fahrversuch sind in diesem Fall eher Hands-Off -Manöver geeignet, da sich das Verhalten in der Simulation einfacher nachstellen lässt. Die Gründe hierfür werden im Folgenden dargelegt. Im Fall einer μ-Split-Bremsung besteht nur bedingt die Möglichkeit, einen Lenkwinkel aus einer Messung in eine Simulation einzuspeisen. Die Straße ist in der Realität nicht so ideal und glatt wie in der Simulation. Ferner können in einer Closed-Loop-Simulation kleine Änderungen in der Umgebung zu größeren Änderungen im Simulationsergebnis oder in Regeleingriffen führen. Wenn der Fahrer hierbei eingreift, ist dies nicht zielführend, da das Verhalten des realen Fahrers in der Simulation nicht identisch reproduziert werden kann. Außerdem können sich im Versuch auch ohne Lenkeinflüsse des Fahrers Abweichungen bei mehreren μ-Split-Bremsungen ergeben136 . Somit wurden für die Validierung Hands-Off -Manöver für die μ-Split-Bremsungen gewählt, da der Einfluss des Fahrers minimiert wird und sowohl die Simulationen als auch die Fahrversuche reproduzierbarer nachgestellt werden können. In der Simulation ist es möglich, diesen Fall nachzustellen, indem der virtuelle Fahrer die Hände vom Lenkrad lässt. Die Voraussetzung dafür ist, dass momentenbasiert gelenkt wird und der Fahrer beim Start der Bremsung kein Lenkmoment mehr auf das Lenkrad gibt. Die Durchführung von Hands-Off -Manövern in der Simulationen stellen hohe Anforderungen an die simulierten Komponenten der Lenkung, denn Reibungen, Übersetzungen und Trägheiten müssen sehr genau mit dem Realsystem übereinstimmen. Andernfalls kann es bei diesen Manövern vorkommen, dass die Simulation instabil137 oder unrealistisch138 wird. Im Folgenden wird der Simulationsaufbau für die Closed-Loop-Simulationen vorgestellt.

136 137 138

Z. B. wenn der Bremspunkt nicht genau getroffen wird. Dieses Phänomen kann z. B. auftreten, wenn eine Trägheit zu klein ist. Hier kann sich ein System aufschwingen. Dieses Phänomen kann z. B. auftreten, wenn eine Trägheit zu groß ist. Hier ist ein System ggf. zu ideal modelliert.

4.3 Simulationsaufbau für die DSR-Funktion

87

4.3 Simulationsaufbau für die DSR-Funktion In Abbildung 4.1 ist der Simulationsaufbau für die Testphasen 2, 3, 4 und 5 für die DSR-Funktion dargestellt. Es folgt eine Beschreibung des Simulationsaufbaus. Das Gesamtmodell besteht aus den Modulen Fahrdynamik, ESC und EPS.

Modul FahrdynamikStreckenmodell

PhysikalischeSignale

BusͲSignale Entwicklungsgegenstand Bremsdruck, Raddrehzahlen, Längs- und QuerBeschleunigungen, Gierrate

Umgebungsmodell Bremsdrücke an Rädern

Modul ESC

Modul EPS

Streckenmodell

Streckenmodell

Hydraulik

AktuellesLenkmoment DSRͲStatus,EPSͲStatus,…

Elektromotor

XiL-SW

Lenkmomentanforderung, DSRͲStatus,Gierrate,…

XiL-SW

Abbildung 4.1: Simulationsaufbau für DSR-Tests

Die Kopplung von Bus-Signalen wurde analog zur Fahrzeugvernetzung umgesetzt. Insgesamt sendet das Modul ESC knapp 40 Bus-Signale an das Modul EPS, während das EPS im Gegenzug ca. 15 Signale an das ESC sendet. Für eine bessere Übersichtlichkeit sind in der Abbildung lediglich die wichtigsten Signale dargestellt, die spezifisch für die DSR-Funktion sind. Dies sind jeweils DSR-Statusinformationen: das aktuelle Lenkmoment vom Modul EPS und das angeforderte Moment vom ESC. Für eine einheitliche Definition von physikalischen Schnittstellen der Streckenmodelle wurde folgendermaßen vorgegangen: In einem vernetzten System von Streckenmodellen sind die Eingänge stets kritischer als die Ausgänge. Bleibt ein Ausgang unbelegt, ist dies unproblematisch. Wenn jedoch ein Eingang unbelegt bleibt, treten in der Regel Probleme auf, denn ein Streckenmodell berechnet auf dieser Basis jeweilige Ausgangsdaten. In Abschnitt 3.4.1 wurde bereits ein Aufbau mit einem zusätzlichen elektrischen Bremskraftverstärker vorgestellt. Die Streckenmodelle sind hierbei so geschnitten, dass die einzelnen

88

4 Anwendungsbeispiel

Komponenten numerisch möglichst stabil sind. In dem hier vorgestellten Fahrzeugprojekt befindet sich jedoch kein elektrischer, sondern ein normaler Bremskraftverstärker. Um dieselben Schnittstellen weiter zu verwenden, existiert eine Umrechnung im Fahrdynamikmodell, die als zusätzlichen Ausgang einen Bremsdruck am Hauptbremszylinder herausgibt. Dies ist eine Skalierung des Bremspedalwegs auf einen am ESC anliegenden Bremsdruck am Hauptbremszylinder. Falls benötigt, kann ein elektrischer Bremskraftverstärker mit identischen Schnittstellen integriert werden. Hier bliebe das Ausgangssignal des Bremsdrucks von der Fahrdynamik unbelegt und der Bremsdruck würde vom elektrischen Bremskraftverstärker stammen. Die weiteren Ausgangssignale der Fahrdynamik zum ESC sind die Raddrehzahlen der vier Räder, die Gierrate sowie die Quer- und Längsbeschleunigungen. Diese Beschleunigungen werden im Motorraum an der Position im virtuellen Fahrzeug abgenommen, wo auch der entsprechende Sensor im Fahrzeug verortet ist. Physikalische Ausgänge des ESCs sind die vier Bremsdrücke an den einzelnen Rädern, aus denen im Fahrdynamikmodell ein Bremsmoment berechnet wird. Diese Schnittstelle vereinfacht die Wiederverwendung von Modellen, denn das auf das Fahrzeug wirkende Bremsmoment hängt beispielsweise von der Größe der Bremsbelege oder den verwendeten Felgen und Reifen ab. Um hier verschiedene Varianten zu simulieren, ändert sich nichts am Modul ESC. Ein Hydrauliksystem kann daher für verschiedene Konfigurationen verwendet werden. Auf der anderen Seite kann ein anderes Hydraulikmodell139 integriert werden, ohne dass das Fahrzeugmodell geändert werden muss. Dies kann auch mithilfe von Parametern im Hydraulikmodell geschehen, ohne dass das Modell ausgetauscht werden muss. Nachdem die Schnittstelle zwischen Fahrdynamik und ESC vorgestellt wurde, folgt die Erläuterung der Schnittstelle zwischen Fahrdynamikmodell und EPS. Da für μ-Split-Bremsungen auch Rotationskräfte der Reifen von Bedeutung sind, wurde die Lenkung mit den Reifen zusammen mit der Fahrdynamik in einem Modell modelliert. Das SiL-SW-Element der Lenkung bekommt als Eingangssignal eine Drehstabverdrehung, die ähnlich zum Sensor im Fahrzeug an der Eingangswelle des Lenkgetriebes abgenommen wird. Hinzu kommen Informationen über den Weg und die Geschwindigkeit der Zahnstange, die das Steuergerät im Fahrzeug mithilfe des Elektromotors ermittelt. Diese werden als zusätzliche Eingänge am Modul EPS angelegt. Auf Basis dieser Daten berechnet das Steuergerät eine Unterstützungskraft, die über den Elektromotor auf die Zahnstange umgesetzt wird. Mit diesem Aufbau lassen sich auch die vorgestellten Hands-Off -Manöver simulieren. Hier hängt die gemessene Drehstabverdrehung des Steuergeräts nicht nur von der Lenkradstellung und der Lenkradträgheit ab, sondern es existieren auch Rückwirkungen der Reifen, die über die Zahnstange übertragen werden. Es folgen Hinweise zum Messaufbau mit einer Beschreibung der im Fahrversuch durchgeführt Manöver.

4.4 Messaufbau und Beschreibung der im Fahrversuch durchgeführten Manöver Für die Validierung eines Gesamtmodells sollten sowohl die physikalischen Schnittstellen zwischen den Modellen als auch relevante Signale für die Bewertung des Funktionsverhaltens 139

Z. B. wenn ein Hydrauliksystem einen stärkeren Bremsdruckaufbau für die Funktion ACC unterstützt.

4.4 Messaufbau und Beschreibung der im Fahrversuch durchgeführten Manöver

89

gemessen werden. Der Versuchsaufbau kann sich demnach ändern, je nachdem welche Signale benötigt werden. Für die Validierung der Schnittstellen musste in diesem Fall zusätzliche Messtechnik installiert werden, um die benötigten Signale messen zu können. Für die Messung wurde der komplette CAN-Bus des Fahrwerks mitgeschnitten. Seitens des ESCs liegen hier die Raddrehzahlen, die Quer- und Längsbeschleunigungen und die Gierrate vor. Die Bremsdrücke am Hauptbremszylinder und die Bremsdrücke der einzelnen Räder wurden mithilfe einer Messtechnik des Steuergeräteherstellers gemessen. Die steuergeräteinternen Größen des ESCs wurden wiederum mithilfe des XCP-Protokolls gemessen. Für die Messgrößen der Lenkung wurden der Lenkwinkel und das Lenkmoment über den CANBus des Fahrwerks mitgeschnitten. Da die Übersetzungen bekannt sind, lässt sich der Lenkwinkel in Zahnstangenwege und -geschwindigkeiten umrechnen. Als zusätzliche Validierungsgröße wurde der aufgenommene Strom der Lenkung gemessen. Aufgrund des hohen messtechnischen Aufwands wurden weitere Größen wie die Spurstangenkräfte, die wirkende Zahnstangenkraft vom Elektromotor oder Einzelradlasten außen vor gelassen. Diese Größen werden über das Gesamtverhalten des Fahrzeugs validiert, das mit weiterer Messtechnik erfasst wurde. Für die Bewertung des Fahrzeugverhaltens wurde eine GPS-Plattform auf dem Dach des Fahrzeugs montiert. Da sich auf dem Prüfgelände in der Nähe der μ-Split-Prüfstrecke Bäume und Hügel befinden, war eine Messtechnik vonnöten, die auch bei Beeinträchtigungen des GPSEmpfangs zuverlässige Werte liefert [57]. Mithilfe der GPS-Signale können unter anderem Trajektorien, Bremswege und Kurvenradien aus dem Fahrversuch mit Simulationsergebnissen verglichen werden. Ferner können ESC-Daten plausibilisiert werden, da auf diese Weise weitere Sensoren für Quer- und Längsbeschleunigungen am Fahrzeugmittelpunkt in die Validierung miteinbezogen werden können. Außerdem ermöglicht das GPS eine zusätzliche Erfassung der Geschwindigkeit. Dies kann bei glatter Fahrbahn von Relevanz sein, da vom ESC gemessene Geschwindigkeiten an einzelnen Rädern von der Geschwindigkeit der Fahrzeugmitte abweichen können. Für die Validierung wurden im Versuch verschiedene Manöver gefahren. Der Grund besteht darin, Längs- und Querdynamik des Modells bei unterschiedlichen Bedingungen getrennt voneinander validieren zu können. Darauf aufbauend können die μ-Split-Bremsungen validiert werden. Hier besteht ein hoher Anspruch an die Modelle, da sowohl die Längs- als auch die Querdynamik des Fahrzeugs genau abgebildet werden müssen. Im Detail wurden folgende Manöver im Fahrversuch gefahren: • Bremsung aus 80 km/h auf einem Streckenabschnitt mit hohem Reibwert bei etwa 0,8 μ • Bremsung aus 80 km/h auf einem Streckenabschnitt mit niedrigem Reibwert bei etwa 0,2 μ • Kreisfahrt mit steigender Geschwindigkeit von 0 bis 100 km/h140 • Kurvenbremsung aus 80 km/h bei einem Lenkwinkel von etwa 40 Grad141 140 141

Auf nassem Asphalt bei etwa 0,8 μ. Auf nassem Asphalt bei etwa 0,8 μ.

90

4 Anwendungsbeispiel

• Hands-Off -μ-Split-Bremsung aus 80 km/h bei Reibwerten von etwa 0,8 μ links und 0,2 μ rechts Die Manöver wurden jeweils siebenmal gefahren, damit einzelne Ausreißer im Versuch identifiziert werden können. Dies entspricht dem Erfahrungswert von Personen, die regelmäßig Fahrversuche durchführen. Falls bei zwei oder drei Versuchen größere Abweichungen durch Windeinflüsse oder verschobene Bremspunkte vorliegen, existieren dennoch genügend Daten, um die Simulation gegen den Fahrversuch zu validieren. Für die Bewertung der Simulation wird somit auch die Abweichung von Daten im Fahrversuch in die Validierung miteinbezogen. Für Daten, die im Versuch weniger reproduzierbar sind, müssen in der Simulation tendenziell weniger genaue Übereinstimmungen mit einzelnen Versuchen erzielt werden. Der Grund liegt darin, dass in erster Linie der Anspruch besteht, in der Simulation ähnlich gute Ergebnisse wie im Fahrversuch zu bekommen. Für die Validierung der Längsdynamik dienen die ersten beiden Bremsmanöver ohne Lenkeingriffe. Dabei kann die Längsdynamik mit dem Bremsweg bei hohen und niedrigen Reibwerten validiert werden. Für die Validierung der Querdynamik wurden Kreisfahrten mit steigender Geschwindigkeit gefahren. Hierbei nimmt auch der Lenkwinkel zu, bis das Fahrzeug bzgl. der Querdynamik in den Grenzbereich kommt. Dieser tritt z. B. ein, wenn ab einer bestimmten Geschwindigkeit bei einem bestimmten Lenkwinkel über den Reifen keine zusätzliche Querbeschleunigung mehr aufgebaut werden kann. Hier schiebt das Fahrzeug im hohen Geschwindigkeitsbereich über die Vorderräder und ein höherer Lenkwinkel führt nicht mehr zu einem engeren Kurvenradius. Schließlich folgen Manöver, bei denen Quer-und Längsdynamik zusammen validiert werden können. Für diesen Zweck wurden Kurvenbremsungen und die μ-Split-Bremsungen gefahren. Bei den Kurvenbremsungen können Querbeschleunigungen und Gierraten sowie das Wankverhalten bzgl. der Querdynamik abgeglichen werden. Dazu können gleichzeitig die Bremswege und Längsbeschleunigungen validiert werden, wobei der Abgleich gegenüber der μ-Split-Bremsung weniger komplex ist, da keine verschiedenen Reibwerte an den Rädern vorliegen. Mithilfe der ausgewählten Manöver können sowohl die Quer- als auch die Längsdynamikeigenschaften separat und zusammen validiert werden.

4.5 Modellkonfiguration beim Durchlauf der Testphasen In diesem Anwendungsbeispiel wird die Austauschbarkeit von Modellen für die Simulationsanforderungen der Testphasen anhand des Fahrdynamikmodells gezeigt, um die durchgängige Integration verschiedener Module zu zeigen. Bei den Modulen EPS und ESC handelt es sich um Variantenmodelle, die beim Durchlauf der Testphasen wiederverwendet werden. Die verschiedenen Module wurden mithilfe einer CoSimulationsplattform vernetzt. Hier werden unterschiedliche Simulationswerkzeuge miteinander vernetzt, indem vom Hersteller einer solchen Plattform Adapter für die unterstützen Werkzeuge bereitgestellt werden. Bei Anwendung der Methode liegen für Ein- und Ausgänge identische Namen vor, daher kann die Vernetzung automatisch erfolgen. Außerdem lässt sich ein Modul sehr einfach austauschen,

4.5 Modellkonfiguration beim Durchlauf der Testphasen

91

indem lediglich der Pfad des Moduls verändert wird, falls Module im selben Simulationswerkzeug vorliegen. Dies wurde am Beispiel des Moduls EPS realisiert, indem die Module in zwei Matlab-Simulink-Modellen mit identischen Schnittstellen austauschbar sind. Da während des Schreibens dieser Arbeit kein Modell als FMU vorlag, ist die Untersuchung der Eignung der Module bzgl. der vorgestellten Klassifizierungskriterien in Matlab-Simulink umgesetzt worden. Die Validierung der Module erfolgte bereits beim Modellersteller, daher ist lediglich das Verhalten der Module bei verschiedenen Frequenz- und Wertebereichen analysiert worden. Hierfür sind in Vorbereitung für den Modellaufbau benötigte Manöver zunächst mithilfe des im Rahmen der Arbeit entwickelten Testsystemkonfigurators beschrieben und anschließend die resultierenden Werte- und Frequenzbereiche exportiert worden. Es folgte eine getrennte Untersuchung der Module in den Werte- und Frequenzbereichen gemäß der entwickelten Verfahren des MAWs. Das Verhalten des Moduls der Lenkung wurde hierbei z. B. von zwei Lieferanten analysiert. Mithilfe der bekannten Werte- und Frequenzbereiche konnte bereits im Vorhinein analysiert werden, dass enthaltene Streckenmodelle nicht für alle Manöver geeignet sind. So ergeben sich bei einem Modell z. B. Instabilitäten bei hohen Frequenzen, die vor der Modellintegration analysiert werden konnten. Die einheitlichen Schnittstellen mit definierten Werteund Frequenzbereichen sorgen dennoch für eine Austauschbarkeit der Module und es wurde die Integrationsfähigkeit bzgl. der Stabilität der Kopplung analysiert, sodass hier bereits ein Mehrwert der vorgestellten Methode deutlich wird. Darüber hinaus wurde untersucht, ob die Streckenmodelle für die Vorapplikation und den Variantentest echtzeitfähig sind. Anhand des Fahrdynamikmodells wird im Folgenden die Austauschbarkeit im Entwicklungsprozess vorgestellt. Beim Vorapplikations- und Variantenmodell handelt es sich um das kommerzielle Fahrdynamikmodell „Dyna4“ der Firma Tesis. Als Auslegungsmodell findet ein Fahrdynamikmodell im Simulationswerkzeug „Adams“ Verwendung. Die verschiedenen Fahrdynamikmodule werden mit identischen Schnittstellen betrieben. Die Testphasen werden in geänderter Reihenfolge durchlaufen, da die Funktion für das spezifische Fahrzeug bereits appliziert wurde. Zunächst wird der Schnittstellentest durchgeführt, um zu testen, ob die gestellten Anforderungen an die Funktion DSR korrekt umgesetzt wurden. Es folgt der Variantentest, bei dem die Robustheit der Funktion geprüft wird, indem die μ-SplitBremsungen bei verschiedenen Geschwindigkeiten und Reibwerten getestet werden. Nachdem gezeigt wurde, dass die Anforderungen auch bei verschiedenen Testvarianten erfüllt werden, wird mit der Bauteilauslegung fortgefahren. Hier können auftretende Kräfte oder Lasten am Fahrzeug sehr genau simuliert werden, wobei das Fahrdynamikmodell möglichst exakt an das Versuchsfahrzeug angeglichen wurde. Daran schließt sich der Abnahmetest an, worauf anschließend eine Vorapplikation folgt. Hier wird das Variantenmodell des bestehenden Fahrzeugs an ein mögliches neues Derivat angepasst. Mithilfe dieses Modells können die Steuergeräte vorappliziert werden, d. h. die bestehenden steuergeräteinternen Parameter können an ein neues Fahrzeug angepasst werden. Es folgt der Schnittstellentest, in dem Zustände und Übergänge der DSR-Funktion untersucht werden.

92

4 Anwendungsbeispiel

4.6 Schnittstellentest In dieser Testphase werden die verteilten Funktionsmodule der DSR-Funktion jeweils getrennt voneinander getestet. Hierbei steht der Test auf Konsistenz zwischen Anforderungen aus dem Lastenheft und dem Code, der auf dem Steuergerät läuft, im Fokus. Es ist üblich, die textuell beschriebenen Zustände aus dem Lastenheft in ein Zustandsmodell zu überführen. Auf Basis dieses Modells kann dann die Konsistenz zum vorliegenden Code überprüft werden, indem geprüft wird, ob sich das Testmodell und der Code bei gleichem Input identisch verhalten. Dies wurde mithilfe eines modellbasierten Tests verwirklicht. Hier werden automatisiert Testfälle aus dem Testmodell generiert, die alle Zustände und Übergänge des kompletten Testmodells ablaufen. Für die Umsetzung wurden die DSR-Zustände und die Zustandsübergänge der Lenkung und der Bremse jeweils getrennt in MATLAB Simulink Stateflow142 modelliert. Anschließend wurden aus den Testmodellen, die das Verhalten der einzelnen Funktionsteile gemäß des Lastenhefts nachstellen, Testfälle mithilfe des Simulink Design Verifiers [75] generiert. Für die Beschreibung des Verhaltens sind somit alle Zustandsinformationen aus dem Lastenheft der Funktion berücksichtigt. Es handelt sich z. B. um Eingriff- und Abbruchbedingungen für die DSR-Funktion. Ferner existieren für den DSR-Teil der Lenkung Bedingungen für überlagerte Eingriffe von anderen Funktionen wie Parklenk- und Spurhalteassistenten, die im Testmodell abgebildet sind. Hierbei ändert sich auch das Verhalten bei verschiedenen Bordnetzspannungen und Fehlerzuständen. Für den Test wurde zudem die temporale Logik in verschiedenen Zuständen berücksichtigt. Dies beinhaltet Wechselzeiten zwischen Zuständen und erlaubte Zeitintervalle zwischen Eingriffen. 4.6.1 Darstellung der verwendeten Modelle Für die Durchführung dieser Testphase wurden jeweils Variantenmodelle der Module ESC und EPS mit Anforderungen aus dem Lastenheft verglichen. In Abbildung 4.2 wird dargestellt, welche Modelle für den Schnittstellentest der Lenkung verwendet wurden143 . Generell besteht die Problematik, dass sich Software- und Hardwareversionen eines Steuergerät oft während der Entwicklung ändern. Der entwicklungsbegleitende Test muss sicherstellen, dass sich keine Inkonsistenzen zwischen Lastenheft und Code ergeben. Wenn eine neue Anforderung hinzukommt oder eine bestehende Anforderung verfeinert wird, muss diese im Testmodell berücksichtigt werden. Nun muss zudem die Konsistenz zwischen neuem Testmodell und Code sichergestellt werden. Hierbei wird angestrebt, diesen Test möglichst hochgradig zu automatisieren, damit die händische und zeitaufwändige Arbeit entfällt. Die zu testende Implementierung ist ein SiL-SW-Element, dass zusammen mit dem Variantenmodell der Lenkung als zusammengehöriges Modul getestet wird. Das zusätzlich benötigte Testmodell wurde von einem Mitarbeiter der Firma MES spezifisch für die Schnittstellentests 142 143

Toolbox für Matlab Simulink mit der Zustandsgraphen mit z. B. zeitlichen Abhängigkeiten modelliert und simuliert werden können, siehe [76]. Für den Schnittstellentest des Funktionsteils im Modul ESC wurde ebenfalls das Variantenmodel verwendet. Die Vorstellung der Ergebnisse erfolgt beispielhaft anhand des Funktionsteils der Lenkung.

4.6 Schnittstellentest

93

Simulationsmodul Variantenmodell (36

Testfälle

Vergleich

Testmodell DSR-Zustände der Lenkung

Abbildung 4.2: Verwendete Modelle für den Schnittstellentest am Beispiel der Lenkung

entwickelt. Nachdem die verwendeten Modelle beleuchtet wurden, folgt die Darstellung der Ergebnisse. 4.6.2 Ergebnisse Im Simulink Design Verifer können verschiedene Metriken und Ziele für die Abdeckung von Testmodellen angegeben werden. Die Algorithmen zur Testfallerstellung und Anwendung der Metrik läuft dabei vollautomatisiert mithilfe des Simulink Design Verifers. Zur Analyse der Abdeckung des Testmodells wurde hier MCDC [61] verwendet, da sich diese Metrik insbesondere für sicherheitskritische Anwendungen eignet. Sie analysiert alle Zustände, Übergänge und Bedingungen. Konkret werden alle In- und Outputs aufgerufen, wobei jegliche mögliche Pfade bzw. Entscheidungen abgegangen werden, Bedingungen nehmen alle möglichen Werte an und es wird geprüft, ob jede Bedingung unabhängig zur Veränderung einer Entscheidung führt. Die Metrik gibt somit nicht nur ein Maß, ob alle Zustände oder Entscheidungen erreichbar sind, sondern sie signalisiert darüber hinaus, ob alle Bedingungen auch eine Entscheidung verändern. Hier können somit auch redundante Bedingungen gefunden werden. Für das Testmodell der Lenkung ergaben sich 142 Ziele, die mit 14 Testfällen abgedeckt werden konnten. Darauffolgend wurden die Testfälle wie in Abbildung 4.2 beschrieben gleichzeitig auf das Testmodell und auf das SiL-SW-Element angewendet. Die Validierung erfolgte hier rein optisch. Sie ist jedoch auf verschiedene Arten automatisierbar, indem ein Toleranzbereich für die Zeitachse vorgesehen wird. In diesem Fall könnten die beiden Signale zunächst voneinander abgezogen werden. Anschließend wird analysiert, ob im resultierenden Signalverlauf länger als z. B. 50 ms ein Wert ungleich null vorliegt.

94

4 Anwendungsbeispiel

8

DSR Status Lenkung

7

Testmodell SiL-Steuergerät

6 5 4 3 2 1 0

6

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 Zeit [s]

7

7.1 7.2 7.3 7.4 7.5

Abbildung 4.3: Modellbasierter Testfall des DSR-Zustands der Lenkung

Ein Ausschnitt eines Testfalls der Lenkung ist in Abbildung 4.3 dargestellt. Aufgezeigt ist der zeitliche Verlauf des DSR-Zustands der Lenkung über 1.5 Sekunden. Hierbei wird der Ausgang des Testmodells in durchgezogener Linie dargestellt. Der entsprechende Ausgang des SiL-SWElements ist hingegen in gestrichelter Form skizziert. In der Abbildung fällt auf, dass die Zustandsänderungen am Ausgang des SiL-SW-Elements zeitverzögert im Vergleich zum Testmodell auftreten. Dies lässt sich dadurch erklären, dass der Steuergerätecode eigene Berechnungs- und Auswertezyklen besitzt. Beispielsweise werden DSR-Anforderungen nicht in jeder Millisekunde ausgewertet, da sie auf dem CAN-Bus auch mit einer niedrigeren Frequenz ausgetauscht werden. Solche Eigenschaften der Funktionsmodule wurden im Testmodell in diesem Fall nicht hinterlegt, da sie für die Bewertung der korrekt umgesetzten Anforderungen nicht erforderlich sind. Durch eine Verschiebung der Signale oder eine Bestimmung der erlaubten Abweichung lassen sich die Signale trotzdem automatisiert vergleichen, vgl. Abschnitt 4.8.2. Der Zustandsverlauf der beiden Signale zeigt eine hohe Übereinstimmung. Die Zustände 4, 3, und 7 werden jeweils in korrekter Abfolge erreicht. Es stimmen auch die Zeitspannen überein, in denen sich SiL-SW-Element und Testmodell im jeweiligen Zustand befinden. So wird Zustand 7 zwischen Sekunde 7.2 und 7.4 beispielsweise jeweils gleich lang gehalten. Analog wurde auch der modellbasierte Test für den DSR-Teil des ESCs umgesetzt. Hier gestaltete sich das Erreichen und Testen aller Zustände komplizierter als bei der Lenkung, da mehr Eingriffbedingungen für die Aktivierung der DSR-Funktion erfüllt werden müssen.

4.7 Variantentest

95

4.6.3 Zusammenfassung des Schnittstellentests Der Schnittstellentest ermöglicht zusammenfassend eine effiziente Durchführung von Tests für Zustände und funktionale Anforderungen. Diese unterstützen den Fahrversuch zielgerichtet, indem steuergeräteübergreifende Zustände systematisch getestet werden. Hierbei hat sich das Vorgehen als effizient erwiesen genau ein Testmodell pro Funktionsteil eines Steuergeräts zu erstellen, damit die Testmodelle übersichtlich und wartbar bleiben. Mithilfe von modellbasierten Tests lässt sich die Auswertung und Validierung von Tests einzelner Module darüber hinaus hochgradig automatisieren. Wie sich bei der Durchführung der Schnittstellentests bestätigt hat, sind keine spezifischen Anforderungen an benötigte Streckenmodelle erforderlich. In der Regel besteht auch die Möglichkeit, Zustandstests ohne Streckenmodelle durchführen. Im Folgenden wird der Variantentest vorgestellt.

4.7 Variantentest In dieser Testphase wird das Verhalten der Funktion DSR mithilfe von verschiedenen Manövern untersucht. Hierfür wurden die μ-Split-Bremsungen mit verschiedenen Reibwerten und Geschwindigkeiten getestet. Die Simulation wurde komplett in einer Closed-Loop durchgeführt, d. h. ein virtueller Fahrer stellt die μ-Split-Bremsungen aus dem Fahrversuch möglichst genau nach. Es werden somit keine Messgrößen in die Simulation eingespielt. 4.7.1 Darstellung der verwendeten Modelle Für die Durchführung dieser Testphase wurden jeweils Variantenmodelle der drei benötigten Module genutzt, vgl. Abbildung 4.4.

0RGXO 9DULDQWHQPRGHOO )DKUG\QDPLN'\QD

0RGXO 9DULDQWHQPRGHOO (6&

0RGXO 9DULDQWHQPRGHOO (36

Abbildung 4.4: Verwendete Modelle für den Variantentest

Bei den Modulen EPS und ESC handelt es sich um die jeweiligen Modelle, die bereits im Schnittstellentest verwendet wurden. Als Fahrdynamikmodell wird das echtzeitfähige „Dyna4“ verwendet. Als Vorbereitung für diese Testphase wurden die benötigten Manöver zunächst anhand des TSKs beschrieben. Anschließend sind die Modelle für die benötigten Betriebsbereiche einzeln gemäß der Verfahren aus dem MAW analysiert worden. Die darauffolgende Validierung der vernetzen Modelle erfolgte gemäß des beschrieben Validierungskonzepts aus Abschnitt 3.4.4

96

4 Anwendungsbeispiel

schrittweise, wobei im Folgenden lediglich die Ergebnisse der Gesamtsimulation dargestellt werden. 4.7.2 Ergebnisse In Abbildung 4.5 ist der Lenkradwinkel bei der Simulation mit verschiedenen Reibwerten dargestellt. Die Anfangsgeschwindigkeit für die Vollbremsung liegt bei allen Simulationen bei 80 km/h. Nach Beginn der Vollbremsung stellen sich verschiedene Lenkwinkel ein, da je nach Reibwertdifferenz verschieden stark gegengelenkt werden muss. Der größte Lenkwinkel ergibt sich beim in blau dargestellten Manöver mit einer Reibwertdifferenz von 0.9. Eine Lenkwinkeldifferenz von 0.3 führt lediglich zu einem Lenkwinkel von etwa 10 Grad. Es zeigt sich auch, dass das Manöver zwischen gelber und roter Kurve kürzer andauert, da sich der Bremsweg verringert. In Abbildung 4.6 ist die dazugehörige Gierrate der Simulationen dargestellt. Diese steigt nach dem Bremsschlag bei Sekunde 1 von 0 auf 3-5 Grad pro Sekunde an. Nach dem Anstieg regelt die Funktion DSR entgegen, sodass das Fahrzeug gerade in der Spur bleibt. Insgesamt lässt sich feststellen, dass die Simulation der Funktion für die verschiedenen Reibwertkombinationen mit den identifizierten Modelleigenschaften realisiert werden kann. 20

Reibwerte: 1.0 links, 0.1 rechts Reibwerte: 0.8 links, 0.2 rechts Reibwerte: 0.8 links, 0.5 rechts

Lenkradwinkel [Grad]

10 0 −10 −20 −30 −40 −50 −60

0

1

2

3

4

5

6

7

8

9

Zeit [s]

Abbildung 4.5: Lenkradwinkel mit verschiedenen Reibwerten bei einer μ-Split-Bremsung (80 km/h)

4.7 Variantentest

97

6

Reibwerte: 1.0 links, 0.1 rechts Reibwerte: 0.8 links, 0.2 rechts Reibwerte: 0.8 links, 0.5 rechts

Gierrate [Grad/s]

4 2 0 −2 −4 −6

0

1

2

3

4

5

7

6

8

9

Zeit [s] Abbildung 4.6: Gierrate mit verschiedenen Reibwerten bei einer μ-Split-Bremsung (80 km/h)

20

60 km/h 80 km/h 100 km/h

Lenkradwinkel [Grad]

10 0 −10 −20 −30 −40 −50 −60

0

1

2

3

4

5 Zeit [s]

6

7

8

9

10

Abbildung 4.7: Lenkradwinkel einer μ-Split-Bremsung bei verschiedenen Geschwindigkeiten (Reibwerte: 0.8 links, 0.2 rechts)

98

4 Anwendungsbeispiel

In Abbildung 4.7 werden Lenkradwinkel bei verschiedenen Geschwindigkeiten dargestellt. In diesem Fall bleiben die Reibwerte der Straße konstant bei 0.8 und 0.2 μ. Bei 60 km/h dauert das Bremsmanöver etwa 4.5 Sekunden. Bei höheren Geschwindigkeiten verlängert sich das Manöver entsprechend um etwas mehr als 1.5 Sekunden. Nach dem Bremsschlag ergeben sich erneut Unterschiede beim Lenkradwinkel, da die Gegenlenkunterstützung geschwindigkeitsabhängig ist. Relativ konstant sind hingegen die Bremsdrücke bei den verschiedenen Geschwindigkeiten, siehe Abbildung 4.8. Während der Bremsung ergibt sich für die verschiedenen Geschwindigkeiten ein ähnlicher Verlauf von 30-60 Bar. Das Ende des Manövers lässt sich dadurch erkennen, dass der Bremsdruck auf etwa 100 Bar ansteigt. Auch die Simulationen mit verschiedenen Geschwindigkeiten sind somit möglich, da die Anforderungen bzgl. der Streckenmodelle für die Funktion erfüllt werden und das Fahrzeugverhalten stabil bleibt. 160 Bremsung bei 60 km/h Bremsung bei 80 km/h Bremsung bei 100 km/h

Bremsdruck vorne links [Bar]

140 120 100 80 60 40 20 0

0

1

2

3

4 Zeit [s]

5

6

7

8

Abbildung 4.8: Bremsdruck vorne links bei μ-Split-Bremsung bei verschiedenen Geschwindigkeiten (Reibwerte: 0.8 links, 0.2 rechts)

4.7.3 Zusammenfassung des Variantentests Als sinnvolle Ergänzung zum Fahrversuch lässt sich mithilfe dieser Testphase zusammenfassend eine deutlich höhere Anzahl von Testvarianten durchführen. Dies zeigt sich darin, dass eine große Anzahl von Manövern und verschiedene Varianten einer Funktion getestet werden können, wobei auch einzelne Manöver aus dem Fahrversuch gezielt reproduziert werden können. Es wird darüber hinaus deutlich, dass die Modelleigenschaften geeignet sind, da zuvor definierte

4.8 Bauteilauslegung

99

Manöver auch simuliert werden können. Nach der Verwendung der Werkzeuge ergibt sich zudem, dass die vorher definierten Modelleigenschaften bzgl. verschiedener Module getestet werden können, wenn diese zuvor bekannt sind. Wenn das Modul der Lenkung durch eine andere Implementierung mit dazugehörigem Streckenmodell ausgetauscht wird, ergeben sich z. B. numerische Instabilitäten bei Lenkwinkeln mit hoher Frequenz, da diese beim Streckenmodell nicht vorgesehen sind. Dies bestätigt sich auch durch den Test des einzelnen Moduls. Es folgt die Bauteilauslegung, um zu zeigen, dass mit dem genauer parametrierten „Adams“Modell auch genauere Simulationsergebnisse erreicht werden können. Hierfür erfolgt zudem ein Vergleich mit Versuchsdaten.

4.8 Bauteilauslegung Für diese Testphase wird die Simulation möglichst genau zum Messfahrzeug aufgebaut und es erfolgt ein Vergleich mit den Simulationen des Variantenmodells und Messdaten. 4.8.1 Darstellung der verwendeten Modelle Für diese Testphase wird das Variantenmodell der Fahrdynamik durch ein Auslegungsmodell ersetzt, vgl. Abbildung 4.9.

0RGXO $XVOHJXQJVPRGHOO )DKUG\QDPLN$GDPV

0RGXO

0RGXO 9DULDQWHQPRGHOO (6&

9DULDQWHQPRGHOO (36

Abbildung 4.9: Verwendete Modelle für die Bauteilauslegung

Die Basis für das Auslegungsmodell bildet ein MKS-Modell in „Adams“, in dem Achsen und Fahrwerkseigenschaften sehr detailliert nachgebildet werden können. An diesem Modell wurden mehrere fahrzeugspezifische Änderungen vorgenommen, wobei die wichtigen Zustandsvariablen neben dem Manöver mithilfe der Werkzeuge beschrieben und überprüft wurden. Ein großer Einflussfaktor für Fahrdynamiksimulationen sind die Reifen. Für eine möglichst genaue Übereinstimmung zwischen Versuch und Simulation wurden gleiche Reifen mit identischem Reifendruck in Simulation und Versuch verwendet. Für die Simulation diente ein sehr genaues FTire-Reifenmodell der Firma cosin scientific software, vgl. [43]. Dieses wurde gemäß der Manöver im Fahrversuch bei 80 km/h auf einem Prüfstand vermessen. Im Fahrdynamikmodell „Dyna4“ wurde eine echtzeitfähige Variante desselben Reifens verwendet. Zusätzlich zum

100

4 Anwendungsbeispiel

Reifen wurden Dämpfungseigenschaften, Stabilisatoren, Radlasten, Gewichte sowie die Straße an die Konfiguration im Fahrversuch angepasst. Es lassen sich auch bereits vermessene Straßen in „Adams“ einspielen, für den hier vorliegenden Fall wird die Straße jedoch abschnittsweise durch zwei glatte Flächen dargestellt. Der rechte Teil der Fahrbahn stellt den Streckenabschnitt mit niedrigem Reibwert dar. Dieser liegt identisch zur Konfiguration im Variantentest bei etwa 0,2 μ. Da die Teststrecke zum Zeitpunkt der Messungen nass war, ergibt sich für die andere Seite der Fahrbahn ein Reibwert von ca. 0,8 μ, was ebenso der jeweiligen Konfiguration im Variantentest entspricht. Der Aufwand, der für die Anpassung des „Adams“-Modells getrieben wurde, ist jedoch deutlich höher, sodass die Erwartung besteht, die Messergebnisse des spezifischen Fahrzeugs mit diesem Modell genauer zu reproduzieren. Es folgt die Darlegung der Validierung zwischen Fahrversuch und Simulationen. 4.8.2 Ergebnisse In den Abbildungen 4.10 bis 4.14 werden in vier gestrichelten schwarzen Linien verschiedene Messungen eines Signals dargestellt. Die dazugehörigen Closed-Loop-Simulationsergebnisse in „Adams“ und „Dyna4“ werden mithilfe von blauen bzw. roten Linien visualisiert. Hierbei wird lediglich ein Ausschnitt der verglichenen Manöver und Signale gezeigt, die die Tendenz der Übereinstimmung widerspiegeln. Quantitative Methoden zum automatisierten Vergleich von Signalen aus Messungen und Simulation werden in einer Masterarbeit vorgestellt, die im Rahmen der vorliegenden Arbeit betreut wurde, siehe [28]. Die hier vorgestellten Vergleiche werden im Rahmen dieser Ausarbeitung lediglich optisch vorgestellt. Eine vollautomatisierte Validierung von Mess- und Simulationsdaten könnte somit zukünftig verfolgt werden. In Abbildung 4.10 ist beispielhaft die Radgeschwindigkeit des rechten vorderen Rades dargestellt. Dies ist die Fahrzeugseite mit dem niedrigen Reibwert. Der Bremsschlag zeigt sich durch den Raddrehzahlverlauf bei Sekunde 1.0, indem die Raddrehzahlen in den Messungen auf etwa 30 bis 50 km/h sinken. Simulationen und Fahrversuch haben insgesamt einen hohen Grad an Übereinstimmung, wobei der Raddrehzahlverlauf beim Bremsschlag vom „Adams“-Modell besser als vom „Dyna4“Modell reproduziert wird. Hier liegen die Raddrehzahlen in „Adams“ näher am Durchschnitt der Messungen, der bei etwa 45 km/h liegt. Nach Sekunde 1.5 zeigen die Verläufe in Simulationen und Messungen eine hohe Übereinstimmung, da die Raddrehzahlen der Simulationen in einem von den Messungen aufgespannten Raum liegen und die Signalfrequenzen sich ebenfalls ähneln. Die Drehzahlen der anderen Räder entsprechen der Übereinstimmung des gezeigten Beispiels. Hier bestätigt die Simulation auch, dass die Raddrehzahlen der Hinterreifen einen glatteren Verlauf aufzeigen als die Vorderräder.

4.8 Bauteilauslegung

Abbildung 4.10: μ-Split-Bremsung Radgeschwindigkeit vorne rechts

Abbildung 4.11: μ-Split-Bremsung Bremsdruck vorne links

101

102

4 Anwendungsbeispiel

Abbildung 4.12: μ-Split-Bremsung Bremsdruck vorne rechts

Ein ähnliches Verhalten zeigt sich bei den Bremsdrücken der einzelnen Räder. In Abbildung 4.11 ist der Bremsdruck des Rades vorne links dargestellt. Beim Bremsschlag wird in Messungen und Simulationen jeweils ein Bremsdruck von ca. 40 Bar erreicht. Im anschließenden Verlauf liegt der Bremsdruck zwischen ca. 25 und 80 Bar. Die „Adams“-und „Dyna4“-Simulationen spiegeln das Verhalten der Messungen gut wider, wobei der Wertebereich, indem sich der Bremsdruck in der Simulation gegenüber der Messung während der Bremsung bewegt, etwas geringer ausfällt144 . Diese Unterschiede erklären sich durch die Straße, die in der Simulation einen konstanten Reibwert hat. In Abbildung 4.12 ist der Bremsdruck des Reifens vorne rechts dargestellt. Wie erwartet, ist der Bremsdruck des rechten Rades im Gegensatz zum linken Rad deutlich geringer, da auf der rechten Seite weniger Bremsmoment aufgebaut werden kann. Der Grund liegt darin, dass auf der rechten Seite der Fahrbahn ein niedrigerer Reibwert vorliegt. Ein stärkerer Bremsdruck würde dazu führen, dass das Rad beim Bremsen stehen bliebe. In den Simulationen wird der initiale Bremsschlag mit ca. 40 Bar wird erneut sehr genau getroffen. Danach liegen Simulationen und Messungen im gleichen Wertebereich zwischen etwa 5 und 25 Bar. Die Raddrehzahlen und die Bremsdrücke beeinflussen bei diesem Manöver primär die Längsdynamik und den resultierenden Bremsweg. Abbildung 4.13 zeigt den entsprechenden Verlauf der Längsbeschleunigung. 144

In der Messung pendelt der Druck während der Bremsung zwischen 15 und 80 Bar. In den Simulationen liegt der Druck bei ca. 20 bis 60 Bar.

4.8 Bauteilauslegung

103

Nachdem die Bremsung bei Sekunde eins gestartet ist, steigt die Längsbeschleunigung in negativer Richtung an. Ab Sekunde zwei fällt der Beschleunigungswert hierbei weitgehend konstant. Sobald das Fahrzeug zum Stehen kommt145 , geht die Beschleunigung nach einem leichten Überschwingen wieder zurück auf null. Die Messdaten werden in der „Adams“-Simulation gut repräsentiert. Somit wird die Längsdynamik von diesem Modell zufriedenstellend dargestellt. Die Verzögerung bei niedrigen Geschwindigkeiten wird vom Variantenmodell nicht ganz sauber dargestellt, daher ergibt sich ein anderes Verhalten nach der Sekunde fünf. Bezüglich der Längsbeschleunigung verhält sich das „Adams“-Modell somit realistischer für dieses Manöver.

Abbildung 4.13: μ-Split-Bremsung Längsbeschleunigung

Die Querdynamik äußert sich bei diesem Manöver unter anderem über die Gierrate und über den resultierenden Lenkradwinkel. Das Fahrzeug wird bei diesem Manöver zur Seite mit höherem Reibwert gezogen, das heißt bei diesem Hands-Off -Manöver zieht das Fahrzeug nach links. Darauf reagiert die Funktion DSR mit einer Gegenlenkunterstützung zur rechten Seite, um das Fahrzeug möglichst gerade in der Spur zu halten. Entgegen der Daten aus dem Fahrversuch startet der Lenkradwinkel in der Simulation bei exakt null Grad, vgl. 4.14. Der exakte Lenkradwinkelverlauf aus dem Fahrversuch ist schwierig zu reproduzieren, da das richtige Moment anliegen und sich die Fahrbahn an das Manöver anpassen müsste. 145

Etwa nach Sekunde 6.2.

104

4 Anwendungsbeispiel

Nach 1.5 Sekunden sorgt die Funktion DSR für eine starke Beeinflussung des Lenkradwinkels, was sich in Simulationen und Messungen zeigt. Ab etwa zwei Sekunden ergeben sich Lenkradwinkel zwischen 20 und 30 Grad, was sich in der „Adams“-Simulation ebenfalls bestätigt. Kleinere Abweichungen zeigen sich nach dem Bremsschlag, wobei im „Dyna4“-Modell im Vergleich zu „Adams“ ein stärkeres Überschwingen zu konstatieren ist. Ferner ist der Lenkradwinkel des „Dyna4“-Modells gegenüber den Messungen und der „Adams“-Simulation ab Sekunde 3 etwas zu glatt. Am Lenkradwinkel zeigt sich, dass es zielführend ist, unterschiedlich detaillierte Modelle zu haben.

Abbildung 4.14: μ-Split-Bremsung Lenkradwinkel mit Messungen und unterschiedlich detaillierten Modellen

4.8.3 Zusammenfassung der Bauteilauslegung Die Durchführung dieser Testphase zeigt, dass es für einige Manöver sinnvoll ist, Konfigurationen im Fahrversuch sehr genau nachzustellen. Durch die Verwendung sehr genauer Modelle, die zu einem höheren Rechenaufwand führen, lassen sich auch genauere Simulationsergebnisse erreichen. Es zeigt sich somit, dass die entwickelte Methode mit verschiedenen Testphasen und unterschiedlich detaillierten Modellen sich als zielführend erweist. Somit sind insbesondere die Bauteilauslegungsmodelle sinnvoll, wenn kritische Manöver simuliert werden sollen. Bezüglich der Quer- und der Längsdynamik ergibt sich insgesamt eine hohe Übereinstimmung zwischen Fahrversuch und Simulationen. Besonders bzgl. des Lenkwinkels ist die „Adams“Simulation genauer, wobei auch hier kleinere Abweichungen zwischen Simulation und Fahrversuch existieren. Ein Grund dafür liegt darin, dass im Fahrversuch Abschnitte mit mehr oder weniger Wasser auf der Straße existieren. Zudem wurde der Reifen lediglich für eine normale Straße parametriert. Die Unterschiede zwischen „Adams“ und „Dyna4“ erklären sich wiederum

4.9 (Vor-)Applikation

105

über genauer abgebildete Zustandsvariablen wie z. B. Rotationskräfte, die mithilfe des detaillierteren Reifenmodells genauer abgebildet sind. Eine noch größere Übereinstimmung ließe sich erreichen, wenn der Reifen für verschiedene Reibwerte parametriert würde. Außerdem könnte die Straße genau vermessen werden, sodass identische Reibwerte in der Simulation verwendet werden könnten. Es bestehen zudem Toleranzen für verbaute Bauteile, sodass beispielsweise auch verbaute Federn und Achsen des Fahrzeugs vermessen werden könnten. Weitere Verbesserungen an den vorgestellten Modellen sind demnach möglich. Darüber hinaus könnten die beiden Variantenmodelle EPS und ESC durch Auslegungsmodelle ersetzt werden, so dass beispielsweise Verzögerungen beim Bremsdruckaufbau genauer dargestellt werden. Im Allgemeinen sollten Anpassungen an Modellen nur solange durchgeführt werden, bis eine benötigte Genauigkeit zwischen Simulation und Fahrversuch erreicht wird und dies wirtschaftlich sinnvoll ist. Die Maß für die Genauigkeit zwischen Simulation und Fahrversuch hängt letztlich von den Anforderungen des Funktionsentwicklers ab, jedoch sollte die Simulation generell im Streubereich von verschiedenen Messung liegen, siehe Unterkapitel 3.4.4. Es kann in einer späten Phase im Entwicklungsprozess außerdem wirtschaftlicher sein, einen Fahrversuch durchzuführen, falls genügend Fahrzeuge verfügbar sind. Dennoch bietet sich stets eine Simulation als zusätzliches Testwerkzeug an. Die vorher definierten Modelleigenschaften führen auch für dieses anspruchsvolle Manöver zu Simulationsergebnissen, die das Verhalten des Fahrzeugs im Fahrversuch sehr genau reproduzieren. Die definierte Methode und die Verwendung der Werkzeuge erweist sich zusammenfassend auch für diese Testphase als zielführend. Es folgt die Darstellung der Vorapplikation.

4.9 (Vor-)Applikation In dieser Testphase wird beispielhaft eine virtuelle (Vor-)Applikation der Funktion DSR vorgestellt. 4.9.1 Darstellung der verwendeten Modelle Als Basis für die Durchführung dieser Testphase dient der Modellaufbau aus Testphase 3, vgl. Abbildung 4.15. In der Annahme, dass sich die Hardware der Lenkung und der Bremse nicht ändern, wurde lediglich das Fahrdynamikmodell angepasst. Hierfür wurden das verwendete Manöver und die benötigten Zustandsvariablen für das Fahrdynamikmodell mithilfe des TSKs spezifiziert. Es wurden Fahrzeugschwerpunkt, Masse, Trägheiten, Radstände und Gewicht des bestehenden Fahrzeugs am bestehenden Variantenmodell verändert. Auf diese Weise lässt sich das Verhalten der Steuergeräte anhand weniger Änderungen am Fahrdynamikmodell untersuchen.

106

4 Anwendungsbeispiel

0RGXO 9RUDSSOLNDWLRQVPRGHOO )DKUG\QDPLN'\QD

0RGXO

0RGXO 9DULDQWHQPRGHOO (6&

9DULDQWHQPRGHOO (36

Abbildung 4.15: Verwendete Modelle für die Vorapplikation

4.9.2 Zusammenfassung der (Vor-)Applikation Mithilfe dieses neuen Fahrdynamikmodells können steuergeräteinterne Parameter in den XiL-SWElementen an das neue Fahrzeugmodell angepasst werden. Hierbei handelt es sich beispielsweise um Parameter im Modul ESC, die das Fahrzeugverhalten auf der Basis von internen Streckenmodellen im ESC schätzen. Außerdem können Parameter in der Lenkung verändert werden, welche die Lenkkraftunterstützung durch den Elektromotor beeinflussen. Eine detaillierte Darstellung und Funktionsweise der steuergeräteinternen Parameter wäre zwar interessant, sie hätte jedoch den Rahmen dieser Arbeit gesprengt. Da in dieser Testphase nicht der Schwerpunkt auf der Validierung dieser Methode liegt, wird sie lediglich kurz vorgestellt. Bezüglich der Modelleigenschaften ergibt sich, dass das Vorgehen, die Werkzeuge für die Definition und Prüfung der Modelleigenschaften zu verwenden, geeignet ist. Inwiefern die steuergeräteinternen Parameter als Grundlage für den Fahrversuch genutzt werden können, muss funktionsspezifisch untersucht werden. Abgesehen von diesem Aspekt ergibt sich durch diese Testphase der Vorteil, dass vor dem ersten Fahrversuch überprüft werden kann, ob plausible Eingriffe der Steuergeräte vorliegen und ob das Verhalten der Funktion den Anforderungen entspricht.

4.10 Abnahmetest Der Abnahmetest wurde in einem anderen Fahrzeugprojekt umgesetzt, daher werden an dieser Stelle keine Ergebnisse oder Modelle vorgestellt. Die Vernetzung zwischen Lenkungs- und Bremsprüfstand wurde mithilfe einer Echtzeitkopplung von zwei Komponenten-Prüfständen der Firma dSPACE realisiert. Für den Test wurden Prüfstände der Lenkung und der Bremse miteinander vernetzt, die zuvor lediglich separat liefen.

4.11 Zusammenfassung des Anwendungsbeispiels Der Simulationsaufbau mit den zuvor Schnittstellen vereinfacht insgesamt den Austausch einzelner Module, vgl. Unterkapitel 4.3. So konnten ein EPS-Modul mit einer Software eines anderen Herstellers oder andere Reifen integriert werden, um zu untersuchen, welche Unterschiede sich

4.12 Auswertung der Methodik

107

dadurch in den Ergebnissen ergeben. Die Simulation bleibt dabei stabil, d. h. das Fahrzeug bleibt in der Spur und es treten plausible Lenkradwinkel und Kräfte auf. Eine Robustheit der Simulation ist somit gegeben. Im Vergleich der Simulationen untereinander ergeben sich für das Auslegungsmodell höhere Übereinstimmungen bzgl. des Lenkradwinkels oder der Längsbeschleunigung. Jedoch hat das verwendete MKS-Modell keine hinreichende Aussagekraft bezüglich des Windwiderstands oder der Akustik. Es zeigt sich somit, das ein Modell, das alle anspruchsvollen Manöver genau abbildet, wirtschaftlich nicht effizient umsetzbar ist. Dennoch hat das „Dyna4“-Modell seine Stärken gegenüber dem „Adams“-Modell. So bietet „Adams“ nur bedingt Möglichkeiten zur Testautomatisierung und das vorhandene Modell ist nicht echtzeitfähig. Zusammenfassend wird für dieses anspruchsvolle Manöver mit dem Auslegungsmodell der höchste Grad an Übereinstimmung zwischen Simulation und Fahrversuch erreicht. Das Variantenmodell eignet sich dennoch sehr gut für Vergleiche zwischen Simulationen. Für die vorgestellte Methode dieser Arbeit bestätigt sich an dieser Stelle, dass die klassifizierten Simulationsmodelleigenschaften für die Testphasen geeignet sind. Es wurde auch bestätigt, dass der Aufwand steigt, je genauer eine Simulation mit einem spezifischen Manöver im Fahrversuch übereinstimmen soll. Es folgt eine Auswertung der Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen anhand der Erfahrungen der Funktion DSR.

4.12 Auswertung der Methodik Gesamtheitlich betrachtet besteht beim Softwaretest das Ziel, Fehler möglichst früh zu finden. Nachdem Fehler behoben wurden, wird erneut getestet, um weitere Fehler zu finden. Die vorgestellte Methodik leistet einen Beitrag, damit diese Schleife schneller durchgeführt werden kann, da die Software am Beispiel der Funktion DSR mithilfe der Methodik kontinuierlich in der Simulation getestet werden kann. Die Entwicklung der Funktion DSR musste in der Vergangenheit komplett im Fahrversuch durchgeführt werden. Die Ursache, weshalb auf Simulation verzichtet werden musste, lag darin, dass die Simulation von μ-Split-Bremsungen aufgrund ungeeigneter Streckenmodelle nicht möglich war. Die in dieser Arbeit vorgestellte Methodik ermöglicht nun eine stabile Simulation und macht den entwicklungsbegleitenden Test durch Simulation zukünftig möglich. Darüber hinaus zeigt sich, dass der Aufwand für den Aufbau einer solchen Simulation signifikant reduziert werden kann. Die größte Herausforderung beim Simulationsaufbau für Fahrfunktionen liegt in den Streckenmodellen. Diese werden von unterschiedlichen Parteien entwickelt und die Eigenschaften verschiedener Streckenmodelle waren zuvor nicht aufeinander abgestimmt. Bei der Anwendung der Methodik zeigt sich, dass die Werkzeuge Testsystemkonfigurator und Modellanalysewerkzeug einen signifikanten Beitrag für einen schnelleren und effizienteren Simulationsaufbau leisten, da Anforderungen nun systematisch beschrieben und getestet werden können. Ein generelles Problem bzgl. der Streckenmodelle lag darin, dass die Werte- und Frequenzbereiche verschiede-

108

4 Anwendungsbeispiel

ner Streckenmodelle von Ein- und Ausgängen nicht aufeinander abstimmt waren. So konnten manche Manöver simuliert werden, andere führten hingegen zu Abstürzen. Mithilfe des Tests einzelner Modulen kann nun vorab getestet werden, ob sich ein Modul bei verschiedenen Manövern plausibel verhält. So konnten Fehler wie falsche Einheiten oder numerische Instabilitäten in höheren Frequenzbereichen im Modul EPS mithilfe des MAWs bereits vor der Modellintegration gefunden werden. Eine andere Herausforderung bzgl. der Genauigkeit einer Simulation waren nicht bekannte bzw. fehlende Zustandsvariablen in Streckenmodellen. So fehlten z. B. Zustandsvariablen in einzelnen Modulen, die bei Anwendung der Methodik nun in einem definierten Prozess beschrieben werden können. Am Beispiel des Fahrdynamikmodells waren für den Modellersteller z. B. Massenträgheiten des Lenkrads nicht von Interesse, die für das vorliegende Manöver jedoch einen signifikanten Einfluss auf das Ergebnis haben. Bei der Durchführung von Systemsimulationen besteht generell ein Kompromiss zwischen Genauigkeit und Gültigkeitsbereich, der mithilfe der entwickelten Methodik mit den Testphasen adressiert wird, indem unterschiedlich genaue Streckenmodelle für Tests beschrieben werden können. Es konnten im Schnittstellentest mit geringerem Aufwand Ungenauigkeiten bzgl. der Anforderungen aus dem Lastenheft identifiziert werden. Außerdem kann im Variantentest schneller eine größere Anzahl von Tests gegenüber dem Fahrversuch durchgeführt werden. Ferner erlaubt die Bauteilauslegung genauere Simulationen, die zukünftig als zusätzliches Testwerkzeug verwendet werden können. Diese Testphasen führen zu einer Qualitätssteigerung in der Entwicklung, wobei stets das Ziel besteht, den Aufwand für den Aufbau einer Simulation möglichst gering zu halten. Ein großes Problem beim Test durch Simulation stellten die Schnittstellen zwischen verschiedenen Streckenmodellen dar. Undefinierte Schnittstellen erschwerten zuvor einerseits den Aufbau, da verschiedene Einheiten, Vorzeichen und Koordinatensysteme zu großem händischen Anpassungsaufwand führten. Anwender, die sich nicht mit dem physikalischen System auskennen, sind nicht in der Lage einen Fehler an den Schnittstellen zu finden. Andererseits waren die Module zuvor ungünstig geschnitten, sodass hohe Frequenzen an Schnittstellen zu Abstürzen im Gesamtsystem führten. Hier helfen die im TSK eindeutig beschriebenen Schnittstellen, die solche Instabilitäten auf Basis verschiedener Rollen bereits früh kenntlich machen. Es ergibt sich zudem der Vorteil, dass die Methodik es erlaubt, einzelne Modelle oder einen Simulationsverbund systematisch mit dem Fahrversuch validieren zu können. So können zusätzlich zur Software auch Streckenmodelle bzgl. ihrer notwendigen Eigenschaften getestet werden. Schließlich entfällt so die fehleranfällige Anpassung. So senken die festen Schnittstellen die Kosten für den Simulationsaufbau und Module verschiedener Hersteller können nun leicht ausgetauscht werden. Dies konnte am Beispiel der EPS- und Fahrdynamikmodule gezeigt werden. Außerdem können durch die austauschbaren Module nun auch ohne händische Anpassungen detailliertere Tests in der Simulation realisiert werden. Hierdurch steigt auch die Zuverlässigkeit einer Simulation, da viele Bestandteile wiederverwendet werden. Es konnte gezeigt werden, dass die Methodik am Beispiel der Funktion DSR Zeit und damit auch Kosten beim Aufbau einer Simulation spart und zu einer Qualitätssteigerung in der Entwicklung führt. Die Vorteile einer entwicklungsbegleitenden Simulation sind vielfältig. Es kann z. B. schneller getestet werden, ob ein Fehler auch in einer neuen Softwareversion vorliegt. Somit

4.12 Auswertung der Methodik

109

besteht auch die Möglichkeit, schneller zu einer serienreifen Software zu kommen, da nun auch komplexe Manöver mithilfe der Methodik simuliert werden können. Insgesamt ist der initiale Aufwand für einen Simulationsaufbau zwar höher. Hier rentiert sich die Methodik jedoch schnell, da die definierten Anforderungen dazu führen, dass etwa 30 Prozent der Zeit für die Inbetriebnahme einer Simulation gespart werden kann. Zusammenfassend unterstützt die Methodik dabei, dass die Tests durch Simulation schneller, effizienter, genauer und zuverlässiger werden.

5 Zusammenfassung Der Einsatz der Simulation für den Test von Steuergerätesoftware spielt bereits heute eine wichtige Rolle und der Testbedarf wird sich vor dem Hintergrund des automatisierten bzw. autonomen Fahrens weiter erhöhen. Der Grund liegt darin, dass Systeme und Funktionen den Fahrer immer mehr bei seinen Aufgaben unterstützen. Diese Systeme sind nicht nur innerhalb des Fahrzeugs vernetzt, sondern sie interagieren auch zunehmend mit der Umgebung. Hier gilt es neben der Verifikationen einer Funktion auch die Validierung mit der Rückwirkung des Funktionsverhaltens auf das Fahrzeug zu betrachten. Aufgrund des steigenden Umfangs von Software gerät daher zunehmend die Funktionsentwicklung und -bewertung durch Simulationen in den Fokus. Diese Aussage manifestiert sich durch die hohe Anzahl von prognostizieren Testkilometern, vgl. [110, S. 933]. Für die Durchführung solcher Simulation ist im Kontext des autonomen bzw. automatisierten Fahrens die Abbildung des virtuellen Fahrzeugs von zentraler Bedeutung. Hierfür werden im Rahmen dieser Arbeit Lösungen vorgeschlagen, indem auf Basis von Testanforderungen benötigte Streckenmodelleigenschaften definiert werden. Die Basis für dieses Vorgehen bilden feste Schnittstellen zwischen Streckenmodellen verschiedener Module, die den Aufwand für den Aufbau von vernetzten Steuergerätetests signifikant vereinfachen, vgl. Unterkapitel 4.12. Optimalerweise ist eine Schnittstelle derart gewählt, dass Fahrzeugdaten aus dem Fahrversuch direkt für Validierungen genutzt werden können. Für die Validierung einer vernetzten Simulation mit verschiedenen Modulen wurde ein darauf aufbauendes Validierungskonzept vorgeschlagen, mit dem sich ein Gesamtmodell schrittweise teilen und wieder zusammensetzen lässt, siehe Abschnitt 3.4.4. Die Fragestellung, was in welcher Form wann getestet werden soll, wurde in Form von Testphasen für Funktionen dargelegt, siehe Unterkapitel 3.3. Diese werden im Folgenden noch einmal zusammengefasst. Die Verifikation einer Funktion in Form des Schnittstellentests bietet die Möglichkeit, das Verhalten einer Funktion gegen Anforderungen aus dem Lastenheft zu testen. Im Fall von in dieser Arbeit durchgeführten modellbasierten Tests lässt sich dieser Schritt automatisieren, sodass der wiederkehrende Aufwand verhältnismäßig gering wird, vgl. Abschnitt 3.3.2. Dieses Vorgehen eignet sich insbesondere dann, wenn wiederkehrend getestet werden soll, ob neue Softwarestände vollständig die Anforderungen erfüllen. Nachdem eine Funktion verifiziert worden ist, kann die Applikation einer Funktion an ein spezifisches Fahrzeug angepasst werden. Hierfür können Parametervarianten in der Simulation ermittelt werden. Für eine applizierte Funktion kann anschließend der Variantentest erfolgen. Hierfür werden Tests mit verschiedenen Fahrzeugkonfigurationen, Manövern, Fahrern und Ausstattungsvarianten durchgeführt. Für einzelne Fälle bietet es sich an, genauere Untersuchungen durchzuführen, um bestimmte Konfigurationen im Fahrversuch noch genauer nachzustellen. Um Schwingungen, Vibrationen oder wirkende Kräfte auf Bauteile zu untersuchen, nimmt die benötigte Rechenzeit für Simulationen zu, sodass Modelle ggf. nicht mehr echtzeitfähig sind. Dennoch ergibt sich der Vorteil, dass Funktion und Bauteile in dieser Testphase sehr genau aufeinander abgestimmt werden

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9_5

112

5 Zusammenfassung

können. Schließlich folgt der Abnahmetest, bei dem Funktionen auf Prüfständen mit der finalen Hardware getestet werden. Es hat sich gezeigt, dass sich die Testphasen für die Unterstützung der Funktionsentwicklung durch Simulationen eignen. Aufbauend auf den vorgestellten Testphasen wurden geeignete Eigenschaften für Streckenmodelle klassifiziert, die auf die Anforderungen der unterschiedlichen Testanforderungen zugeschnitten worden sind. Die Klassifikation erfolgte auf Basis der Kriterien Echtzeitfähigkeit, Zeitpunkt der Verfügbarkeit im Entwicklungsprozess, Aufwand für die Modellerstellung und Integrationsfähigkeit bzgl. der Stabilität der Kopplung, vgl. Unterkapitel 4.5 und 4.12. Es wurde dargestellt, dass drei verschiedene Streckenmodelltypen für die Abdeckung aller Testphasen benötigt werden. Diese Testanforderungen werden in Form von Manövern für einzelne Module und Komponenten definiert. In der Einleitung dieser Arbeit wurde aufgezeigt, welche Herausforderungen bzgl. der Streckenmodelle bestehen, siehe Unterkapitel 1.2. Die in der Arbeit dargestellten Lösungsvorschläge werden im Folgenden kurz erläutert. Die Definition und Prüfung von Eigenschaften verschiedener Streckenmodelle gestaltet sich manuell sehr aufwändig, da verschiedene Schritte eingehalten und sichergestellt werden müssen. Aus diesem Grund wurden Werkzeuge entwickelt, die die Definition und Prüfung von Streckenmodelleigenschaften automatisiert durchführen. Allen Ein- und Ausgängen von Streckenmodellen werden Gültigkeitsbereiche in Form von Werteund Frequenzbereichen zugeordnet. Diese Gültigkeitsbereiche werden anhand von Manövern abgeleitet. Bei einer Anregung von Streckenmodellen im Gültigkeitsbereich lässt sich darauf aufbauend vor der operativen Verwendung untersuchen, wie sich Simulationsmodelle für benötigte Manöver verhalten. Für die Untersuchung des Verhaltens eines Modells wurde ein geeignetes Verfahren vorgestellt. Mit der Beziehung von Ausgängen einzelner Module zu Eingängen anderer Module im vernetzten Streckenmodellverbund werden darüber hinaus die numerischen Probleme bei der Kopplung behandelt. Ausgangssignale dürfen je nach Konfiguration des Testsystems nur in bestimmten Frequenzbereichen liegen. Die Informationen über die Frequenzbereiche von Ausgängen stammen jeweils von Eingängen anderer Streckenmodelle. Je nach Testphase müssen Kopplungssignale auch in einem bestimmten Frequenzbereich liegen, damit eine stabile Kopplung verwirklicht werden kann. Die Festlegung von Modellumfängen sorgt dafür, dass verschiedene Zustandsvariablen für unterschiedliche Modelle festgelegt werden können. Auf diese Weise lässt sich vermeiden, dass Streckenmodelle nicht alle benötigten Zustandsvariablen eines Realsystems abbilden. Außerdem werden keine zusätzlichen Zustandsvariablen in Streckenmodellen abgebildet, die der Modellnutzer ggf. nicht benötigt. Ein weiterer Lösungsvorschlag ist die Wiederverwendung von Modellen. Einerseits wurde dargestellt, wie Modelle auf PCs und Prüfständen wiederverwendet werden können. Anderseits gibt es je nach Testbedarf klassifizierte Modelle, d. h. Modelle eignen sich entweder nur für spezifische Manöver oder sie werden allgemeiner verwendet.

5 Zusammenfassung

113

Wenn alle Schritte eingehalten wurden, lässt sich ein automatisierter Modellaufbau verwirklichen, denn Modelle können z. B. als FMUs von verschiedenen Zulieferern automatisiert vernetzt werden, siehe Unterkapitel 4.5. Dies wurde im Rahmen der Arbeit anhand einer CoSimulationsplattform verwirklicht, da Algorithmen bestehen, um Ein- und Ausgänge verschiedener Module automatisiert zu vernetzen. Im Rahmen des Anwendungsbeispiels können Module verschiedener Zulieferer ausgetauscht werden. Anhand der Funktion DSR wurde die Praxistauglichkeit der vorgestellten Methode gezeigt. Die Ergebnisse wurden mithilfe von Fahrversuchen validiert, wobei die Methodik insbesondere für die Auslegungsmodelle zum Erfolg führt. Hier zeigt sich auch die Notwendigkeit der definierten Anforderungen an Streckenmodelle, denn je genauer Ergebnisse aus der Simulation den Fahrversuch reproduzieren, desto höher ist der Aufwand für die Parametrierung. Im folgenden Kapitel wird darauf eingegangen, inwiefern die Ziele der Arbeit erreicht werden konnten.

6 Fazit Nachdem in der Einleitung erläutert worden ist, welche Herausforderungen bei der aktuellen Entwicklung von Fahrfunktionen existieren, wurde in Abschnitt 1.3.2 dargestellt, welche Ziele sich darauf aufbauend für diese Arbeit ergeben. Das vorliegende Kapitel zeigt, inwiefern diese Ziele erreicht wurden. In erster Linie bestehen Herausforderungen in der Heterogenität. Diese bezieht sich auf die Testanforderungen im Entwicklungsprozess, die sich auch in den Simulationen widerspiegeln. Hierbei bestehen insbesondere Lücken zwischen Tests in der frühen und späten Phase der Funktionsentwicklung sowie zwischen verschiedenen Testmethoden. Die Testanforderungen wurden mithilfe der Testphasen strukturiert, wobei folgende Faktoren berücksichtigt wurden: die frühere und schnellere Fehlerbehebung, die verschiedene Funktionsreife, die unterschiedliche Genauigkeit von Simulationen, die Varianten beim Test und das komplexe Systemdenken statt den bisherigen bauteilorientierten Strukturen. Die Testphasen wurden mit Befragungen und praktischen Umsetzungen validiert. Mithilfe der Testphasen können schnellere Iterationsschleifen und agile Ansätze bei der Funktionsentwicklung verwirklicht werden, wie Abbildung 6.1 verdeutlicht.

6FKQHOOHUH ,WHUDWLRQVVFKOHLIHQ Abbildung 6.1: Testphasen ermöglichen schnellere Iterationsschleifen

Für die Durchführung der Testphasen werden geeignete Modelleigenschaften benötigt. Um eine möglichst geringe Anzahl von Modellen sicherzustellen, stehen die Wiederverwendung von Simulationsmodellen im Entwicklungsprozess und für verschiedene Tests in unterschiedlichen Abteilungen im Fokus. Die Auswahl der Streckenmodelltypen erfolgte anhand der Kriterien Echtzeitfähigkeit, Zeitpunkt der Verfügbarkeit im Entwicklungsprozess, Aufwand für die Modellerstellung und Integrationsfähigkeit bzgl. der Stabilität der Kopplung. Es konnte gezeigt werden, dass die Tests mithilfe von lediglich drei verschiedenen Streckenmodelltypen durchführbar sind.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9_6

116

6 Fazit

Eine Herausforderung bei der Systemsimulation besteht außerdem darin, dass die Kopplung von Modellen zu numerischen Problemen führen kann und Simulationsmodelle ggf. nicht für alle benötigten Anwendungsbereiche verwendbar sind. Um dies zu lösen, erhält jedes Streckenmodell feste Schnittstellen und definierte Werte- und Frequenzbereiche, damit vor der Modellerstellung definiert und anschließend getestet werden kann, ob sich ein Streckenmodell für einen bestimmten Test einer Fahrzeugfunktion eignet. Darüber hinaus können auf diese Weise In- und Outputs aufeinander abgestimmt werden. Die Art der Schnittstellen wird dahingehend geprüft, ob es zu numerischen Problemen bei der Kopplung kommt. Hierbei werden in den verschiedenen Testphasen verschiedene Empfehlungen zur Durchführung der Co-Simulation vorgeschlagen, die unterschiedliche Frequenzbereiche übertragen können. Die Werte- und Frequenzbereiche an Schnittstellen werden auf Basis von Manövern ermittelt. Ein weiteres Ziel besteht in einem geeigneten Vorgehen zur Beschreibung der Detaillierung von Modelleigenschaften. Um dies zu ermöglichen, werden Rollen und Prozesse benötigt. Streckenmodelle, die durch die Rolle eines Modellverwalters definiert und gepflegt werden, werden Genauigkeiten für Zustandsvariablen vorgegeben, die mit dem Realsystem über eine Messung verglichen werden können. Mithilfe des in der Arbeit entwickelten Testsystemkonfigurators können Zustandsvariablen automatisiert gepflegt werden. Eine geeignete Auswahl der Zustandsvariablen sowie dazu passende Schnittstellen zwischen Streckenmodellen ermöglichen darüber hinaus, dass nur die benötigten Teile eines Realsystems in geeigneter Detaillierung und Genauigkeit abgebildet werden müssen. Die entwickelte Methode soll dazu führen, dass der finanzielle und zeitliche Aufwand beim Aufbau von Simulationen deutlich reduziert wird. Um dies zu erreichen, wurden die durchzuführenden Schritte zur Definition von Testanforderungen, Schnittstellen und Modelleigenschaften bis zur Prüfung der Streckenmodelleigenschaften stark automatisiert. Der Testsystemkonfigurator verwaltet den Aufbau von Systemsimulationen. Für verschiedene Systemsimulationen werden alle benötigten Modelle mit deren Zustandsvariablen sowie Werte- und Frequenzbereichen zwischen Fachabteilungen und Funktionen im Entwicklungsprozess abgestimmt. Sobald die definierten Modelle vorliegen, können sie mithilfe des im Rahmen der Arbeit entwickelten Modellanalysewerkzeugs automatisiert getestet werden. Die Forschungsergebnisse dieser Arbeit liefern wichtige Erkenntnisse für eine effizientere Durchführung von Funktionstests in der Simulation. Zuvor bestand kein strukturiertes Vorgehen für die Definition und Prüfung von Streckenmodelleigenschaften im Entwicklungsprozess. Analog zur Softwareentwicklung in der Informatik wird in dieser Arbeit ein definierter Workflow für Simulationen mit der Beschreibung von Anforderungen, dem Design, dem Simulationsaufbau und den dazugehörigen Tests vorgestellt. Es folgt ein Ausblick mit weiteren Anwendungs- und Forschungsfeldern, die sich auf Basis der Forschungsergebnisse dieser Arbeit ergeben haben.

7 Ausblick Zunächst werden offene Fragestellungen bezüglich der direkten Anwendung der Forschungsergebnisse im Entwicklungsprozess beleuchtet. Anschließend werden neue Forschungsgebiete für mögliche weitere Arbeiten dargestellt, die sich aus den gewonnen Erkenntnissen dieser Arbeit ergeben haben. Das Anwendungsbeispiel anhand der Funktion DSR erfolgte in einem Fahrzeugprojekt, das zum Zeitpunkt der Umsetzung der Methode bereits fertig entwickelt war. Es standen daher genügend Fahrzeuge für die Validierung von Simulationen zur Verfügung. Außerdem waren benötigte Konstruktionsdaten für den Modellaufbau bereits verfügbar. Für die Umsetzung der Forschungsergebnisse in einem neuen Fahrzeugprojekt werden testphasenspezifische Prozesse für die Datenbeschaffung benötigt. Einerseits sind Abstimmungsrunden notwendig, in denen deutlich wird, welche Daten für die Erfüllung von Zustandsvariablen für eine Testphase benötigt werden. Andererseits muss abgestimmt werden, wer die Daten zur Verfügung stellt und wann sie in welchem Format an einen Modellersteller weitergegeben werden. Denkbar sind z. B. spezifische Termine für die Datenbereitstellung vor Integrationsstufen, die funktionsspezifisch abgestimmt werden müssen. Ein weiterer offener Punkt stellt die benötigte Genauigkeit von Zustandsvariablen dar, damit Fahrversuche oder Prototypen eingespart werden können. In Abbildung 7.1 ist ein mögliches Baukasten

Hut 1

Hut 2

Hut 3

Hut n

…

Versuch

X

X X …

Simulation

Übereinstimmung von Simulation und Versuch

9DOLGLHUXQJ der Methode

Reduktion von Varianten im Versuch

Nur noch Hauptvarianten im Versuch

Abbildung 7.1: Einsatz der Simulation im Entwicklungsprozess

Vorgehen dargestellt, wie sich dessen angenähert werden kann. Hierbei werden für die Entwicklung eines Baukastens und der ersten Hüte alle Versuche und Simulationen parallel durchgeführt. Nachdem die Methode validiert worden ist, können in darauffolgenden Hüten Versuche eingespart werden. Wie groß Abweichungen zwischen Simulation und Versuch sein dürfen und

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9_7

118

7 Ausblick

wie genau Zustandsvariablen dafür sein müssen, muss funktionsspezifisch festgelegt werden. Allgemeine Ansätze wie eine fest definierte prozentuale Abweichung für alle Funktionen sind hier zu diesem Zeitpunkt nicht möglich, da die benötigte Übereinstimmung davon abhängt, wie reproduzierbar ein Manöver im Fahrversuch ist und wie genau eine Simulation einen Fahrversuch abbilden muss. Allgemein kann dabei die in Unterkapitel 3.4.4 vorgestellte prozentuale Abweichung als Metrik für den Vergleich zwischen Simulation und Fahrversuch verwendet werden. Weitere Aktivitäten könnten zukünftig so weit gehen, dass Funktionen mithilfe von Simulationen freigegeben werden. Ein weiterer Aspekt ist das Variantenmanagement von Tests. Es sollte festgelegt werden, welche Testfälle sowohl im Fahrversuch als auch in SiL- und in HiL-Umgebungen durchgeführt werden. Es folgt die Darstellung weiterer offener Arbeitsgebiete im Kontext von virtuellen Steuergerätetests. Der Inhalt dieser Arbeit basiert auf Modelleigenschaften im Fahrzeug mit signalorientiertem Datenaustausch. Zukünftig werden zunehmend Services und mobile Dienste im Fahrzeug umgesetzt, die ggf. über das Internet upgedatet werden können, vgl. [55]. Für den Bereich der Umfeldsimulation stellt sich in Bezug auf das autonome oder automatisierte Fahren die Frage nach einer geeigneten Abstraktion von z. B. Kamera- und Radarsensoren für die Erfassung der Umgebung. Hier besteht Forschungsbedarf, um zu untersuchen, ob das vorgestellte Konzept ebenfalls umsetzbar sind. Es existieren neben Zustandsvariablen wie Abtastungseigenschaften eines Sensors beispielsweise auch Einflüsse des Wetters oder Reflexionen. Für fahrzeugübergreifende Funktionen sind zudem Netzwerksimulationen und die Abstraktion des Umfelds mit anderen Fahrzeugen erforderlich. Für solche eventbasierten Simulationen, die mithilfe von Objektlisten kommunizieren, besteht ebenfalls Forschungsbedarf für Validierungskonzepte zwischen Simulationen und Fahrversuch. Für eine schnellere Lieferung von Steuergerätecodes gilt es zukünftig, geeignete Prozesse für die Generierung und den Austausch von SiL-Komponenten zu etablieren. Darauf aufbauend könnten Continuous Integration-Methoden verwirklicht werden. Dabei besteht das Ziel, die Simulationen bei neuen Softwareständen automatisiert auf virtuellen Maschinen oder Dockern durchzuführen. Docker bieten gegenüber virtuellen Maschinen eine skalierbarere Architektur, da die Software stärker vom Betriebssystem entkoppelt wird, vgl. [41]. Mithilfe dieser Methoden könnten die Tests deutlich schneller und zudem parallel durchgeführt werden. Für vernetzte, agilentwickelte Funktionen wäre es zudem denkbar, dass Zulieferer Zugang zu solchen Testumgebungen bekommen. Auf diese Weise ließe sich der gesamte Steuergerätecode direkt in einer Umgebung entwickeln und kontinuierlich testen. Zusätzlicher Forschungsbedarf besteht im Bereich der Testfallgenerierung. Im aktuellen Entwicklungsprozess von Software werden üblicherweise aus Anforderungen Tests abgeleitet. In der vorgestellten Methode werden darauf aufbauend testphasenspezifische Anforderungen146 an eine Simulationsumgebung gestellt, um daraus geeignete Gültigkeitsbereiche von Streckenmodellen definieren zu können. Problematisch ist, dass im Kontext von automatisierten Fahrfunktionen zukünftig nicht alle Anforderungen und Eingriffssituationen im Vorfeld bekannt sind. Hier besteht daher Forschungspotential für stochastisch generierte Tests. Ferner ist denkbar, dass Daten von fahrenden Fahrzeugen auf der Straße in virtuelle Testfahrten integriert werden. Für vorher 146

Z. B. welche Manöver mit einer Modellvernetzung simuliert werden sollen.

7 Ausblick

119

unbekannte Anforderungen müssten relevante Eigenschaften im Nachhinein an Modellersteller weitergegeben werden, um sicherzustellen, dass die Durchführbarkeit von Tests gewährleistet wird. Bereits heute bieten Simulationen für Steuergerätetests einen großen Mehrwert und das Gebiet wird sich in den nächsten Jahren wohl stark weiterentwickeln. Für die Tests von automatisierten Fahrfunktionen ist es unerlässlich, das virtuelle Fahrzeug in geeigneter Form abzubilden. Diese Arbeit leistet einen Beitrag, dass die dafür benötigten Streckenmodelle strukturiert beschrieben, erstellt und getestet werden.

Literaturverzeichnis [1]

ACOSAR Website. – http://www.acosar.eu/, Abruf: 27.02.2017

[2]

Association for Standardization of Automation and Measuring Systems. – https://www. asam.net/, Abruf: 06.05.2014

[3]

AUTOSAR Spezifikation. – http://www.autosar.org/, Abruf: 05.05.2014

[4]

Norm DIN 53 804 . DIN 53 804 Teil 1, Statistische Auswertungen - Meßbare (kontinuierliche) Merkmale. Abs. 8.2 Ausreißertest nach Grubbs

[5]

FMI Support in Tools - Compatibility Table. – https://www.fmi-standard.org/tools, Abruf: 17.07.20117

[6]

Functional Mock-up Interface for Model Exchange and Co-Simulation, Dokument Version 2.0. – https://www.fmi-standard.org/downloads, Abruf: 15.07.2014

[7]

GRAL - GRAphing Library. – http://trac.erichseifert.de/gral/, Abruf: 01.02.2017

[8]

Norm IEEE 1588 . IEEE 1588TM Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems

[9]

Norm IEEE 802 . IEEE 802 standards

[10] Norm IEEE 1278 . IEEE Standard for Distributed Interactive Simulation–Application Protocols [11] Norm IEEE 1516-2010 . IEEE Standard for Modeling and Simulation (M & S) High Level Architecture (HLA) – Framework and Rules [12] Norm IEC 61158-3/4/5/6-12 . Industrial communication networks – Fieldbus specifications – Part 3-12: Data-link layer service definition – Part 4-12: Data-link layer protocol specification – Part 5-12: Application layer service definition – Part 6-12: Application layer protocol specification – Type 12 elements (EtherCAT) [13] MODELISAR. – https://itea3.org/project/modelisar.html, Abruf: 01.09.2016 [14] Package javax.swing - Provides a set of lightweight (all-Java language) components that, to the maximum degree possible, work the same on all platforms. – https://docs.oracle.com/javase/7/docs/api/javax/swing/package-summary.html, Abruf: 01.02.2017 [15] Package org.apache.commons.math3.transform Implementations of transform methods, including Fast Fourier transforms. – http://commons.apache.org/proper/commons-math/ javadocs/api-3.4/org/apache/commons/math3/transform/package-summary.html, Abruf: 01.02.2017

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9

122

Literaturverzeichnis

[16] PEAK Systems Website. – http://www.peak-system.com/PCAN-USB.199.0.html, Abruf: 27.02.2017 [17] Norm ISO 9000:2005 . Qualitätsmanagement [18] Norm ISO 11898-4 . Road vehicles – Controller area network (CAN) – Part 4: Timetriggered communication [19] Norm ISO 26262 . Road vehicles – Functional safety [20] A simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. – http://junit.org/junit4/, Abruf: 01.02.2017 [21] Norm ISO/IEC 15504-5 . SPICE (Software Process Improvement and Capability Determination) [22] VN1600 - Flexible, kosteneffiziente Bus-Interfaces mit USB-Schnittstelle für CAN, CAN FD, LIN, K-Line, J1708 und IO. – https://vector.com/vi_vn1600_de.html, Abruf: 27.02.2017 [23] Norm DIN 44300-6:1985-10 1985. Informationsverarbeitung; Begriffe; Speicherung [24] A DAMSKI, D. : Simulation in der Fahrwerktechnik. Springer Fachmedien Wiesbaden, 2014 [25] A RISTOTELES: Verkürztes Zitat aus Metaphysik VII 17, 1041b Fahrerassistenzsteuergerät. – http://www.audi.de/de_vdt_ [26] AUDI AG: content_entry/brand/de/vorsprung_durch_technik/content/2014/10/zentrales-f ahrerassistenzsteuergeraet-zfas.html, Abruf: 02.01.2015 [27] AUTOSAR: Technical Overview. – http://www.autosar.org/index.php?p=1&up=2&uup= 0&uuup=0&uuuup=0&uuuuup=0, Abruf: 05.05.2014 [28] BALCI, S. : Entwicklung einer Methodik für die Validierung von Simulationsmodellen im Kontext der virtuellen Fahrzeugabsicherung. Masterarbeit, Leibniz Universität Hannover, 2017 [29] BARTELT, C. ; BAUER, O. ; B ENEKEN, G. ; B ERGNER, K. ; B IROWICZ, U. ; B LISS, T. ; C ORDES, N. ; C RUZ, D. ; D OHRMANN, P. ; F RIEDRICH, J. ; G NATZ, M. ; H AMMER SCHALL, U. ; H IDVEGI -BARSTORFER , I. ; H UMMEL, H. ; I SRAEL, D. ; K LINGENBERG, T. ; K LUGSEDER, K. ; K ÜFFER, I. ; K UHRMANN, M. ; K RANZ, M. ; K RANZ, W. ; M EINHARDT, H.-J. ; M EISINGER, M. ; M ITTRACH, S. ; N EUSSER, H.-J. ; N IEBUHR, D. ; P LÖGERT, K. ; R AUH, D. ; R AUSCH, A. ; R ITTEL, T. ; RÖSCH, W. ; S AAS, E. ; S CHRAMM, J. ; S IHLING, M. ; T ERNITÉ, T. ; VOGEL, S. ; W ITTMANN, M. : V-Modell XT - Das deutsche Referenzmodell für Systementwicklungsprojekte Version: 2.0. 2006 [30] B ENEDIKT, M. : ICOS Independent Co-Simulation. 2017. – http://www.v2c2.at/de/icos/, Abruf: 30.05.2017

Literaturverzeichnis

123

[31] B ENEDIKT, M. ; WATZENIG, D. ; Z EHETNER, J. ; H OFER, A. : Macro-step-size selection and monitoring of the coupling error for weak coupled subsystems in the frequencydomain. V International Conference on Computational Methods for Coupled Problems in Science and Engineering, 2013 [32] B ENEDIKT, M. ; WATZENIG, D. ; Z EHETNER, J. ; H OFER, A. : Modelling and analysis of the non-iterative coupling process for co-simulation. Mathematical and Computer Modelling of Dynamical Systems: Methods, Tools and Applications in Engineering and Related Sciences, 19:5, 451-470, DOI: 10.1080/13873954.2013.784340, Ibiza, Spain, 2013 [33] B ENEDIKT, M. ; WATZENIG, D. ; Z EHETNER, J. ; H OFER, A. : NEPCE - A nearly energy preserving coupling element for weak-coupled problems and co-simulations. V International Conference on Computational Methods for Coupled Problems in Science and Engineering, Ibiza, Spain, 2013 [34] B ENEDIKT, M. ; Z EHETNER, J. ; S TETTINGER, G. ; W IERSE, M. ; KOKAL, H. : Modellbasierte Kopplung zur Lösung des Echtzeit-Co-Simulationsproblems. 17. Kongress, SIMVEC – Simulation und Erprobung in der Fahrzeugentwicklung 2014, VDI-Berichte 224, 2014 [35] B ENKER, H. : Differentialgleichungen mit MATHCAD und MATLAB. Springer-Verlag, Berlin / Heidelberg / New York, 2005 [36] B RAUN, T. : Zuverlässige modusbasierte Kommunikation und Virtual Prototyping in der Entwicklung verteilter Echtzeitsysteme. University of Kaiserslautern, 2016 [37] B RÜCKNER, C. ; S WYNNERTON, B. : Busbasiertes Architekturkonzept für Hardware-inthe-Loop-Prüfstände. ATZ Elektronik, 2014 Elektronik und Software beherrschen Innovationen [38] B RÜNGLINGHAUS, C. : im Auto. 2014. – https://www.springerprofessional.de/automobilelektronik— software/antriebsstrang/elektronik-und-software-beherrschen-innovationen-imauto/6561802, Abruf: 15.05.2017 [39] B UCHHOLZ, P. : Modellgestützte Analyse und Optimierung. 2007. – http://ls4www.cs.tu-dortmund.de/Lehre/07-41127.html, Validierung von Modellen (Kapitel 8), Abruf: 04.03.2018 [40] B USCH, M. : Zur effizienten Kopplung von Simulationsprogrammen. Kassel University Press, 2012 [41] C ARVALHO, L. ; M ARDEN, M. : The Business Value of Red Hat OpenShift. 2016. – https://www.redhat.com/cms/managed-files/cl-business-value-of-red-hat-openshiftanalyst-paper-inc0461277lw-201611-en.pdf, Abruf: 09.05.2017 [42] C HIAS T EK S ALES: CosiMate - Heterogeneous co-simulation in distributed environments. 2017. – http://site.cosimate.com/files/CosiMate_Brochure.pdf, Abruf: 30.05.2017 [43] C OSIN S CIENTIFIC S OFTWARE: FTire Flexible Structure Tire Model. 2017

124

Literaturverzeichnis

[44] DAS V IRTUELLE FAHRZEUG F ORSCHUNGSGESELLSCHAFT: ICOS Independent CoSimulation - User Manual. 2015. – Version 3.2 [45] D IETRICH, B. : Funktionsorientierte Entwicklung schafft Transparenz und stellt perfektes Zusammenspiel aller Komponenten sicher. ElektronikPraxis, 2009. – http://www.elektronikpraxis.vogel.de/themen/elektronikmanagement/projektqualitaetsm anagement/articles/169542/, Abruf: 25.08.2018 [46] D ÜSER, T. : X-in-the-Loop – ein durchgängiges Validierungsframework für die Fahrzeugentwicklung am Beispiel von Antriebsstrangfunktionen und Fahrerassistenzsystemen. Karlsruher Institut für Technologie (KIT); Institut für Produktentwicklung, 2010 [47]

D SPACE G MB H: DS1006 Processor Board. 2017. – https://www.dspace.com/shared/ data/pdf/2017/dSPACE_DS1006_Catalog2017_E.pdf, Abruf: 21.04.2017

[48] E LEKTROBIT AUTOMOTIVE G MB H: Driver assistance software EB Assist solutions. November 2015. – https://d23rjziej2pu9i.cloudfront.net/wp-content/uploads/ 2015/12/14161006/Productbrochure_Driver-Assistance_Software_2015_12.pdf, Abruf: 21.04.2017 [49] F ILLER, T. ; S OPPA, A. ; S ZCZERBICKA, H. : Efficient Control Design and Application with Co-Simulation and the FMI standard. European Control Conference, 2015 [50] F ILLER, T. : Analyse der virtuellen Steuergeräteabsicherung auf Basis des FMI Standards. Masterarbeit, Leibniz Universität Hannover, 2014 [51] F ILLER, T. ; BALS, C. ; S OPPA, A. : Usage of FMI at Audi and Volkswagen. In: FMI User Meeting, Modelica Conference, September 2015 [52] F ILLER, T. ; S CHULZ, T. ; S OPPA, A. ; S ZCZERBICKA, H. : Integrationsmethodik für Simulationsmodelle beim vernetzten Steuergerätetest. In: Simulation und Erprobung in der Fahrzeugentwicklung 2016, 18. Kongress, SIMVEC – Simulation und Erprobung in der Fahrzeugentwicklung 2016, VDI-Berichte 2279, November 2016 [53] F ILLER, T. ; S OPPA, A. ; S ZCZERBICKA, H. : Gesamtfahrzeugsimulation auf Basis des FMI Standards. In: Dynamisches Gesamtsystemverhalten von Fahrzeugantrieben, Haus der Technik e.V., März 2015 [54] F RIEDEMANN, D. : Prognose zur Einsatzfähigkeit von Mehrkörpersimulationsmethoden im Fahrwerksentwicklungsprozess. Universitätsbibliothek der Technischen Universität Berlin, 2012 [55] F ÜRST, S. : The AUTOSAR Adaptive Platform for Connected and Autonomous Vehicles. – https://vector.com/congress/files/presentations/VeCo16_06_29Nov_Reithalle_Fuerst_ BMW.pdf, Abruf: 05.05.2017 [56] G EIMER, M. ; K RÜGER, T. ; L INSEL, P. : Co-Simulation, gekoppelte Simulation oder Simulatorkopplung? Ein Versuch der Begriffsvereinheitlichung. O + P Zeitschrift, 2006

Literaturverzeichnis

125

[57] G ENE S YS E LEKTRONIK G MBH: ADMA Automotive Dynamic Motion Analyzer mit 1000 Hz. – http://www.genesys-offenburg.de/produkte/adma-familie-gpsinertialsystemautomotivebahn/adma-g-proplus/, Abruf: 09.03.2017 [58] G LOSS, S. ; S LEZÁK, M. ; PATZER, A. : Virtualisation - Validation of over 200 Transmission Variants on PC. 2013 [59] G OMES, C. ; T HULE, C. ; B ROMAN, D. ; L ARSEN, P. ; VANGHELUWE, H. : Co-simulation: State of the art. 2017. – http://arXiv.org, Abruf: 05.02.2018 [60] G ROSS, D. : Report from the Fidelity Implementation Study Group. 1999 [61] H AYHURST, K. ; D., V. ; C HILENSKI, J. ; R IERSON, L. : A Practical Tutorial on Modified Condition/Decision Coverage. – https://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001tm210876-MCDC.pdf, Abruf: 14.03.2017 [62] H EISSING, B. ; E RSOY, M. ; G IES, S. : Fahrwerkhandbuch. Springer Fachmedien Wiesbaden, 2013 (ATZ/MTZ-Fachbuch) [63] H ILLENBRAND, M. : Funktionale Sicherheit nach ISO 26262 in der Konzeptphase der Entwicklung von Elektrik / Elektronik Architekturen von Fahrzeugen. KIT Scientific Publishing, 2012 [64] H OAGG, J. B. ; L ACY, S. L. ; BABUSKA, V. : Sequential multisine excitation signals for system identification of large space structures. In: American Control Conference (2006) [65] H UBER, K. ; P., A. ; S TROPEK, R. : Bug Busters - Test Driven Development in .NET. (2008). – http://www.software-architects.com/devblog/2008/03/15/Bug-Busters—TestDriven-Development-in-NET, Abruf: 01.02.2017 [66] J UNGHANNS, D. A. ; S ERWAY, R. ; L IEBEZEIT, D. T. ; B ONIN, M. : Building virtual ecus quickly and economically. ATZ Elektronik, 2012 [67] K ÜMMEKE, H. : Blockschaltbild erweiterter Regelkreis. Lizenziert unter CC BY-SA 3.0 über Wikimedia Commons, 2015. – https://commons.wikimedia.org/wiki/File: Blockschaltbild_erweiterter_regelkreis.gif#/media/File:Blockschaltbild_erweiterter_ regelkreis.gif, Abruf: 24.03.2019 [68] KOOMEN, T. ; A ALST, L. van d. ; B ROEKMAN, B. ; V ROON, M. : TMap Next, for result-driven testing. UTN Publishers, 2006 [69] K RDZALIC, D. G. ; D RISS, A. : Software-Architektur ohne Autosar Verallgemeinerte Schablone für Embedded-Systeme. Springer Automotive Media, 2014 [70] K UMAR, S. ; R AI, S. : Survey on Transport Layer Protocols: TCP & UDP. International Journal of Computer Applications, 2012 [71] L ANGNER, F. ; A LSMANN, D. U. ; M EYER, J. : Fahrversuch versus HiL-Test. Juni 2008. – http://www.elektroniknet.de/elektronik-automotive/software-tools/fahrversuch-versushil-test-911.html, Abruf: 02.08.2017

126

Literaturverzeichnis

[72] L EHMANN, E. : Time Partition Testing - | Systematischer Test des kontinuierlichen Verhaltens von eingebetteten Systemen. Technische Universität Berlin, 2004 [73] L INDLAR, F. : Modellbasierter evolutionärer Funktionstest. Berlin Institute of Technology, 2012. – http://dx.doi.org/10.14279/depositonce-3232, Abruf: 07.10.2016 [74] L ÜKE, H. D.: The Origins of the Sampling Theorem, IEEE Communications Magazine. IEEE Communications Magazine, 1999 [75] M ATH W ORKS , I NC .: Identifizieren von Entwurfsfehlern, Generieren von Testfällen und Verifizieren von Entwürfen anhand der Anforderungen. – https://de.mathworks.com /products/sldesignverifier.html, Abruf: 01.03.2017 [76] M ATH W ORKS , I NC .: Modellierung und Simulation von Entscheidungslogiken mit Hilfe von Zustandsautomaten und Flussdiagrammen. – https://de.mathworks.com/products/ stateflow.html, Abruf: 01.03.2017 [77] M ATH W ORKS , I NC .: S-Function Callback Methods. – http://www.mathworks.de/de/ help/simulink/sfg/s-function-callback-methods.html, Abruf: 05.05.2014 [78] M AUSS, J. ; S IMONS, M. : Steuergeräte-Simulation auf PC mittels TriCore-Emulation. ATZ Elektronik, 2012 [79] M AUSS, J. : Virtual ECUs for Automotive Development. Modelon FMI Tag, 2014 [80] M ICRO N OVA AG: Gemeinsam fit für die Zukunft. 2016. – http://www.micronova.de/ fileadmin/files/pdf/testing/Testing_Kompendium_2016.pdf, Abruf: 21.04.2017 [81] M IEGLER, M. : Continuous Integration “Komplexität beherrschen Risiken minimieren“. Workshop Automotive Software Engineering, 2016 [82] O BJECT M ANAGEMENT G ROUP: Data Distribution Service. April 2015 [83] O RACLE C ORPORATION: Package javax.xml.bind - Provides a runtime binding framework for client applications including unmarshalling, marshalling, and validation capabilities.. – http://docs.oracle.com/javaee/5/api/javax/xml/bind/package-summary.html, Abruf: 01.02.2017 [84] PAPULA, L. : Mathematik für Ingenieure und Naturwissenschaftler Band 2. Viewegs Fachbücher der Technik, Wiesbaden, 2001 [85] PATZER, A. ; Z AISER, R. : XCP – Das Standardprotokoll für die Steuergeräte-Entwicklung - Grundlagen und Einsatzgebiete. Stuttgart : Vector, 2013 [86] P INNOW, K. : AUTOSAR-Software mit ASCET. 2009 [87] P LEXIM G MB H: Entwicklung, Analyse und Validierung von Regelalgorithmen auf der Zielhardware. – https://www.plexim.com/de/plecs/pil, Abruf: 01.08.2016 [88] P ONN, J. ; L INDEMANN, U. : Konzeptentwicklung und Gestaltung technischer Produkte. Springer-Verlag Berlin Heidelberg, 2008

Literaturverzeichnis

127

[89] P ROFF, H. : Entscheidungen beim Übergang in die Elektromobilität. Springer Fachmedien Wiesbaden, 2015 [90] R EIF, K. : Bosch Autoelektrik und Autoelektronik: Bordnetze, Sensoren und elektrische Systeme, 6. Auflage. Vieweg+Teubner Verlag, 2011 [91] R EINER, J. ; M EYER, J. : Evolutionäres Testen von Steuergeräten. (2010), Oktober. – http://www.elektroniknet.de/automotive/tools/artikel/30047/, Abruf: 07.10.2016 [92] ROLFSMEIER, A. ; G RASCHE, C. : Funktionsentwicklung für moderne Fahrerassistenzsysteme. Automobil-Elektronik, 2010 [93] S ALTELLI, A. ; TARANTOLA, S. ; C HAN, K.-S. : A quantitative model independent method for global sensitivity analysis of model output. . – In: Technometrics 41 (1999), S.39–56 [94] S CHÄUFFELE, J. ; Z URAWKA, T. : Automotive Software Engineering: Grundlagen, Prozesse, Methoden und Werkzeuge effizient einsetzen. Springer Fachmedien Wiesbaden, 2016 (ATZ/MTZ-Fachbuch). – https://books.google.de/books?id=FrbmDAAAQBAJ, Abruf: 26.08.2018 [95] S CHIERBAUM, T. ; A NACKER, H. ; G AUSEMEIER, J. : Formalisierte Anforderungen in der Entwicklung mechatronischer Systeme. In: Tag des Systems Engineering (TdSE), 8.-9. Nov., Paderborn, Germany, 2014 [96] S CHUERMANS, R. ; K UNZ, H.-G. ; A MSBECK, H. ; K ELLERS, B. ; RUOFF, B. ; M OTZ, R. ; F ORWICK, D. : The Universal Measurement and Calibration Protocol Family 1.1.0. ASAM e. V., 2008 [97] S CHULZ, T. : Entwicklung eines Werkzeugs zur Analyse von Modellen zur Ankopplung in Simulationsumgebungen. Masterarbeit, Leibniz Universität Hannover, 2016 [98] S HAMPINE, L. F. ; R EICHELT, M. W.: The MATLAB ODE Suite. SIAM Journal on Scientific Computing, 1997 R Automotive - Test Process Improvement (Deut[99] S OGETI D EUTSCHLAND G MB H: TPI sche Übersetzung) Version: 1.01. (2006)

[100] S ZCZERBICKA, H. : Modellierung des dynamischen Verhalten von Systemen. 2016. – https://www.sim.uni-hannover.de/de/Modellierung-des-dynamischen-Verhaltens-vonSystemen/modellierung_ws14.html, Abruf: 02.08.2017 [101] TESIS DYNAWARE G MB H: ve-DYNA Suspension Analysis Toolbox. 2013. – https://www.tesis-dynaware.com/en/products/vedyna/add-ons/suspension-toolbox.html, Abruf: 23.02.2017 [102] TLK-T HERMO G MB H: TISC Suite - Connects Simulation Tools. – https://www.tlkthermo.com/index.php/de/tisc-suite, Abruf: 30.05.2017 [103] T RAUTMANN, M. : Grundlagen der Fahrzeugmechatronik. Vieweg+Teubner Verlag, 2009

128

Literaturverzeichnis

R Prozes[104] VDA - V ERBAND DER AUTOMOBILINDUSTRIE: Automotive SPICE sassessment. – http://www.automotivespice.com/fileadmin/software-download/Autom otiveSPICE_PAM_v23_DE.pdf, Abruf: 27.04.2017

[105] VI- GRADE G MB H: VI-CarRealTime. 2013. – https://www.vi-grade.com/en/products/ vi-carrealtime/, Abruf: 24.03.2019 [106] VOLKSWAGEN A KTIENGESELLSCHAFT: Baukastenprinzip - Vielfalt durch einheitliche Standards. Verlag Rommerskirchen GmbH & Co. KG, 2012 [107] W EGENER, J. : Evolutionärer Test des Zeitvehaltens von Realzeit-Systemen. Shaker Verlag, 2001 [108] W EILKIENS, T. : Systems Engineering mit SysML/UML. dpunkt.verlag GmbH, 2006 [109] W ICKERT, S. ; S ANDMANN, W. : Zündung aus, Motor aus, alle Anzeigen auf Anfang – Ist das wirklich so? ETAS RealTimes magazine, 2005 [110] W INNER, H. ; H AKULI, S. ; L OTZ, F. ; S INGER, C. : Handbuch Fahrerassistenzsysteme. Springer Fachmedien Wiesbaden, 2015 (ATZ/MTZ-Fachbuch) [111] W ITTIG, K.-J. : Qualitätsmanagement in der Praxis. Vieweg+Teubner Verlag, 1993 [112] W OLF, H. : Ergonomische Untersuchung des Lenkgefühls an Personenkraftwagen. Südwestdeutscher Verlag für Hochschulschriften, 2009 [113] W ÖRN, H. : Echtzeitsysteme: Grundlagen, Funktionsweisen, Anwendungen. SpringerVerlag, 2006 [114] Z IMMER, M. : Durchgängiger Simulationsprozess zur Effizienzsteigerung und Reifegraderhöhung von Konzeptbewertungen in der Frühen Phase der Produktentstehung. Springer Vieweg, 2015 [115] Z IMMERMANN, K. ; S CHMIDGALL, R. : Bussysteme in der Fahrzeugtechnik, ATZ/MTZFachbuch. Springer Fachmedien Wiesbaden, 2010

Anhang Modelleigenschaften.txt aus Textdatei 1

V a r i a n t e n m o d e l l f ü r Modul Bremse

2 3 4 5 6 7

I n p u t : B r e m s d r u c k E i n h e i t : Bar M i n i m a l e r Wert : 0 . 0 M a x i m a l e r Wert : 2 0 0 . 0 Minimale Frequenz : 0 . 0 Maximale F r e q u e n z : 0 . 0 6 1 0 3 5 1 5 6 2 5

8 9 10 11 12 13

I n p u t : Q u e r b e s c h l e u n i g u n g E i n h e i t : m/ s ^2 M i n i m a l e r Wert : −2.0 M a x i m a l e r Wert : 2 . 0 Minimale Frequenz : 0 . 0 Maximale F r e q u e n z : 0 . 0 4 5 7 7 6 3 6 7 1 8 7 5

14 15 16 17 18 19

I n p u t : R a d d r e h z a h l V L E i n h e i t : kmh M i n i m a l e r Wert : 0 . 0 M a x i m a l e r Wert : 1 0 0 . 0 Minimale Frequenz : 0 . 0 Maximale F r e q u e n z : 0 . 0 4 5 7 7 6 3 6 7 1 8 7 5

20 21 22 23 24 25

I n p u t : RaddrehzahlVR E i n h e i t : kmh M i n i m a l e r Wert : 0 . 0 M a x i m a l e r Wert : 1 0 0 . 0 Minimale Frequenz : 0 . 0 Maximale F r e q u e n z : 0 . 0 4 5 7 7 6 3 6 7 1 8 7 5

26 27 28 29 30 31

I n p u t : RaddrehzahlHR E i n h e i t : kmh M i n i m a l e r Wert : 0 . 0 M a x i m a l e r Wert : 1 0 0 . 0 Minimale Frequenz : 0 . 0 Maximale F r e q u e n z : 0 . 0 4 5 7 7 6 3 6 7 1 8 7 5

32 33 34 35 36 37

I n p u t : R a d d r e h z a h l H L E i n h e i t : kmh M i n i m a l e r Wert : 0 . 0 M a x i m a l e r Wert : 1 0 0 . 0 Minimale Frequenz : 0 . 0 Maximale F r e q u e n z : 0 . 0 4 5 7 7 6 3 6 7 1 8 7 5

38

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2019 T. Filler, Entwicklung einer Methodik für die durchgängige Integration von Hardware und Softwaremodellen in Simulationen für Fahrfunktionen, AutoUni – Schriftenreihe 139, https://doi.org/10.1007/978-3-658-26308-9

130

39

Anhang

Zustandsvariable : Bremszylinder

40 41 42

V o r a p p l i k a t i o n s m o d e l l V o r a p p l i k a t i o n −DSR_Mue_Split−Bremse f ü r Modul Bremse

43 44 45 46 47 48 49 50 51 52 53 54

I n p u t : B r e m s d r u c k E i n h e i t : Bar Zielwert 200.0 Zielzeit 2.0 Zurückgehzeit 8.0 Rückkehrzeit 15.0 Pause 5.0

~ ~

Output

Cloneable

~ ~

1

Input

0..*

1

addManeuver(String): Maneuver compareManeuvers(Maneuver): boolean XSGDWH$OO3ODQW0RGHOV$QG0RGHO/LQNDJHV YRLG XSGDWH0RGHO/LQNDJHV0DQHXYHU6WULQJ>@

+ + + +

1..*

maneuvers: Vector modelLinkages: Vector testPh: testPhase uniqueName: String

Function

-

-inp

1

0..*

addInput(String): Input addOutput(String): Output addPlantModel(PlantModel): PlantModel addStateVariable(String): String

+ + + +

1 +

0..*

Module inputs: Vector outputs: Vector plantmodels: Vector stateVariables: Vector uniqueName: String

~ ~ ~ ~ ~

max: double maxFrequency: double min: double minFrequency: double pause: boolean phase: boolean ReleaseTargetTime: boolean ReturnTime: boolean sineType: boolean startValue: boolean targetTime: boolean targetValue: boolean uniqueName: String unit: String

uniqueName: String unit: String

class 76.

addInput(Input): InputDescription

inputs: Vector testP: testPhase uniqueName: String

Maneuv er

addFunction(String): Function addModelLinkage(String): ModelLinkage addModule(String): Module FUHDWH0RGHO/LVW)LOH YRLG

+ + + +

1..*

0..*

functionList: Vector modelLinkages: Vector modules: Vector

-

TestSystemModel

0..*

0..*

1..*

PlantModel

1..*

addStateVariable(String): String

inputs: Vector modul: String outputs: Vector stateVariables: Vector typeOfModel: int uniqueName: String

Observable

+

1 -

+ + +

+

1 -

1..*

1

-

0..* ModelLinkage

updateMinMaxAndFrequencies(): void

inp: String pause: double phase: double ReleaseTargetTime: double ReturnTime: double sineType: double startValue: double targetTime: double targetValue: double

InputDescription

addFunction(Function): Function checkPlausibility(): boolean getTestPhase(): testPhase

functionlist: Vector plantModels: Vector testPh: testPhase uniqueName: String

1..*

0..*

1..*

Anhang 131

TSK-Klassendiagramm

132

Anhang

Im oben gezeigten TSK-Klassendiagramm sind die wichtigsten Klassen des TSKs in einem UMLDiagramm dargestellt, wobei die Klassen View und Controller an dieser Stelle nicht erläutert werden, da sich die Algorithmen nur im Model befinden. Die Klasse TestSystemModel speichert und verwaltet alle Konfigurationen für Fahrzeuge, die mithilfe von .xml-Dateien gespeichert und geladen werden können. In einer Instanz eines TestSystemModels werden Funktionslisten, Modellvernetzungen und Module verwaltet. Module verfügen jeweils über eine Liste von Inputs, Outputs und Zustandsvariablen. Die Inund Outputs von Modulen werden direkt als Vektor gespeichert. Identifiziert werden Elemente mithilfe eines festen Namens. Wenn ein neuer In- oder Output hinzugefügt werden soll, wird zuvor geprüft, ob sich bereits ein Element mit gleichem Namen in der Liste befindet. Verfügbare Zustandsvariablen eines Moduls werden mithilfe einer Liste von Strings verwaltet, wobei die verfügbaren Variablen vom Modellverwalter vorgegeben werden. Objekte der Klasse Output haben lediglich einen Namen und eine Einheit. Die Werte und Frequenzbereiche ergeben sich erst beim Generieren der Modelleigenschaften, wenn eindeutig feststeht, welche Outputs von welchen Inputs abhängen. Inputs haben hingegen eine größere Liste von Attributen. Neben der Einheit und dem eindeutigen Namen werden Inputs mithilfe der Beschreibungssprache für Signale charakterisiert, siehe Abschnitt 3.5.1. In der Klasse Input beschreibt der Modellverwalter mithilfe von Booleans, welche Merkmale von Anwendern abgefragt werden. Die Klasse Input verfügt darüber hinaus über die minimalen und maximalen Werte und Frequenzen über alle Manöver eines Eingangs. Diese Werte sind für die Beschreibung der Werte- und Frequenzbereiche der Variantenmodelle entscheidend, da diese für alle Manöver geeignet sein sollen. Eingaben erfolgen im TSK durch den Anwender, wobei Manövereingaben für einzelne Signaleigenschaften in der Klasse InputDescription gespeichert werden. Zunächst müssen hierfür Funktionen spezifiziert werden. Da der Anwender weiß, welche Module für seine Funktion relevant sind, erfolgt durch ihn auch deren Verwaltung. Wird ein Modul entfernt oder ein neues Modul hinzugefügt, sorgt die Methode updateAllPlantModelsAndModelLinkages dafür, dass die entsprechenden Streckenmodelle und Modellvernetzungen erstellt bzw. entfernt werden. Des Weiteren wird sichergestellt, dass für alle Manöver und Testphasen einer Funktion entsprechende Streckenmodelle existieren. Dies geschieht auf der Basis eines festen Schemas für die Namen. Wenn ein manöverspezifisches Streckenmodell nicht vorhanden ist, wird dies für eine Funktion neu erstellt. Hierbei wird auch berücksichtigt, welche Testphasen für eine Funktion bzw. für ein Manöver vorgesehen sind. Wenn der Anwender eine Testphase für ein Manöver entfernt und ein manöverspezifisches Streckenmodell daher nicht mehr benötigt, wird dies auch in dieser Methode mithilfe des festen Namensschemas identifiziert und entfernt. So wird sichergestellt, dass genau die benötigten Streckenmodelle für eine Funktion existieren. Anschließend werden die Modellvernetzungen für die Manöver einer Funktion aktualisiert. Dies geschieht mithilfe der Funktion updateModelLinkages, die für ein gegebenes Manöver und eine Liste von Modulen die Modellvernetzungen erstellt. Im Algorithmus wird über die Testphasen iteriert, um zu prüfen, ob eine spezifische Modellvernetzung bereits vorliegt und wenn dies nicht der Fall ist, wird sie erstellt. Außerdem werden Funktionen zu einer bereits bestehenden hinzugefügt, um im Nachhinein identifizieren zu können, welche Funktionen mit

Anhang

133

einer Modellvernetzung getestet werden können. Schließlich werden noch die zuvor erstellten Streckenmodelle hinzugefügt, um durchgängig identifizieren zu können, welche Streckenmodelle zu welchen Vernetzungen und Funktionen gehören. Für ein Manöver erstellt der Anwender nun Beschreibungen an einzelne Inputs. Die entscheidende Funktionalität liegt in der Funktion updateMinMaxAndFrequencies. Für die Testphasen 2 oder 4 werden mithilfe der Manöverbeschreibungen die jeweiligen Eingänge von Streckenmodellen aktualisiert. Hier wird das Signal zunächst erzeugt und es werden darauf aufbauend Frequenzund Wertebereiche analysiert. Vor dem Hintergrund, dass Variantenmodelle für alle Manöver gültig sein sollen, werden hier auch die minimalen und maximalen Werte und Frequenzen über alle Testphasen aktualisiert. Wird ein minimaler Wert kleiner oder ein maximaler Wert größer, so wird dieser im entsprechenden Input direkt aktualisiert. Komplizierter wird es hingegen, wenn ein minimaler Wert größer oder ein maximaler Wert kleiner wird. In diesem Fall wird der neue Wert über alle Manöver aller Funktionen, die ein Modul verwenden, neu berechnet. Der Grund liegt darin, dass das Variantenmodell für alle Manöver gültig sein soll und ein neuer minimaler oder maximaler Wert am spezifischen Eingang nun von einem Manöver einer anderen Funktion abhängen kann. Die Liste von Streckenmodelleigenschaften wird mithilfe der Funktion createModelList erzeugt, in der über alle vorhandenen Streckenmodelle iteriert wird. Die Eigenschaften der Inputs stehen bereits fest. Die Eigenschaften der Outputs werden automatisiert anhand der Manöverbeschreibung sowie den Werte- und Frequenzbereichen von Inputs ermittelt. Außerdem wird überprüft, ob Modelle sich bzgl. der Spezifikation ähneln, da verschiedene Anwender nicht wissen, welche Eingaben für andere Funktionen existieren. Modelle werden als ähnlich eingestuft, wenn alle Zustandsvariablen gleich und die Werte aller Manövereingaben eines Streckenmodells nahezu identisch sind147 .

147

Bezogen auf den Wertebereich liegt die erlaubte Abweichung standardmäßig bei 2 Prozent.