WO1998010300A1 - Verfahren zum prüfen der bauteile eines systems in einem kraftfahrzeug - Google Patents

Verfahren zum prüfen der bauteile eines systems in einem kraftfahrzeug Download PDF

Info

Publication number
WO1998010300A1
WO1998010300A1 PCT/EP1997/004693 EP9704693W WO9810300A1 WO 1998010300 A1 WO1998010300 A1 WO 1998010300A1 EP 9704693 W EP9704693 W EP 9704693W WO 9810300 A1 WO9810300 A1 WO 9810300A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
control device
software
control unit
loaded
Prior art date
Application number
PCT/EP1997/004693
Other languages
English (en)
French (fr)
Inventor
Norbert Ehmer
Original Assignee
Itt Manufacturing Enterprises, Inc.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Itt Manufacturing Enterprises, Inc. filed Critical Itt Manufacturing Enterprises, Inc.
Priority to US09/254,358 priority Critical patent/US6401049B1/en
Priority to JP51220698A priority patent/JP2001506021A/ja
Priority to EP97940138A priority patent/EP0923743B1/de
Priority to DE59707567T priority patent/DE59707567D1/de
Publication of WO1998010300A1 publication Critical patent/WO1998010300A1/de

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M17/00—Testing of vehicles
    • G01M17/007—Wheeled or endless-tracked vehicles
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M15/00—Testing of engines
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01M—TESTING STATIC OR DYNAMIC BALANCE OF MACHINES OR STRUCTURES; TESTING OF STRUCTURES OR APPARATUS, NOT OTHERWISE PROVIDED FOR
    • G01M15/00—Testing of engines
    • G01M15/04—Testing internal-combustion engines
    • G01M15/05—Testing internal-combustion engines by combined monitoring of two or more different engine parameters

Definitions

  • the present invention relates to a method for checking the functionality of the components of a system in a motor vehicle, the system having at least one software-operated control device which can be connected to a control device, software can be loaded into the control device by means of the control device and before the functionality of the components of the system is checked, the control device loads testing software into the control device.
  • this object is achieved with a method of the type mentioned, the special feature of which there is that after the test has been carried out, the operating software by means of which the control and / or regulation of the system is carried out is loaded from the control device into the control device.
  • test software it is easily possible to adapt the test software to changes in the system. While it was necessary in the prior art to change the control unit as a whole because the software was stored in the control unit without the possibility of modification, the test software can be changed in the method proposed according to the invention and loaded into the corresponding control unit via the control unit if the test software is needed. It is then only necessary to store the test software in the corresponding control devices.
  • control units are required, for example, at the end of the production process to check the components of the system, as well as in workshops, at certain intervals - depending on the time or based on the kilometers traveled since the last check - or also based on another, but possibly not recognized to be able to carry out a check of the functionality of the components of the system in more specifically identified errors.
  • the test software is therefore replaced by the operating software after the test has been carried out.
  • the total storage space requirement is low. It proves to be an advantage that the operating software is not stored in the control unit during the test process, but only the test software. This means that the test software has the full space and the entire capacity of the control unit available during the test process.
  • the loading of the test software takes place after the make the connection between control unit and control unit automatically.
  • the functionality of the components of the system should generally be checked. A particularly simple handling and execution of the test is achieved if the test software is loaded automatically.
  • the test can also be started automatically when the test software has finished loading.
  • system-specific data are transmitted to the control device.
  • This system-specific data can be, for example, a version number of the control device and / or information about the components integrated in the system.
  • the test software that corresponds to the system-specific data is then loaded from the control device.
  • several test programs can be stored in the control device, which correspond to different possibilities of the system-specific data.
  • the corresponding test software is then selected in the control unit.
  • system-specific data in the control device may be evaluated in such a way that, on the basis of the components identified on the basis of the system-specific data, certain target values and tolerances are correspondingly determined in a table and are loaded from the control device into the control device as part of the test software.
  • test software it is also conceivable to adapt the test software accordingly with regard to some test steps.
  • the measures according to the invention also allow simple adaptation to changes in the operating software if the operating software is not temporarily stored in the control device in order to subsequently load the same software back into the control device.
  • the modified operating software is then stored in the control units of the individual workshops.
  • the vehicles are then gradually tested for the components of their systems.
  • the correspondingly changed operating software is then loaded into the control units of the individual motor vehicles.
  • all vehicles are adapted to the changed operating software without control units in the motor vehicles having to be replaced.
  • the operating software is automatically loaded or reloaded after the completion of the test. This in turn makes handling the test easy.
  • the operating software is only loaded if the check has shown that there is no error in the system. If an error is detected, this error must first be corrected. A control unit without operating software can be treated like a faulty system. This means that a corresponding warning lamp is activated. After the fault has been remedied, it is advisable to check the components again to ensure that there is no further fault. Time can be saved if test software and possibly operating software do not have to be reloaded.
  • system-specific data are transmitted to the control device.
  • the operating software that corresponds to the system-specific data is then loaded from the control device.
  • the operating software can also be updated in a simple manner if different operating software versions are provided for different control devices, for example different types of vehicles.
  • a data memory is present in the control unit, in which data are stored during or after the completion of the test process. This makes it possible, for example, to create statistics about the quality rate, the number of bug fixes in the service or a statement about the reliability against the production date and the test station number.
  • the data memory is a non-volatile data memory, so that the data remain stored even when the on-board battery of the motor vehicle is disconnected. Especially for evaluations of a A longer period of time shows that there are no data losses.
  • parameters are stored in the control unit, which the operating software can access and by means of which an optimal adjustment to all components during operation can be made individually is made possible.
  • this not only makes it possible to detect and correct errors, but also to compensate for deviations which are within a tolerance and which do not yet represent an error, but which, under certain circumstances, can impair the function of the entire system.
  • test steps are documented. It has been shown to be advantageous that the test process as a whole is comprehensible and that the test process can also be documented over a longer period.
  • Fig. 2 an embodiment of a flow chart in the control device
  • FIG. 3 an embodiment of a flow chart in the control unit in cooperation with the flow chart of FIG. 2.
  • 1 shows a control device 1, which has a memory 6, in which, for example, different versions of test software for the corresponding control devices can be stored, as well as different versions of operating software for the corresponding control devices.
  • the control device 1 can transmit data to a control device 2 via a connecting line 4, e.g. Transfer test software or operating software. Likewise, data transmission from control unit 2 to control unit 1 can be provided, for example via a separate data line 5.
  • a connecting line 4 e.g. Transfer test software or operating software.
  • a data memory 3 is advantageously present in the control unit 2, in which data about the test process of the functionality of the components of the system installed in a motor vehicle can be stored. Data stored in the data memory 3 can also be transmitted to the control device 1. Likewise, depending on the tolerances of the various components, sensors, or actuators determined during the test, parameters can be stored in the data memory 3, which the operating software can access and by means of which an optimal adjustment to all components is made possible during operation.
  • FIG. 2 shows a flow chart of a part of the method that can run in the control device 1.
  • step 10 system-specific data are first transmitted from the control device to the control device. This transmission can take place, for example, by recognizing that the control unit 2 has been connected to the control unit 1 and, as a result, has caused the system-specific data to be transmitted. These system-specific data can relate, for example, to the version number of control unit 2 or also information about the system configuration or the components used.
  • step 11 it is then checked in the control device 1 whether corresponding test software is available for this system-specific data.
  • step 12 If this is not the case, the corresponding error is displayed in step 12.
  • the corresponding test software is available or can be generated on the basis of the transmitted system-specific data by changing tables, for example by adapting setpoints or tolerances, or by changing test programs in the control device 1, the corresponding test software is transmitted in step 13.
  • step 14 it is checked whether the transfer of the test software has been completed.
  • step 13 continues with the transfer of the test software.
  • step 14 If the check in step 14 shows that the test software has been completely transmitted, a corresponding transmission identifier is transmitted from the control device 1 to the control device 2 in step 15.
  • a control identifier is transmitted from the control device 2 to the control device 1 when the test procedure has been completed. This is explained in detail in connection with FIG. 3.
  • step 16 it is checked whether the test identifier has been transmitted by the control unit.
  • this check identifier is checked in step 17. If it is determined on the basis of the test identifier that an error has been detected during the test, an error log is created in step 18. This can be done, for example, by evaluating the test identifier if individual errors can thereby be individualized. In the simplest case, it is indicated that an error has been detected. However, further data can also be evaluated, which are transmitted from the control unit 2 to the control unit 1 if the detected error can be determined under certain circumstances by this additional data.
  • step 17 If the check in step 17 showed that no error was detected, the corresponding operating software for the control device is loaded in step 19 from the control device 1 into the control device 2.
  • This operating software can be read out, for example, from the memory 6 of the control device 1.
  • the operating software can also be updated in a simple manner.
  • the operating software can also not be loaded if, in addition to the operating software, the test software is loaded into the control unit before the test and the test software thus remains in the control unit. However, if the operating software is no longer stored in the control unit when the test software is loaded, the test software has a larger capacity available.
  • FIG. 3 shows an exemplary embodiment of a flowchart of the method that runs in control unit 2 and interacts with the flowchart of the method according to FIG. 2 that runs in control unit 1.
  • step 20 system-specific data are first transmitted from control device 2 to control device 1.
  • step 21 the test software is read in, which is transmitted from the control device 1 to the control device 2.
  • the operating software of the control unit 2 was advantageously previously transferred to the control unit 1 for temporary storage or is overwritten with the test software, i.e. deleted. This has the advantage that the test software can use the full resources. However, it is also conceivable to leave the operating software in the control unit 2.
  • step 22 it is checked whether the transmission identifier has been transmitted by the control device 1. According to step 15 of FIG. 2, this means that the transfer of the test software has been completed.
  • step 21 continues with reading in the test software.
  • step 23 in which the checking of the components of the system is started.
  • Step 24 checks whether the testing of the components of the system has been completed.
  • this data can also be parameters that are determined depending on the tolerances of the various components, sensors, or actuators determined during the test, which the operating software can access later and by means of which an optimal adjustment can be made during operation individually to all components.
  • Step 26 checks whether an error has been detected during the test.
  • an error log is created in accordance with step 27. It is possible to transmit the data in addition to the test identifier with the meaning "error detected” and to narrow down the error in the control device 1. It is also possible to completely create the error log in control unit 2 and to transmit it to control unit 1 for display.
  • step 26 If no error has been detected in step 26, the corresponding test identifier with the meaning "error-free" is transmitted to the control device 1 in step 28.
  • step 28 it is possible in step 28 to create a log of the test steps carried out, which have led to an error-free result, and to transmit them with the corresponding test identifier.
  • step 27 in addition to the error log, the test steps that led to an error-free result are also logged. It is then possible to create a documentation of all test steps.
  • step 29 the corresponding operating software is then loaded from the control device 1 into the control device 2.
  • test software is a simple adaptation of the test software to the various manufacturers, manufacturing plants or manufacturing processes, regardless of the operating software.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Chemical & Material Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Combustion & Propulsion (AREA)
  • Stored Programmes (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zum Prüfen sowie ggf. Einstellen auf individuelle Systemkomponenten der Bauteile eines Systems in einem Kraftfahrzeug, wobei das System wenigstens ein software-betriebenes Steuergerät aufweist, wobei das Steuergerät mit einem Leitgerät verbindbar ist, wobei mittels des Leitgerätes Software in das Steuergerät geladen werden kann, wobei vor einer Prüfung der Bauteile des Systems von dem Leitgerät eine Prüfsoftware in das Steuergerät geladen wird.

Description

Verfahren zum Prüfen der Bauteile eines Systems in einem Kraftfahrzeug
Die vorliegende Erfindung betrifft ein Verfahren zum Prüfen der Funktionsfähigkeit der Bauteile eines Systems in einem Kraftfahrzeug, wobei das System wenigstens ein software-be- triebenes Steuergerät aufweist, das mit einem Leitgerät verbindbar ist, wobei mittels des Leitgerätes Software in das Steuergerät geladen werden kann und wobei vor einer Prüfung der Funktionsfähigkeit der Bauteile des Systems von dem Leitgerät eine PrüfSoftware in das Steuergerät geladen wird.
Der Anmelderin ist bereits ein derartiges Verfahren bekannt, bei dem in dem Steuergerät sowohl die Betriebssoftware zur Steuerung bzw. Regelung des Systems abgelegt ist sowie ebenfalls dauerhaft eine PrüfSoftware, mittels der eine Überprüfung der Bauteile des Systems auf richtigen Einbau sowie auf die Funktion der Bauteile erfolgt. Ein derartiges Verfahren wird beispielsweise im Zusammenhang mit einem Anti- blockiersystem in einer Bremsanlage eines Kraftfahrzeuges eingesetzt.
Es ist die Aufgabe der vorliegenden Erfindung, die Prüfung der Funktionsfähigkeit der Bauteile eines Systems mit möglichst geringem Aufwand an Änderungen des Systems und mit geringem Speicherplatzbedarf durchführen zu können.
Erfindungsgemäß wird diese Aufgabe mit einem Verfahren der eingangs genannten Art gelöst, dessen Besonderheit darin besteht, daß daß nach dem Durchführen der Prüfung die Betriebssoftware, mittels der die Steuerung und/oder Regelung des Systems erfolgt, von dem Leitgerät in das Steuergerät geladen wird.
Bei dem erfindungsgemäßen Verfahren ist es in einfacher Weise möglich, die PrüfSoftware an Änderungen des Systemes anzupassen. Während es beim Stand der Technik notwendig war, das Steuergerät insgesamt zu ändern, weil die Software ohne Änderungsmöglichkeit in dem Steuergerät abgelegt war, kann bei dem erfindungsgemäß vorgeschlagenen Verfahren die Prüfsoftware geändert werden und über das Leitgerät in das entsprechende Steuergerät geladen werden, wenn die PrüfSoftware benötigt wird. Es muß dann also lediglich die PrüfSoftware in den entsprechenden Leitgeräten abgelegt sein. Die Leitgeräte werden dabei beispielsweise am Ende des Produktionsprozesses benötigt, um eine Prüfung der Bauteile des Systems vorzunehmen sowie in Werkstätten, um in bestimmten Intervallen -zeitabhängig oder aufgrund der seit der letzten Prüfung zurückgelegten Kilometer- oder auch aufgrund eines anderweitig erkannten, aber unter Umständen nicht näher identifizierten Fehlers eine Prüfung der Funktionsfähigkeit der Bauteile des Systems vornehmen zu können.
Bei dem Verfahren nach der Erfindung wird also nach dem Durchführen der Prüfung die die Prüfsoftware durch die Betriebssoftware ersetzt. Dadurch wird der insgesamt benötigte Speicherplatzbedarf gering. Als Vorteil erweist es sich dabei, daß während des Prüf organges die Betriebssoftware nicht in dem Steuergerät abgelegt ist, sondern nur die Prüf- software. Dadurch steht der PrüfSoftware während des Prüf- vorganges der volle Platz und die gesamte Kapazität des Steuergerätes zur Verfügung.
Bei einer vorteilhaften Ausgestaltung des Verfahren nach Anspruch 2 erfolgt das Laden der Prüfsoftware nach dem Her- stellen der Verbindung zwischen Steuergerät und Leitgerät selbsttätig. Wenn das Steuergerät mit dem Leitgerät verbunden wird, soll in der Regel eine Prüfung der Funktionsfähigkeit der Bauteile des Systems vorgenommen werden. Eine besonders einfache Handhabung und Durchführung der Prüfung wird erreicht, wenn das Laden der PrüfSoftware selbsttätig erfolgt. Dabei kann auch der Start der Prüfung selbsttätig vorgenommen werden, wenn das Laden der PrüfSoftware beendet ist.
Bei einer weiteren vorteilhaften Ausgestaltung des Verfahrens nach Anspruch 3 werden an das Leitgerät systemspezifische Daten übertragen. Diese systemspezifischen Daten können dabei beispielsweise eine Versionsnummer des Steuergerätes und/oder Informationen über die in das System integrierten Bauteile sein. Von dem Leitgerät wird dann die PrüfSoftware geladen, die den systemspezifischen Daten entspricht. Dabei können in dem Leitgerät mehrere Prüfprogramme abgelegt sein, die verschiedenen Möglichkeiten der systemspezifischen Daten entsprechen. Es wird dann also in dem Leitgerät die entsprechende PrüfSoftware ausgewählt.
Es ist auch möglich, daß die systemspezifischen Daten in dem Leitgerät dahingehend ausgewertet werden, daß anhand der aufgrund der systemspezifischen Daten identifizierten Bauteile bestimmte Sollwerte und Toleranzen in einer Tabelle entsprechend bestimmt werden und als Teil der Prüfsoftware von dem Leitgerät in das Steuergerät geladen werden.
Ebenso ist es auch denkbar, die Prüfsoftware hinsichtlich einiger Prüfschritte entsprechend anzupassen.
Wenn in dem Leitgerät alle Versionen der Betriebssoftware abgelegt sind, die aufgrund von Systemkonfigurationen und verwendeten Bauteilen auftreten können, kann vor dem Laden der Prüfsoftware in das Steuergerät die Betriebssoftware im Steuergerät gelöscht werden.
Es ist jedoch auch möglich, die Betriebssoftware von dem Steuergerät in das Leitgerät zur zwischenzeitlichen Speicherung umzuladen.
Durch die Maßnahmen nach der Erfindung ist außerdem eine einfache Anpassung an Änderungen der Betriebssoftware möglich, wenn keine Zwischenspeicherung der Betriebssoftware in dem Leitgerät erfolgt, um dieselbe Software anschließend wieder in das Steuergerät zu laden.
In die Leitgeräte der einzelnen Werkstätten wird dann die entsprechend geänderte Betriebssoftware abgelegt. Nach und nach werden die Fahrzeuge dann einer Prüfung hinsichtlich der Bauteile ihrer Systeme unterzogen. Nach Abschluß der Prüfung wird dann jedesmal die entsprechend geänderte Betriebssoftware in die Steuergeräte der einzelnen Kraftfahrzeuge geladen. Nach und nach erfolgt also in allen Fahrzeugen eine Anpassung an die geänderte Betriebssoftware, ohne daß deswegen Steuergeräte in den Kraftfahrzeugen ausgetauscht werden müßten.
Ebenso kann dabei bei der Herstellung des Fahrzeuges berücksichtigt werden, daß verschiedene Fahrzeugtypen unterschiedliche Betriebssoftware benötigen. Es müssen dann also bei der Produktion der Fahrzeuge keine unterschiedlichen Steuergeräte vorgehalten werden.
Bei der Ausgestaltung des Verfahrens nach Anspruch 5 wird nach dem Abschluß der Prüfung die Betriebssoftware selbsttätig geladen oder zurückgeladen. Dadurch erfolgt wiederum eine einfache Handhabung bei der Durchführung der Prüfung. Bei der Ausgestaltung des Verfahrens nach Anspruch 5 wird die Betriebssoftware nur dann geladen, wenn die Prüfung ergeben hat, daß in dem System kein Fehler vorliegt. Wenn ein Fehler erkannt wird, muß zunächst dieser Fehler behoben werden. Ein Steuergerät ohne Betriebssoftware kann dabei wie eine fehlerhafte Anlage behandelt werden. Das heißt, es wird eine entsprechende Warnlampe angesteuert. Nachdem der Fehler behoben worden ist, ist es dabei zweckmäßig, die Prüfung der Bauteile erneut vorzunehmen, um sicherzugehen, daß kein weiterer Fehler vorliegt. Dabei kann Zeit gespart werden, wenn nicht erneut Prüfsoftware und gegebenenfalls Betriebssoftware umgeladen werden muß.
Bei einer vorteilhaften Ausgestaltung des Verfahrens nach Anspruch 6 werden an das Leitgerät systemspezifische Daten übertragen. Von dem Leitgerät wird dann die Betriebssoftware geladen, die den systemspezifischen Daten entspricht. Dabei kann in einfacher Weise ein Update der Betriebssoftware auch dann realisiert werden, wenn verschiedene Betriebssoftwareversionen für verschiedene Steuergeräte - beispielsweise unterschiedlicher Fahrzeugtypen - vorgesehen sind.
Bei einer weiteren Ausgestaltung des Verfahrens nach Anspruch 8 ist in dem Steuergerät ein Datenspeicher vorhanden, in den Daten während oder nach Abschluß des PrüfVorganges abgelegt werden. Dadurch ist es möglich, beispielsweise über das Herstellungsdatum und die Prüfplatznummer eine Statistik zu erstellen über die Qualitätsrate, die Zahl der Fehlerbehebungen im Service oder auch eine Aussage über die Ausfallsicherheit zu machen.
Als vorteilhaft erweist es sich bei der Ausgestaltung des Verfahrens nach Anspruch 8, daß der Datenspeicher ein nichtflüchtiger Datenspeicher ist, so daß also auch bei einem Abklemmen der Bordbatterie des Kraftfahrzeuges die Daten gespeichert bleiben. Insbesondere für Auswertungen über ei- nen längeren Zeitraum hin zeigt sich dabei, daß keine Datenverluste auftreten.
Bei der Ausgestaltung des Verfahren nach Anspruch 9 werden abhängig von den bei der Prüfung ermittelten Toleranzen der verschiedenen Bauteile, Sensoren, oder Aktoren Parameter im Steuergerät gespeichert werden, auf die die Betriebssoftware zugreifen kann und mittels denen während des Betriebes ein optimaler Angleich individuell an alle Komponenten ermöglicht wird.
Vorteilhaft wird dadurch nicht nur eine Erkennung und Behebung von Fehlern möglich sondern es können auch Abweichungen ausgeglichen werden, die innerhalb einer Toleranz liegen und noch keinen Fehler darstellen aber unter Umständen die Funktion des gesaraten Systems beeinträchtigen können.
Bei einer weiteren Ausgestaltung des Verfahrens nach Anspruch 10 erfolgt eine Dokumentation aller Prüfschritte. Vorteilhaft zeigt sich dabei, daß der PrüfVorgang insgesamt nachvollziehbar wird und auch der Prüfvorgang über einen längeren Zeitraum dokumentiert werden kann.
Ein Ausführungsbeispiel der Erfindung ist in der Zeichnung näher dargestellt. Es zeigen dabei:
Fig. 1: eine Prinzipdarstellung eines Leitgerätes und eines Steuergerätes im Zusammenwirken,
Fig. 2: ein Ausführungsbeispiel eines Ablaufdiagrammes im Leitgerät und
Fig. 3: ein Ausführungsbeispiel eines Ablaufdiagrammes im Steuergerät im Zusammenwirken mit dem Ablaufdiagramm nach Fig. 2. Fig. 1 zeigt ein Leitgerät 1, das einen Speicher 6 aufweist, in dem beispielsweise verschiedene Versionen von Prüfsoftware für die entsprechenden Steuergeräte gespeichert sein können wie auch verschiedene Versionen von Betriebssoftware für die entsprechenden Steuergeräte.
Das Leitgerät 1 kann an ein Steuergerät 2 über eine Verbindungsleitung 4 Daten wie z.B. PrüfSoftware oder Betriebssoftware übertragen. Ebenso kann - beispielsweise über eine separate Datenleitung 5 - eine Datenübertragung von dem Steuergerät 2 zu dem Leitgerät 1 vorgesehen sein.
Vorteilhaft ist in dem Steuergerät 2 ein Datenspeicher 3 vorhanden, in dem Daten über den PrüfVorgang der Funktionsfähigkeit der Bauteile des in ein Kraftfahrzeug eingebauten Systems gespeichert werden können. In dem Datenspeicher 3 gespeicherte Daten können dabei ebenfalls an das Leitgerät 1 übertragen werden. Ebenso können in dem Datenspeicher 3 abhängig von den bei der Prüfung ermittelten Toleranzen der verschiedenen Bauteile, Sensoren, oder Aktoren Parameter gespeichert werden, auf die die Betriebssoftware zugreifen kann und mittels denen während des Betriebes ein optimaler Angleich individuell an alle Komponenten ermöglicht wird.
Fig. 2 zeigt ein Ablaufdiagramm eines Teiles des Verfahrens, das in dem Leitgerät 1 ablaufen kann. In dem Schritt 10 werden dabei zunächst von dem Steuergerät systemspezifische Daten an das Leitgerät übertragen. Diese Übertragung kann dabei beispielsweise erfolgen, indem erkannt wird, daß das Steuergerät 2 an das Leitgerät 1 angeschlossen wurde und - dadurch veranlaßt - die systemspezifischen Daten übertragen werden. Diese systemspezifischen Daten können dabei beispielsweise die Versionsnummer des Steuergerätes 2 betreffen oder auch Informationen über die Systemkonfiguration oder die verwendeten Bauteile. In dem Schritt 11 wird dann in dem Leitgerät 1 überprüft, ob zu diesen systemspezifischen Daten eine entsprechende Prüfsoftware vorhanden ist.
Ist dies nicht der Fall, erfolgt in dem Schritt 12 eine Anzeige des entsprechenden Fehlers.
Wenn die entsprechende Prüfsoftware vorhanden ist bzw. anhand der übertragenen systemspezifischen Daten durch Änderung von Tabellen, beispielsweise durch Anpassung von Sollwerten oder Toleranzen, oder durch Änderung von Prüfprogrammen in dem Leitgerät 1 generiert werden kann, erfolgt in dem Schritt 13 die Übertragung der entspechenden PrüfSoftware.
In dem Schritt 14 wird überprüft, ob die Übertragung der PrüfSoftware abgeschlossen ist.
Ist dies nicht der Fall, wird in dem Schritt 13 mit der Übertragung der PrüfSoftware fortgefahren.
Wenn die Überprüfung in dem Schritt 14 ergibt, daß die Prüf- software vollständig übertragen worden ist, wird in dem Schritt 15 eine entsprechende Übertragungskennung von dem Leitgerät 1 an das Steuergerät 2 übertragen.
Von dem Steuergerät 2 wird an das Leitgerät 1 eine Prüfungskennung übertragen, wenn der PrüfVorgang abgeschlossen worden ist. Im einzelnen wird dies im Zusammenhang mit Figur 3 erläutert .
In dem Schritt 16 wird überprüft, ob die Prüfungskennung von dem Steuergerät übertragen worden ist.
Ist dies der Fall, erfolgt in dem Schritt 17 eine Überprüfung dieser Prüfungskennung. Wird anhand der Prüfungskennung festgestellt, daß bei der Prüfung ein Fehler erkannt worden ist, so wird in dem Schritt 18 ein Fehlerprotokoll erstellt. Dies kann beispielsweise durch Auswertung der Prüfungskennung erfolgen, wenn sich dadurch einzelne Fehler individualisieren lassen. Im einfachsten Falle wird angezeigt, daß ein Fehler erkannt worden ist. Es können aber auch weitere Daten ausgewertet werden, die von dem Steuergerät 2 an das Leitgerät 1 übertragen werden, wenn sich durch diese weiteren Daten unter Umständen der erkannte Fehler feststellen läßt.
Wenn die Überprüfung in dem Schritt 17 ergab, daß kein Fehler erkannt wurde, wird die entsprechende Betriebssoftware für das Steuergerät in dem Schritt 19 von dem Leitgerät 1 in das Steuergerät 2 geladen.
Diese Betriebssoftware kann dabei beispielsweise aus dem Speicher 6 des Leitgerätes 1 ausgelesen werden.
Es ist dabei möglich, daß zu Beginn der Übertragung die Betriebssoftware des Steuergerätes 2 zu dem Leitgerät 1 übertragen und dort zwischengespeichert wurde. Es wird dann wieder die Betriebssoftware geladen, die in dem Steuergerät 2 vor der Prüfung geladen war.
Ebenso ist es auch möglich, daß in dem Speicher 6 verschiedene Versionen der Betriebssoftware gespeichert sind und daß anhand der übertragenen systemspezifischen Daten die entsprechende Version der Betriebssoftware ausgewählt wird. Dabei kann beispielsweise in einfacher Weise auch ein Update der Betriebssoftware durchgeführt werden.
Es kann aber auch das Laden der Betriebssoftware unterbleiben, wenn die Prüfsoftware zusätzlich zu der Betriebssoftware vor der Prüfung in das Steuergerät geladen wird und die PrüfSoftware also in dem Steuergerät verbleibt. Wenn die Betriebssoftware aber nicht mehr in dem Steuergerät abgelegt ist, wenn die PrüfSoftware geladen wird, steht der Prüfsoftware allerdings eine größere Kapazität zur Verfügung.
Fig. 3 zeigt ein Ausführungsbeispiel eines Ablaufdiagrammes des Verfahrens, das im Steuergerät 2 abläuft und mit dem Ablaufdiagramm des Verfahrens nach Fig. 2 zusammenwirkt, das in dem Leitgerät 1 abläuft.
In dem Schritt 20 werden zunächst systemspezifische Daten von dem Steuergerät 2 an das Leitgerät 1 übertragen.
In dem Schritt 21 wird darvn die PrüfSoftware eingelesen, die von dem Leitgerät 1 an das Steuergerät 2 übertragen wird. Die Betriebssoftware des Steuergerätes 2 wurde dabei vorteilhaft vorher zur Zwischenspeicherung an das Leitgerät 1 übertragen oder wird mit der PrüfSoftware überschrieben, d.h. gelöscht. Dies bringt den Vorteil, daß die PrüfSoftware die vollen Ressourcen nutzen kann. Es ist jedoch auch denkbar, die Betriebssoftware in dem Steuergerät 2 zu belassen.
In dem Schritt 22 wird überprüft, ob die Ubertragungskennung von dem Leitgerät 1 übertragen wurde. Entsprechend dem Schritt 15 der Figur 2 bedeutet dies, daß die Übertragung der PrüfSoftware abgeschlossen ist.
Wenn in dem Steuergerät 2 die Ubertragungskennung noch nicht erkannt worden ist, so wird mit dem Schritt 21 mit dem Einlesen der Prüfsoftware fortgefahren.
Wenn die Ubertragungskennung erkannt worden ist, so wird mit dem Schritt 23 fortgefahren, in dem mit der Prüfung der Bauteile des Systems begonnen wird. In dem Schritt 24 wird überprüft, ob die Prüfung der Bauteile des Systems abgeschlossen ist.
Ist dies nicht der Fall, wird mit der Prüfung der Funktionsfähigkeit der Bauteile des Systems (Schritt 23) fortgefahren.
Andernfalls werden in dem Schritt 25 die während der Prüfung ermittelten Daten in dem Datenspeicher 3 gespeichert. Diese Daten können dabei neben einer Dokumentation der Prüfschritte auch Parameter sein, die abhängig von den bei der Prüfung ermittelten Toleranzen der verschiedenen Bauteile, Sensoren, oder Aktoren Parameter ermittelt werden, auf die die Betriebssoftware später zugreifen kann und mittels denen während des Betriebes ein optimaler Angleich individuell an alle Komponenten ermöglicht wird.
In dem Schritt 26 wird überprüft, ob bei der Prüfung ein Fehler erkannt worden ist.
Ist dies der Fall, so wird entsprechend Schritt 27 ein Fehlerprotokoll erstellt. Es ist möglich, dabei neben der Prüfungskennung mit der Bedeutung "Fehler erkannt" auch die Daten zu übertragen und in dem Leitgerät 1 die nähere Eingrenzung des Fehlers vorzunehmen. Ebenso ist es auch möglich, in dem Steuergerät 2 das Fehlerprotokoll komplett zu erstellen und zur Anzeige an das Leitgerät 1 zu übertragen.
Wenn in dem Schritt 26 kein Fehler erkannt worden ist, wird in dem Schritt 28 die entsprechende Prüfungskennung mit der Bedeutung "fehlerfrei" an das Leitgerät 1 übertragen.
Es ist dabei möglich, in dem Schritt 28 ein Protokoll über die durchgeführten Prüfschritte, die zu einem fehlerfreien Ergebnis geführt haben, zu erstellen und mit der entsprechenden Prüfungskennung mit zu übertragen. Ebenso können in dem Schritt 27 neben dem Fehlerprotokoll auch die Prüfschritte protokolliert werden, die zu einem fehlerfreien Ergebnis geführt haben. Es ist dann möglich, eine Dokumentation aller Prüfschritte zu erstellen.
In dem Schritt 29 wird dann die entsprechende Betriebssoftware von dem Leitgerät 1 in das Steuergerät 2 geladen.
Insgesamt ist also eine einfache Anpassung der Prüfsoftware individuell an die verschiedenen Hersteller, Herstellerwerke oder Fertigungsprozesse möglich, unabhängig von der Betriebssoftware.

Claims

Patentansprüche
Verfahren zum Prüfen der Funktionsfähigkeit der Bauteile eines Systems in einem Kraftfahrzeug, wobei das System wenigstens ein software-betriebenes Steuergerät (2) aufweist, das mit einem Leitgerät (1) verbindbar ist, wobei mittels des Leitgerätes (1) Software in das Steuergerät (2) geladen werden kann (4) und wobei vor einer Prüfung der Funktionsfähigkeit der Bauteile des Systems von dem Leitgerät ( 1 ) eine PrüfSoftware in das Steuergerät (2) geladen wird (13), dadurch gekennzeichnet, daß nach dem Durchführen der Prüfung (16) die Betriebssoftware, mittels der die Steuerung und/oder Regelung des Systems erfolgt (19), von dem Leitgerät (1) in das Steuergerät (2) geladen wird (Schritt 19).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß nach dem Herstellen der Verbindung zwischen Steuergerät (2) und Leitgerät (1) das Laden der PrüfSoftware in das Steuergerät (2) selbsttätig erfolgt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß von dem Steuergerät (2) an das Leitgerät (1) systemspezifische Daten übertragen werden (10, 20) und von dem Leitgerät (1) die PrüfSoftware geladen wird, die den systemspezifischen Daten entspricht.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß nach dem Abschluß der Prüfung (16, 17) die Betriebssoftware selbsttätig geladen wird (19).
5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, daß die Betriebssoftware nur dann geladen wird, wenn die Prüfung ergeben hat, daß in dem System kein Fehler vorliegt (17, 19).
6. Verfahren nach einem der Ansprüche 3 bis 5, dadurch gekennzeichnet, daß von dem Steuergerät (2) an das Leitgerät ( 1 ) systemspezifische Daten übertragen werden (10,20) und von dem Leitgerät (1) die Betriebssoftware geladen wird, die den systemspezifischen Daten entspricht.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß in dem Steuergerät (2) ein Datenspeicher (3) vorhanden ist, in den Daten während oder nach Abschluß des PrüfVorganges abgelegt werden.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß der Datenspeicher (3) ein nichtflüchtiger Datenspeicher ist.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß abhängig von den bei der Prüfung ermittelten Toleranzen der verschiedenen Bauteile, Sensoren, oder Aktoren Parameter im Steuergerät gespeichert werden (3), auf die die Betriebssoftware zugreifen kann und mittels denen während des Betriebes ein optimaler Angleich individuell an alle Komponenten ermöglicht wird (25).
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß eine Dokumentation aller
Prüfschritte erfolgt (27, 28).
PCT/EP1997/004693 1996-09-04 1997-08-28 Verfahren zum prüfen der bauteile eines systems in einem kraftfahrzeug WO1998010300A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US09/254,358 US6401049B1 (en) 1996-09-04 1997-08-28 Process for inspecting the components of a system in a motor vehicle
JP51220698A JP2001506021A (ja) 1996-09-04 1997-08-28 自動車のシステムの構成要素を検査する方法
EP97940138A EP0923743B1 (de) 1996-09-04 1997-08-28 Verfahren zum prüfen der bauteile eines systems in einem kraftfahrzeug
DE59707567T DE59707567D1 (de) 1996-09-04 1997-08-28 Verfahren zum prüfen der bauteile eines systems in einem kraftfahrzeug

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19635839.6 1996-09-04
DE19635839A DE19635839A1 (de) 1996-09-04 1996-09-04 Verfahren zum Prüfen des Bauteils eines Systems in einem Kraftfahrzeug

Publications (1)

Publication Number Publication Date
WO1998010300A1 true WO1998010300A1 (de) 1998-03-12

Family

ID=7804579

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP1997/004693 WO1998010300A1 (de) 1996-09-04 1997-08-28 Verfahren zum prüfen der bauteile eines systems in einem kraftfahrzeug

Country Status (5)

Country Link
US (1) US6401049B1 (de)
EP (1) EP0923743B1 (de)
JP (1) JP2001506021A (de)
DE (2) DE19635839A1 (de)
WO (1) WO1998010300A1 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19921845A1 (de) * 1999-05-11 2000-11-23 Bosch Gmbh Robert Diagnosetestvorrichtung für Kraftfahrzeuge mit programmierbaren Steuergeräten
DE19961589A1 (de) * 1999-12-21 2001-07-05 Bosch Gmbh Robert Serviceelement in verteilten Systemen
US7636665B2 (en) * 2000-01-04 2009-12-22 Intuit Inc. Method and system for remotely managing business and employee administration functions
DE102005013935A1 (de) * 2005-03-26 2006-10-05 Daimlerchrysler Ag Verfahren zum mobilen Prüfen von Aggregaten, insbesondere von Kraftfahrzeug-Motoren und -Getrieben
US8326959B2 (en) * 2009-09-04 2012-12-04 Spirit Aerosystems, Inc. Virtual production testing of large integrated products
US8754779B2 (en) 2010-08-18 2014-06-17 Snap-On Incorporated System and method for displaying input data on a remote display device
US9330507B2 (en) 2010-08-18 2016-05-03 Snap-On Incorporated System and method for selecting individual parameters to transition from text-to-graph or graph-to-text
US9633492B2 (en) 2010-08-18 2017-04-25 Snap-On Incorporated System and method for a vehicle scanner to automatically execute a test suite from a storage card
US8560168B2 (en) 2010-08-18 2013-10-15 Snap-On Incorporated System and method for extending communication range and reducing power consumption of vehicle diagnostic equipment
US9117321B2 (en) 2010-08-18 2015-08-25 Snap-On Incorporated Method and apparatus to use remote and local control modes to acquire and visually present data
US8463953B2 (en) 2010-08-18 2013-06-11 Snap-On Incorporated System and method for integrating devices for servicing a device-under-service
US8983785B2 (en) 2010-08-18 2015-03-17 Snap-On Incorporated System and method for simultaneous display of waveforms generated from input signals received at a data acquisition device
JP5768697B2 (ja) * 2011-12-15 2015-08-26 富士通株式会社 動作テスト方法、情報処理装置およびプログラム
JP2014032488A (ja) * 2012-08-02 2014-02-20 Denso Corp 制御装置の出荷検査方法
DE102019208862B4 (de) * 2019-06-18 2021-12-30 Volkswagen Aktiengesellschaft Verfahren zum Durchführen einer Testfahrt

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4532594A (en) * 1981-07-13 1985-07-30 Nissan Motor Company, Limited Multiple microcomputer system with comonitoring/back-up for an automotive vehicle
WO1989006839A1 (en) * 1988-01-15 1989-07-27 Micro Processor Systems, Inc. Interchangeable diagnostic instrument system
EP0465793A2 (de) * 1990-07-09 1992-01-15 Mercedes-Benz Ag Mehrrechnersystem für Steuer- und Diagnosegeräte bei einem Kraftfahrzeug
EP0599488A2 (de) * 1992-11-18 1994-06-01 Canon Information Systems, Inc. Verfahren und Vorrichtung zur Prüfung einer Schnittstellekarte

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4592053A (en) * 1982-02-19 1986-05-27 Omron Tateisi Electronics Co. Programmable controller
DE3546127A1 (de) * 1985-12-24 1987-06-25 Bosch Gmbh Robert Verfahren zur automatischen ueberpruefung von steuergeraeten
JPH0827645B2 (ja) * 1987-04-27 1996-03-21 株式会社東芝 プログラマブルコントロ−ラ
DE3717012A1 (de) * 1987-05-21 1988-12-08 Vdo Schindling Verfahren zur programmierung eines digitalen steuergeraetes
JPH0776735B2 (ja) * 1988-09-28 1995-08-16 富士重工業株式会社 車輌診断システム
JPH0776736B2 (ja) * 1988-09-28 1995-08-16 富士重工業株式会社 車輌診断システム
US5278759A (en) * 1991-05-07 1994-01-11 Chrysler Corporation System and method for reprogramming vehicle computers
US5255208A (en) * 1991-08-08 1993-10-19 Aeg Westinghouse Transportation Systems, Inc. On-line processor based diagnostic system
DE4238539A1 (de) * 1992-11-14 1994-05-19 Vdo Schindling Verfahren zur Programmierung eines Steuergerätes ohne Diagnoseschnittstelle
US5541840A (en) * 1993-06-25 1996-07-30 Chrysler Corporation Hand held automotive diagnostic service tool
DE4400079C2 (de) * 1994-01-04 1997-01-30 Bosch Gmbh Robert Verfahren zur Prüfung von elektronischen Steuergeräten
US5646865A (en) * 1994-10-27 1997-07-08 General Motors Corporation Automotive diagnostic communications
US5884202A (en) * 1995-07-20 1999-03-16 Hewlett-Packard Company Modular wireless diagnostic test and information system
US6009360A (en) * 1996-10-07 1999-12-28 Spx Corporation Engine analyzer with real-time digital display
US5908455A (en) * 1996-10-07 1999-06-01 Hewlett-Packard Company High performance automotive diagnostics instrumentation architecture
US6134489A (en) * 1997-12-24 2000-10-17 Smedley; Randy C. Automobile cruise control parameter recording apparatus
US6169943B1 (en) * 1999-07-14 2001-01-02 Eaton Corporation Motor vehicle diagnostic system using hand-held remote control

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4532594A (en) * 1981-07-13 1985-07-30 Nissan Motor Company, Limited Multiple microcomputer system with comonitoring/back-up for an automotive vehicle
WO1989006839A1 (en) * 1988-01-15 1989-07-27 Micro Processor Systems, Inc. Interchangeable diagnostic instrument system
EP0465793A2 (de) * 1990-07-09 1992-01-15 Mercedes-Benz Ag Mehrrechnersystem für Steuer- und Diagnosegeräte bei einem Kraftfahrzeug
EP0599488A2 (de) * 1992-11-18 1994-06-01 Canon Information Systems, Inc. Verfahren und Vorrichtung zur Prüfung einer Schnittstellekarte

Also Published As

Publication number Publication date
US6401049B1 (en) 2002-06-04
DE19635839A1 (de) 1998-03-05
EP0923743A1 (de) 1999-06-23
EP0923743B1 (de) 2002-06-19
DE59707567D1 (de) 2002-07-25
JP2001506021A (ja) 2001-05-08

Similar Documents

Publication Publication Date Title
WO1998010300A1 (de) Verfahren zum prüfen der bauteile eines systems in einem kraftfahrzeug
DE19921845A1 (de) Diagnosetestvorrichtung für Kraftfahrzeuge mit programmierbaren Steuergeräten
DE102017121761B4 (de) Elektropneumatisches Bremssystem mit Testmodus für den pneumatischen Backup-Bremskreis sowie Fahrzeug mit einem solchen Bremssystem
DE102020130277A1 (de) Ausfallsicherheitsventileinheit, Elektronisch steuerbares pneumatisches Bremssystem, Verfahren zum Betreiben eines Bremssystems
EP1110130B1 (de) Steuergerät
WO2022002942A1 (de) Verfahren zum prüfen eines select-high-ventils
DE102018123750A1 (de) Elektropneumatische Anhängersteuerventileinheit für Nordamerika
WO2015070945A1 (de) Verfahren und system zum erkennen von betriebszuständen eines fahrzeuges und fahrzeug mit derartigem system
EP2724903A2 (de) Bremsvorrichtung für Arbeitsmaschinen und Verfahren zum Betätigen der Bremsvorrichtung
DE10344460B4 (de) Verfahren zur Fehlerbehandlung bei elektronischen Steuergeräten
DE102012218252B4 (de) Verfahren zur Inbetriebnahme eines Fahrzeuggetriebes und/oder einer Fahrzeugkupplung
WO2005014360A1 (de) Verfahren und vorrichtung zum erkennen eines ausfalls eines druckluftverbraucher­kreises in einer elektronischen druckluftanlage für fahrzeuge
EP1497632B2 (de) Verfahren zur überwachung und fehlerdiagnose für komponenten des antriebsstrangs eines kraftfahrzeugs
DE102014205087A1 (de) Verfahren zur automatisierten Inbetriebnahme eines Getriebes eines Kraftfahrzeuges
EP1366964B1 (de) Feststellbremsanlage und Verfahren zum Betreiben einer Feststellbremsanlage
DE102007052106A1 (de) Elektronische Fahrzeug-Steuereinrichtung und Steuerungsspezifikations-Festlegungsverfahren für dieselbe
DE102017112817A1 (de) Inbetriebnahme-Steuergerät eines Verbunds aus Steuergeräten eines Kraftfahrzeugs und Verfahren zur Inbetriebnahme von Steuergeräten
EP2112009B1 (de) Verfahren zur Überprüfung eines Umgebungsventils in einer geschlossenen Niveauregelungsanlage eines Fahrzeuges
EP0716636B1 (de) Verfahren und vorrichtung zur abstimmung einer elektrisch-pneumatischen bzw. elektrisch-hydraulischen bremsanlage eines kraftfahrzeugs
DE102017112394A1 (de) Verfahren zur Inbetriebnahme eines automatisierten Aktors, insbesondere eines Fahrzeuges
DE102006034970A1 (de) Fertigungs-Verfahren für Kraftfahrzeuge
DE102008035777A1 (de) Verfahren zum Steuern zumindest einer Kupplung
DE102006052049A1 (de) Verfahren zur Instandsetzung der Fahrzeugelektronik eines Kraftfahrzeugs
DE102022000824A1 (de) Verfahren zur werkerlosen Bearbeitung von Fahrzeugen in einer Automobilfertigung
DE102023202272A1 (de) Verfahren zum redundanten Überwachen von Fahrfunktionen

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1997940138

Country of ref document: EP

ENP Entry into the national phase

Ref country code: JP

Ref document number: 1998 512206

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 09254358

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1997940138

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 1997940138

Country of ref document: EP