EP1671139A1 - System und verfahren zum testen von steuervorgängen bei einem fahrzeug - Google Patents
System und verfahren zum testen von steuervorgängen bei einem fahrzeugInfo
- Publication number
- EP1671139A1 EP1671139A1 EP04762742A EP04762742A EP1671139A1 EP 1671139 A1 EP1671139 A1 EP 1671139A1 EP 04762742 A EP04762742 A EP 04762742A EP 04762742 A EP04762742 A EP 04762742A EP 1671139 A1 EP1671139 A1 EP 1671139A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- signal
- signals
- intervention
- control processes
- vehicle
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/005—Testing of electric installations on transport means
- G01R31/006—Testing of electric installations on transport means on road vehicles, e.g. automobiles or trucks
- G01R31/007—Testing of electric installations on transport means on road vehicles, e.g. automobiles or trucks using microprocessors or computers
Definitions
- the invention is based on a system for testing control processes in a vehicle in accordance with the features of the independent claims not known from the prior art.
- Control units with their software are becoming increasingly important.
- the prerequisite for a greater depth of testing while shortening development cycles is the extensive relocation of tests from the road to the laboratory and the standardization and automation of these tests.
- modern development and test methods as well as optimal tool support are required, such as the LabCar from ETAS GmbH, a hardware-in-the-loop test system in accordance with the white paper "LabCar” from 1999 release 10/1999 of ETAS GmbH & Co. KG, Stuttgart.
- the invention described below is intended to address this situation in test systems with regard to control processes in a vehicle, in particular in hardware-in-the-loop. Improve and optimize test systems such as LabCar.
- the system and the method for testing control processes in a vehicle are based on a simulation model that reacts to the control processes to be tested, with experimental software being advantageously superordinate in the simulation model and between the experiment software and a component that triggers the control processes a signal curve is formed, the signal curve being divided into at least two signals by at least two intervention points and at least one identifier being provided which enables the signals to be assigned to the signal curve.
- the points of intervention are expediently provided with identifiers or the signals generated by the points of intervention.
- the resulting signals are advantageously assigned to different signal groups and expediently these different signal groups or the signals assigned to them are optically represented or visualized.
- Point of intervention to enter a signal to replace such a signal in the signal curve for example, a signal output by a signal generator or a constant value that replaces the original signal in the context of a desired test scenario.
- the present invention thus aims to visualize the signal profiles within the test system associated with the component triggering the control processes, to display the values of the corresponding signals and to provide the user with additional functionality so that he can set up and operate the test system in an efficient manner ,
- Figure 1 schematically shows a control or regulation within the driver-vehicle environmental network.
- Figure 2 shows an inventive development scheme of the test system.
- FIG. 3 schematically shows a signal curve or signal flow in a test system with corresponding intervention points.
- FIG. 4 shows a signal or signal value representation table according to the invention.
- FIG. 5 shows a possible implementation of the identifiers according to the invention by using an identifier graph.
- the invention aims at the development and the validation of control processes in the case of components triggering a vehicle, in particular electronic controls or regulators or regulators in the automotive sector.
- the validation of these controls is sometimes a very complex process that cannot be carried out without the use of special tools.
- These tools or test systems are intended to enable the vehicle to be simulated in the laboratory through various steps in the development process and thus make the electronic control or controller believe that it is installed in the real vehicle.
- Such a controller typically has a large number of interfaces, i. H. Inputs and outputs that are coupled with other components in the vehicle and interact with them.
- these interfaces represent a very complex structure for the user in that it is difficult to find their way.
- the invention and its various forms are to be seen against this background.
- the aim of the present invention is therefore that on the one hand a user can keep an overview of the complexity of the system and that the efficiency in daily use of the system is increased considerably. It can also be used to improve software and software products that are used in a test system to control an experiment.
- Block 100 represents the driver and block 101 the environment.
- numerous signal flows can exist between the components vehicle, driver and environment.
- the driver is in this Representative for all other users of a vehicle function, such as other passengers.
- the environment also includes other vehicles or electronic systems in the vicinity of the vehicle, such as tools such.
- B. Diagnostic testers that are connected to the vehicle's electronic systems in the service plant start. This logical system architecture for control, regulation and
- Monitoring systems according to Figure 1 symbolizes the following sequence.
- the driver operates levers or switches in the vehicle, e.g. B. a turn signal or the accelerator pedal.
- This driver request is forwarded via the so-called setpoint generator 102 to the control unit 103, that is to say a component which triggers the control processes.
- the controller 103 processes this information and controls actuators 104. For example, if the
- control system will control the injection valves and throttle valve so that more fuel is brought into the combustion chamber.
- system or controlled system 105 is then a part of the vehicle that processes the action of the actuator, that is to say the cylinder that burns the fuel and transmits the generated torque to the vehicle.
- sensors 106 are needed that
- Detect the behavior of the vehicle or individual components If, for example, the speed desired by the driver is reached, this is detected by a sensor.
- the sensor forwards the information it detects to the controller so that it can react to it.
- the driver now perceives the behavior of his vehicle and will influence it accordingly.
- it also has
- FIG. 1 thus represent the signal flow in the manner just described as an example.
- a system for testing control operations on a vehicle must be able to simulate all of the units except the controller itself, which are shown in Figure 1. This can either be done by software or in some applications also requires the use of special electronics, hardware that the control unit, for. B. supplied with exactly the electrical signals, as they would also occur in the real vehicle.
- the test system is now equipped with software; so-called experiment software is superordinate to the simulation model enables the user to do the following: On the one hand, to configure the system, ie to make basic settings of the simulation model and any hardware used, and, furthermore, to put the control into operation, since modern controls are often equipped with extensive diagnostic functions.
- these functions are intended to determine whether the control system is supplied with implausible signals. If such cases occur, the control goes into an emergency running state, which makes a test with the test system no longer meaningful. This means that the experiment software must support the user to perform a simulation in which the controller does not go directly into such an emergency state, and also to perform an interactive test, which means that the
- Experiment software must provide functionality that enables the user to interact with the test system through an operating PC. And finally, record and manage data that arises during a test.
- the position of this experiment software as well as the interaction, that is to say the signal flow or the signal curves that are created, are shown again in more detail later in FIG. 3.
- a user now typically has the view of the test system shown in FIG. 2.
- a controller in block 201 the signal detection, in block 202 static actuator models and in block 203 dynamic ones
- Block 204 shows a model of route, driver and environment, which is followed by dynamic sensor models with block 205, static sensor models with block 206 and signal generation with block 207.
- the 200 typically has any number of inputs and outputs.
- the graphic shown in FIG. 2 is followed by the controller 200 in a clockwise direction.
- Output signals from the controller are detected by an optional signal detection. If the control is in the form of a physical object, the signal is recorded
- 201 for example, a hardware component. Then there is another optional unit that converts the electrical signals into physical units. B. a voltage into a temperature. Then in block 203 the dynamic
- Simulation of the actuator behavior in the test system This is followed by a simulation of the driver, the environment and the rest of the vehicle before the signal curve via corresponding units for signal generation, ie a dynamic sensor model 205, a static sensor model 206 and a signal generation 207 are fed back to the controller 200.
- the blocks or units shown in FIG. 2 are typically implemented in different 5th tools.
- the controller itself can exist either as a physical subject or as a model in a simulation tool.
- the blocks signal detection 201 and signal generation 207 can be present as electronic components, that is to say in hardware, or can be implemented in a simulation tool.
- the remaining blocks in Figure 2 are typically available in a simulation tool.
- the simulation model thus comprises at least the model of route, driver and environment as well as the dynamic actuator models and the dynamic sensor models, i.e. blocks 203 to 205 in Figure 2.
- the problem is that the signal curve5 shown in FIG. 2 is not unique. Rather, there is the possibility that an output signal from the controller is connected to several signal acquisition channels, which are then connected again to several static actuator models, etc. Furthermore, the problem that the user of the test system is exposed to is that the simulation tools just mentioned differ could be. This means that 0 z. B. the dynamic actuator models 203 are implemented in a tool A, while the static actuator models are present in a tool B.
- FIG. 3 now shows the signal flow or the signal profiles and access to signals in a test system, in particular the LapCar system mentioned in the introduction.
- the simulation software 308 is built on the one hand from the simulation model 307 and on the other hand from the experiment software 306.
- the component 300 to be tested which triggers the control processes that is to say for example the control unit or the controller (hardware or software implemented), is connected to a block 301 of the hardware and a block 302 of the real-time input / output (real time-i / o).
- an open-loop configuration OLC is optionally available between block 302 and the experiment software 306, depending on the signal direction, blocks 303 and 304. This so-called open loop configuration, represented by the
- Blocks 303 and 304 can be accessed in the signal path between the model and the hardware, and signals from a signal generator 305 or constant values can be fed in, for example.
- This open loop configuration OLC is the intermediate layer between the model specification and the drivers for the input / output hardware.
- the open loop configuration has several tasks. The
- the main task is to convert physical values into electrical values (for signals from the vehicle model to the control unit) and the reverse conversion of electrical values into physical values (for signals that are sent from the control unit to the vehicle).
- This essentially corresponds to the tasks that sensors (physical in electrical) and actuators (electrical in physical) perform in the vehicle. Sensors and actuators are in the open loop configuration
- Blocks 303 and 304 Blocks 303 and 304, modeled.
- Flow 0.24 liters per minute can be converted.
- the main function of modeling sensors and actuators is also the minimum requirement for an OLC. Since the OLC contains both the electrical and the physical value of every signal that is sent to or received by the control unit, it is suitable ideal as a central point for user intervention on the signals. For this purpose, both sensors and actuators have the option of influencing the physical as well as the electrical value in three variants; On the one hand, to pass the value 1: 1 through, on the other hand, to set the value 5 manually to a constant size, or to stimulate it, ie to get the value from a signal generator, so that signal sequences can be specified manually.
- the third intervention option in this exemplary embodiment is the inputs and outputs of the component which triggers the control processes, that is to say in particular of the control unit 300.
- This intervention point is designated 309, and the signals are called control unit signals SGS at this point.
- model signals, hardware signals and control unit signals are one and the same signal curve. With the corresponding designations, only the point of intervention in the entire signal path or signal course is specified.
- the signal paths or signal courses from and to the control device, the access points or intervention points thereon and the points at which signals from the signal generator or otherwise can be fed in are shown in FIG.
- signal flows or signal profiles can be specified and tracked, that is to say from the simulation model via the real-time output 302 to the control unit connections and vice versa.
- Signal properties can also be determined and edited here.
- a signal curve can be tracked across the intervention points 309, 310, 31 1 and 312 and nevertheless individual signals can be treated according to the intervention points. For this, these signals are translated into appropriate
- control unit signals SGS are thus obtained, which for example correspond to control unit pins, ECU pins (Electronic Control Unit) here in FIG. 4 ECU1 to ECU3.
- a plurality of hardware signals are then provided, for example, for different signal profiles, precisely in the real-time I / O 302 or behind the open loop configuration, shown here as hardware signals HWS, RTI / Ol to RTI / 04.
- the model signals MS in this example here with M1 to M5, are likewise used at the point of engagement 312.
- the number of individual signals in the signal groups is chosen arbitrarily and depends essentially; according to the respective test on the signal profiles.
- these signals can now be visualized or represented optically, as shown in this table, with further assignment to the respective signal curve of the individual signals. This is achieved by means of identifiers which are either assigned to the intervention points or to the individual signals.
- a first possibility of such identifiers is, for example, to provide ECU1 with an identifier Kl, RTI / 02, for example with an identifier K l, K2 and z.
- the signal path from ECU1 via RTI / 02 to Ml can be clearly understood by identifier K1 and identifier K2, and the advantages of visualizing the value display and the intervention options are given.
- a further possibility of the identification assignment is a so-called link graph 500 corresponding to FIG. 5.
- the signals according to the table from FIG. 4, ECU1 to ECU3, RTI / OL to RTI / 04 and M1 to M5 are shown again by way of example.
- the direction arrows in both directions are now selected in this graph.
- the signal direction can also be shown separately here.
- the corresponding identifiers can now either be assigned to the signals or the intervention points, here 502 and 503.
- a simple path is, for example, ECU1, RTI / Ol and Ml, to which an identifier 1 is continuously assigned, or alternatively, an identifier is assigned in corresponding interfaces between ECU1 and RTI / Ol and RTI / Ol and Ml, which the respective
- the invention can also be carried out in a computer program with program code which makes it possible to carry out all of the steps according to the invention when the program is executed on a computer.
- the identification adaptation, the identification change and in general the creation of the possibility of intervention can advantageously be implemented by a computer program with program code.
- this computer program can of course also be implemented on a computer program product with program code, which is stored on a machine-readable carrier and is used to carry out the method according to the invention when the program is executed on a computer.
- Such machine-readable carriers are, for example, memory modules such as EPROM, Flash-EPROM, ROM, ROM, EEPROM etc., but also CD-ROM, DVD, diskette and similar machine-readable carriers, as well as the possibility of reading the program into a computer system via text recognition.
- the invention can thus be used as a software product. This gives you the opportunity within a
- Test system that is used to validate developments in the field of automotive electronics, to visualize the signal path or signal loss through the test system and via the object to be validated, to display the values of these signals recorded during a test and to indicate certain options for intervening in the signal curve enable.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Chemical & Material Sciences (AREA)
- Combustion & Propulsion (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Combined Controls Of Internal Combustion Engines (AREA)
- Testing And Monitoring For Control Systems (AREA)
- Electrical Control Of Air Or Fuel Supplied To Internal-Combustion Engine (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
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
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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10345615A DE10345615A1 (de) | 2003-09-29 | 2003-09-29 | System und Verfahren zum Testen von Steuervorgängen bei einem Fahrzeug |
PCT/DE2004/001955 WO2005040838A1 (de) | 2003-09-29 | 2004-09-03 | System und verfahren zum testen von steuervorgängen bei einem fahrzeug |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1671139A1 true EP1671139A1 (de) | 2006-06-21 |
Family
ID=34441812
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP04762742A Ceased EP1671139A1 (de) | 2003-09-29 | 2004-09-03 | System und verfahren zum testen von steuervorgängen bei einem fahrzeug |
Country Status (6)
Country | Link |
---|---|
US (1) | US20070118319A1 (de) |
EP (1) | EP1671139A1 (de) |
JP (1) | JP2007507765A (de) |
CN (1) | CN1860374A (de) |
DE (1) | DE10345615A1 (de) |
WO (1) | WO2005040838A1 (de) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102006031242A1 (de) * | 2006-07-06 | 2008-01-10 | Robert Bosch Gmbh | Verfahren zum Durchführen eines Tests |
EP1898282B1 (de) * | 2006-09-11 | 2010-11-17 | dSPACE digital signal processing and control engineering GmbH | Verfahren zum Test eines elektronischen Steuerungssystems |
JP5059017B2 (ja) * | 2006-09-27 | 2012-10-24 | 富士通テン株式会社 | シミュレーション装置 |
EP1998160A1 (de) * | 2007-05-31 | 2008-12-03 | Nederlandse Organisatie voor toegepast- natuurwetenschappelijk onderzoek TNO | Vorrichtung und verfahren zur Prüfung eines Kraftfahrzeuges |
KR20100037151A (ko) * | 2007-07-23 | 2010-04-08 | 아시우스 테크놀로지스, 엘엘씨 | 다이어포닉 소리 변환 커플러 및 이어버드 |
US8204711B2 (en) * | 2009-03-25 | 2012-06-19 | GM Global Technology Operations LLC | System and apparatus for managing test procedures within a hardware-in-the-loop simulation system |
DE102009048981B4 (de) * | 2009-10-09 | 2016-12-29 | Dspace Digital Signal Processing And Control Engineering Gmbh | Vorrichtung zum Testen einer elektrischen Komponente |
US9973403B2 (en) * | 2014-05-09 | 2018-05-15 | Lawrence F. Glaser | Intelligent traces and connections in electronic systems |
CN104850112A (zh) * | 2014-11-04 | 2015-08-19 | 北汽福田汽车股份有限公司 | 电动汽车整车控制器测试方法和*** |
CN110134099B (zh) * | 2018-02-08 | 2021-08-24 | 中车株洲电力机车研究所有限公司 | 一种控制软件的测试***及方法 |
CN114061970A (zh) * | 2021-10-08 | 2022-02-18 | 东风本田汽车有限公司 | 一种车辆速度控制方法及装置 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2045592A1 (de) * | 1999-04-30 | 2009-04-08 | Horiba, Ltd. | Motor- oder Fahrzeugprüfvorrichtung |
US6846386B2 (en) * | 2000-06-22 | 2005-01-25 | Metso Paper Karlstad Ab | Method of ensuring flatness of a vane in a headbox by means of a mounting arrangement, headbox with such a mounting arrangement, a mounting arrangement and vane therefor |
US7076740B2 (en) * | 2002-01-15 | 2006-07-11 | National Instruments Corporation | System and method for performing rapid control prototyping using a plurality of graphical programs that share a single graphical user interface |
-
2003
- 2003-09-29 DE DE10345615A patent/DE10345615A1/de not_active Withdrawn
-
2004
- 2004-09-03 JP JP2006527263A patent/JP2007507765A/ja active Pending
- 2004-09-03 WO PCT/DE2004/001955 patent/WO2005040838A1/de active Application Filing
- 2004-09-03 CN CNA2004800283058A patent/CN1860374A/zh active Pending
- 2004-09-03 US US10/574,051 patent/US20070118319A1/en not_active Abandoned
- 2004-09-03 EP EP04762742A patent/EP1671139A1/de not_active Ceased
Non-Patent Citations (1)
Title |
---|
See references of WO2005040838A1 * |
Also Published As
Publication number | Publication date |
---|---|
JP2007507765A (ja) | 2007-03-29 |
WO2005040838A1 (de) | 2005-05-06 |
CN1860374A (zh) | 2006-11-08 |
DE10345615A1 (de) | 2005-05-19 |
US20070118319A1 (en) | 2007-05-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2367083B1 (de) | Vorrichtung zur Erstellung eines Programms für eine speicherprogrammierbare Steuerung, Programmiereinrichtung und Verfahren zur Programmierung einer speicherprogrammierbaren Steuerung | |
DE102012211981A1 (de) | Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms | |
WO2008152010A1 (de) | Vorrichtung und verfahren zur simulation einer entwicklungsanlage für einen prüfstand | |
EP1309844A2 (de) | Verfahren und anordnung zur abgasuntersuchung an kraftfahrzeugen mit bordeigenem motorsteuerungs- und diagnosesystem | |
EP1428126A2 (de) | Verfahren zur softwareverifikation für steuereinheiten und verifikationssystem | |
WO2008003615A1 (de) | Verfahren zum durchführen eines tests | |
WO2005040838A1 (de) | System und verfahren zum testen von steuervorgängen bei einem fahrzeug | |
DE112008001098T5 (de) | Systeme und Verfahren zum Simulieren eines Fahrzeugbetriebs | |
EP2343611A1 (de) | Verfahren zur rechnergestützten Erzeugung eines ausführbaren Steuerungsprogramms und diesbezügliche Konfigurationseinrichtung | |
DE102004012143B3 (de) | Verfahren zum Testen der Funktion von in einem Kraftfahrzeug eines bestimmten Typs verbauten, über einen Kommunikationsbus adressierbaren elektronischen und elektrischen Komponenten | |
EP1597641A1 (de) | Steuergerät zum steuern eines antriebsaggregates eines fahrzeugs | |
DE102009034242A1 (de) | Verfahren und Vorrichtung zum Prüfen eines Steuergeräts eines Fahrzeugs | |
EP1639416A1 (de) | Elektronische steuereinheit und verfahren zur spezifikation einer software-architektur f r eine elektronische steuereinheit | |
WO2007065585A1 (de) | Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten | |
WO2008037656A2 (de) | Rechnerbasiertes werkzeug und verfahren zum extrahieren des funktionscodes von steuergeräten | |
AT511297B1 (de) | Verfahren zur Erzeugung eines Modells einer Kommunikationsaufgabe | |
DE102009053794A1 (de) | Datenverarbeitungseinheit sowie Verfahren zur Herstellung eins Maschinenfiles | |
DE102016225041B4 (de) | Verfahren zum Betreiben einer Brennkraftmaschine, Steuereinrichtung für eine Brennkraftmaschine, und Brennkraftmaschine mit einer solchen Steuereinrichtung | |
EP4363981A1 (de) | Verfahren und vorrichtung zum rekonfigurieren einer systemarchitektur eines automatisiert fahrenden fahrzeugs | |
DE102020207921A1 (de) | Verfahren zum Einrichten eines Fahrzeugsimulationsmodells | |
DE10339336A1 (de) | Verfahren zur Entwicklung einer technischen Komponente | |
AT525591A1 (de) | Verfahren und Vorrichtung zur automatischen Analyse eines Diagnosesystems eines Fahrzeugs | |
DE102022131564A1 (de) | Steuervorrichtung für ein Zonensteuergerät, Zonensteuergerät und Verfahren zum Betreiben eines Zonensteuergeräts | |
DE102006008726B4 (de) | Verfahren und Vorrichtung zum Aktualisieren einer Anlagensoftware | |
EP1691309A1 (de) | Kontextsensitive Benutzerhilfe in einer softwarebasierten Entwicklungsumgebung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20060502 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR |
|
17Q | First examination report despatched |
Effective date: 20060808 |
|
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20101015 |