AT510913A2 - Verfahren und ein Entwicklungssystem zum Entwickeln eines Fahrzeugs - Google Patents

Abstract

Um die Entwicklung von Fahrzeugen über die gesamte Prozesskette zu unterstützen wird vorgeschlagen, Fahrzeugkomponenten und eine Prüfumgebung mittels Schnittstellenblöcken 3-5, 7-12 aus Prüflingsparametern und Prüflingsfunktionen zu modellieren und zentral abzulegen, wobei eine Applikation 22, 23, 24, 26 oder ein Entwicklungsprodukt 21, 25 auf die benötigten Schnittstellenblöcke zugreifen kann.

Description

Printed: 08-03-2012 E014.1

10 2012/50063 AV-3465 AT

Verfahren und ein Entwicklungssystem zum Entwickeln eines Fahrzeugs

Die gegenständliche Erfindung betrifft ein Verfahren und ein Entwicklungssystem zum Entwickeln eines Fahrzeugs in einer EntwicklungsUmgebung unter Nutzung verschiedener Entwicklungsprodukten, in denen zumindest eine Applikation zur Durchführung in einer Prüfum-5 gebung implementiert ist. Für komplexe Fahrzeugentwicklungen ist die Prozesskette lange. Diese beginnt in der Regel mit der Simulation. Danach werden erste Teile des Gesamtfahrzeugs entwickelt und getestet. Sukzessive findet mehr Integration verschiedener Fahrzeugkomponenten statt, bis das Gesamtfahrzeug auf der Straße getestet und abgestimmt wird. Für diese Aufgaben gibt es 10 eine Vielzahl an Entwicklungsprodukten, für die verschiedene Applikationen entwickelt werden müssen. Unter Applikation wird dabei allgemein eine bestimmte Entwicklungsaufgabe verstanden, die in einer bestimmten Prüfumgebung, wie z.B. eine Simulationsumgebung oder einem Prüfstand, auf einem bestimmten realen oder simulierten Prüfling durchgeführt wird. Die Applikation ist dabei im Entwicklungsprodukt implementiert und der Prüfling ist eine 15 bestimmte Komponente oder eine Kombination verschiedener Komponenten des Fahrzeugs, wie z.B. ein Verbrennungsmotor, ein Antriebsstrang, ein Getriebe, eine Batterie, eine Steuereinheit, das Fahrzeug selbst, etc. Eine Applikation ist z.B. ein Emissionstest, eine Motorleistungsmessung, die Kalibrierung einer Steuereinheit, etc. Solche Entwicklungsprodukte haben in den meisten Fällen eigene Umgebungen zur Entwicklung von Applikationen. 20 Benutzer müssen daher häufig in verschiedenen Entwicklungsstufen der Prozesskette, in denen unterschiedliche Entwicklungsprodukte zum Einsatz kommen, dieselbe Applikation mehrmals entwickeln. Z.B. kann es notwendig sein, für zwei verschiedene Entwicklungsprodukte die Applikation „Leistungsmessung" zur Verfügung zu stellen. Dies kann dazu führen, dass die Testergebnisse schwer bis gar nicht vergleichbar sind, was in weiterer Folge zu 25 Fehlern führen kann. Speziell am Beginn der Prozesskette haben eventuelle Fehler auch eine starke Auswirkung bezüglich Termin und Kosten für die gesamte Fahrzeugentwicklung.

Darüber hinaus ist die Struktur der Prüflingsparameter in den meisten Entwicklungsprodukten vorgegeben. Unter Prüflingsparameter werden Werte (Skalare, Vektoren, Kennfelder) verstanden, die den Prüfling näher beschreiben. Manche Entwicklungsprodukte lassen zu, 30 dass zusätzliche Prüflingsparameter definiert werden können, jedoch sind diese dann nur für bestimmte Applikationen im Entwicklungsprodukt nutzbar und nicht generell für das Entwicklungsprodukt selbst, also auch für andere Applikation«! im Entwicklungsprodukt. In aller Regel sind diese Prüflingsparameter auch nicht in anderen Entwicklungsprodukten verfügbar. Die gesamte Komplexität für alle möglichen Applikationen in allen Entwicklungsprodukten 35 kumuliert sich somit in den Prüflingsparametern. Z.B. könnten in einem Entwicklungsprodukt -1- Λ7-ΓΛ-ί>ηι;>

Printed: 08-03-2012 E014.1 10 2012/50063

AV-3465 AT für den Anwendungsfall einer einfachen Motorleistungsmessung Parameter für Fahrerverhalten sichtbar bzw. teilweise notwendig einzugeben sein, obwohl diese in der Applikation Motorleistungsmessung gar nicht verwendet werden. Auch ist es denkbar, dass ein Prüflingsparameter für verschiedene Entwicklungsprodukte oder Applikationen mehrmals eingegeben 5 werden muss. Z.B. kann es sein, dass die Fahrzeugmasse an völlig verschiedenen Stellen mehrmals eingegeben werden muss. Die Struktur der Prüflingsparameter ist auch oftmals im Entwicklungsprodukt bzw. in der Applikation fix vorgegeben und kann vom Benutzer nicht verändert werden. Dies führt zu unnötigem Aufwand und erhöht die Fehlenwahrscheinlichkeit und Anzahl der möglichen Inkonsistenzen. Im schlimmsten Fall entstehen so Fehler, die erst 10 in späten Schritten des Entwicklungsprozesses erkannt werden und nur mehr mit hohem Aufwand korrigierbar sind.

Es ist daher eine Aufgabe der gegenständlichen Erfindung, die oben genannten Nachteile durch ein Verfahren und eine Vorrichtung zu beheben und damit die Entwicklung von Fahrzeugen über eine Prozesskette hinweg zu erleichtern. 15 Diese Aufgabe wird erfindungsgemäß dadurch gelöst, indem eine Modellumgebung vorgesehen ist, in der das Fahrzeug und die Prüfumgebung mittels einer Anzahl von Schnittstellenblöcken als Fahrzeugmodell modelliert ist, wobei einzelne Fahrzeugkomponenten als Schnittstellenkomponenten definiert sind und die Schnittstellenblöcke zentral im Entwicklungssystem abgespeichert sind und ein Schnittstellenblock durch eine Anzahl von Prüf-20 lingsparametem und eine Anzahl von Prüflingsfunktionen beschrieben ist und die Applikation oder ein Entwicklungsprodukt auf die Schnittstelienblöcke der benötigten Fahrzeugkomponenten und der Prüfumgebung und der darin definierten, benötigten Prüflingsparameter und Prüflingsfunktionen zugreift. Damit bleibt es dem Anwender überlassen, wie die Prüflingsparameter strukturiert sind und es ist möglich, abhängig von der Anwendung sehr einfache bis 25 zu sehr komplexe Modelle zu definieren. Durch die klare Definition der Schnittstellenblöcke können verschiedene Applikationen bzw. Entwicklungsprodukte geregelt auf die Prüflingsparameter und Prüflingsfunktionen zugreifen. Diese können an beliebiger Stelle im Entwicklungsprozess definiert werden. Mit Einführung einer übergreifenden Entwicklungsumgebung wird die Erstellung von Applikationen über die gesamte Prozesskette unterstützt. Die Appli-30 kation kann in mehreren Entwicklungsprodukten in verschiedenen Entwicklungsstufen der Prozesskette (z.B. in der Simulation und am Fahrzeugprüfstand) verwendet werden. Damit werden auch redundante und widersprüchliche Parameterdefinitionen vermieden.

Die gegenständliche Erfindung wird nachfolgend unter Bezugnahme auf die Figuren 1 und 2, die schematisch beispielhafte, nicht einschränkende und vorteilhafte Ausgestaltungen der 35 Erfindung zeigen, erläutert. Dabei zeigt -2-

Printed: 08-03-2012 E014.1 10 2012/50063

AV-3465 AT

Fig 1 schematisch eine Modeilumgebung zur Modellierung eines Fahrzeugs odereiner Prüfumgebung und

Fig. 2 ein Entwicklungssystem mit einer Modellumgebung und einer Entwicklungsumgebung. 5 In Fig.1 ist eine Modellumgebung 1 dargestellt, in der verschiedene Fahrzeuge 2i, 22 ... 2„ modelliert sind. Jedes Fahrzeug 2i, 22... 2„ ist durch eine Anzahl von Schnittstellenblöcken definiert. Jeder Schnittstellenblock ist durch eine Anzahl von Prüflingsparametern und einer Anzahl von Prüflingsfunktionen beschrieben. Das Fahrzeug 2i in Fig. 1 z.B. durch die Schnittstellenblöcke 3, 4, 5. Dabei kann der Schnittstellenblock 3 z.B. allgemein das Fahr-10 zeug beschreiben, z.B. mit Prüflingsparametem wie Gewicht, Radlastfaktoren, Getriebetyp, Geschwindigkeit, etc., und mit Prüflingsfunktionen, wie z.B. Start oder Stop. Der Schnittstellenblock 4 könnte z.B. den Verbrennungsmotor beschreiben mit für einen Verbrennungsmotor wichtigen Prüflingsparametern, wie z.B. Anzahl der Zylinder, Motortyp, Hubraumvolumen, etc., und den Prüflingsfunktionen, wie z.B. Anlassen, Beschleunigen, Motorbremse. Der 15 Schnittstellenblock 5 könnte z.B. den Kraftstoff beschreiben, z.B. mit Prüflingsparametem wie Kraftstofftyp, Kohlenstoffgewichtsanteil, Dichte, etc., und mit Prüflingsfunktionen, wie z.B. Füllstandsanzeige. Selbstverständlich kann es auch Vorkommen, dass ein Schnittstellenblock auch keine Prüflingsfunktion beinhaltet. Einzelne Schnittstellenblöcke könnten auch logisch gruppiert werden, um die Übersichtlichkeit zu erhöhen, wie in Fig. 1 für die Schnitt-20 Stellenblöcke 4 und 5, die den Verbrennungsmotor und den Kraftstoff beschreiben, dargestellt. Es sind selbstverständlich verschiedenste weitere Schnittstellenblöcke denkbar, wie z.B. Reifen, Generator, Batterie, Batteriemanagement, Sicherheitssysteme, Unterhaltungssysteme, Steuereinheiten, etc., die zusätzlich in jedem Fahrzeug 2 enthalten sein könnten.

Je nach Entwicklungsprojekt bzw. auch Entwicklungsstand kann die Komplexität des model-25 Herten Fahrzeugs 2 auch steigen, z.B. in dem weitere Schnittstellblöcke, Prüflingsparameter und/oder Prüflingsfunktionen hinzukommen. Die derart definierten Fahrzeug 2 werden in der Modellumgebung 1, z.B. in Form eines Computersystems, zentral abgespeichert, z.B. in einer Datenbank 13. Um die Fahrzeuge 2 in der Modellumgebung 1 bearbeiten zu können, kann eine Benutzerschnittstelle 6, z.B. ein Anschluss für ein Ein- oder Ausgabegerät oder ein 30 Netzwerkanschluss, vorgesehen sein. In der Modellumgebung 1 oder in einer Datenbank 13 können auch fertige Templates von modellierten Fahrzeugen 2 oder von Schnittstellenblöcken abgelegt sein, die für ein neues Entwicklungsprojekt aufgerufen und adaptiert werden können. Bestehende Fahrzeuge 2 können natürlich bei Bedarf auch jederzeit um weitere Schnittstellenblöcke, Prüflingsparameter und/oder Prüflingsfunktionen ergänzt werden. 35 Schnittstellenblöcke können dazu in der Modellumgebung 1 bei Bedarf angelegt werden oder es kann auf vorhandene, allgemein definierte und abgespeicherte Schnittstellenblöcke, z.B. -3- jn7^L9if»9 ’ Printed: 08-03-2012 E014.1

10 2012/50063 AV-3465 AT in der Datenbank 13, zurückgegriffen werden, die dann an die eigenen Anforderungen angepasst werden.

Es ist außerdem denkbar, dass bestimmte Komponenten des Fahrzeugs durch ein Simulationsmodell simuliert werden, wobei auch hier eine Fahrzeugkomponente durch einen Schnitt-5 stellenblock mit Prüflingsparameter und Prüflingsfunktionen näher beschrieben wird. Z.B. kann ein Verbrennungsmotor durch ein geeignetes Simulationsmodell nachgebildet werden. Grundsätzlich sind zu allen Komponenten eines Fahrzeugs Simulationsmodelle bekannt.

In der Modellumgebung 1 können aber natürlich auch noch weitere Schnittstellenblöcke 7, 8, 9, 10, 11, 12 definiert werden, wie in Fig. 2 dargestelit, die nicht das Fahrzeug 2 beschrei-10 ben, sondern die Prüfumgebung, die für die Durchführung der Entwicklungsaufgabe (Applikation) benötigt wird. Die Prüfumgebung könnte z.B. ein Motorprüfstand, eine Kalibriereinrichtung, eine Simulationseinrichtung, etc. sein. Das könnte z.B. ein Schnittstellenblock 7 für eine elektrische Belastungsmaschine in einem Prüfstand sein, ein Schnittstellenblock 8 für einen Prüfstand, ein Schnittstellenblock 9,10 für ein Messgerät, ein Schnittstellenblock 12 15 für eine Simulationsumgebung oder ein Schnittstellenblock 11 für das Automatisierungssystem des Prüfstandes.

In einer Entwicklungsumgebung 20 eines Entwicklungssystems 30 werden nun für die Fahrzeugentwicklung verschiedene Applikationen 22, 23, 24, 26 entwickelt, die auf unterschiedlichen Entwicklungsprodukten 21,25 implementiert sein können. Jede Applikation 22, 23, 24, 20 26 betrifft ein bestimmtes Fahrzeug 21( 2a, bzw. benötigt verschiedene Fahrzeugkomponen ten des Fahrzeug 2·,, 22, die in Form von Schnittstellenblöcken 4, 5, 6 beschrieben sind, und benötigt verschiedene Prüfumgebungen, die ebenfalls in Form von Schnittstellenblöcken 7, 8, 9, 10, 11, 12 beschrieben sind. Dabei ist es natürlich möglich, dass verschiedene Applikationen auf dieselben Fahrzeuge 2Ί, 22 bzw. Fahrzeugkomponenten zugreifen. Aufgrund der 25 zentralen Definition des Fahrzeugs 2i, 22 in Form von Schnittstellenblöcken 4, 5, 6 und der Prüfumgebung in Form weiterer Schnittstellenblöcke 7, 8, 9,10,11,12 in der Modellumgebung 1, müssen diese aber jeweils nur einmal definiert werden und jedes Entwicklungsprodukt 21,25 bzw. jede Applikation 22, 23, 24, 26 kann über die gesamte Prozesskette der Fahrzeugentwicklung hinweg auf diese Schnittstellenblöcke je nach Bedarf zugreifen. Die 30 Applikation 22 in Fig.2, z.B. eine Leistungsermittlung am Verbrennungsmotor, ist im Entwicklungsprodukt 21 implementiert und betrifft ein Fahrzeug 2i wie oben beschrieben. Aus dem Fahrzeugmodell werden z.B. nur die Komponenten, bzw. die diese beschreibenden Schnittstellenblöcke, z.B. Verbrennungsmotor und Kraftstoff, benötigt. Zusätzlich wird noch ein Schnittstellenblock 7, der eine elektrische Belastungsmaschine beschreibt, ein Schnittstel-35 lenblock 8, der den Prüfstand beschreibt, und ein Schnittstellenblock 11, der das Automati-sierungssystem des Prüfstandes beschreibt, benötigt. Dasselbe Fahrzeug 2\ kann gleichzei- -4- *07-03-2012

Printed: 08-03-2012 10 2012/50063 AV-3465 AT tig auch in einer anderen Applikationen 26, wie z.B. eine Emissionsmessung, und/oder in einem anderen Entwicklungsprodukt 25 verwendet werden, wobei gegebenenfalls dafür im Fahrzeug 2i auch weitere Schnittstellenblöcke, Prüflingsparameter oder Prüflingsfunktionen hinzugefügt werden können. 5 Auf diese Weise muss das Fahrzeug nur einmal als Fahrzeugmodell definiert werden. Jede Applikation oder jedes Entwicklungsprodukt kann dann auf diese zentrale Definition zugreifen und zwar nur auf die Teile des Fahrzeugmodells, die für die Applikation bzw. für das Entwicklungsprodukt benötigt werden - jede Applikation bzw. jedes Entwicklungsprodukt erhält somit eine eigene, festgelegte Sicht auf die Gesamtheit der definierten Piüflingspara-10 meter und Prüflingsfunktionen. Werden für weitere Entwicklungsprodukte oder Applikationen weitere Prüflingsparameter oder Prüflingsfunktionen benötigt, so können die Schnittstellenblöcke entsprechend ergänzt werden oder neue Prüflingsparameter, Prüflingsfunktionen oder Schnittstellenblöcke hinzugefügt werden. Auf diese Weise wird sichergestellt, dass jeder Prüflingsparameter für jedes Fahrzeug nur einmal existiert, womit einerseits redundante is Definitionen und andererseits widersprüchliche Definitionen vermieden werden. Das Fahrzeug ist über die gesamte Prozesskette hinweg für alle für die Fahrzeugentwicklung benötigten Applikationen und Entwicklungsprodukten durchgängig und gleichbleibend definiert. Es kann, wie in Fig. 2 dargestellt, im Entwicklungssystem 30 eine zentrale Datenbank 13 geben, auf die sowohl die Entwicklungsumgebung 20, als auch die Modellumgebung 1 zu-20 greifen kann. Die Datenbank 13 kann aber natürlich auch in der Entwicklungsumgebung 20 oder der Modellumgebung 1 integriert sein. E014.1 -5- Λ7-rw-omo

Claims (2)

1. AV-34B5 AT Patentansprüche 1. Verfahren zum Entwickeln eines Fahrzeugs in einer Entwicklungsumgebung (20) unter Nutzung verschiedener Entwicklungsprodukten (21, 25), in denen zumindest eine Applikation 5 (22, 23, 24, 26) zur Durchführung in einer Prüfumgebung implementiert ist, dadurch ge kennzeichnet, dass einzelne Fahrzeugkomponenten und die Prüfumgebung in Form von Schnittstellenblöcken (3, 4, 5, 7, 8, 9,10, 11, 12) definiert werden, wobei ein Schnittstellenblock (3, 4, 5, 7, 8, 9, 10, 11, 12) durch eine Anzahl von Prüflingsparametern und eine Anzahl von Prüflingsfunktionen beschrieben wird und das Fahrzeug durch eine Anzahl von io Schnittstellenblöcken (3, 4, 5) als Fahrzeugmodell (2) modelliert wird und dass die Applikation (22, 23, 24, 26) oderein Entwicklungsprodukt (21,25) auf die Schnittstellenblöcke (3, 4, 5, 7, 8, 9, 10, 11, 12) der benötigten Fahrzeugkomponenten und Prüfumgebung und die darin definierten, benötigten Prüflingsparameter und Prüflingsfunktionen zugreift.
2. 2. Entwicklungssystem zum Entwickeln eines Fahrzeugs in einer Entwicklungsumgebung 15 (20) unter Nutzung verschiedener Entwicklungsprodukten (21,25), in denen zumindest eine Applikation (22, 23, 24,26) zur Durchführung in einer Prüfumgebung implementiert ist, dadurch gekennzeichnet, dass eine Modellumgebung (1) vorgesehen ist, in der das Fahrzeug und die Prüfumgebung mittels einer Anzahl von Schnittstellenblöcken (3, 4, 5, 7, 8, 9, 10, 11, 12) als Fahrzeugmodell (2) modelliert ist, wobei einzelne Fahrzeugkomponenten als 20 Schnittstellenkomponenten (3, 4, 5) definiert sind und die Schnittstellenblöcke (3,4, 5, 7, 8, 9, 10, 11, 12) zentral im Entwicklungssystem (30) abgespeichert sind und ein Schnittstellenblock (3, 4, 5, 7, 8, 9, 10, 11, 12) durch eine Anzahl von Prüflingsparametem und eine Anzahl von Prüflingsfunktionen beschrieben ist und dass die Applikation (22, 23,24, 26) oder ein Entwicklungsprodukt (21, 25) auf die Schnittstellenblöcke (3, 4, 5, 7, 8, 9,10, 11,12) der 25 benötigten Fahrzeugkomponenten und der Prüfumgebung und der darin definierten, benötigten Prüflingsparameter und Prüflingsfunktionen zugreift. -6-