WO2018192840A1 - Steuergerät und betriebsverfahren hierfür - Google Patents

Steuergerät und betriebsverfahren hierfür Download PDF

Info

Publication number
WO2018192840A1
WO2018192840A1 PCT/EP2018/059461 EP2018059461W WO2018192840A1 WO 2018192840 A1 WO2018192840 A1 WO 2018192840A1 EP 2018059461 W EP2018059461 W EP 2018059461W WO 2018192840 A1 WO2018192840 A1 WO 2018192840A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
unit
controller
control unit
information
Prior art date
Application number
PCT/EP2018/059461
Other languages
English (en)
French (fr)
Inventor
Jochen Schauffele
Holger Niemann
Markus Weingaertner
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
Priority to CN201880025928.1A priority Critical patent/CN110506298B/zh
Publication of WO2018192840A1 publication Critical patent/WO2018192840A1/de

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data

Definitions

  • the invention relates to a control unit, in particular for a motor vehicle, having a computing unit for executing software, a memory unit assigned to the computing unit, a first software stored in the memory unit for the at least temporary collection of information about one
  • the invention further relates to a method for operating such
  • the invention further relates to a device for processing data and a method for operating such a device.
  • the stored first software serves, for example, to perform diagnostic functions to find and classify errors such as component errors.
  • the control device is designed to load at least a second software, which is different from the first software, via the data interface from the external unit and to execute it by means of the arithmetic unit.
  • a second software which is different from the first software
  • the equipment of control devices for example, during their production, already account for a possibly comparatively extensive second software, so that appropriate resources (memory, computing time) are occupied in the controller only for the provision or execution of the second software, if they actually needed becomes.
  • the first software when executed by the arithmetic unit, the first software enables a diagnosis of at least one function of the control unit itself and / or a diagnosis of at least one further component connected to the control unit, whereby a first diagnosis result is obtained.
  • the first software may be software that includes one or more
  • the first software may include a predeterminable set of minimal diagnostic functions, which are required, for example, to detect system effects of potential errors.
  • the control unit according to the invention can be provided, for example, at the time of its production, for example by a programming operation known per se.
  • the above-mentioned information about the operation of the control unit or the information about the operation of components connected to the control unit may include all variables of the control device or components mentioned or any combinations thereof, in particular also sensor measured values, data from communication interfaces associated with the controller, and the like.
  • the controller may include information about the operation of the controller connected to the controller
  • Control unit received CAN messages contain and the like.
  • control unit is designed to send information collected by the first software, in particular the first diagnostic result obtained by means of the first software, to the at least one external unit.
  • the evaluation of the diagnostic result can advantageously take place outside the control unit and, for example, by means of a powerful one
  • Device for data processing are performed, for example by a central server system, a distributed computer system (cloud), or the like.
  • the diagnostic results may be in some embodiments It can also advantageously be made available to a system which represents a so-called virtual vehicle, that is to say a digital representation of a majority or a totality of control devices or their operating parameters arranged in an actually existing vehicle.
  • the second software is designed to execute a collection of information, which is more specific than the first software, on the operation of the control device and / or components connected thereto.
  • the diagnostic functionality can be expediently extended via the options provided by the first software, in particular individually adapted to possibly existing faulty images or problems, which is made possible by the evaluation of the information about the operation of the control device or the relevant components.
  • the second software comprises one or more, in particular directly executable by the arithmetic unit, diagnostic functions that have been obtained or programmed depending on the first diagnostic result.
  • the arithmetic unit can directly use the, for example, more specific diagnostic functions of the second software.
  • the second software of the arithmetic unit is provided directly in the form of an executable computer program which, for example, at least temporarily in the
  • Control unit can be cached, in particular in a flash memory or a working memory of the control unit, where there is
  • the step of loading the second software and / or the step of executing the second software during the operation of the control unit or the computing unit can take place.
  • the arithmetic unit for carrying out the steps of loading and executing according to the invention advantageously does not have to be put into a special programming state, as it does
  • firmware upgrades may be required that require complete reprogramming of the entire memory of the controller.
  • control unit is configured to load the second software as a function of at least one event, wherein the at least one event depends on the at least temporary collection of information and / or at least one external request to the control unit.
  • the control unit is configured to load the second software as a function of at least one event, wherein the at least one event depends on the at least temporary collection of information and / or at least one external request to the control unit.
  • Software is triggered.
  • the loading of the second software is triggered by the external request to the control unit. This may be expedient, for example, if changed operating conditions for the control unit result, which possibly necessitate a change in the execution of the first software or a supplement by the second software.
  • external events trigger or trigger the charging or reloading of the second software, such as an additional diagnostic function.
  • Possible events are, for example: newly occurring faults of other similar or different types of control devices, in particular a newly occurring security problem, the transfer of the control device or a control system containing target system (for example motor vehicle) in a regionally different market with possibly other legally required diagnostic functions, a changed socially required state of the art, in particular with regard to the functionality of the first and / or second software, an external cause for examining a wear pattern or corrosion image or other states of the control device or components connected thereto, for example caused by measures for quality assurance, especially socially desired,
  • Another aspect of the present invention relates to an apparatus for processing data according to claim 8.
  • the apparatus is adapted to a control unit, in particular of a
  • Control unit information about an operation of the
  • the device according to the invention advantageously enables the efficient equipping of control devices, for example control devices according to the invention, in particular for motor vehicles, with a specific diagnostic functionality in the context of the second software according to the invention already described above.
  • the device is designed to evaluate the information about the operation of the control device in order to derive at least one fault pattern from it, to optimize the specific diagnostic software towards the at least one fault image.
  • This specific diagnostic software may then be as the one above
  • FIG. 1 shows schematically a block diagram of an embodiment of a
  • FIG. 2 schematically shows a simplified flowchart of an embodiment of an operating method according to the invention for a control unit
  • FIG. 3 shows schematically a simplified flowchart of another
  • FIG. 4 schematically shows an operating scenario according to an embodiment.
  • FIG. 1 schematically shows a block diagram of an embodiment of a control device 100 according to the invention
  • Control unit 100 to a control device for a motor vehicle act, for example, to control an internal combustion engine of the motor vehicle.
  • the control unit has an arithmetic unit 1 10, which is, for example, at least one microcontroller and / or microprocessor and / or digital signal processor (DSP) and / or an application-specific integrated
  • ASIC application-specific integrated circuit
  • FPGA programmable logic device
  • the arithmetic unit 110 is assigned a memory unit 120 which has at least one random access memory (RAM), in particular of the SRAM type and / or of the DRAM type, and / or at least one nonvolatile RAM (non-volatile RAM). NVRAM)), eg a flash EPROM.
  • RAM random access memory
  • NVRAM nonvolatile RAM
  • a first software 131 which is provided for the at least temporary collection of information about an operation of the control unit 100, is stored in the memory unit 120.
  • the first software 131 may also be provided to collect, at least temporarily, information about an operation of a component 200 connected to the control unit 100.
  • the component 200 may be, for example, another control device or another
  • Act device that is in data communication with the controller 100.
  • both devices 100, 200 may be connected to a common data bus, for example a CAN bus.
  • a common data bus for example a CAN bus.
  • the control unit 100 further has a data interface 140 for exchanging data with at least one external unit 300.
  • the external unit 300 may be, for example, a remotely located server system configured to exchange data with the controller 100. Particular preference is given in some embodiments in the
  • Data interface 140 at least partially wireless or
  • radio-based data interface For this purpose, known wireless communication technologies such as cellular mobile radio networks, wireless networks (WLAN) and the like or combinations thereof may be used.
  • WLAN wireless networks
  • control unit 100 is designed to load at least one second software 132, which is different from the first software 131, via the data interface 140 from the external unit 300 and to execute it by means of the arithmetic unit 110. This is advantageous to the control unit 100.
  • second software 132 allows a more specific collection of information about the operation of the controller 100 and / or components 200 connected thereto. If required, the charging of this second software 132 in a particularly advantageous manner can dispense with the equipment of control units 100, for example during their production, with an optionally comparatively extensive second software, so that corresponding resources (memory, computing time) in the control unit 100 are only then used for the Provision or
  • the first software 131 when executed by the computing unit 110, enables a diagnosis of at least one function of the controller 100 itself and / or a diagnosis of at least one further component 200 connected to the controller 100, thereby producing a first diagnostic result is obtained.
  • the first software 131 may be diagnostic software that performs one or more diagnostic functions.
  • the first software 131 may be diagnostic software that performs one or more diagnostic functions.
  • Software 131 a predefinable set of minimal diagnostic functions which are required, for example, to detect system effects of possible errors.
  • the control unit 100 can be provided, for example, at the time of its production, for example by a programming operation known per se.
  • the above-mentioned information about the operation of the control unit or the information about the operation of components connected to the control unit can be any of the control unit 100 detected sizes of the control device or the components mentioned or any
  • Combinations thereof include, in particular, sensor readings, data from communication interfaces associated with the controller, and the like.
  • the controller 100 may in some embodiments
  • Embodiments the information about the operation of connected to the controller 100 components 200 via a corresponding
  • Communication interface P1 (CAN bus, LIN bus, FlexRay bus, other communication interface types) obtained over which the controller 100 is connected to the respective components 200.
  • such information may also include portions of CAN messages received by the controller 100, and the like.
  • control unit 100 is configured to use the first software 131
  • the evaluation of the diagnostic result can advantageously take place outside the control unit 100 and be carried out, for example, by means of a powerful data processing device, for example using a central server system, a distributed computer system ("cloud") or the like be advantageously provided to a system which represents a so-called virtual vehicle, that is, a digital representation of a majority or total of arranged in an actual existing vehicle control units or their operating parameters.
  • the second software 132 is designed to execute a collection of information that is more specific than the first software 131 on the operation of the control device 100 and / or components 200 connected thereto.
  • Possibilities are widened meaningful, in particular individually adapted to any existing faulty images or problems, which is due to the
  • the second software comprises one or more, in particular directly executable by the arithmetic unit 1 10, diagnostic functions that have been obtained or programmed depending on the first diagnostic result.
  • the arithmetic unit 1 10 directly, for example, the more specific
  • the second software 132 of the computing unit 110 is provided directly in the form of an executable computer program (for example binary code), which can be temporarily stored, for example at least temporarily, in the control unit 100, in particular in a flash memory or also in a flash memory
  • Arithmetic unit 1 10 is available.
  • Arithmetic unit 1 10 done.
  • the arithmetic unit 1 10 for carrying out the inventive steps of loading and execution advantageously does not have to be set in a special programming state, as required for example in firmware upgrades that require a complete reprogramming of the entire memory of the controller.
  • control unit 100 is configured to load the second software 132 as a function of at least one event, wherein the at least one event is based on the at least temporary collection of information (executed, for example, by means of the first software 131).
  • the loading of the second software 132 is triggered.
  • the loading of the second software 132 may alternatively or additionally be provided that the loading of the second
  • Software 132 is triggered by the external request to the control unit 100. This can be useful, for example, if changed
  • external events trigger or trigger the loading or reloading of the second software 132, such as an additional diagnostic function.
  • Possible events are, for example: newly occurring faults of other similar or different types of control devices, in particular a newly occurring security problem, the transfer of the control device 100 or a target system containing the control device 100 (for example
  • Control unit 100 or components connected thereto for example, initiated by measures for quality assurance, a, in particular socially desired, change, in particular constriction of tolerances in diagnostic functions (eg exhaust gas, object recognition), the testing of component hypotheses in the field for development or
  • FIG. 2 schematically shows a simplified flowchart of a
  • At least one second software 132 (FIG. 1), which is different from the first software 131, is loaded via the data interface 140 from the external unit 300.
  • this may be a specific diagnostic software not previously included in the controller, but e.g. has been created externally to the control unit 100, for example as a function of diagnostic results obtained by means of the first software 131, which the control unit 100 previously sent to the external unit 300.
  • the second software 132 is executed by means of the arithmetic unit 110, and in this case e.g. receive a second diagnostic result, which may be sent in an optional further step 420 from the controller 100 to the external unit 300.
  • the control unit 100 can execute a local error reaction or a signaling to a user as a function of the second diagnostic result.
  • the second software 132 can be deleted again from the memory of the control unit 100 in preferred embodiments.
  • the device 300 is designed to receive from a control device, in particular from the control device 100 according to the invention, information about operation of the control device 100 and / or components 200 connected thereto and to create a specific diagnostic software for the control device 100 in dependence on this information to the control unit 100 to transfer.
  • the device 300 according to the invention advantageously makes it possible to provide efficient equipment for control units 100, in particular for motor vehicles, with a specific diagnostic functionality in the context of the second software 132 according to the invention already described above.
  • the device 300 is designed to receive the information about the operation of the control device 100 to evaluate at least one error pattern derived therefrom, and to optimize the specific diagnostic software on the at least one error image.
  • This specific diagnostic software can then be sent as the second software 132 already described above to the control unit 100 according to the invention or loaded by the control unit 100 (see step 400 of FIG.
  • FIG. 3 shows schematically a simplified flowchart of a
  • Embodiment of an operating method for the external unit 300 cf. Fig. 1.
  • the external unit 300 receives information from the controller 100, e.g. the first diagnostic information.
  • the external unit 300 creates a specific one
  • FIG. 4 schematically shows an operating scenario according to an embodiment. It is considered as an example target system for the control unit 100, a motor vehicle, or a plurality of motor vehicles, each with the
  • Control unit 100 are equipped.
  • the reference symbol M1 in FIG. 4 describes a quantity of the motor vehicles in the field with the control device 100.
  • the reference M2 describes a first subset of these field vehicles with the controller 100, namely that subset at which execution of the first (e.g., pre-installed)
  • Diagnosis software 131 has been found a suspected malfunction of the controller 100 or a thereof at least indirectly monitorable component 200.
  • the controllers 100 of this first subset M2 may advantageously load a specific second diagnostic software 132 using the principle of the present invention, e.g. from the external unit 300, which has been created or adapted in particular depending on the previously identified malfunction, to a more specific diagnosis than the first
  • Diagnostic software 132 leads, for example, to confirmation of a malfunction only in the case of a second subset M3 of first subset M2, but not in all vehicles of first subset M2.
  • the vehicles of the second subset M3 can then advantageously examined in the field or in the
  • the principle according to the invention advantageously makes it possible to limit (suspect) suspicious vehicles in order to examine more efficiently only a certain subset M3 of the total quantity M1, whereby costs can be saved and possibly actually due to an error affected ECUs 100 can be identified faster and more efficiently.
  • Provision and use of second software 132 in a control unit 100 is advantageously possible, the second software only in the
  • controller 100 when it is actually needed. This saves memory resources of the controller 100 and advantageously allows the
  • inventive principle particularly good for the provision of diagnostic software, which in particular directly to a example by means of a first
  • Diagnostic Software 131 detected error image or a suspected error can be tailored.
  • At first suspicion may occur
  • Diagnostic software 131 are obtained, the error image, for example in
  • tailored second diagnostic software can be nachentwickelt or for improved error detection and loaded for execution in the control unit 100.
  • the reloading of the diagnostic function or generally the second software 132 for example by means of a
  • Flash over the air FOTA
  • FOTA Flash over the air
  • Memory area of the controller 100 overwritten, but only one of the second software 132 associated area. This prevents an operation of the controller 100 for the transmission of the second software 132 to be interrupted.
  • the application of the principle according to the invention advantageously makes it possible to limit a set of suspicious vehicles, compare the amount M1 of Figure 4, to the actual vehicles actually affected, which advantageously corresponds to a minimization of the so-called "defective subgroup.” In this way, in particular, a very precise definition may also be possible This makes it advantageous to reduce the costs of a field campaign, since the number of affected vehicles is included directly in these costs.
  • the further component may be, for example to act a lambda probe, which is connected to an engine control unit.
  • the control unit 100 can receive information about which output data of the lambda probe via communication links common to the engine control unit
  • the second software 132 can be provided, for example, to specifically check such output data of the lambda probe for errors.
  • the principle according to the invention thus also makes possible a specific diagnosis of components or systems which are not even directly connected to the control device 100 according to the invention, but rather, for example via a communication connection P1 or via another control device.
  • controller 100 it is possible for a series start of the controller 100 only development and installation of a few central diagnostic functions, for example to detect system effects. Further diagnostic functions with, for example, higher selectivity with respect to a component diagnosis are further developed in the form of the second software, for example only when corresponding component errors occur, and can be made available to the control unit 100 using the principle according to the invention later.

Abstract

Die Erfindung betrifft ein Steuergerät (100), insbesondere für ein Kraftfahrzeug, mit einer Recheneinheit (110) zur Ausführung von Software, einer der Recheneinheit zugeordneten Speichereinheit (120), einer in der Speichereinheit (120) gespeicherten ersten Software (131) zur zumindest zeitweisen Sammlung von Informationen über einen Betrieb des Steuergeräts (100) und/oder damit verbundener Komponenten, und mit einer Datenschnittstelle (140) zum Austausch von Daten mit wenigstens einer externen Einheit (300), dadurch gekennzeichnet, dass das Steuergerät (100) dazu ausgebildet ist, wenigstens eine zweite Software (132), die von der ersten Software (131) verschieden ist, über die Datenschnittstelle (140) von der externen Einheit (300) zu laden und mittels der Recheneinheit (110) auszuführen.

Description

Beschreibung
Titel
Steuergerät und Betriebsverfahren hierfür Stand der Technik
Die Erfindung betrifft ein Steuergerät, insbesondere für ein Kraftfahrzeug, mit einer Recheneinheit zur Ausführung von Software, einer der Recheneinheit zugeordneten Speichereinheit, einer in der Speichereinheit gespeicherten ersten Software zur zumindest zeitweisen Sammlung von Informationen über einen
Betrieb des Steuergeräts und/oder damit verbundener Komponenten, und mit einer Datenschnittstelle zum Austausch von Daten mit wenigstens einer externen Einheit. Die Erfindung betrifft ferner ein Verfahren zum Betreiben eines derartigen
Steuergeräts.
Die Erfindung betrifft weiter eine Vorrichtung zur Verarbeitung von Daten sowie ein Verfahren zum Betreiben einer derartigen Vorrichtung.
Steuergeräte der eingangs genannten Art sind bekannt und werden
beispielsweise in elektronischen bzw. mechatronischen Systemen von
Kraftfahrzeugen verwendet. Die gespeicherte erste Software dient dabei beispielsweise zur Ausführung von Diagnosefunktionen, um Fehler wie beispielsweise Komponentenfehler zu finden und zu klassifizieren. Herkömmliche
Diagnosefunktionen sind in der Erstellung und im Betrieb ressourcenaufwendig, andererseits jedoch unerlässlich um die genannten Fehler erkennen. Allerdings reichen die heute gängigen Diagnosefunktionen angesichts der stetig steigenden Mächtigkeit und Komplexität mechatronischer Systeme nicht in allen Fällen aus, zuverlässig die oben genannten Fehler entdecken. Insbesondere der wachsenden Anzahl von sogenannten root-cause-Fehlerbildern kann mit den bekannten Diagnosefunktionen nicht begegnet werden.
Besonders nachteilig ist zum einen die wachsende Anzahl von
Diagnosefunktionen, die zur umfassenden Fehlerdetektion bei den Zielsystemen für die eingangs genannten Steuergeräte erforderlich ist. Zum anderen ist auch die steigende Komplexität der erforderlichen Diagnosefunktionen selbst nachteilig, weil hierdurch ein stark ansteigender Aufwand für das Erstellen und testen der Diagnosefunktionen bedingt wird. Zudem häufen sich dadurch auch sogenannte sekundäre Fehler. So stellen insbesondere in modernen
Kraftfahrzeugen fälschlicherweise reagierende Diagnosefunktionen einen signifikanten Anteil der anschlagenden Diagnosen (Fehlapplikation) dar.
Offenbarung der Erfindung
Demgemäß ist es Aufgabe der vorliegenden Erfindung, ein Steuergerät und ein Betriebsverfahren der eingangs genannten Art dahingehend zu verbessern, dass eine gesteigerte Flexibilität und gleichzeitig eine verbesserte Zuverlässigkeit bei der Erkennung von Fehlern erreicht wird.
Diese Aufgabe wird bei dem Steuergerät der eingangs genannten Art
erfindungsgemäß dadurch gelöst, dass das Steuergerät dazu ausgebildet ist, wenigstens eine zweite Software, die von der ersten Software verschieden ist, über die Datenschnittstelle von der externen Einheit zu laden und mittels der Recheneinheit auszuführen. Dadurch ist vorteilhaft die Möglichkeit gegeben, beispielsweise bedarfsweise das Steuergerät mit einer gegenüber der ersten Software spezialisierteren Software zu versorgen, die beispielsweise eine spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts und/oder damit verbundener Komponenten ermöglicht. Besonders vorteilhaft kann durch das erfindungsgemäße Laden dieser zweiten Software im
Bedarfsfalle die Ausstattung von Steuergeräten, beispielsweise bei deren Herstellung, bereits mit einer gegebenenfalls vergleichsweise umfangreichen zweiten Software entfallen, sodass entsprechende Ressourcen (Speicher, Rechenzeit) in dem Steuergerät nur dann für die Vorhaltung bzw. Ausführung der zweiten Software belegt werden, wenn diese tatsächlich benötigt wird. Bei einer bevorzugten Ausführungsform ist vorgesehen, dass die erste Software bei der Ausführung durch die Recheneinheit eine Diagnose wenigstens einer Funktion des Steuergeräts selbst und/oder eine Diagnose wenigstens einer weiteren mit dem Steuergerät verbundenen Komponente ermöglicht, wodurch ein erstes Diagnoseergebnis erhalten wird. Mithin kann es sich bei der ersten Software um eine Software handeln, welche ein oder mehrere
Diagnosefunktionen ausführt. Beispielsweise kann die erste Software einen vorgebbaren Satz von minimal-Diagnosefunktionen enthalten, welche zum Beispiel erforderlich sind, um System-Auswirkungen von möglichen Fehlern zu erkennen. Mit dieser ersten Software kann das erfindungsgemäße Steuergerät beispielsweise zum Zeitpunkt seiner Produktion versehen werden, beispielsweise durch einen an sich bekannten Programmiervorgang.
Generell können die vorstehend genannten Informationen über den Betrieb des Steuergeräts bzw. die Informationen über den Betrieb von mit dem Steuergerät verbundenen Komponenten alle durch das Steuergerät erfassbaren Größen des Steuergeräts oder der genannten Komponenten oder beliebige Kombinationen hieraus umfassen, insbesondere auch Sensor-Messwerte, Daten von mit dem Steuergerät assoziierten Kommunikationsschnittstellen, und dergleichen.
Beispielsweise kann das Steuergerät bei manchen Ausführungsformen die Informationen über den Betrieb von mit dem Steuergerät verbundenen
Komponenten über eine entsprechende Kommunikationsschnittstelle (CAN-Bus, LIN-Bus, FlexRay-Bus, andere Kommunikationsschnittstellentypen) erhalten, über die das Steuergerät mit den betreffenden Komponenten verbunden ist. Beispielsweise können solche Informationen auch Teile von mittels des
Steuergeräts empfangenen CAN-Botschaften enthalten und dergleichen.
Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass das Steuergerät dazu ausgebildet ist, mittels der ersten Software gesammelte Informationen, insbesondere das mittels der ersten Software erhaltene erste Diagnoseergebnis, an die wenigstens eine externe Einheit zu senden. Dadurch kann die Auswertung des Diagnoseergebnisses vorteilhaft außerhalb des Steuergeräts erfolgen und beispielsweise mittels einer leistungsfähigen
Vorrichtung zur Datenverarbeitung ausgeführt werden, beispielsweise durch ein zentrales Serversystem, ein verteiltes Rechnersystem (cloud), oder dergleichen. Insbesondere können die Diagnoseergebnisse bei manchen Ausführungsformen auch vorteilhaft einem System zur Verfügung gestellt werden, welches ein sogenanntes virtuelles Fahrzeug repräsentiert, also eine digitale Repräsentation einer Mehrheit oder Gesamtheit von in einem tatsächlich vorhandenen Fahrzeug angeordneten Steuergeräten bzw. deren Betriebsparameter.
Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die zweite Software dazu ausgebildet ist, eine gegenüber der ersten Software spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts und/oder damit verbundener Komponenten auszuführen. Damit kann die Diagnosefunktionalität über die von der ersten Software gegebenen Möglichkeiten sinnvoll erweitert werden, insbesondere individuell angepasst an gegebenenfalls vorhandene Fehlerbilder bzw. Probleme, was durch die Auswertung der Informationen über den Betrieb des Steuergeräts bzw. der betreffenden Komponenten ermöglicht ist.
Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die zweite Software eine oder mehrere, insbesondere direkt durch die Recheneinheit ausführbare, Diagnosefunktionen umfasst, die in Abhängigkeit des ersten Diagnoseergebnisses erhalten bzw. programmiert worden sind. Dadurch kann die Recheneinheit direkt die beispielsweise spezifischeren Diagnosefunktionen der zweiten Software nutzen. Besonders bevorzugt wird die zweite Software der Recheneinheit direkt in Form eines ausführbaren Computerprogramms zur Verfügung gestellt, welches beispielsweise zumindest zeitweise in dem
Steuergerät zwischengespeichert werden kann, insbesondere in einem Flash- Speicher oder auch einem Arbeitsspeicher des Steuergeräts, wo es zur
Ausführung durch die Recheneinheit zur Verfügung steht.
Bei einer weiteren bevorzugten Ausführungsform kann der Schritt des Ladens der zweiten Software und/oder der Schritt des Ausführens der zweiten Software während des Betriebs des Steuergeräts bzw. der Recheneinheit erfolgen.
Insbesondere kann vorgesehen sein, dass die Recheneinheit zur Ausführung der erfindungsgemäßen Schritte des Ladens und Ausführens vorteilhaft nicht in einen speziellen Programmierzustand versetzt werden muss, wie er
beispielsweise bei Firmware-Upgrades erforderlich ist, die eine komplette Neuprogrammierung des gesamten Speichers des Steuergeräts erfordern.
Dadurch kann die zweite Software bedarfsweise dynamisch in dem Steuergerät zum Einsatz kommen und zur Erkennung bzw. Klassifizierung von Fehlern beitragen.
Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass das Steuergerät dazu ausgebildet ist, die zweite Software in Abhängigkeit von wenigstens einem Ereignis zu laden, wobei das wenigstens eine Ereignis von der zumindest zeitweisen Sammlung von Informationen abhängt und/oder von wenigstens einer externen Anfrage an das Steuergerät. Mit anderen Worten kann bei manchen Ausführungsformen vorgesehen sein, dass in Abhängigkeit der Sammlung von Informationen durch die erste Software das Laden der zweiten
Software ausgelöst wird. Bei anderen Ausführungsformen kann alternativ oder ergänzend vorgesehen sein, dass das Laden der zweiten Software durch die externe Anfrage an das Steuergerät ausgelöst wird. Dies kann beispielsweise dann zweckmäßig sein, wenn sich geänderte Betriebsbedingungen für das Steuergerät ergeben, die gegebenenfalls eine Veränderung der Ausführung der ersten Software bzw. eine Ergänzung durch die zweite Software erforderlich machen.
Einer weiteren vorteilhaften Ausführungsform zufolge ist also vorgesehen, dass externe Ereignisse das Laden bzw. Nachladen der zweiten Software wie beispielsweise einer zusätzlichen Diagnosefunktion anstoßen bzw. auslösen. Mögliche Ereignisse sind beispielsweise: neu auftretende Fehler anderer gleichartiger oder verschiedenartiger Steuergeräte, insbesondere eine neu auftretende Security-Problematik, die Verbringung des Steuergeräts bzw. eines das Steuergerät enthaltenden Zielsystems (zum Beispiel Kraftfahrzeug) in einen regional anderen Markt mit gegebenenfalls anderen gesetzlich geforderten Diagnosefunktionen, ein geänderter gesellschaftlich geforderter Stand der Technik insbesondere bezüglich der Funktionalität der ersten und/oder zweiten Software, ein externer Anlass zur Untersuchung eines Abnutzungsbildes bzw. Korrosionsbildes bzw. sonstiger Zustände des Steuergeräts bzw. hiermit verbundener Komponenten, beispielsweise veranlasst durch Maßnahmen zur Qualitätssicherung, eine, insbesondere gesellschaftlich gewünschte,
Veränderung, insbesondere Einengung, von Toleranzen in Diagnosefunktionen (beispielsweise Abgas, Objekterkennung), das Testen von Bauteilhypothesen im Feld für Entwicklungs- bzw. Weiterentwicklungsprozesse betreffend das Steuergerät, eine Validierung von Funktionen im Feld mit Bestimmung einer sogenannten„threshold consumption".
Als eine weitere Lösung der Aufgabe der vorliegenden Erfindung ist ein
Verfahren gemäß Patentanspruch 7 angegeben.
Ein weiterer Aspekt der vorliegenden Erfindung betrifft eine Vorrichtung zur Verarbeitung von Daten gemäß Patentanspruch 8. Die Vorrichtung ist dazu ausgebildet, von einem Steuergerät, insbesondere von einem
erfindungsgemäßen Steuergerät, Informationen über einen Betrieb des
Steuergeräts und/oder damit verbundener Komponenten zu empfangen und in Abhängigkeit von diesen Informationen eine spezifische Diagnosesoftware für das Steuergerät zu erstellen und an das Steuergerät zu übertragen. Die erfindungsgemäße Vorrichtung ermöglicht vorteilhaft die effiziente Ausstattung von Steuergeräten, beispielsweise erfindungsgemäßen Steuergeräten, insbesondere für Kraftfahrzeuge, mit einer spezifischen Diagnosefunktionalität im Rahmen der vorstehend bereits beschriebenen erfindungsgemäßen zweiten Software.
Bei einer bevorzugten Ausführungsform ist vorgesehen, dass die Vorrichtung dazu ausgebildet ist, die Informationen über den Betrieb des Steuergeräts auszuwerten, um wenigstens ein Fehlerbild hieraus abzuleiten, die spezifische Diagnosesoftware auf das wenigstens eine Fehlerbild hin zu optimieren. Diese spezifische Diagnosesoftware kann dann als die vorstehend bereits
beschriebene zweite Software an das erfindungsgemäße Steuergerät gesendet bzw. von dem Steuergerät geladen und sodann bei Bedarf ausgeführt werden.
Als eine weitere Lösung der Aufgabe der vorliegenden Erfindung ist ein
Betriebsverfahren für eine Vorrichtung gemäß Patentanspruch 10 angegeben.
Nachfolgend werden beispielhafte Ausführungsformen der Erfindung unter Bezugnahme auf die Zeichnung erläutert. In der Zeichnung zeigt:
Figur 1 schematisch ein Blockdiagramm einer Ausführungsform eines
erfindungsgemäßen Steuergeräts, Figur 2 schematisch ein vereinfachtes Flussdiagramm einer Ausführungsform eines erfindungsgemäßen Betriebsverfahrens für ein Steuergerät,
Figur 3 schematisch ein vereinfachtes Flussdiagramm einer weiteren
Ausführungsform des erfindungsgemäßen Betriebsverfahrens, und
Figur 4 schematisch ein Betriebsszenario gemäß einer Ausführungsform.
Figur 1 zeigt schematisch ein Blockdiagramm einer Ausführungsform eines erfindungsgemäßen Steuergeräts 100. Beispielsweise kann es sich bei dem
Steuergerät 100 um ein Steuergerät für ein Kraftfahrzeug (nicht gezeigt) handeln, zum Beispiel zur Steuerung einer Brennkraftmaschine des Kraftfahrzeugs. Das Steuergerät weist eine Recheneinheit 1 10 auf, bei der es sich beispielsweise um wenigstens einen Mikrocontroller und/oder Mikroprozessor und/oder digitalen Signalprozessor (DSP) und/oder einen anwendungsspezifischen integrierten
Schaltkreis (ASIC) und/oder einen programmierbaren Logikbaustein (FPGA) oder dergleichen handeln kann.
Der Recheneinheit 1 10 ist eine Speichereinheit 120 zugeordnet, die wenigstens einen Arbeitsspeicher (Direktzugriffsspeicher, RAM, Random Access Memory), insbesondere vom SRAM-Typ und/oder vom DRAM-Typ, und/oder wenigstens einen nichtflüchtigen Speicher (non-volatile RAM (NVRAM)), aufweisen kann, z.B. einen Flash-EPROM. In der Speichereinheit 120 ist eine erste Software 131 gespeichert, die zur zumindest zeitweisen Sammlung von Informationen über einen Betrieb des Steuergeräts 100 vorgesehen ist. Alternativ oder ergänzend kann die erste Software 131 bei weiteren Ausführungsformen auch dazu vorgesehen sein, zumindest zeitweise Informationen über einen Betrieb einer mit dem Steuergerät 100 verbundenen Komponente 200 zu sammeln. Bei der Komponente 200 kann es sich beispielsweise um ein anderes Steuergerät oder eine sonstige
Vorrichtung handeln, die mit dem Steuergerät 100 in Datenverbindung steht. Beispielsweise können beide Vorrichtungen 100, 200 an einen gemeinsamen Datenbus, beispielsweise einen CAN-Bus, angeschlossen sein. Ein
entsprechender Datenbus ist in Figur 1 beispielhaft durch den Blockpfeil P1 angedeutet. Das Steuergerät 100 weist ferner eine Datenschnittstelle 140 zum Austausch von Daten mit wenigstens einer externen Einheit 300 auf. Bei der externen Einheit 300 kann es sich beispielsweise um ein entfernt angeordnetes Serversystem handeln, das zum Austausch von Daten mit dem Steuergerät 100 ausgebildet ist. Besonders bevorzugt handelt es sich bei manchen Ausführungsformen bei der
Datenschnittstelle 140 um eine zumindest abschnittsweise drahtlose bzw.
funkbasierte Datenschnittstelle. Hierzu können an sich bekannte Technologien zur drahtlosen Kommunikation wie beispielsweise zelluläre Mobilfunknetze, drahtlose Netzwerke (WLAN) und dergleichen oder Kombinationen hieraus verwendet werden.
Erfindungsgemäß ist vorgesehen, dass das Steuergerät 100 dazu ausgebildet ist, wenigstens eine zweite Software 132, die von der ersten Software 131 verschieden ist, über die Datenschnittstelle 140 von der externen Einheit 300 zu laden und mittels der Recheneinheit 1 10 auszuführen. Dadurch ist vorteilhaft die
Möglichkeit gegeben, beispielsweise bedarfsweise das Steuergerät 100 mit einer gegenüber der ersten Software 131 andersartigen, insbesondere
spezialisierteren, zweiten Software 132 zu versorgen, die beispielsweise eine spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts 100 und/oder damit verbundener Komponenten 200 ermöglicht. Besonders vorteilhaft kann durch das erfindungsgemäße Laden dieser zweiten Software 132 im Bedarfsfalle die Ausstattung von Steuergeräten 100, beispielsweise bei deren Herstellung, bereits mit einer gegebenenfalls vergleichsweise umfangreichen zweiten Software entfallen, sodass entsprechende Ressourcen (Speicher, Rechenzeit) in dem Steuergerät 100 nur dann für die Vorhaltung bzw.
Ausführung der zweiten Software belegt werden, wenn diese tatsächlich benötigt wird und z.B. momentan geladen ist bzw. ausgeführt wird.
Bei einer bevorzugten Ausführungsform ist vorgesehen, dass die erste Software 131 bei der Ausführung durch die Recheneinheit 1 10 eine Diagnose wenigstens einer Funktion des Steuergeräts 100 selbst und/oder eine Diagnose wenigstens einer weiteren mit dem Steuergerät 100 verbundenen Komponente 200 ermöglicht, wodurch ein erstes Diagnoseergebnis erhalten wird. Mithin kann es sich bei der ersten Software 131 um eine Diagnosesoftware handeln, welche ein oder mehrere Diagnosefunktionen ausführt. Beispielsweise kann die erste
Software 131 einen vorgebbaren Satz von minimal-Diagnosefunktionen enthalten, welche zum Beispiel erforderlich sind, um Systemauswirkungen von möglichen Fehlern zu erkennen. Mit dieser ersten Software 131 kann das erfindungsgemäße Steuergerät 100 beispielsweise zum Zeitpunkt seiner Produktion versehen werden, beispielsweise durch einen an sich bekannten Programmiervorgang.
Generell können die vorstehend genannten Informationen über den Betrieb des Steuergeräts bzw. die Informationen über den Betrieb von mit dem Steuergerät verbundenen Komponenten alle durch das Steuergerät 100 erfassbaren Größen des Steuergeräts oder der genannten Komponenten oder beliebige
Kombinationen hieraus umfassen, insbesondere auch Sensormesswerte, Daten von mit dem Steuergerät assoziierten Kommunikationsschnittstellen, und dergleichen. Beispielsweise kann das Steuergerät 100 bei manchen
Ausführungsformen die Informationen über den Betrieb von mit dem Steuergerät 100 verbundenen Komponenten 200 über eine entsprechende
Kommunikationsschnittstelle P1 (CAN-Bus, LIN-Bus, FlexRay-Bus, andere Kommunikationsschnittstellentypen) erhalten, über die das Steuergerät 100 mit den betreffenden Komponenten 200 verbunden ist. Beispielsweise können solche Informationen auch Teile von mittels des Steuergeräts 100 empfangenen CAN-Botschaften enthalten und dergleichen.
Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass das Steuergerät 100 dazu ausgebildet ist, mittels der ersten Software 131
gesammelte Informationen, insbesondere das mittels der ersten Software 131 erhaltene erste Diagnoseergebnis, an die wenigstens eine externe Einheit 300 zu senden. Dadurch kann die Auswertung des Diagnoseergebnisses vorteilhaft außerhalb des Steuergeräts 100 erfolgen und beispielsweise mittels einer leistungsfähigen Vorrichtung zur Datenverarbeitung ausgeführt werden, beispielsweise unter Verwendung eines zentralen Serversystems, eines verteilten Rechnersystems („cloud"), oder dergleichen. Insbesondere können die Diagnoseergebnisse bei manchen Ausführungsformen auch vorteilhaft einem System zur Verfügung gestellt werden, welches ein sogenanntes virtuelles Fahrzeug repräsentiert, also eine digitale Repräsentation einer Mehrheit oder Gesamtheit von in einem tatsächlich vorhandenen Fahrzeug angeordneten Steuergeräten bzw. deren Betriebsparameter. Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die zweite Software 132 dazu ausgebildet ist, eine gegenüber der ersten Software 131 spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts 100 und/oder damit verbundener Komponenten 200 auszuführen. Damit kann die Diagnosefunktionalität über die von der ersten Software 131 gegebenen
Möglichkeiten sinnvoll erweitert werden, insbesondere individuell angepasst an gegebenenfalls vorhandene Fehlerbilder bzw. Probleme, was durch die
Auswertung der Informationen über den Betrieb des Steuergeräts 100 bzw. der betreffenden Komponenten 200 ermöglicht ist.
Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass die zweite Software eine oder mehrere, insbesondere direkt durch die Recheneinheit 1 10 ausführbare, Diagnosefunktionen umfasst, die in Abhängigkeit des ersten Diagnoseergebnisses erhalten bzw. programmiert worden sind. Dadurch kann die Recheneinheit 1 10 direkt die beispielsweise spezifischeren
Diagnosefunktionen der zweiten Software nutzen. Besonders bevorzugt wird die zweite Software 132 der Recheneinheit 1 10 direkt in Form eines ausführbaren Computerprogramms (z.B. Binärcode) zur Verfügung gestellt, welches beispielsweise zumindest zeitweise in dem Steuergerät 100 zwischengespeichert werden kann, insbesondere in einem Flash-Speicher oder auch einem
Arbeitsspeicher des Steuergeräts, wo es zur Ausführung durch die
Recheneinheit 1 10 zur Verfügung steht.
Bei einer weiteren bevorzugten Ausführungsform kann der Schritt des Ladens der zweiten Software 132 und/oder der Schritt des Ausführens der zweiten Software 132 während des Betriebs des Steuergeräts 100 bzw. der
Recheneinheit 1 10 erfolgen. Insbesondere kann vorgesehen sein, dass die Recheneinheit 1 10 zur Ausführung der erfindungsgemäßen Schritte des Ladens und Ausführens vorteilhaft nicht in einen speziellen Programmierzustand versetzt werden muss, wie er beispielsweise bei Firmware-Upgrades erforderlich ist, die eine komplette Neuprogrammierung des gesamten Speichers des Steuergeräts erfordern. Dadurch kann die zweite Software 132 bedarfsweise dynamisch in dem Steuergerät 100 zum Einsatz kommen und z.B. zur Erkennung bzw.
Klassifizierung von Fehlern beitragen. Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, dass das Steuergerät 100 dazu ausgebildet ist, die zweite Software 132 in Abhängigkeit von wenigstens einem Ereignis zu laden, wobei das wenigstens eine Ereignis von der zumindest zeitweisen Sammlung von Informationen (ausgeführt z.B. mittels der ersten Software 131 ) abhängt und/oder von wenigstens einer externen Anfrage an das Steuergerät 100. Mit anderen Worten kann bei manchen Ausführungsformen vorgesehen sein, dass in Abhängigkeit der Sammlung von Informationen durch die erste Software 131 das Laden der zweiten Software 132 ausgelöst wird. Bei anderen Ausführungsformen kann alternativ oder ergänzend vorgesehen sein, dass das Laden der zweiten
Software 132 durch die externe Anfrage an das Steuergerät 100 ausgelöst wird. Dies kann beispielsweise dann zweckmäßig sein, wenn sich geänderte
Betriebsbedingungen für das Steuergerät 100 ergeben, die gegebenenfalls eine Veränderung der Ausführung der ersten Software bzw. eine Ergänzung durch die zweite Software erforderlich machen.
Einer weiteren vorteilhaften Ausführungsform zufolge ist vorgesehen, dass externe Ereignisse das Laden bzw. Nachladen der zweiten Software 132 wie beispielsweise einer zusätzlichen Diagnosefunktion anstoßen bzw. auslösen. Mögliche Ereignisse sind beispielsweise: neu auftretende Fehler anderer gleichartiger oder verschiedenartiger Steuergeräte, insbesondere eine neu auftretende Security-Problematik, die Verbringung des Steuergeräts 100 bzw. eines das Steuergerät 100 enthaltenden Zielsystems (zum Beispiel
Kraftfahrzeug) in einen regional anderen Markt mit gegebenenfalls anderen gesetzlich geforderten Diagnosefunktionen, ein geänderter gesellschaftlich geforderter Stand der Technik insbesondere bezüglich der Funktionalität der ersten und/oder zweiten Software, ein externer Anlass zur Untersuchung eines Abnutzungsbildes bzw. Korrosionsbildes bzw. sonstiger Zustände des
Steuergeräts 100 bzw. hiermit verbundener Komponenten, beispielsweise veranlasst durch Maßnahmen zur Qualitätssicherung, eine, insbesondere gesellschaftlich gewünschte, Veränderung, insbesondere Einengung, von Toleranzen in Diagnosefunktionen (beispielsweise Abgas, Objekterkennung), das Testen von Bauteilhypothesen im Feld für Entwicklungs- bzw.
Weiterentwicklungsprozesse betreffend das Steuergerät 100, eine Validierung von Funktionen im Feld mit Bestimmung einer sogenannten„threshold consumption". Figur 2 zeigt schematisch ein vereinfachtes Flussdiagramm einer
Ausführungsform eines erfindungsgemäßen Betriebsverfahrens für das
Steuergerät 100. In einem ersten Schritt 400 wird wenigstens eine zweite Software 132 (Fig. 1 ), die verschieden ist von der ersten Software 131 , über die Datenschnittstelle 140 von der externen Einheit 300 geladen. Beispielsweise kann es sich hierbei um eine spezifische Diagnosesoftware handeln, die zuvor nicht bereits in dem Steuergerät enthalten war, sondern z.B. extern zu dem Steuergerät 100 erstellt worden ist, beispielsweise in Abhängigkeit von mittels der ersten Software 131 erhaltenen Diagnoseergebnissen, die das Steuergerät 100 zuvor an die externe Einheit 300 gesandt hat.
In Schritt 410 wird die zweite Software 132 mittels der Recheneinheit 1 10 ausgeführt, und es wird hierbei z.B. ein zweites Diagnoseergebnis erhalten, das in einem optionalen weiteren Schritt 420 auch von dem Steuergerät 100 an die externe Einheit 300 gesandt werden kann. Alternativ oder ergänzend kann das Steuergerät 100 eine lokale Fehlerreaktion bzw. eine Signalisierung an einen Benutzer in Abhängigkeit des zweiten Diagnoseergebnisses ausführen.
Sofern die zweite Software 132 nicht mehr von dem Steuergerät 100 benötigt wird, kann sie bei bevorzugten Ausführungsformen wieder aus dem Speicher des Steuergeräts 100 gelöscht werden.
Ein weiterer Aspekt der vorliegenden Erfindung betrifft eine Vorrichtung zur Verarbeitung von Daten, vgl. die externe Einheit 300 aus Figur 1 . Die Vorrichtung 300 ist dazu ausgebildet, von einem Steuergerät, insbesondere von dem erfindungsgemäßen Steuergerät 100, Informationen über einen Betrieb des Steuergeräts 100 und/oder damit verbundener Komponenten 200 zu empfangen und in Abhängigkeit von diesen Informationen eine spezifische Diagnosesoftware für das Steuergerät 100 zu erstellen und an das Steuergerät 100 zu übertragen. Die erfindungsgemäße Vorrichtung 300 ermöglicht vorteilhaft die effiziente Ausstattung von Steuergeräten 100, insbesondere für Kraftfahrzeuge, mit einer spezifischen Diagnosefunktionalität im Rahmen der vorstehend bereits beschriebenen erfindungsgemäßen zweiten Software 132.
Bei einer bevorzugten Ausführungsform ist vorgesehen, dass die Vorrichtung 300 dazu ausgebildet ist, die Informationen über den Betrieb des Steuergeräts 100 auszuwerten, um wenigstens ein Fehlerbild hieraus abzuleiten, und die spezifische Diagnosesoftware auf das wenigstens eine Fehlerbild hin zu optimieren. Diese spezifische Diagnosesoftware kann dann als die vorstehend bereits beschriebene zweite Software 132 an das erfindungsgemäße Steuergerät 100 gesendet bzw. von dem Steuergerät 100 geladen (vgl. Schritt 400 aus Figur
2) und sodann bei Bedarf ausgeführt werden.
Figur 3 zeigt schematisch ein vereinfachtes Flussdiagramm einer
Ausführungsform eines Betriebsverfahrens für die externe Einheit 300, vgl. Fig. 1 . In einem ersten Schritt 500 empfängt die externe Einheit 300 Informationen von dem Steuergerät 100, z.B. die ersten Diagnoseinformationen. In einem zweiten Schritt 510 erstellt die externe Einheit 300 eine spezifische
Diagnosesoftware als zweite Software 132 für das Steuergerät 100 und überträgt sodann diese zweite Software 132 an das Steuergerät 100.
Figur 4 zeigt schematisch ein Betriebsszenario gemäß einer Ausführungsform. Es wird beispielhaft als Zielsystem für das Steuergerät 100 ein Kraftfahrzeug betrachtet, bzw. eine Vielzahl von Kraftfahrzeugen, die jeweils mit dem
Steuergerät 100 ausgestattet sind. Das Bezugszeichen M1 in Figur 4 beschreibt eine Menge der im Feld befindlichen Kraftfahrzeuge mit dem Steuergerät 100.
Das Bezugszeichen M2 beschreibt eine erste Teilmenge dieser im Feld befindlichen Kraftfahrzeuge mit dem Steuergerät 100, und zwar diejenige Teilmenge, bei der durch Ausführung der ersten (z.B. vorinstallierten)
Diagnosesoftware 131 ein Verdacht auf eine Fehlfunktion des Steuergeräts 100 oder einer hiervon wenigstens mittelbar überwachbaren Komponente 200 festgestellt worden ist. Die Steuergeräte 100 dieser ersten Teilmenge M2 können unter Anwendung des erfindungsgemäßen Prinzips vorteilhaft eine spezifische zweite Diagnosesoftware 132 laden, z.B. von der externen Einheit 300, die insbesondere in Abhängigkeit der zuvor erkannten Fehlfunktion erstellt bzw. angepasst worden ist, um eine spezifischere Diagnose als die erste
Diagnosesoftware 131 zu ermöglichen. Das Ausführen der zweiten
Diagnosesoftware 132 führt beispielsweise nur noch bei einer zweiten Teilmenge M3 der ersten Teilmenge M2 zu einer Bestätigung einer Fehlfunktion, nicht aber bei allen Fahrzeugen der ersten Teilmenge M2. Die Fahrzeuge der zweiten Teilmenge M3 können sodann vorteilhaft im Feld untersucht bzw. in die
Werkstatt zurückgerufen werden, um eine noch gründlichere Fehlerdiagnose auszuführen, was auf die dritte Teilmenge M3 von Fahrzeugen führt, bei denen hierbei tatsächlich z.B. ein Komponentenfehler erkannt werden kann.
Wie aus Fig. 4 ersichtlich ist, ermöglicht das erfindungsgemäße Prinzip vorteilhaft die Eingrenzung von (fehler-)verdächtigen Fahrzeugen, um effizient nur eine gewisse Teilmenge M3 der Gesamtmenge M1 näher untersuchen zu müssen, wodurch Kosten gespart werden können und die möglicherweise tatsächlich durch einen Fehler betroffenen Steuergeräte 100 schneller und effizienter identifiziert werden können.
Das erfindungsgemäße Prinzip ermöglicht vorteilhaft das dynamische
Bereitstellen und Nutzen von zweiter Software 132 in einem Steuergerät 100. Dadurch ist es vorteilhaft möglich, die zweite Software erst dann in dem
Steuergerät 100 bereitzustellen, wenn sie tatsächlich benötigt wird. Dies spart Speicherressourcen des Steuergeräts 100 und ermöglicht vorteilhaft die
Erstellung bzw. Veränderung der zweiten Software 132 kurz bevor sie tatsächlich in dem Steuergerät 100 zum Einsatz kommt. Dadurch eignet sich das
erfindungsgemäße Prinzip besonders gut zur Vorhaltung von Diagnosesoftware, welche insbesondere direkt auf ein beispielsweise mittels einer ersten
Diagnosesoftware 131 erkanntes Fehlerbild bzw. einen Fehlerverdacht zugeschnitten werden kann.
Nachstehend sind weitere vorteilhafte Aspekte von weiteren Ausführungsformen genannt.
Bei einer Ausführungsform kann bei ersten Verdachtsmomenten auf
Feldprobleme, die beispielsweise während der Ausführung der ersten
Diagnosesoftware 131 erhalten werden, das Fehlerbild, beispielsweise in
Abhängigkeit des ersten Diagnoseergebnisses, genau eingegrenzt werden, und eine darauf zugeschnittene zweite Diagnosesoftware kann zur verbesserten Fehlerdetektion nachentwickelt bzw. erstellt werden und zur Ausführung in das Steuergerät 100 geladen werden.
Bei einer weiteren Ausführungsform kann das Nachladen der Diagnosefunktion bzw. generell der zweiten Software 132 beispielsweise mittels eines
sogenannten Flash over the air („FOTA") - Mechanismus erfolgen. Besonders bevorzugt wird hierbei jedoch nicht ein gesamter Flash-Speicher bzw.
Speicherbereich des Steuergeräts 100 überschrieben, sondern nur ein der zweiten Software 132 zugeordneter Bereich. Dadurch wird verhindert, dass ein Betrieb des Steuergeräts 100 für die Übertragung der zweiten Software 132 unterbrochen werden muss.
Die Anwendung des erfindungsgemäßen Prinzips ermöglicht vorteilhaft eine Eingrenzung einer Menge von Verdachtsfahrzeugen, vergleiche die Menge M1 aus Figur 4, auf die tatsächlich real betroffenen Fahrzeuge, was vorteilhaft einer Minimierung der sogenannten„defective subgroup" entspricht. Dadurch wird insbesondere auch eine sehr präzise Festlegung möglicherweise von einem Rückruf betroffener Fahrzeuge, vergleiche die Teilmenge M3, ermöglicht. Dies bedingt vorteilhaft eine Kostenreduktion einer Feldaktion, da die Anzahl der betroffenen Fahrzeuge ganz direkt in diese Kosten eingeht.
Bei einer weiteren vorteilhaften Ausführungsform ist vorgesehen, in dem Steuergerät 100 eine solche zweite Software 132 nachzuladen bzw.
auszuführen, welche nicht zur Diagnose des Steuergeräts 100 selbst bzw. eines hiermit direkt verbundenen Systems (beispielsweise ein an das Steuergerät 100 angeschlossener Sensor bzw. Aktor) vorgesehen ist, sondern vielmehr zur Diagnose einer weiteren Komponente 200. Bei der weiteren Komponente kann es sich beispielsweise um eine Lambdasonde handeln, welche an einem Motorsteuergerät angeschlossen ist. Das Steuergerät 100 kann über mit dem Motorsteuergerät gemeinsame Kommunikationsverbindungen beispielsweise Informationen erhalten, welche Ausgangsdaten der Lambdasonde
charakterisieren. Die zweite Software 132 kann beispielsweise dazu vorgesehen sein, solche Ausgangsdaten der Lambdasonde spezifisch auf Fehler hin zu überprüfen. Mit anderen Worten ermöglicht das erfindungsgemäße Prinzip also auch eine spezifische Diagnose von Komponenten bzw. Systemen, die nicht einmal direkt mit dem erfindungsgemäßen Steuergerät 100 verbunden sind, sondern beispielsweise über eine Kommunikationsverbindung P1 bzw. über ein anderes Steuergerät.
Ein weiterer Vorteil des erfindungsgemäßen Prinzips besteht in einer
Verkleinerung des Entwicklungsaufwands für die erste Software 131.
Beispielsweise ist es möglich, für einen Serienstart des Steuergeräts 100 nur eine Entwicklung und Installation von wenigen, zentralen Diagnosefunktionen, beispielsweise zur Erkennung von Systemauswirkungen, vorzusehen. Weitere Diagnosefunktionen mit beispielsweise höherer Trennschärfe bezüglich einer Komponentendiagnose werden in Form der zweiten Software, beispielsweise nur bei Auftreten von entsprechenden Komponentenfehlern, nachentwickelt, und können dem Steuergerät 100 unter Anwendung des erfindungsgemäßen Prinzips später zur Verfügung gestellt werden.
Dies bedingt vorteilhaft eine Aufwandsreduktion in der Entwicklung und ermöglicht einen beschleunigten Markteintritt.
Ein weiterer besonderer Vorteil des erfindungsgemäßen Prinzips ist die
Verkleinerung des Steuergeräte-Ressourcenbedarfs. Insbesondere trennscharfe und aufwendige Diagnosefunktionen, die vergleichsweise viel Laufzeit und/oder Speicher erfordern, werden nur bei Auftreten von entsprechenden Fehlern, beispielsweise erkannt durch die ersten Diagnosesoftware 131 ,„aktiviert" (beispielsweise Nachladen und Ausführen der zweiten Diagnosesoftware 132).

Claims

Ansprüche
1 . Steuergerät (100), insbesondere für ein Kraftfahrzeug, mit einer
Recheneinheit (1 10) zur Ausführung von Software, einer der Recheneinheit zugeordneten Speichereinheit (120), einer in der Speichereinheit (120) gespeicherten ersten Software (131 ) zur zumindest zeitweisen Sammlung von Informationen über einen Betrieb des Steuergeräts (100) und/oder damit verbundener Komponenten, und mit einer Datenschnittstelle (140) zum Austausch von Daten mit wenigstens einer externen Einheit (300), dadurch gekennzeichnet, dass das Steuergerät (100) dazu ausgebildet ist, wenigstens eine zweite Software (132), die von der ersten Software (131 ) verschieden ist, über die Datenschnittstelle (140) von der externen Einheit (300) zu laden und mittels der Recheneinheit (1 10) auszuführen.
2. Steuergerät (100) nach Anspruch 1 , wobei die erste Software (131 ) bei der Ausführung durch die Recheneinheit (1 10) eine Diagnose wenigstens einer Funktion des Steuergeräts (100) selbst und/oder eine Diagnose wenigstens einer weiteren mit dem Steuergerät (100) verbundenen Komponente (200) ermöglicht, wodurch ein erstes Diagnoseergebnis erhalten wird.
3. Steuergerät (100) nach einem der vorstehenden Ansprüche, wobei das
Steuergerät (100) dazu ausgebildet ist, mittels der ersten Software (131 ) gesammelte Informationen, insbesondere ein bzw. das mittels der ersten Software (131 ) erhaltenes erstes Diagnoseergebnis an die wenigstens eine externe Einheit (300) zu senden.
4. Steuergerät (100) nach einem der vorstehenden Ansprüche, wobei die
zweite Software (132) dazu ausgebildet ist, eine gegenüber der ersten Software (131 ) spezifischere Sammlung von Informationen über den Betrieb des Steuergeräts (100) und/oder damit verbundener Komponenten (200) auszuführen. Steuergerät (100) nach einem der Ansprüche 2 bis 4, wobei die zweite Software (132) eine oder mehrere, insbesondere direkt durch die
Recheneinheit (1 10) ausführbare, Diagnosefunktionen umfasst, die in Abhängigkeit des ersten Diagnoseergebnisses erhalten bzw. programmiert worden sind.
Steuergerät (100) nach einem der vorstehenden Ansprüche, wobei das Steuergerät (100) dazu ausgebildet ist, die zweite Software in Abhängigkeit von wenigstens einem Ereignis zu laden, wobei das wenigstens eine Ereignis von der zumindest zeitweisen Sammlung von Informationen abhängt und/oder von wenigstens einer externen Anfrage an das
Steuergerät (100).
Verfahren zum Betreiben eines Steuergeräts (100), insbesondere für ein Kraftfahrzeug, mit einer Recheneinheit (1 10) zur Ausführung von Software, einer der Recheneinheit zugeordneten Speichereinheit (120), einer in der Speichereinheit (120) gespeicherten ersten Software (131 ) zur zumindest zeitweisen Sammlung von Informationen über einen Betrieb des
Steuergeräts (100) und/oder damit verbundener Komponenten (200), und mit einer Datenschnittstelle (140) zum Austausch von Daten mit wenigstens einer externen Einheit (300), dadurch gekennzeichnet, dass das Steuergerät (100) wenigstens eine zweite Software (132), die von der ersten Software (131 ) verschieden ist, über die Datenschnittstelle (140) von der externen Einheit (300) lädt (400) und mittels der Recheneinheit (1 10) ausführt (410).
Vorrichtung (300) zur Verarbeitung von Daten, die dazu ausgebildet ist, von einem Steuergerät (100), insbesondere von einem Steuergerät (100) nach einem der Ansprüche 1 bis 6, Informationen über einen Betrieb des
Steuergeräts (100) und/oder damit verbundener Komponenten zu empfangen (500) und in Abhängigkeit von diesen Informationen eine spezifische Diagnosesoftware (132) für das Steuergerät (100) zu erstellen (510) und an das Steuergerät (100) zu übertragen (520).
Vorrichtung (300) nach Anspruch 8, wobei die Vorrichtung (300) dazu ausgebildet ist, die Informationen über den Betrieb des Steuergeräts (100) auszuwerten, um wenigstens ein Fehlerbild hieraus abzuleiten, und die spezifische Diagnosesoftware (132) auf das wenigstens eine Fehlerbild hin zu optimieren.
10. Verfahren zum Betreiben einer Vorrichtung (300) zur Verarbeitung von
Daten, umfassend die folgenden Schritte: Empfangen (500) von
Informationen von einem Steuergerät (100), insbesondere von einem Steuergerät (100) nach einem der Ansprüche 1 bis 6, über einen Betrieb des Steuergeräts (100) und/oder damit verbundener Komponenten, in
Abhängigkeit von diesen Informationen, Erstellen (510) einer spezifischen Diagnosesoftware (132) für das Steuergerät (100), Übertragen (520) der spezifischen Diagnosesoftware (132) an das Steuergerät (100).
PCT/EP2018/059461 2017-04-19 2018-04-12 Steuergerät und betriebsverfahren hierfür WO2018192840A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201880025928.1A CN110506298B (zh) 2017-04-19 2018-04-12 控制设备和用于该控制设备的运行方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017206559.1A DE102017206559A1 (de) 2017-04-19 2017-04-19 Steuergerät und Betriebsverfahren hierfür
DE102017206559.1 2017-04-19

Publications (1)

Publication Number Publication Date
WO2018192840A1 true WO2018192840A1 (de) 2018-10-25

Family

ID=62002128

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/059461 WO2018192840A1 (de) 2017-04-19 2018-04-12 Steuergerät und betriebsverfahren hierfür

Country Status (4)

Country Link
CN (1) CN110506298B (de)
DE (1) DE102017206559A1 (de)
FR (1) FR3065551A1 (de)
WO (1) WO2018192840A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020216065A1 (de) * 2019-12-20 2021-06-24 Robert Bosch Gesellschaft mit beschränkter Haftung Vorrichtung mit einer Schnittstelle und Verfahren zum Betreiben einer Vorrichtung mit einer Schnittstelle

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442553A (en) * 1992-11-16 1995-08-15 Motorola Wireless motor vehicle diagnostic and software upgrade system
DE102005057776A1 (de) * 2004-12-02 2006-06-14 General Motors Corp., Detroit Verfahren zum Aktualisieren von Fahrzeugdiagnose-Software
US20100023201A1 (en) * 2008-07-24 2010-01-28 David Scott Kinney Method and apparatus for obtaining vehicle data
EP2996090A1 (de) * 2014-09-10 2016-03-16 The Boeing Company Konfigurierbare bordseitige informationsverarbeitung

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2284631A1 (de) * 2009-07-17 2011-02-16 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Fahrzeugdiagnosesystems, Steuerungsprogramm und Fahrzeugdiagnosesystem
US8296007B2 (en) * 2010-05-05 2012-10-23 Ford Global Technologies, Llc Embedded vehicle data recording tools for vehicle servicing
DE102011076378A1 (de) * 2011-05-24 2012-11-29 Robert Bosch Gmbh Diagnosevorrichtung für Kraftfahrzeuge und Diagnoseverfahren
US8930064B2 (en) * 2011-10-27 2015-01-06 Snap-On Incorporated Method and system for automated and manual data capture configuration
SE536394C2 (sv) * 2012-01-13 2013-10-08 Scania Cv Ab System och metod för tillhandahållande av diagnostisk felinformation på basis av innehåll från två databaser
US9142066B2 (en) * 2013-01-04 2015-09-22 Innova Electronics, Inc. Multi-stage diagnostic system and method
US20150161824A1 (en) * 2013-12-10 2015-06-11 Ims Solutions, Inc. Indirect characterization of transportation networks and vehicle health
DE102014204128A1 (de) * 2014-03-06 2015-09-10 Robert Bosch Gmbh Elektronische Einheit für eine Fahrzeugkommunikationsschnittstelle
US9304846B2 (en) * 2014-04-29 2016-04-05 Ford Global Technologies, Llc Apparatus and method of error monitoring with a diagnostic module
US20160196696A1 (en) * 2015-01-01 2016-07-07 Ge Aviation Systems Llc Method of identifying faults in an aircraft
CN106250471A (zh) * 2016-07-29 2016-12-21 东北大学 一种用于列车atp的数据自动提取与存储系统及方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5442553A (en) * 1992-11-16 1995-08-15 Motorola Wireless motor vehicle diagnostic and software upgrade system
DE102005057776A1 (de) * 2004-12-02 2006-06-14 General Motors Corp., Detroit Verfahren zum Aktualisieren von Fahrzeugdiagnose-Software
US20100023201A1 (en) * 2008-07-24 2010-01-28 David Scott Kinney Method and apparatus for obtaining vehicle data
EP2996090A1 (de) * 2014-09-10 2016-03-16 The Boeing Company Konfigurierbare bordseitige informationsverarbeitung

Also Published As

Publication number Publication date
CN110506298B (zh) 2022-09-06
CN110506298A (zh) 2019-11-26
DE102017206559A1 (de) 2018-10-25
FR3065551A1 (fr) 2018-10-26

Similar Documents

Publication Publication Date Title
DE102006028695B4 (de) Elektronisches Steuersystem mit Fehlfunktionsüberwachung
DE102008015352B4 (de) Verfahren zum Aufzeichnen von Daten und Datenaufzeichnungssystem
DE102005015664A1 (de) Diagnosesystem zur Bestimmung einer gewichteten Liste möglicherweise fehlerhafter Komponenten aus Fahrzeugdaten und Kundenangaben
DE102018109195A1 (de) Diagnosesystem und Verfahren zum Verarbeiten von Daten eines Kraftfahrzeugs
WO2009103387A1 (de) Verfahren zum erfassen von diagnosedaten in einem kraftfahrzeug mittels eines flüchtigen ringspeichers und anschliessender datenreduktion in einen nichtflüchtigen speicher
EP2102723B1 (de) Verfahren und vorrichtung zum diagnostizieren von funktionen und fahrzeugsystemen
WO2018192840A1 (de) Steuergerät und betriebsverfahren hierfür
EP1860565A1 (de) Verfahren zur Funktionsprüfung eines Steuergeräts für ein Kraftfahrzeug
DE102007010264B4 (de) Verfahren zum Betreiben eines ersten und eines zweiten Steuergeräts und Geräteanordnung mit dem ersten und dem zweiten Steuergerät
EP2729857B1 (de) Dokumentation von fehlern in einem fehlerspeicher eines kraftfahrzeugs
EP3132322B1 (de) Verfahren zur diagnose eines kraftfahrzeugsystems, diagnosegerät für ein kraftfahrzeugsystem, steuergerät für ein kraftfahrzeugsystem und kraftfahrzeug
DE10228610A1 (de) Verfahren zum Überprüfen eines auf einer elektronischen Recheneinheit ablaufenden Steuerprogramms
WO2020127239A1 (de) Verfahren zur diagnose einer sicherheitskomponente in einem kraftfahrzeug
DE102020205416A1 (de) Vorrichtung und Verfahren zum Diagnostizieren eines Ruhemodus eines CANs für ein Fahrzeug
DE102009028871A1 (de) Verfahren zum Überprüfen eines Speichers
DE102006015207A1 (de) Verfahren und Vorrichtung zur Entwicklung eines Systems für die Betriebsdiagnostik von Fahrzeugen
DE102013216558B4 (de) Verfahren zur Diagnose eines steuerbaren Schaltelements eines Motorsteuergeräts
DE102009053751B4 (de) Verfahren zum Diagnostizieren eines Fehlers an einem Kraftfahrzeug
DE102012015783A1 (de) Diagnoseverfahren und Diagnosesystem für ein Kraftfahrzeug
DE102011052511A1 (de) Verfahren zur Verarbeitung von Daten in einem Beeinflussungsgerät
DE102005031724B4 (de) Verfahren und Vorrichtung zur Diagnose von elektronischen Systemen eines Kraftfahrzeugs
DE102022105249A1 (de) Verfahren zum prüfen von obd-relevanz eines eingangssignals
DE102016203303A1 (de) Fahrzeugdiagnose
EP4167041A1 (de) Verfahren und vorrichtung zur automatischen analyse eines diagnosesystems eines fahrzeugs
DE102018202530A1 (de) Verfahren zum Durchführen einer Diagnose in einem Fahrzeug

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: 18718135

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18718135

Country of ref document: EP

Kind code of ref document: A1