WO2008003615A1 - Verfahren zum durchführen eines tests - Google Patents

Verfahren zum durchführen eines tests Download PDF

Info

Publication number
WO2008003615A1
WO2008003615A1 PCT/EP2007/056356 EP2007056356W WO2008003615A1 WO 2008003615 A1 WO2008003615 A1 WO 2008003615A1 EP 2007056356 W EP2007056356 W EP 2007056356W WO 2008003615 A1 WO2008003615 A1 WO 2008003615A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
vehicle
module
software
control unit
Prior art date
Application number
PCT/EP2007/056356
Other languages
English (en)
French (fr)
Inventor
Richard Joergl
Stefan Hafner
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2008003615A1 publication Critical patent/WO2008003615A1/de

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 relates to a method for carrying out a test of a control unit located in a vehicle, a device for carrying out a test of a control unit located in a vehicle, and a computer program and a computer program product.
  • test procedures and evaluations are usually very time consuming.
  • the necessary influence of sensors and actuators, which interact with the control unit, is done manually by a test person, so that a poor reproducibility is given.
  • measurements usually have to be done after the end of the Tests are evaluated manually.
  • a monitoring function test protocol is also filled out manually, with a checklist typically being ticked off.
  • the document DE 103 03 489 A1 describes a method for testing software of a control unit of a vehicle.
  • the control unit is arranged in a control unit which interacts with a test system via data exchange.
  • those which are transmitted via an interface directly from the test system to the control unit are used.
  • a controlled by the control unit controlled system is at least partially simulated by the test system.
  • the test system comprises a simulation computer with a simulation means comprising models for simulating the vehicle and / or the driver and / or the environment, whereby the respective influences of these variables on the control unit alone can be influenced computer-aided without the need for mechanical devices.
  • At least one operating situation that may arise during operation of the vehicle is automatically simulated.
  • a test of the controller and in particular a software test for this controller when used in the vehicle and thus under real conditions is possible.
  • the at least one operating situation for example, a driver command and thus an input of a driver of the vehicle is automatically simulated.
  • an actuation of a pedal that is brakes, throttle or pedaling the domes, normalized by a hardware module provided for this purpose and reproducible done.
  • an error of the vehicle can be automatically simulated.
  • possible operating situations are thus all To simulate environmental influences on the vehicle and the control unit automatically and repeatably.
  • the test is carried out in at least one test environment and / or under at least one test condition.
  • the test may be performed within a multi-segment test series under laboratory conditions and / or while the vehicle is traveling. Consequently, it is possible to flexibly test the controller in consideration of various conditions.
  • At least one step of the test is typically performed automatically, so that a reliable control of the test can be realized. Suitable steps include automated measurement, automatic evaluation and logging of the test. A test procedure is usually also evaluated automatically, i. analyzed, described and / or evaluated, as well as processed. In addition, test inputs can be automated.
  • the device according to the invention is designed to carry out a test of a control device located in a vehicle and has at least one module which is designed to automatically simulate at least one operating situation which may arise during operation of the vehicle.
  • the at least one module is designed as a hardware module in an embodiment, this is usually a robot-like trained electromechanical loading device, the automatic actuation of components, eg. A lever, pedal, button, etc., of the vehicle trained during the test.
  • This hardware module generates driver commands or inputs of the driver.
  • other environmental influences for example weather conditions or road conditions, can be automatically simulated by hardware modules.
  • Such hardware modules are, for example, designed as a pedal simulation module, relay module, starter module, etc.
  • the at least one module can also be designed as a software module and perform in this capacity the method and thus the test computer-aided. - A -
  • the invention additionally relates to a computer program with program code means in order to carry out all the steps of a method according to the invention when the computer program is executed on a computer or a corresponding arithmetic unit, in particular in a device according to the invention.
  • the invention further relates to a computer program product with program code means which are stored on a computer-readable data carrier in order to carry out all the steps of a method according to the invention, when the computer program is executed on a computer or a corresponding computing unit, in particular in a device according to the invention.
  • test system Automatic Test Control (A.T.C., automatic test control) is presented, with the help of which tests of the software of engine control units can be automated on and / or in the vehicle or under laboratory conditions.
  • test automation capability offers great potential for savings.
  • a higher degree of reproducibility and a precisely defined test procedure can be achieved, which would not be possible manually.
  • the monitoring function test checks whether the functions and measures implemented in the control unit for the protection of persons have the expected effect.
  • the monitoring function test covers a total of 71 standardized test cases using the example of a realized project.
  • test Since the test must be carried out by definition in the vehicle, it offers the ATC for an initial evaluation of monitoring function tests.
  • ATC Automatic Test Control
  • a complete solution of hardware and software is provided in order to be able to process and evaluate test procedures in an automated manner.
  • the method according to the invention is independent of the project and control devices and can be used in various test environments, for example in the laboratory or in the vehicle, using test cases.
  • the method according to the invention and / or the device according to the invention and thus the test system do not simulate the surroundings of the control device, which as a rule consists of sensors and actuators that interact with the control device, but inputs by the driver and errors possibly occurring in the vehicle.
  • driver commands such as accelerating, braking or starting are usually automated as test input, and short circuits and shunts are generated on the cable harness of the control unit.
  • FIG. 1 shows a first embodiment of an arrangement which is suitable for realizing a first variant of the method according to the invention.
  • Figure 2 shows a schematic representation of a second embodiment of an arrangement which is suitable for implementing a second variant of the method according to the invention.
  • FIG. 1 shows a first embodiment of an arrangement 2 which is suitable for realizing a first variant of the method according to the invention.
  • This arrangement 2 comprises a computer 4 on which the software suitable for carrying out the method is stored and executed.
  • a device 6 for carrying out the Method has in this embodiment, designed as a data bus 8 first hardware module and a second hardware module, which is designed here as a receiving unit 10 and a so-called.
  • the arrangement 2 comprises a parallel interface module 12, a vehicle 14, which may also be a test vehicle or so-called labcar, and the control unit 16 for the vehicle 14 to be tested.
  • the control unit 16 is arranged in the vehicle 14 and for performing or supporting functions of the vehicle 14.
  • the Aufbrechbox 10 of the device 6 is connected via a standard harness 18 to the vehicle 14, the receiving unit 8 is connected via a second harness 20 to the controller 16. Accordingly, the device 6 is connected between the vehicle 14 and the control unit 16. Only a communication line 22 (RS232 interface) and a CAN interface 24 are needed to control the device 6 from the computer 4. It would also be conceivable to combine the automatic test control (A.T.C.) and the breakaway box 10 into a single module.
  • A.T.C. automatic test control
  • test cases are typically done using the metalanguage of TAXI.
  • the user can enter test steps in full text in an Excel spreadsheet.
  • Existing test cases can be used for the A.T.C. be used.
  • the test steps are performed by the A.T.C. processed.
  • the evaluation is carried out by reading current values from the control unit 16 with the software INCA and comparing them with setpoints.
  • the result of the evaluation is provided by the A.T.C. logged and, for example, saved in HTML format in tabular form.
  • an automatic measurement with all relevant measurement channels can be recorded via INCA. This serves as proof of a valid test procedure in addition to the test protocol.
  • the individual test steps can be tracked using a TAXI-Excel sheet as user interface. This has a status window from the A.T.C. which provides further useful information about errors that occur, the test status, and so on.
  • the software used in the implementation of the method is implemented as a Windows application and executable on any Windows PCs and laptops. All for The settings necessary for the test procedure can be entered via a graphical user interface.
  • test cases are entered with an Excel template introduced for TAXI. This makes it possible to use existing TAXI test cases with the A.T.C. to expire. In addition, the use of this already widespread and easy-to-use form of input minimizes the training required.
  • the software uses INCA as an interface to the control unit 16 for the evaluation. Thus, a largely standardized tool is used.
  • vehicle-specific CAN is accessed via a CAN interface in order to simulate messages, such as, for example, a redundant brake signal.
  • FIG. 2 shows a schematic representation of a second embodiment of an arrangement 50 which is suitable for implementing a second variant of the method according to the invention for testing a software of a control device 58.
  • This arrangement 50 comprises a first unit 52, a second unit 54, which in this embodiment form a device provided for carrying out the method, and a vehicle 56 with a control unit 58 located therein.
  • the first unit 52 has software 60 here three software modules, namely with an ATC - Software for automatic test control, a Vector-CAN driver and an INCA software, as well as a CAN hardware 62 with a Vector CAN CardX.
  • the software 60 is stored on a computer and executes on the computer to perform the method.
  • the second unit 54 comprises eight interacting hardware modules 64, 66, 68, 70, 72, 74, 76, 78, namely a pedal simulation module 64, a receiving module 66, a CAN-Rx / Tx module 68, a starter module 70, a relay module 72 and optionally a PWM module 74, an input module 76 for receiving digital data and an output module 78 for outputting analog data or signals.
  • the software 60 is connected via a serial RS232 interface 80 to the receiving module 66 and thus via this receiving module 66 with all hardware modules 64, 66, 68, 70, 72, 74, 76, 78 of the second unit 54.
  • the CAN hardware 62 is connected to the CAN-Rx / Tx module 68 via a CAN (Controller Area Network) interface 82.
  • the first software module is also connected via a MAC interface 84 to the vehicle 56 and thus also to the controller 58.
  • a connection is provided via a standard cable harness 86.
  • the hardware modules 64, 66, 68, 70, 72, 74, 76, 78 of the device are controlled by the software 60 via the serial RS232 interface 80 with the aid of the computer.
  • the aid of the CAN hardware 62 it is possible to manipulate the messages sent or received via the CAN interface 82 and thus via a CAN bus.
  • the device consisting of the two units 52, 54 is constructed as a modular system. Essentially, this system consists of the receiving unit 66, which evaluates the data sent by the computer during the test, and the RS232 interface 80 serving here as the data bus, which during the test has individual test and thus hardware modules 64, 66, 68, 70, 72, 74, 76, 78 controls.
  • the first implemented hardware module is the pedal simulation module 64.
  • a pedal signal for actuating a brake, gas or clutch pedal can be simulated by a potentiometer, which is controlled by a servo motor, so that different speed ranges can be achieved fully automatically
  • Relay module 72 is suitable for testing relays. Relays are used to simulate load drops or short circuits. The maximum number of relays is currently limited to 1024 pieces. Whereby about 300-500 relays suffice to manipulate all the software-relevant pins of the control unit 58.
  • the starter module 70 is a logic with which the vehicle 56 can be started fully automatically with start buttons or buttons.
  • the method can not only be used to perform a monitoring function test, but is also suitable for any other vehicle conditional tests 56, such as CAN tests, I / O tests, stall tests, test of known bugs, regression tests, etc.
  • vehicle conditional tests 56 such as CAN tests, I / O tests, stall tests, test of known bugs, regression tests, etc.
  • the method and the device are not designed to be project-specific, so that they can be used in different areas.
  • the only prerequisite for this is an INCA interface from the software 60 to the control unit 58.
  • a connection to the vehicle 56 or a labcar is also possible, so that driver commands are to be transmitted to the vehicle 56 and thus to be realized.
  • only a small configuration effort on the vehicle 56 is required. This means that tests have to be simulated even during driving cycles.
  • the only condition for this is the standardized interface between the vehicle 56 and the second unit 54 of the device provided by the standard wiring harness 86 and a closed-loop operation of the vehicle 56.
  • the monitoring function test in the vehicle 56 has been successfully performed several times. An approximately 80 percent reduction in the test procedure compared to manual testing was evident.
  • the average effort for a manual monitoring function test is currently in manhours (Mh):
  • test cases Performing the monitoring function test cases for 71 test cases in the stand: 61 test cases (automatic) 1 Mh in the driving mode: 10 test cases (manual) 1 Mh

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)
  • Debugging And Monitoring (AREA)

Abstract

Bei dem erfindungsgemäßen Verfahren zum Durchführen eines Tests eines in einem Fahrzeug (14) befindlichen Steuergeräts (16) wird mindestens eine Betriebssituation, die sich während eines Betriebs des Fahrzeugs (14) ergeben kann, automatisch simuliert.

Description

Beschreibung
Titel
Verfahren zum Durchführen eines Tests
Die Erfindung betrifft ein Verfahren zum Durchführen eines Tests eines in einem Fahrzeug befindlichen Steuergeräts, eine Einrichtung zum Durchführen eines Tests eines in einem Fahrzeug befindlichen Steuergeräts sowie ein Computerprogramm und ein Computerprogrammprodukt.
Stand der Technik
In den letzten Jahren hat die Komplexität der Software von Motorsteuergeräten stetig zugenommen. Um eine qualitativ hochwertige Software entwickeln zu können, steigert sich ebenfalls der Testaufwand für einzelne Softwarekomponenten. Dies bedeutet, dass bei gleichbleibenden Prozessen der Entwicklungsaufwand von einer Steuergerätegeneration zur nächsten Steuergerätegeneration zunimmt. Daher ist es notwendig, neue Strategien und Werkzeuge zu Effizienzsteigerung derartiger Tests zu entwickeln, um einerseits die Qualität der Software weiter zu steigern und andererseits den Entwicklungsaufwand zu minimieren.
Bislang werden alle für den Überwachungsfunktionstest im Fahrzeug notwendigen Tätigkeiten manuell durchgeführt, so werden bspw. Kurzschlüsse erzeugt, Pedale betätigt, Messergebnisse evaluiert, usw..
Derartige Testdurchführungen und Auswertungen sind in der Regel sehr zeitaufwendig. Die notwendige Beeinflussung von Sensoren und Aktoren, die mit dem Steuergerät wechselwirken, erfolgt durch eine Testperson manuell, so dass eine schlechte Reproduzierbarkeit gegeben ist. Außerdem müssen Messungen zumeist nach Ende des Tests manuell ausgewertet werden. Ein Überwachungsfunktionstest-Protokoll wird e- benfalls manuell ausgefüllt, wobei typischerweise eine Checkliste abgehakt wird.
Aufgrund des steigenden Aufwands bei zunehmender Anzahl von Überwachungsfunkti- onstests und durchzuführenden Testfällen wurde der sog. "Black Box Überwachungsfunktionstest" eingeführt, der jedoch aufgrund einer geringen Testtiefe vergleichsweise oberflächlich ist.
Die Druckschrift DE 103 03 489 Al beschreibt ein Verfahren zum Testen von Software einer Steuereinheit eines Fahrzeugs. Bei diesem Verfahren ist vorgesehen, dass die Steuereinheit in einem Steuergerät angeordnet ist, das mit einem Testsystem über Datenaustausch wechselwirkt. Hierbei werden diejenigen, die über eine Schnittstelle direkt von dem Testsystem zu dem Steuergerät übertragen werden, verwendet. Dabei wird durch das Testsystem eine von der Steuereinheit steuerbare Regelstrecke wenigstens teilweise simuliert. Das Testsystem umfasst einen Simulationsrechner mit einem Simulationsmittel, das Modelle zur Simulation des Fahrzeugs und/oder des Fahrers und/oder der Umwelt umfasst, wodurch die jeweiligen Einflüsse dieser Größen auf die Steuereinheit allein rechnergestützt, ohne dass mechanische Einrichtungen erforderlich sind, beeinflusst werden können.
Offenbarung der Erfindung
Bei dem erfindungsgemäßen Verfahren zum Durchführen eines Tests eines in einem Fahrzeug befindlichen Steuergeräts wird mindestens eine Betriebssituation, die sich während eines Betriebs des Fahrzeugs ergeben kann, automatisch simuliert.
Somit ist ein Test des Steuergeräts und insbesondere einer Softwaretest für dieses Steuergerät bei Verwendung im Fahrzeug und somit unter realen Bedingungen möglich. Als die mindestens eine Betriebssituation wird bspw. ein Fahrerkommando und somit eine Eingabe eines Fahrers des Fahrzeugs automatisch simuliert. Hierzu kann eine Betätigung eines Pedals, also Bremsen, Gasgeben oder Treten des Kuppeln, durch ein hierfür vorgesehenes Hardwaremodul normiert und reproduzierbar erfolgen. Des weiteren kann als die mindestens eine Betriebssituation ein Fehler des Fahrzeugs automatisch simuliert werden. Als denkbare Betriebssituationen sind somit sämtliche Umwelteinflüsse auf das Fahrzeug sowie das Steuergerät automatisch und wiederholbar zu simulieren.
In Ausgestaltung wird der Test in mindestens einer Testumgebung und/oder unter min- destens einer Testbedingung durchgeführt. Somit kann der Test innerhalb einer aus mehreren Abschnitten bestehenden Testreihe unter Laborbedingungen und/oder während einer Fahrt des Fahrzeugs durchgeführt wird. Folglich ist es möglich, das Steuergerät unter Berücksichtigung verschiedenartiger Bedingungen vielseitig zu testen.
Ergänzend wird typischerweise mindestens ein Schritt des Tests automatisch durchgeführt, so dass eine zuverlässige Kontrolle des Tests zu realisieren ist. Hierbei in Frage kommende Schritte sind eine automatisierte Messung, eine automatische Auswertung sowie Protokollierung des Tests. Ein Ablauf des Tests wird üblicherweise auch automatisch evaluiert, d.h. analysiert, beschrieben und/oder bewertet, sowie abgearbeitet. Zu- dem können Testeingaben automatisiert werden.
Die erfindungsgemäße Einrichtung ist zum Durchführen eines Tests eines in einem Fahrzeug befindlichen Steuergeräts ausgebildet und weist mindestens ein Modul auf, das dazu ausgebildet ist, mindestens eine Betriebssituation, die sich während eines Betriebs des Fahrzeugs ergeben kann, automatisch zu simulieren.
Hierbei ist in Ausgestaltung das mindestens eine Modul als Hardwaremodul ausgebildet, dabei handelt es sich in der Regel um eine roboterartig ausgebildete elektrome- chanische Beaufschlagungsvorrichtung, die zur automatischen Betätigung von Kompo- nenten, bspw. eines Hebels, Pedals, Knopfs usw., des Fahrzeugs während des Test ausgebildet ist. Dabei erzeugt dieses Hardwaremodul Fahrerkommandos bzw. Eingaben des Fahrers. Des weiteren können durch Hardwaremodule auch sonstige Umwelteinflüsse, bspw. Wetterbedingungen, oder Straßenverhältnisse, automatisch simuliert werden. Derartige Hardwaremodule sind bspw. als Pedalsimulationsmodul, Relaismo- dul, Startermodul usw. ausgebildet. Das mindestens eine Modul kann auch als Softwaremodul ausgebildet sein und in dieser Eigenschaft das Verfahren und somit den Test rechnergestützt durchführen. - A -
Die Erfindung betrifft zudem ein Computerprogramm mit Programmcodemitteln, um alle Schritte eines erfindungsgemäßen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer erfindungsgemäßen Einrichtung, ausgeführt wird.
Die Erfindung betrifft des weiteren ein Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines erfindungsgemäßen Verfahrens durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer erfindungsgemäßen Einrichtung, ausgeführt wird.
Mit der Erfindung wird insbesondere das Testsystem Automatic Test Control (A.T.C., automatische Testkontrolle) vorgestellt, mit dessen Hilfe Tests der Software von Motorsteuergeräten am und/oder im Fahrzeug oder unter Laborbedingungen automatisiert werden können.
Da bei der Softwareentwicklung das Testen ungefähr 40-50% des Gesamtaufwands verursacht, bietet die mit der Erfindung bereitgestellte Möglichkeit zur Testautomatisierung große Einsparpotentiale. Zudem ist ein höherer Grad an Reproduzierbarkeit und ein exakt definierter Testablauf zu erreichen, was manuell nicht möglich wäre.
Gerade bei Software-Tests im Fahrzeug bietet sich eine Automatisierung an, da oftmals die gleichen Testabläufe durchgeführt werden müssen, bspw. für Überwachungsfunktionstests, Inpul/Output- Tests, Dauerlauftests, oder CAN- bzw. Controller- Area-Network- Tests. Mit der A.T.C. wurden am Beispiel eines Überwachungsfunktionstests erste Erfahrungswerte gesammelt.
Laut der Verfahrensanweisung Nr. Y 400 899 025 wird mit dem Überwachungsfunktionstest überprüft, ob die im Steuergerät zum Schutz von Personen realisierten Funkti- onen und Maßnahmen in erwartetem Umfang wirken. Der Überwachungsfunktionstest umfasst am Beispiel eines realisierten Projekts insgesamt 71 standardisierte Testfälle.
Da der Test per Definition im Fahrzeug durchgeführt werden muss, bietet er sich für eine erste Evaluierung von Überwachungsfunktionstests die A.T.C. an. Mit der vorliegenden Erfindung und insbesondere der Automatic Test Control (A.T.C.) wird eine Komplettlösung aus Hard- und Software bereitgestellt, um Testabläufe automatisiert abzuarbeiten und evaluieren zu können. Das erfindungsgemäße Verfahren ist projekt- und steuergeräteunabhängig und kann in verschiedenen Testumgebungen, bspw. im Labor oder im Fahrzeug, unter Anwendung von Testfällen eingesetzt werden.
Das erfindungsgemäße Verfahren und/oder die erfindungsgemäße Einrichtung und somit das Testsystem simulieren dabei nicht die Umgebung des Steuergeräts, die in der Regel aus Sensoren und Aktoren besteht, die mit dem Steuergerät wechselwirken, sondern Eingaben des Fahrers und im Fahrzeug möglicherweise auftretende Fehler.
Daher ist es möglich, die Steuergerätesoftware unter möglichst realitätsnahen Bedin- gungen und demnach im realen Fahrzeug auf ein korrektes Verhalten im Fehlerfall zu überprüfen. Bei Durchführung des Verfahrens werden in der Regel als Testeingabe Fahrerkommandos wie Gasgeben, Bremsen oder Starten automatisiert sowie Kurz- und Nebenschlüsse am Kabelbaum des Steuergeräts erzeugt.
Kurze Beschreibung der Zeichnungen
Figur 1 zeigt eine erste Ausführungsform einer Anordnung, die zur Realisierung einer ersten Variante des erfindungsgemäßen Verfahrens geeignet ist.
Figur 2 zeigt in schematischer Darstellung eine zweite Ausführungsform einer Anordnung, die zur Realisierung einer zweiten Variante des erfindungsgemäßen Verfahrens geeignet ist.
Ausführungsformen der Erfindung
Figur 1 zeigt eine erste Ausführungsform einer Anordnung 2, die zur Realisierung einer ersten Variante des erfindungsgemäßen Verfahrens geeignet ist. Diese Anordnung 2 umfasst einen Computer 4, auf dem die zur Durchführung des Verfahrens geeignete Software abgespeichert und auszuführen ist. Eine Einrichtung 6 zur Durchführung des Verfahrens weist in dieser Ausführungsform ein als Daten- Bus 8 ausgebildetes erstes Hardwaremodul sowie ein zweites Hardwaremodul, das hier als Empfangseinheit 10 bzw. eine sog. Aufbrechbox ausgebildet ist, auf. Das weiteren umfasst die Anordnung 2 ein paralleles Schnittstellenmodul 12, ein Fahrzeug 14, wobei es sich auch um ein Testfahrzeug bzw. sog. Labcar handeln kann, sowie das zu testende Steuergerät 16 für das Fahrzeug 14. Das Steuergerät 16 ist in dem Fahrzeug 14 angeordnet und zur Durchführung oder Unterstützung von Funktionen des Fahrzeugs 14 vorgesehen.
Die Aufbrechbox 10 der Einrichtung 6 ist über einen Standard- Kabelbaum 18 mit dem Fahrzeug 14 verbunden, die Empfangseinheit 8 ist über einen zweiten Kabelbaum 20 mit dem Steuergerät 16 verbunden. Demnach ist die Einrichtung 6 zwischen dem Fahrzeug 14 und dem Steuergerät 16 geschaltet. Lediglich eine Kommunikationsleitung 22 (RS232 Interface) und ein CAN-Interface 24 werden zur Steuerung der Einrichtung 6 vom Computer 4 aus benötigt. Denkbar wäre auch eine Kombination der automati- sehen Testkontrolle (A.T.C.) und der Aufbrechbox 10 zu einem einheitlichen Modul.
Die Eingabe von Testfällen erfolgt typischerweise über die Metasprache von TAXI. Hierbei kann der Nutzer Testschritte im Volltext in eine Excel-Tabelle eingetragen. Bereits bestehende Testfälle können für die A.T.C. verwendet werden. Während des Tests werden die Testschritte von der A.T.C. abgearbeitet. Die Auswertung erfolgt, indem aktuelle Werte aus dem Steuergerät 16 mit der Software INCA ausgelesen und mit Sollwerten verglichen werden. Das Ergebnis der Auswertung wird von der A.T.C. protokolliert und bspw. im HTML-Format tabellarisch gespeichert. Zusätzlich kann eine automatische Messung mit allen relevanten Messkanälen via INCA aufgezeichnet wer- den. Dies dient neben dem Testprotokoll als Nachweis eines gültigen Testablaufs.
Während eines Testablaufs sind die einzelnen Testschritte mit Hilfe eines TAXI- Excel Sheets als Benutzeroberfläche verfolgbar. Diese weist ein Statusfenster von der A.T.C. auf, das weitere nützliche Informationen zu auftretenden Fehlern, dem Teststatus usw. liefert.
Die bei Durchführung des Verfahrens verwendete Software ist als Windows- Anwendung realisiert und auf beliebigen Windows-PCs und Laptops ausführbar. Alle für den Testablauf notwendigen Einstellungen können über ein graphisches Benutzerinterface eingegeben werden.
Die Eingabe der Testfälle erfolgt mit einem für TAXI eingeführten Excel-Template. Da- durch ist es möglich, bereits bestehende TAXI-Testfälle auch mit der A.T.C. ablaufen zu lassen. Zudem wird durch die Verwendung von dieser bereits weit verbreiteten und leicht zu bedienenden Eingabeform der Einschulungsaufwand minimiert. Die Software nutzt zur Auswertung INCA als Schnittstelle zum Steuergerät 16. Damit wird ein weitgehend standardisiertes Werkzeug verwendet.
Neben der Messdatei von INCA wird zur Testauswertung ein HTML-Protokoll erstellt. Daher ist es nicht mehr notwendig, den Test nach dessen Ablauf manuell auszuwerten, da dies von der A.T.C. schon während des Testablaufes automatisch erledigt wird.
Zusätzlich wird über eine CAN-Schnittstelle auf den fahrzeugspezifischen CAN zugegriffen, um Botschaften, wie bspw. ein redundantes Bremssignal, zu simulieren.
Figur 2 zeigt in schematischer Darstellung eine zweite Ausführungsform einer Anordnung 50, die zur Realisierung einer zweiten Variante des erfindungsgemäßen Verfah- rens zum Testen einer Software eines Steuergeräts 58 geeignet ist.
Diese Anordnung 50 umfasst eine erste Einheit 52, eine zweite Einheit 54, die in dieser Ausführungsform eine zur Durchführung des Verfahrens vorgesehene Einrichtung bilden, und ein Fahrzeug 56 mit einem darin befindlichen Steuergerät 58. Die erste Ein- heit 52 weist eine Software 60 mit hier drei Softwaremodulen, nämlich mit einer A.T.C. - Software zur automatischen Testkontrolle, einem Vector-CAN-Treiber und einer INCA- Software, sowie eine CAN-Hardware 62 mit einer Vector CAN CardX auf. Die Software 60 ist auf einem Computer gespeichert und zur Durchführung des Verfahrens auf diesem auszuführen.
Die zweite Einheit 54 umfasst acht untereinander wechselwirkende Hardwaremodule 64, 66, 68, 70, 72, 74, 76, 78, nämlich ein Pedalsimulationsmodul 64, ein Empfangmodul 66, ein CAN-Rx/Tx-Modul 68, ein Startermodul 70, ein Relaismodul 72 sowie jeweils optional ein PWM-Modul 74, ein Eingabemodul 76 zum Empfang digitaler Daten und ein Ausgabemodul 78 zur Ausgabe analoger Daten oder Signale. Die Software 60 ist über eine serielle RS232-Schnittstelle 80 mit dem Empfangsmodul 66 und somit über dieses Empfangsmodul 66 mit sämtlichen Hardwaremodulen 64, 66, 68, 70, 72, 74, 76, 78 der zweiten Einheit 54 verbunden. Des weiteren ist die CAN-Hardware 62 über eine CAN(Controller Area Network)-Schnittstelle 82 mit dem CAN-Rx/Tx-Modul 68 verbunden. Das erste Softwaremodul ist außerdem über eine MAC-Schnittstelle 84 mit dem Fahrzeug 56 und somit auch mit dem Steuergerät 58 verbunden. Zwischen den Hardwaremodulen 64, 66, 68, 70, 72, 74, 76, 78 der zweiten Einheit 54 und dem Fahrzeug 56 und damit auch dem Steuergerät 58 ist über einen Standard-Kabelbaum 86 eine Verbindung bereitgestellt.
Die Hardwaremodule 64, 66, 68, 70, 72, 74, 76, 78 der Einrichtung werden mit Hilfe des Computers über die serielle RS232-Schnittstelle 80 von der Software 60 angesteuert. Zusätzlich besteht die Möglichkeit, mit Hilfe der CAN-Hardware 62, die über die CAN-Schnittstelle 82 und somit über einen CAN-Bus die zur Durchführung des Tests versendeten bzw. empfangenen Botschaften zu manipulieren.
Die aus den beiden Einheiten 52, 54 bestehende Einrichtung ist als modulares System aufgebaut. Im wesentlichen besteht dieses System aus der Empfangseinheit 66, die die während des Tests vom Computer versendeten Daten auswertet, und der hier als Daten-Bus dienenden RS232-Schnittstelle 80, die während des Tests einzelne Test- und somit Hardwaremodule 64, 66, 68, 70, 72, 74, 76, 78 ansteuert.
Das erste realisierte Hardwaremodul ist das Pedalsimulationsmodul 64. Mit diesem ist vorgesehen, dass durch ein Potentiometer, das von einem Servomotor angesteuert wird, ein Pedalsignal zur Betätigung eines Brems-, Gas- oder Kupplungspedals simuliert werden kann, so dass verschiedene Drehzahlbereiche vollautomatisch erreicht werden können. Das Relaismodul 72 ist zum Testen von Relais geeignet. Mit Hilfe von Relais werden Lastabfälle bzw. Kurzschlüsse simuliert. Die maximale Anzahl an Relais ist derzeit auf 1024 Stück beschränkt. Wobei ca. 300-500 Relais ausreichen, um alle softwarerelevanten Pins des Steuergeräts 58 zu manipulieren.
Bei dem Startermodul 70 handelt es sich um eine Logik, mit der das Fahrzeug 56 mit Startbuttons bzw. -knöpfen vollautomatisch gestartet werden kann. Außerdem können unter relativ geringem Aufwand weitere Hardwaremodule bspw. ein CAN Modul, das PW M -M od u I 74, das Ausgabemodul 78 für Analogsignal usw. realisiert werden.
Um einen sicheren Betrieb der automatischen Testkontrolle (A.T.C.) gewährleisten zu können, ist vorgesehen, in einer Anweisung zur Durchführung des Verfahrens geeignete Maßnahmen zu definieren. Denkbar ist bspw. eine Absicherung gegen eine Bewegung des Fahrzeugs 56 durch mechanische Sperren, indem die Abschleppstange an einer Betonwand befestigt oder der Ganghebel verriegelt wird. Des weiteren ist eine Absicherung durch einen Betrieb am Rollenprüfstand bei Durchführung des Verfahrens unter Laborbedingungen möglich. Zudem ist eine Sicherstellung durch eine Verfahrensanweisung, wonach eine Testperson das Fahrzeug 56 während des Tests nicht verlassen darf, geeignet.
Das Verfahren kann nicht nur zur Durchführung eines Überwachungsfunktionstests verwendet werden, sondern eignet sich auch für beliebige andere Standtests im Fahrzeug 56, bspw. CAN-Tests, I/O-Tests, Abwürgetests, Test of known bugs, Regression Tests, usw.. Durch den modularen Software- und Hardwareaufbau sind auch Erweiterungen an zukünftige Anforderungen leicht realisierbar, wie zum Beispiel die Ausgabe von beliebigen Analog- oder Digitalsignalen, um weitere Eingaben des Fahrers zu si- mulieren. Bei Betrieb auf einem Rollenprüfstand sind auch Tests im Fahrbetrieb des Fahrzeugs 56 denkbar.
Das Verfahren sowie die Einrichtung sind nicht projektspezifisch ausgelegt, so dass ein Einsatz in unterschiedlichen Bereichen möglich ist. Voraussetzung hierfür ist lediglich eine INCA-Schnittstelle von der Software 60 zu dem Steuergerät 58. Auch eine Anbindung an das Fahrzeug 56 bzw. ein Labcar ist möglich, so dass Fahrerkommandos an das Fahrzeug 56 zu übermitteln und somit zu realisieren sind. Hierzu wird nur ein geringer Konfigurationsaufwand an dem Fahrzeug 56 benötigt. Damit sind auch während Fahrzyklen Tests zu simulieren. Bedingung hierfür ist lediglich die durch den Standard- Kabelbaum 86 bereitgestellte standardisierte Schnittstelle zwischen dem Fahrzeug 56 und der zweiten Einheit 54 der Einrichtung sowie eines closed-loop Betriebs des Fahrzeugs 56. Der Überwachungsfunktionstest im Fahrzeug 56 wurde mehrfach erfolgreich durchgeführt. Dabei zeichnete sich eine rund 80-prozentige Verkürzung des Testablaufes im Vergleich zum manuellen Testen ab. Der durchschnittliche Aufwand für einen manuellen Überwachungsfunktionstest beträgt derzeit in Mannstunden (Mh):
Steuergerät 58 am Testplatz vorbereiten 0,5 Mh
Testaufbau im Fahrzeug 56 1,5 Mh
Durchführen der Überwachungsfunktionstest- Tests bei 71 Testfällen im Stand: 61 Testfälle 15 Mh im Fahrbetrieb: 10 Testfälle I Mh
Auswertung der Messungen 4 Mh (Häkchenliste, INCA DAT-file analysieren)
Fertigstellen des Überwachungsfunktionstest-Protokolls 1 Mh
Summe: 23 Mh
Der durchschnittliche Aufwand eines mittels der Erfindung durchgeführten Überwachungsfunktionstest beträgt dagegen:
Steuergerät 58 am Testplatz vorbereiten 0,5 Mh Testaufbau im Fahrzeug 56 1,5 Mh
Durchführen der Überwachungsfunktionstest- Testfälle bei 71 Testfällen im Stand: 61 Testfälle (automatisch) 1 Mh im Fahrbetrieb: 10 Testfälle (manuell) 1 Mh
Auswertung des autom. Protokolls 1 Mh Summe: 5 Mh
Die für den Überwachungsfunktionstest pro Projekt einmal notwendige Erstellung der TAXI-Testfälle hat ca. eine Mannwoche in Anspruch genommen. In Zukunft kann dieser Initialaufwand weiter verkürzt werden. Es ist dann lediglich notwendig, die Testfälle an das entsprechende Fahrzeug 56 unter Berücksichtigung von unterschiedlichem Startverhalten, anderen Fahrpedal-Kennlinien usw. sowie von kundenspezifischen Softwarefunktionen anzupassen.

Claims

Ansprüche
1. Verfahren zum Durchführen eines Tests eines in einem Fahrzeug (14, 56) befindlichen Steuergeräts (16, 58), bei dem mindestens eine Betriebssituation, die sich während eines Betriebs des Fahrzeugs (14, 56) ergeben kann, automatisch simu- liert wird.
2. Verfahren nach Anspruch 1, bei dem als die mindestens eine Betriebssituation ein Fahrerkommando eines Fahrers des Fahrzeugs (14, 56) automatisch simuliert wird.
3. Verfahren nach einem der voranstehenden Ansprüche, bei dem als die mindestens eine Betriebssituation ein Fehler des Fahrzeugs (14, 56) automatisch simuliert wird.
4. Verfahren nach einem der voranstehenden Ansprüche, bei dem der Test unter Laborbedingungen durchgeführt wird.
5. Verfahren nach einem der voranstehenden Ansprüche, bei dem der Test während einer Fahrt des Fahrzeugs (14, 56) durchgeführt wird.
6. Verfahren nach einem der voranstehenden Ansprüche, bei dem für das Steuergerät (16, 58) ein Softwaretest durchgeführt wird.
7. Verfahren nach einem der voranstehenden Ansprüche, bei dem mindestens ein Schritt des Tests automatisch durchgeführt wird.
8. Einrichtung zum Durchführen eines Tests eines in einem Fahrzeug (14, 56) befindlichen Steuergeräts (16, 58), die mindestens ein Modul aufweist, das dazu ausgebildet ist, mindestens eine Betriebssituation, die sich während eines Betriebs des Fahrzeugs (14, 56) ergeben kann, automatisch zu simulieren.
9. Einrichtung nach Anspruch 8, bei der das mindestens eine Modul als Hardware- modul (64, 66, 68, 70, 72, 74, 76, 78) ausgebildet ist.
10. Einrichtung nach Anspruch 8 oder 9, bei der das mindestens eine Modul als Softwaremodul ausgebildet ist.
11. Computerprogramm mit Programmcodemitteln, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 7 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer Einrichtung nach einem der Ansprüche 8 bis 10, ausgeführt wird.
12. Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 7 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere in einer Einrichtung nach einem der Ansprüche 8 bis 10, ausgeführt wird.
PCT/EP2007/056356 2006-07-06 2007-06-26 Verfahren zum durchführen eines tests WO2008003615A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006031242.2 2006-07-06
DE200610031242 DE102006031242A1 (de) 2006-07-06 2006-07-06 Verfahren zum Durchführen eines Tests

Publications (1)

Publication Number Publication Date
WO2008003615A1 true WO2008003615A1 (de) 2008-01-10

Family

ID=38476877

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/056356 WO2008003615A1 (de) 2006-07-06 2007-06-26 Verfahren zum durchführen eines tests

Country Status (2)

Country Link
DE (1) DE102006031242A1 (de)
WO (1) WO2008003615A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103765231A (zh) * 2011-08-27 2014-04-30 奥迪股份公司 用于车辆部件测试的分离适配器和用于车辆部件的测试方法
DE102016219963A1 (de) * 2016-10-13 2018-04-19 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum automatisierten Testen einer Testkomponenten und eine diesbezügliche Vorrichtung
DE102011102888B4 (de) 2010-06-04 2019-10-10 GM Global Technology Operations LLC (n. d. Ges. d. Staates Delaware) Konfigurierbare Testreihe
CN114667241A (zh) * 2019-11-20 2022-06-24 株式会社自动网络技术研究所 车载信息处理装置、程序执行限制方法及计算机程序

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102010039780B4 (de) 2010-08-26 2022-02-17 Robert Bosch Gmbh Verfahren und Vorrichtung zur Prüfung der Arbeitsweise eines kraftfahrzeugähnlichen Systems
DE102011000958A1 (de) * 2011-02-28 2012-08-30 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren und System zum Testen von Software und/oder Hardware eines oder mehrerer in ein Kraftfahrzeug zu integrierender Bauteile
DE102012019301A1 (de) * 2012-09-29 2014-04-03 Daimler Ag Verfahren und Vorrichtung zur Fahrzeugdiagnose
DE102015121225A1 (de) * 2015-12-07 2017-06-08 Deutsche Telekom Ag Verfahren und Vorrichtung zum Testen einer Mehrzahl von Steuereinheiten einer technischen Einheit
CN111090242B (zh) * 2019-11-26 2021-04-16 安徽江淮汽车集团股份有限公司 自动驾驶测试系统精度验证方法、装置、设备及存储介质
DE102020106769A1 (de) 2020-03-12 2021-09-16 Bayerische Motoren Werke Aktiengesellschaft Simulationsvorrichtung
DE102022209278A1 (de) 2022-09-07 2024-03-07 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Trainieren wenigstens eines Algorithmus des maschinellen Lernens zum Ausgeben von Vorgaben für Eingriffe in die Steuerung eines Kraftfahrzeuges bei bestimmten Fahrmanövern

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5430645A (en) * 1993-09-07 1995-07-04 Keller; A. Scott Robotic system for testing of electric vehicles
DE10303489A1 (de) * 2003-01-30 2004-08-12 Robert Bosch Gmbh Verfahren und Vorrichtung zum Testen von Software einer Steuereinheit eines Fahrzeugs
DE10345615A1 (de) * 2003-09-29 2005-05-19 Robert Bosch Gmbh System und Verfahren zum Testen von Steuervorgängen bei einem Fahrzeug
EP1574864A1 (de) * 2004-03-12 2005-09-14 Audi Ag Verfahren zum Testen der Funktion von in einem Kraftfahrzeug eines bestimmten Typs verbauten, über einen Kommunikationsbus adressierbaren elektronischen und elektrischen Komponenten

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5430645A (en) * 1993-09-07 1995-07-04 Keller; A. Scott Robotic system for testing of electric vehicles
DE10303489A1 (de) * 2003-01-30 2004-08-12 Robert Bosch Gmbh Verfahren und Vorrichtung zum Testen von Software einer Steuereinheit eines Fahrzeugs
DE10345615A1 (de) * 2003-09-29 2005-05-19 Robert Bosch Gmbh System und Verfahren zum Testen von Steuervorgängen bei einem Fahrzeug
EP1574864A1 (de) * 2004-03-12 2005-09-14 Audi Ag Verfahren zum Testen der Funktion von in einem Kraftfahrzeug eines bestimmten Typs verbauten, über einen Kommunikationsbus adressierbaren elektronischen und elektrischen Komponenten

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011102888B4 (de) 2010-06-04 2019-10-10 GM Global Technology Operations LLC (n. d. Ges. d. Staates Delaware) Konfigurierbare Testreihe
CN103765231A (zh) * 2011-08-27 2014-04-30 奥迪股份公司 用于车辆部件测试的分离适配器和用于车辆部件的测试方法
DE102016219963A1 (de) * 2016-10-13 2018-04-19 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum automatisierten Testen einer Testkomponenten und eine diesbezügliche Vorrichtung
CN114667241A (zh) * 2019-11-20 2022-06-24 株式会社自动网络技术研究所 车载信息处理装置、程序执行限制方法及计算机程序

Also Published As

Publication number Publication date
DE102006031242A1 (de) 2008-01-10

Similar Documents

Publication Publication Date Title
WO2008003615A1 (de) Verfahren zum durchführen eines tests
DE10303489A1 (de) Verfahren und Vorrichtung zum Testen von Software einer Steuereinheit eines Fahrzeugs
DE10307342B4 (de) Vorrichtung und Verfahren zur modellbasierten On-Board-Diagnose
EP2367083B1 (de) Vorrichtung zur Erstellung eines Programms für eine speicherprogrammierbare Steuerung, Programmiereinrichtung und Verfahren zur Programmierung einer speicherprogrammierbaren Steuerung
DE19933086A1 (de) Verfahren und Vorrichtung zur gegenseitigen Überwachung von Steuereinheiten
DE3810239A1 (de) Multifunktionstester fuer die fehlerdiagnose
EP1392546B1 (de) Vorrichtung zum steuern elektrischer systeme mit einem testmodul
EP1245430A1 (de) Verfahren und Vorrichtung zur Erzeugung einer Anzeige-Bedienumgebung einer Mensch-Maschine-Schnittstelle
DE102015108064B4 (de) Testsystem und Verfahren zum automatisierten Testen von wenigstens zwei gleichzeitig an das Testsystem angeschlossenen Steuergeräten sowie Steuergeräte-Anschluss- und Steuergeräte-Umschalteinheit zur Verwendung in einem solchen Testsystem
DE102012211981A1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
EP3179372A1 (de) Verfahren und vorrichtung zum testen einer mehrzahl von steuereinheiten einer technischen einheit
DE102012019301A1 (de) Verfahren und Vorrichtung zur Fahrzeugdiagnose
WO2008095518A1 (de) Anwendung einer verteilten diagnosearchitektur in autosar
EP1860565B1 (de) Verfahren zur Funktionsprüfung eines Steuergeräts für ein Kraftfahrzeug
EP1671139A1 (de) System und verfahren zum testen von steuervorgängen bei einem fahrzeug
WO1997019392A2 (de) Simulatoreinheit zum simulieren einer peripherieeinheit einer modular aufgebauten speicherprogrammierbaren steuerung
WO2006035038A2 (de) Verfahren zum testen von steuergerätesoftware für ein steuergerät
DE102006053559B4 (de) Inbetriebnahme eines Notbremssystems in einer Werkstatt
DE10307344B4 (de) Vorrichtung und Verfahren zur dezentralen On-Board-Diagnose für Kraftfahrzeuge
DE102006015207A1 (de) Verfahren und Vorrichtung zur Entwicklung eines Systems für die Betriebsdiagnostik von Fahrzeugen
DE102020211541A1 (de) Verfahren zum Erkennen eines Stillstands eines Fahrzeugs
EP3933593A1 (de) Verfahren und computerprogramm zum testen eines technischen systems
EP1639416A1 (de) Elektronische steuereinheit und verfahren zur spezifikation einer software-architektur f r eine elektronische steuereinheit
EP2191335B1 (de) Vorrichtung und verfahren zum computergestützten konstruieren einer anlage
EP3132322A1 (de) Verfahren zur diagnose eines kraftfahrzeugsystems, diagnosegerät für ein kraftfahrzeugsystem, steuergerät für ein kraftfahrzeugsystem und kraftfahrzeug

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07730306

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07730306

Country of ref document: EP

Kind code of ref document: A1