WO2005040838A1

WO2005040838A1 - System und verfahren zum testen von steuervorgängen bei einem fahrzeug

Info

Publication number: WO2005040838A1
Application number: PCT/DE2004/001955
Authority: WO
Inventors: Mathias Pillin; Martin Lehr; Frank Traenkle; Thomas Schmerler; Juergen Meyer
Original assignee: Robert Bosch Gmbh
Priority date: 2003-09-29
Filing date: 2004-09-03
Publication date: 2005-05-06
Also published as: DE10345615A1; JP2007507765A; CN1860374A; EP1671139A1; US20070118319A1

Abstract

System zum Testen von Steuervorgängen bei einem Fahrzeug, mit einem auf die zu testenden Steuervorgänge reagierenden Simulationsmodell, wobei dem Simulationsmodell eine Experimentsoftware übergeordnet ist und zwischen der Experimentsoftware und einer die Steuervorgänge auslösenden Komponente ein Signalverlauf gebildet wird, wobei der Signalverlauf durch wenigstens zwei Eingriffspunkte in wenigstens zwei Signale unterteilt wird und wenigstens eine Kennung vorgesehen ist, welche die Zuordnung der Signale zu dem Signalverlauf ermöglicht.

Description

System und Verfahren zum Testen von Steuervorgängen bei einem Fahrzeug

Stand der Technik

Die Erfindung geht aus von einem System zum Testen von Steuervorgängen bei einem Fahrzeug gemäß den aus dem Stand der Technik nicht bekannten Merkmalen der unabhängigen Ansprüche.

Autofahren wird komfortabler, sicherer und umweltfreundlicher, insbesondere dank eingebetteter Systeme, sogenannten Embedded-Control-Anordnungen. Dadurch wird das Fahrzeug aber auch immer komplexer, und die für die Funktionssicherheit erforderlichen

Tests werden immer umfangreicher, was gleichzeitig die Entwicklungszyklen verlängert. Der Wettbewerb aber fordert von den Automobilherstellern komplexe, einwandfrei funktionierende Systeme in kürzester Zeit auf den Markt zu bringen.

Insbesondere dem Test von elektronischen Komponenten, insbesondere von

Steuergeräten mit deren Software, wächst dabei eine immer größer werdende Bedeutung zu. Voraussetzung für eine höhere Testtiefe bei gleichzeitiger Verkürzung der Entwicklungszyklen ist die weitgehende Verlagerung von Tests von der Straße ins Labor sowie die Standardisierung und Automatisierung dieser Tests. Um diese Anforderung erfüllen zu können bedarf es moderner Entwicklungs- und Testmethoden sowie einer optimalen Tool-Unterstützung, wie beispielsweise dem LabCar der ETAS GmbH, einem Hardware-in-the-loop-Testsystem entsprechend dem Whitepaper "LabCar" von 1999 release 10/1999 der ETAS GmbH & Co. KG, Stuttgart. Die nachfolgend beschriebene Erfindung soll diese Situation bei Testsystemen bezüglich Steuervorgängen bei einem Fahrzeug, insbesondere bei Hardware-in-the-loop- . Testsystemen wie LabCar verbessern und optimieren.

Vorteile der Erfindung

Dazu geht das System und das Verfahren zum Testen von Steuervorgängen bei einem Fahrzeug sowie ein entsprechendes Computerprogramm und Computerprogrammprodukt von einem auf die zu testenden Steuervorgänge reagierenden Simulationsmodell aus, wobei vorteilhafter Weise im Simulationsmodell eine Experimentsoftware übergeordnet ist und zwischen der Experimentsoftware und einer die Steuervorgänge auslösenden Komponente ein Signalverlauf gebildet wird, wobei der Signalverlauf durch wenigstens zwei Eingriffspunkte in wenigstens zwei Signale unterteilt wird und wenigstens eine Kennung vorgesehen ist, welche die Zuordnung der Signale zu dem Signalverlauf ermöglicht.

Damit ergeben sich vorteilhafter Weise innerhalb eines Testsystems das zur Validierung von Entwicklungen im Bereich der Automobilelektronik benutzt wird, die Möglichkeit, den Signalfluss oder Signalverlauf durch das Testsystem und über das zur Validierung anstehende Objekt zu visualisieren, die während eines Tests erfassten Werte dieser

Signale anzuzeigen und bestimmte Eingriffsmöglichkeiten in den Signalverlauf zu ermöglichen.

Somit werden zum Einen zweckmäßiger Weise die Eingriffspunkte selbst mit Kennungen versehen oder die durch die Eingriffspunkte entstehenden Signale.

Vorteilhafter Weise werden die entstehenden Signale unterschiedlichen Signalgruppen zugeordnet und zweckmäßiger Weise diese unterschiedlichen Signalgruppen bzw. die diesen zugeordneten Signale optisch dargestellt bzw. visualisiert.

Damit wird also nicht nur der Signalverlauf bzw. der Signalfluss durch das Testsystem darstellbar, sondern auch die während eines Tests erfassten Werte dieser Signale bzw. die Signale oder deren Werte entsprechend der Eingriffspunkte. Zweckmäßiger Weise werden dabei die Kennungen im System veränderbar ausgelegt, so dass die Signale insbesondere während des Tests verschiedenen Signalverläufen zugeordnet werden können und damit optimierte Testszenarien darstellbar sind.

Dabei ist es insbesondere vorteilhafter Weise möglich, an wenigstens einem

Eingriffspunkt ein ein solches Signal ersetzendes Signal in den Signalverlauf einzugeben, also beispielsweise ein Signal ausgegeben von einem Signalgenerator oder ein konstanter Wert, der das ursprüngliche Signal ersetzt, im Rahmen eines gewünschten Testszenarios.

Die vorliegende Erfindung zielt somit darauf ab, die mit der die Steuervorgänge auslösendenden Komponente verbundenen Signalverläufe innerhalb des Testsystems zu visualisieren, die Werte der entsprechenden Signale anzuzeigen und dem Benutzer zusätzliche Funktionalität zur Verfügung zu stellen, damit er in effizienter Weise das Testsystem aufbauen und bedienen kann.

Zeichnung

Die Erfindung wird im Weiteren anhand der in der Zeichnung dargestellten Figuren näher erläutert. Dabei zeigt

Figur 1 schematisch eine Steuerung bzw. Regelung innerhalb des Fahrer-Fahrzeug- Umweltverbundes.

Figur 2 zeigt ein erfindungsgemäßes Entwicklungsschema des Testsystems.

Figur 3 zeigt schematisch einen Signalverlauf bzw. Signalfluss in einem Testsystem mit entsprechenden Eingriffspunkten.

Figur 4 zeigt eine erfindungsgemäße Signal- bzw. Signalwertdarstellungstabelle.

In Figur 5 ist eine erfindungsgemäße mögliche Realisierung der Kennungen durch Verwendung eines Kennungsgrafen dargestellt.

Beschreibung der Alisführungsbeispiele Elektronische Komponenten und Software kommen bei der Entwicklung neuer Fahrzeuggenerationen eine immer größere Bedeutung zu. Sie werden dazu benutzt, um Kosten zu reduzieren und sich gleichzeitig einen Wettbewerbsvorteil beim Endkunden zu verschaffen.

Die Erfindung zielt auf die Entwicklung und die Validierung von Steuervorgänge bei einem Fahrzeug auslösenden Komponenten insbesondere elektronischen Steuerungen bzw. Regelungen oder Reglern im Automobilbereich ab. Die Validierung dieser Steuerungen ist ein mitunter recht aufwändiger Prozess, der ohne den Einsatz von speziellen Werkzeugen nicht durchgeführt werden kann. Diese Werkzeuge oder Testsysteme sollen eine Simulation des Fahrzeugs im Labor über verschiedene Schritte im Entwicklungsprozess ermöglichen und somit die elektronische Steuerung oder den Regler glauben lassen, er sei im echten Fahrzeug verbaut.

Ein solcher Regler besitzt typischerweise sehr viele Schnittstellen, d. h. Ein- und Ausgänge, die mit anderen Komponenten im Fahrzeug gekoppelt sind und damit wechselwirken. Bei einem Testsystem, das das Verhalten des realen Fahrzeugs nachbilden soll, stellen diese Schnittstellen für den Anwender ein sehr komplexes Gebilde dar, indem man sich nur schwer zurechtfinden kann. Vor diesem Hintergrund ist die Erfindung und ihre verschiedenen Ausprägungen zu sehen. Die vorliegende Erfindung zielt somit darauf ab, dass ein Anwender zum Einen eine Übersicht über die Komplexität des Systems behalten kann und die Effizienz beim täglichen Einsatz des Systems beträchtlich gesteigert wird. Damit können auch Software- und Softwareprodukte, die bei einem Testsystem zur Steuerung eines Experiments verwendet werden, verbessert werden.

Bei der Entwicklung von Steuervorgänge auslösenden Komponenten, also insbesondere von elektronischen Steuerungen und Regelungen im Automobilbereich kann man den Signalfluss anhand der Grafik in Figur 1 veranschaulichen. Einzelne Elemente werden dabei als Blöcke, und die zwischen ihnen bestehenden Signalflüsse als Pfeile dargestellt. Dabei ist mit 107 das Fahrzeug selbst symbolisiert. Block 100 stellt den Fahrer und Block 101 die Umwelt dar. Wie in Figur 1 ersichtlich, können zwischen den Komponenten Fahrzeug, Fahrer und Umwelt zahlreiche Signalflüsse bestehen. Der Fahrer steht in dieser Darstellung stellvertretend auch für alle anderen Benutzer einer Fahrzeugfunktion wie etwa weitere Passagiere. Zur Umwelt zählen auch andere Fahrzeuge oder elektronische Systeme in der Umgebung des Fahrzeugs, etwa Werkzeuge wie z. B. Diagnosetester, die in der Servicewerkstart mit den elektronischen Systemen des Fahrzeugs verbunden werden. Diese logische Systemarchitektur für Steuerungs-, Regelungs- und

Überwachungssysteme gemäß Figur 1 symbolisiert folgenden Ablauf. Der Fahrer bedient Hebel oder Schalter im Fahrzeug, z. B. einen Blinker oder das Gaspedal. Dieser Fahrerwunsch wird über die sogenannten Sollwertgeber 102 an die Steuerungseinheit 103, also einer die Steuervorgänge auslösende Komponente weitergeleitet. Die Steuerung 103 verarbeitet diese Information und steuert Aktuatoren 104 an. Will beispielsweise der

Fahrer beschleunigen, wird die Steuerung so Einspritzventile und Drosselklappe steuern, dass mehr Kraftstoff in den Verbrennungsraum gebracht wird. Die sogenannte Strecke oder Regelstrecke 105 ist dann ein Teil des Fahrzeugs, der die Aktion des Aktuators verarbeitet, also etwa der Zylinder, der den Kraftstoff verbrennt und das erzeugte Moment an das Fahrzeug weitergibt. Schließlich werden Sensoren 106 benötigt, die das

Verhalten des Fahrzeugs oder einzelner Komponenten detektieren. Wenn beispielsweise die vom Fahrer gewünschte Geschwind igkeit erreicht ist, wird dies von einem Sensor erfasst. Der Sensor leitet die von ihm erfasste Information an die Steuerung weiter, damit diese darauf reagieren kann. Der Fahrer nimmt nun das Verhalten seines Fahrzeugs wahr und wird darauf entsprechend wieder Ei nfluss nehmen. Natürlich hat dabei auch die

Umwelt 101 etwa durch Außentemperatur oder Straßenbelag, Wettereinflüsse wie Regen, Schnee oder Wind usw. Einfluss auf das Fahrzeug und den Fahrer. Die Pfeile in Figur 1 geben somit den Signalfluss in der eben beispielhaft beschriebenen Weise wieder.

Die Aufgaben eines Testsystems sind nun die folgenden:

Ein System zum Testen von Steuervorgängen bei einem Fahrzeug muss in der Lage sein, alle Einheiten außer der Steuerung selbst, die in Figur 1 dargestellt sind, zu simulieren. Dies kann entweder durch Software erfolgen oder erfordert in manchen Anwendungen auch den Einsatz von spezieller Elektronik, Hardware, die die Steuerungseinheit z. B. mit genau den elektrischen Signalen versorgt, wie sie im realen Fahrzeug auch auftreten würden. Vom Einsatz dieser Hardware hängt dann auch der Umfang des zugrunde gelegten Simulationsmodells ab, welches die Einheiten bzw. die Komponenten der Figur 1 simuliert. Erfindungsgemäß wird nun das Testsystem mit einer Software ausgerüstet; es wird also dem Simulationsmodell eine sogenannte Experimentsoftware übergeordnet, die dem Benutzer folgendes ermöglicht: Zum Einen, das System zu konfigurieren, d. h. grundlegende Einstellungen des Simulationsmodells und der eventuell verwendeten Hardware vorzunehmen, des Weiteren die Steuerung in Betrieb zu nehmen, da moderne Steuerungen oft mit umfangreichen Diagnosefunktionen ausgerüstet sind. Diese Funktionen sollen zum Einen feststellen, ob die Steuerung mit nicht plausiblen Signalen versorgt wird. Treten solche Fälle auf, geht die Steuerung in einen Notlaufzustand über, der einen Test mit dem Testsystem nicht mehr unbedingt sinnvoll macht. Dies bedeutet, dass die Experiment-Software den Benutzer unterstützen muss, eine Simulation durchzuführen, bei der die Steuerung nicht direkt in einen solchen Notlaufzustand übergeht, außerdem einen interaktiven Test durchzufuhren, was bedeutet, dass die

Experimentsoftware Funktionalität zur Verfügung stellen muss, die es dem Anwender ermöglicht, durch einen Bedien-PC mit dem Testsystem in Wechselwirkung zustehen. Und schließlich Daten, die während eines Tests anfallen, aufzuzeichnen und zu verwalten. Die Position dieser Experimentsoftware sowie die Wechselwirkung, also der entstehende Signalfluss bzw. die Signalverläufe werden später in Figur 3 noch einmal genauer dargestellt.

Abgeleitet aus Figur 1 hat ein Benutzer nun typischerweise die in Figur 2 dargestellte Sicht auf das Testsystem. Darin sind mit Block 200 eine Steuerung, mit Block 201 die Signalerfassung, mit Block 202 statische Aktuatormodelle und im Block 203 dynamische

Aktuatormodelle dargestellt. Block 204 zeigt ein Modell von Strecke, Fahrer und Umwelt, welchem mit Block 205 dynamische Sensormodelle, mit Block 206 statische Sensormodelle und mit Block 207 die Signalerzeugung nachgeordnet sind. Die Steuerung

200 hat typischerweise beliebig viele Ein- und Ausgänge. Die in Figur 2 dargestellte Grafik wird ausgehend von der Steuerung 200 im Uhrzeigersinn verfolgt. Die

Ausgangssignale der Steuerung werden von einer optionalen Signalerfassung detektiert. Liegt die Steuerung als physikalisches Objekt vor, handelt es sich bei der Signalerfassung

201 beispielsweise um eine Hardwarekomponente. Danach gibt es eine weitere optionale Einheit, die die elektrischen Signale in physikalische Einheiten umwandelt, also z. B. eine Spannung in eine Temperatur. Im Anschluss wird in Block 203 das dynamische

Verhalten des Aktuators im Testsystem nachgebildet. Daran schließt sich eine Simulation von Fahrer, Umwelt und dem Rest des Fahrzeugs an, bevor der Signalverlauf über entsprechende Einheiten zur Signalerzeugung, also ein dynamisches Sensormodell 205, ein statisches Sensormodell 206 sowie eine Signalerzeugung 207 zur Steuerung 200 zurückgeführt wird.

Die in Figur 2 dargestellten Blöcke oder Einheiten sind typischerweise in verschiedenen 5. Werkzeugen implementiert. Die Steuerung selbst kann entweder als physikalisches Subjekt oder als Modell in einem Simulationswerkzeug vorliegen. Ebenso können die Blöcke Signalerfassung 201 und Signalerzeugung 207 als elektronische Komponenten, also in Hardware vorliegen oder in einem Simulationswerkzeug implementiert sein. Die übrigen Blöcke in Abbildung 2 liegen typischerweise in einem Simulationswerkzeug vor.0 Das Simulationsmodell umfasst somit wenigstens das Modell von Strecke, Fahrer und Umwelt sowie die dynamischen Aktuatormodelle und die dynamischen Sensormodelle, also die Blöcke 203 bis 205 in Figur 2.

Die Problematik liegt nun zum Einen darin, dass der in Figur 2 dargestellte Signalverlauf5 nicht eindeutig ist. Es besteht vielmehr die Möglichkeit, dass ein Ausgangssignal der Steuerung auf mehrere Signalerfassungskanäle verschaltet wird, die dann wieder mit mehreren statischen Aktuatormodellen verbunden werden usw. Des Weiteren liegt die Problematik, der der Anwender des Testsystems ausgesetzt ist, darin, dass die eben angesprochenen Simulationswerkzeuge unterschiedlich sein können. Dies bedeutet, dass 0 z. B. die dynamischen Aktuatormodelle 203 in einem Werkzeug A implementiert sind, während die statischen Aktuatormodelle in einem Werkzeug B vorliegen.

Damit der Anwender des Testsystems effizient arbeiten kann, liegt nun über der in Figur 2 dargestellten Struktur typischerweise eine weitere Softwareschicht, im Folgenden als5 Experimentsoftware bezeich net, die es ermöglicht, ein Experiment zum Test der Steuerung durchzuführen. Dies bedeutet, dass dem Anwender hier Möglichkeiten zur Verfügung gestellt werden, auf Objekte, also Parameter oder Messgrößen, die die Objekte in Figur 2 anbieten, zuzugreifen. 0 Der Kern der dargestellten Erfindung beruht nun darauf, dass ein Verfahren implementiert wird, das die Schnittstellen der in Figur 2 dargestellten Blöcke und die Verbindung dieser Blöcke untereinander, die im Allgemeinen eben nicht eineindeutiger Natur ist, automatisch erkennt und in die eben definierte Schicht der Experimentsoftware einliest. Dabei werden diese Schnittstellen im Weiteren auch Eingriffspunkte mit sogenannten Identifiern, d. h. Kennungen versehen, die dann in der Experimentsoftware verwendet werden. Ebenso ist es möglich, nicht die Eingriffspunkte mit Kennungen zu versehen, sondern die durch die Eingriffspunkte entstehenden Signale, wie in Figur 3 dargestellt, mit Kennungen zu versehen, welche eine durchgängige Betrachtung erlauben 5. und diese dann in der Experimentsoftware zu verwenden.

Damit kann diese Information dann einem Benutzer entsprechend Figur 4 dargestellt, insbesondere visualisiert, werden mit weiteren Möglichkeiten zur Gestaltung, um folgende Möglichkeiten zu erzielen:0 Anhand des in Figur 2 dargestellten Schemas wird es nun ermöglicht, ausgehend von einem beliebigen Ein- oder Ausgangssignal eines der dargestellten Blöcke, sich den kompletten Signalverlauf anzeigen zu lassen. D. h., der Anwender wird nach Aufruf einer Funktion eine Ansicht auf den gesamten Signalverlauf inklusive aller Mehrdeutigkeiten5 und Verzweigungspunkte erhalten. Als Anhaltspunkte hierfür dienen die vom Benutzer vergebenen Namen der Signale an den Ein- und Ausgängen der in Figur 2 dargestellten Blöcke, wie nachfolgend anhand der Figuren 3 bis 5 näher erläutert. Des Weiteren wird die Möglichkeit zur Verfügung gestellt, anhand der im vorigen Punkt dargestellten Ansicht während eines Experiments mit dem Testsystem alle Werte der Signale 0 anzuzeigen, also zu visualisieren und optisch darzustellen. Darüber hinaus ist die Möglichkeit gegeben, mittels vordefinierter Signal verlaufe in den anhand der im ersten Punkt der Möglichkeiten dargestellten Ansicht in den Signalverlauf einzugreifen und damit eine benutzerdefinierte Stimulation des entsprechenden Signals vorzunehmen, beispielsweise über einen Signalgenerator oder einen konstanten Wert. Und schließlich5 können die in Fi gur 2 außer der Steuerung selbst dargestellten Blöcke parametriert werden oder durch entsprechende Blöcke, die das gleiche Ein- und Ausgangsverhalten besitzen, getauscht werden. Dies schließt insbesondere den Fall ein, in dem das Modell einer Komponente durch eine reale Komponente ersetzt wird, z. B. das Modell einer Drosselklappe durch eine reale Drosselklappe. Damit ist das dargestellte Verfahren und0 das erfindungsgemäße System unabhängig davon, in welchem Entwicklungsstadium sich die Steuerung in Figur 2 befindet, d. h. die Steuerung 200 kann sowohl vollständig in Software vorliegen, in einem physikalischen Steuergerät verbaut sein, oder auch Mischformen dieser beiden Möglichkeiten sind denkbar. Figur 3 zeigt nun den Signalfluss bzw. die Signalverläufe und Zugriff auf Signale in einem Testsystem, insbesondere dem in der Einleitung angesprochenen LapCar-System. Dabei ist die Simulationssoftware 308 zum Einen aus dem Simulationsmodell 307und zum Anderen aus der Experimentsoftware 306 aufgebaut. Die zu testende die Steuervorgänge auslösende Komponente 300, also beispielsweise das Steuergerät oder der Regler (hardware- oder softwareimplementiert) steht dabei mit einem Block 301 der Hardware und einem Block 302 der Echtzeitein-/ausgabe (real time-i/o) in Verbindung. Entsprechend jeder Signalrichtung ist optional zwischen Block 302 und der Experimentsoftware 306 je nach Signalrichtung Blöcke 303 und 304 eine Open-Loop- Configuration OLC. Diese sogenannte Open-Loop-Configuration, dargestellt durch die

Blöcke 303 und 304, kann in den Signalpfad zwischen Modell und Hardware eingegriffen werden, und es können beispielsweise Signale von einem Signalgenerator 305 oder auch Konstantwerte eingespeist werden. Diese Open-Loop-Configuration OLC ist die Zwischenschicht zwischen der Modellspezifikation und den Treibern für die Ein- /Ausgabehardware. Die Open-Loop-Configuration hat mehrere Aufgaben. Die

Hauptaufgabe ist die Wandlung physikalischer Werte in elektrische (für Signale vom Fahrzeugmodell zum Steuergerät) und die umgekehrte Wandlung von elektrischen Werten in physikalische Werte (für Signale, die vom Steuergerät an das Fahrzeug gesendet werden). Dies entspricht im Wesentlichen den Aufgaben, die Sensoren (physikalisch in elektrisch) und Aktuatoren (elektrisch in physikalisch) im Fahrzeug wahrnehmen. Sensoren und Aktuatoren sind in der Open-Loop-Configuration, also den

Blöcken 303 und 304, modelliert.

Sensorbeispiel:

Der physikalische Wert Bremsdruck - 4,3Bar könnte von einem Sensormodell der OLCin den elektrischen Wert, also Spannung an einem Drucksensor UBrems⁼ A2 V umgerechnet werden.

Aktuatorbeispiel:

Der elektrische Wert Tastverhältnis bei der Puls-Weiten-Modulation eines ABS-Ventils, z. B. 0,789 könnte von einem Aktuatormodell der OLC in den physikalischen Wert

Durchfluss = 0,24 Liter pro Minute umgerechnet werden. Die Hauptfunktion, Sensoren und Aktuatoren zu modellieren, ist gleichzeitig die Minimalforderung an eine OLC. Da in der OLC von jedem Signal, das zum Steuergerät gesendet oder von diesem empfangen wird, sowohl die elektrische wie auch der physikalische Wert vorliegen, eignet es sich ideal als zentrale Stelle, um Benutzereingriffe an den Signalen vorzunehmen. Hierzu wird sowohl bei Sensoren als auch bei Aktuatoren die Möglichkeit bereitgestellt, den physikalischen wie auch den elektrischen Wert jeweils in drei Varianten zu beeinflussen; Zum Einen direkt, also den Wert 1 : 1 durchzureichen, zum Anderen konstant den Wert 5. manuell auf eine konstante Größe zu setzen, oder stimuliert, d. h. den Wert aus einem Signalgenerator zu beziehen, wodurch Signalverläufe manuell vorgegeben werden können. Damit ist die Möglichkeit gegeben, das physikalische Fahrzeugmodell teilweise oder komplett von der Real-Time-I/O, also der Echtzeitein-/ausgabe 302 abzukoppeln, indem gewünschte Signale vorgebbar sind. Dadurch werden Regelkreise geöffnet und das 0 Steuergerät ganz oder teilweise nicht mehr im Closed-Loop betrieben, deshalb die Bezeichnung Open-Loop-Configuration. Diese Open-Loop-Configuration ist in den Signaleigenschaften definiert. Eine Änderung der OLC kann für ein laufendes Experiment sofort gültig gemacht werden. Bezüglich des Signalverlaufes bzw. des Signalflusses in einem solchen Testsystem gibt es erfindungsgemäß drei Stellen, an denen 5 au die Signale und deren Eigenschaften zugegriffen werden kann, um sie zu ermitteln, zu visualisieren oder sogar zu verändern. Zum Einen am Eingriffspunkt 312, also den Ein- und Ausgängen der Modellsoftware 308, insbesondere der Experimentsoftware 306. An dieser Stelle werden die Signale dann Modellsignale MS genannt.

0 Ein weiterer Eingriffspunkt sind die Ein- und Ausgänge der Open-Loop-Configuration bzw. der Real-Time-I/O an den Eingriffspunkten 31 1 und 310. An dieser Stelle werden die Signale dann Hardwaresignale HWS genannt.

Die dritte Eingriffsmöglichkeit in diesem Ausführungsbeispiel, also der dritte 5 Eingriffspunkt sind die Ein- und Ausgänge der die Steuervorgänge auslösende Komponente, also insbesondere des Steuergeräts 300. Dieser Eingriffspunkt ist mit 309 bezeichnet, und an dieser Stelle werden die Signale Steuergerätesignale SGS genannt. Im Prinzip handelt es sich bei Modellsignalen, Hardwaresignalen und Steuergerätesignalen um ein und den selben Signalverlauf. Mit den entsprechenden Bezeichnungen wird0 lediglich der Eingriffspunkt im gesamten Signalpfad oder Signalverlauf spezifiziert. Somit sind in Figur 3 die Signalpfade oder Signalverläufe vom und zum Steuergerät, die Zugriffsstellen bzw. Eingriffspunkte auf diese und die Punkte, an denen Signale aus dem Signalgenerator oder anderweitig eingespeist werden können, dargestellt. Somit können hierüber, insbesondere durch die Eingriffspunkte, Signalflüsse bzw. Signalverläufe spezifiziert und verfolgt werden, also vom Simulationsmodell über die Echtzeiteii ausgabe 302 bis zu den Steuergeräteanschlüssen und umgekehrt. Außerdem können hier Signaleigenschaften ermittelt und editiert werden. Dazu werden erfindungsgemäß entweder den Eingriffspunkten selbst oder den dadurch entstehenden

Signalen Kennungen zugeordnet.

Durch diese Kennungszuordnung kann ein Signalverlauf über die Eingriffspunkte 309, 310, 31 1 und 312 hinweg verfolgt werden und trotzdem einzelne Signale entsprechend der Eingriffspunkte behandelt werden. Dazu werden diese Signale in entsprechende

Signalgruppen entsprechend des Eingriffspunktes eingeteilt, wie dies in Figur 4 in der Tabelle dargestellt ist. Bei Eingriffspunkt 309 erhält man also Steuergerätesignale SGS, die beispielsweise den Steuergerätepins, ECU-Pins (Electronic Control Unit) entsprechen hier in Figur 4 ECU1 bis ECU3. Für unterschiedliche Signalverläufe sind dann beispielsweise mehrere Hardwaresignale vorgesehen, eben bei der Real-Time-I/O 302 oder hinter dem Open-Loop-Configuration, hier dargestellt als Hardwaresignale HWS, RTI/Ol bis RTI/04. Ebenso werden an Eingriffspunkt 312 die Modellsignale MS, in diesem Beispiel hier mit Ml bis M5 verwendet. Dabei ist die Anzahl der einzelnen Signale in den Signalgruppen willkürlich gewählt und hängt im Wesentlichen ; entsprechend des jeweiligen Tests von den Signalverläufen ab.

In Figur 4 können nun diese Signale, wie in dieser Tabelle dargestellt, visualisiert oder optisch dargestellt werden, wobei des Weiteren eine Zuordnung zum jeweiligen Signalverlauf der Einzelsignale erfolgen soll. Dies wird durch Kennungen erreicht, die entweder den Eingriffspunkten zugeordnet werden oder den einzelnen Signalen.

Eine erste Möglichkeit solcher Kennungen ist beispielsweise, ECU1 mit einer Kennung Kl zu versehen, RTI/02 beispielsweise mit einer Kennung K l , K2 und z. B. Ml mit einer Kennung Kl , K2, K3. So kann durch Kennung Kl und Kennung K2 der Signalpfad von ECU1 über RTI/02 zu Ml eindeutig nachvollzogen werden, und es sind die genannten Vorteile der Visualisierung der Wertanzeige und der Eingriffsmöglichkeiten gegeben. Eine weitere Möglichkeit der Kennungszuordnung ist ein sogenannter Verknüpfungsgraf 500 entsprechend Figur 5. Darin sind wieder beispielhaft die Signale gemäß der Tabelle aus Figur 4, ECUl bis ECU3, RTI/Ol bis RTI/04 und Ml bis M5 dargestellt. Zur einfacheren Darstellung sind nun die Richtungspfeile in beide Richtungen in diesem Graf gewählt. Es kann aber auch hier die Signalrichtung separat dargestellt sein. Entsprechend der Wege im Verknüpfungsgrafen können nun die entsprechenden Kennungen entweder den Signalen oder den Eingriffspunkten, hier 502 und 503 zugeordnet sein. Ein einfacher Pfad ist beispielsweise ECUl , RTI/Ol und Ml, welchem durchgängig eine Kennung 1 zugeordnet wird, oder aber, es wird in entsprechenden Schnittstellen zwischen ECUl und RTI/Ol sowie RTI/Ol und Ml jeweils eine Kennung zugeordnet, die die jeweilige

Zusammengehörigkeit im gesamten Pfadverlauf darstellt. Gleiches gilt für die Pfade ECU2, RTI/O2, M2 oder optional ECU2, RTI/02, M3 sowie ECU2, RTI/03, M4 und ECU3, RTI/03, M4 oder ECU3, RTI/04, M4. Im Pfad ECU3, RTI/04, M5 ist dann eine angesprochene Signalunterbrechung dargestellt, wo mittels Block 501 ein Signal zu M5 eingekoppelt wird. Dies kann, wie schon angesprochen, ein Signal des Generators 305 sein oder ein Konstantwert oder ein l:l-Durchreichen. Dieser Eingriff und diese Unterbrechung kann auch bei Eingriffspiinkt 502 erfolgen. Entweder durch Zuordnung eineindeutiger Kennungen entsprechend des jeweiligen Signalpfades oder durch eine entsprechende Pfadtabelle zur Nachvollziehung des einzelnen Pfades kann dann eine Eingriffsmöglichkeit und Visualisierungsmöglichkeit im Signalfluss erzeugt werden.

Durch diese Eingriffsmöglichkeiten entsprechend der Eingriffspunkte können nun auch im jeweiligen Experiment Pfade angepasst, Pfade geändert werden, indem Kennungen veränderbar gemacht werden, so dass die Signale im Experiment verschiedenen Signalverläufen zugeordnet werden können. Entsprechend dieser Ausführung können also nun die Signalverläufe entsprechend Figur 2 visualisiert werden und für den

Benutzer entflochten werden.

Neben dem erfϊndungsgemäßen System und dem erfindungsgemäßen Verfahren zum Testen von Steuervorgängen bei einem Fahrzeug kann die Erfindung auch in einem Computerprogramm mit Programmcode ausgeführt sein, die es ermöglicht, alle erfindungsgemäßen Schritte durchzuführen, wenn das Programm auf einem Computer ausgeführt wird. Insbesondere die Kennungsanpassung, die Kennungsveränderung und überhaupt die Schaffung der Eingriffsmöglichkeit kann vorteilhafter Weise durch ein Computerprogramm mit Programmcode realisiert sein. Abgeleitet davon kann dieses Computerprogramm natürlich auch auf einem Computerprogrammprodukt mit Programmcode, der auf einem maschinenlesbaren Träger gespeichert ist und zur Durchführung des erfindungsgemäßen Verfahrens dient, wenn das Programm auf einem Computer ausgeführt wird, realisiert sein. Solche maschinenlesbaren Träger sind beispielsweise Speicherbausteine wie EPROM, Flash- EPROM, ROM, ROM, EEPROM usw., aber auch CD-ROM, DVD, Diskette und ähnliche maschinenlesbare Träger, wie auch die Möglichkeit des Einlesens des Programms via Texterkennung in ein Computersystem. So kann die Erfindung als Softwareprodukt eingesetzt werden. Damit ist die Möglichkeit gegeben, innerhalb eines

Testsystems, das zur Validierung von Entwicklungen im Bereich der Automobilelektronik benutzt wird, die Signal verlaufe bzw. den Signalverlust durch das Testsystem und über das zur Validierung anstehende Objekt zu visualisieren und die während eines Tests erfassten Werte dieser Signale anzuzeigen und bestimmte Eingriffsmöglichkeiten in den Signalverlauf zu ermöglichen.

Claims

Ansprüche

1. System zum Testen von Steuervorgängen bei einem Fahrzeug, mit einem auf die zu testenden Steuervorgänge reagierenden Simulationsmodell, wobei dem Simulationsmodell eine Experimentsoftware übergeordnet ist und zwischen der Experimentsoftware und einer die Steuervorgänge auslösenden Komponente ein Signalverlauf gebildet wird, wobei der Signalverlauf durch wenigstens zwei Eingriffspunkte in wenigstens zwei Signale unterteilt wird und wenigstens eine Kennung vorgesehen ist, welche die Zuordnung der Signale zu dem S ignalverlauf ermöglicht.

2. System nach Anspruch 1, dadurch gekennzeichnet, dass die Eingriffspunkte mit Kennungen versehen werden.

3. System nach Anspruch 1 , dadurch gekennzeichnet, dass die durch die Eingriffspunkte entstehenden Signale mit Kennungen versehen werden.

4. System nach Anspruch 1 , dadurch gekennzeichnet, dass die entstehenden Signale unterschiedlichen Signalgruppen zugeordnet werden

5. System nach Anspruch 4, dadurch gekennzeichnet, dass die die Signale enthaltenden unterschiedlichen Signalgruppen optisch dargestellt werden.

6. System nach Anspruch 1, dadurch gekennzeichnet, dass die Kennungen veränderbar sind und so die Signale verschiedenen Signalverläufen zugeordnet werden können.

7. System nach Anspruch 1, dadurch gekennzeichnet, dass an wenigstens einem- Eingriffspunkt ein ein Signal ersetzendes Signal in den Signal verlauf eingegeben werden kann.

8. Verfahren zum Testen von Steuervorgängen bei einem Fahrzeug, mit einem auf die zu testenden Steuervorgänge reagierenden Simulationsmodell, wobei dem Simulationsmodell eine Experimentsoftware übergeordnet ist und zwischen der Experimentsoftware und einer die Steuervorgänge auslösenden Komponente ein Signaiverlauf gebildet wird, wobei der Signalverlauf durch die Verwendung wenigstens zweier Eingriffspunkte in wenigstens zwei Signale unterteilt wird und wenigstens eine Kennung verwendet wird, welche die Zuordnung der Signale zu dem Signalverlauf ermöglicht.

9. Computerprogramm mit Programmcode zur Durchführung aller Schritte nach Anspruch 8, wenn das Programm auf einem Computer ausgeführt wird.

10. Computerprogrammprodukt mit Programmcode, der auf einem maschinenlesbaren Träger gespeichert ist zur Durchführung des Verfahrens nach Anspruch 8, wenn das Programm auf einem Computer ausgeführt wird.