-
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 Entwicklüngszyklen
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
-
1 schematisch
eine Steuerung bzw. Regelung innerhalb des Fahrer-Fahrzeug-Umweltverbundes.
-
2 zeigt
ein erfindungsgemäßes Entwicklungsschema
des Testsystems.
-
3 zeigt
schematisch einen Signalverlauf bzw. Signalfluss in einem Testsystem
mit entsprechenden Eingriffspunkten.
-
4 zeigt
eine erfindungsgemäße Signal- bzw.
Signalwertdarstellungstabelle.
-
In 5 ist
eine erfindungsgemäße mögliche Realisierung
der Kennungen durch Verwendung eines Kennungsgrafen dargestellt.
-
Beschreibung der Ausfü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 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 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
Servicewerkstatt mit den elektronischen Systemen des Fahrzeugs verbunden
werden. Diese logische Systemarchitektur für Steuerungs-, Regelungs- und Überwachungssysteme
gemäß 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 Geschwindigkeit 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 Einfluss 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 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 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 wurden. Vom
Einsatz dieser Hardware hängt
dann auch der Umfang des zugrunde gelegten Simulationsmodells ab,
welches die Einheiten bzw. die Komponenten der 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 durchzuführen,
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 3 noch einmal genauer dargestellt.
-
Abgeleitet
aus 1 hat ein Benutzer nun typischerweise die in 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 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 2 dargestellten Blöcke oder Einheiten sind typischerweise
in verschiedenen 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 2 liegen
typischerweise in einem Simulationswerkzeug vor. 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 2.
-
Die
Problematik liegt nun zum Einen darin, dass der in 2 dargestellte
Signalverlauf 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 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 2 dargestellten Struktur typischerweise eine weitere
Softwareschicht, im Folgenden als Experimentsoftware bezeichnet,
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 2 anbieten, zuzugreifen.
-
Der
Kern der dargestellten Erfindung beruht nun darauf, dass ein Verfahren
implementiert wird, das die Schnittstellen der in 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 3 dargestellt,
mit Kennungen zu versehen, welche eine durchgängige Betrachtung erlauben
und diese dann in der Experimentsoftware zu verwenden.
-
Damit
kann diese Information dann einem Benutzer entsprechend 4 dargestellt,
insbesondere visualisiert, werden mit weiteren Möglichkeiten zur Gestaltung,
um folgende Möglichkeiten
zu erzielen:
Anhand des in 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 Mehrdeutigkeiten und Verzweigungspunkte
erhalten. Als Anhaltspunkte hierfür dienen die vom Benutzer vergebenen
Namen der Signale an den Ein- und Ausgängen der in 2 dargestellten
Blöcke,
wie nachfolgend anhand der 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 dein Testsystem alle Werte der Signale anzuzeigen,
also zu visualisieren und optisch darzustellen. Darüber hinaus
ist die Möglichkeit
gegeben, mittels vordefinierter Signalverläufe 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ßlich können die
in 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
und das erfindungsgemäße System
unabhängig
davon, in welchem Entwicklungsstadium sich die Steuerung in 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.
-
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 307 und 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 1,32V 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 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 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 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.
-
Ein
weiterer Eingriffspunkt sind die Ein- und Ausgänge der Open-Loop-Configuration
bzw. der Real-Time-I/O an den Eingriffspunkten 311 und 310. An
dieser Stelle werden die Signale dann Hardwaresignale HWS genannt.
-
Die
dritte Eingriffsmöglichkeit
in diesem Ausführungsbeispiel,
also der dritte 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
wird lediglich der Eingriffspunkt im gesamten Signalpfad oder Signalverlauf
spezifiziert. Somit sind in 3 die Signalpfade
oder Signalverläufe
vom und zum Steuergerät,
die Zugriffsstellen bzw. Eingriffspunkte auf diese und die Punkte,
an denen Signale aus dein 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 Echtzeitein-/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, 311 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 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 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/O1 bis RTI/O4. Ebenso
werden an Eingriffspunkt 312 die Modellsignale MS, in diesem
Beispiel hier mit M1 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 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 K1
zu versehen, RTI/O2 beispielsweise mit einer Kennung K1, K2 und
z. B. M1 mit einer Kennung K1, K2, K3. So kann durch Kennung K1
und Kennung K2 der Signalpfad von ECU1 über RTI/O2 zu M1 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 5.
Darin sind wieder beispielhaft die Signale gemäß der Tabelle aus 4,
ECU1 bis ECU3, RTI/O1 bis RTI/O4 und M1 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 ECU1, RTI/O1 und M1, welchem
durchgängig
eine Kennung 1 zugeordnet wird, oder aber, es wird in entsprechenden
Schnittstellen zwischen ECU1 und RTI/O1 sowie RTI/O1 und M1 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/O2, M3 sowie ECU2, RTI/O3,
M4 und ECU3, RTI/O3, M4 oder ECU3, RTI/O4, M4. Im Pfad ECU3, RTI/O4,
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 1:1-Durchreichen. Dieser Eingriff und
diese Unterbrechung kann auch bei Eingriffspunkt 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 2 visualisiert werden und für den Benutzer
entflochten werden.
-
Neben
dem erfindungsgemäß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 Signalverläufe 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.