EP2078253A2 - Verfahren und vorrichtung zur fehlerverwaltung - Google Patents

Verfahren und vorrichtung zur fehlerverwaltung

Info

Publication number
EP2078253A2
EP2078253A2 EP07820411A EP07820411A EP2078253A2 EP 2078253 A2 EP2078253 A2 EP 2078253A2 EP 07820411 A EP07820411 A EP 07820411A EP 07820411 A EP07820411 A EP 07820411A EP 2078253 A2 EP2078253 A2 EP 2078253A2
Authority
EP
European Patent Office
Prior art keywords
component
status value
value
status
determined
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07820411A
Other languages
English (en)
French (fr)
Inventor
Philipp Woerz
Mathias Bieringer
Alexander Schaefer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
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 EP2078253A2 publication Critical patent/EP2078253A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00Testing or monitoring of control systems or parts thereof
    • G05B23/02Electric testing or monitoring
    • G05B23/0205Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0267Fault communication, e.g. human machine interface [HMI]
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04Monitoring the functioning of the control system
    • FMECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02DCONTROLLING COMBUSTION ENGINES
    • F02D41/00Electrical control of supply of combustible mixture or its constituents
    • F02D41/22Safety or indicating devices for abnormal conditions
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/24Pc safety
    • G05B2219/24093Display, show place of error, fault

Definitions

  • the invention relates to a method for error management according to the preamble of claim 1, a corresponding device according to the preamble of claim 12, as well as a corresponding computer program and a computer program product.
  • DE 197 31 116 Al deals with a control device for a system.
  • the system is equipped with sensors. Via connecting lines, measured values of the sensors can be transmitted to the control unit.
  • the control system thus receives information about states of the system.
  • DE 103 02 054 A1 relates to the checking of components of an internal combustion engine. Each component is assigned a diagnostic function that communicates with a central function via an interface.
  • the Electronic Stability Program uses a variety of hardware components.
  • the term hardware component in this context sensors, actuators, data transfer controllers and ECU components of all kinds are summarized.
  • the data transfer controllers may be, for example, CAN or Flex-Ray act.
  • the ECU components include, for example, ROM, RAM, EEPROM or A / D converter.
  • a current state of a component or signal is referred to as status. Possible states are for example “valid”, “temporarily invalid”, “not initialised” and “invalid”. Under the status "not initialized” several stages are possible.
  • the states of individual components are determined decentrally by many monitoring algorithms. This means that the monitoring algorithms are distributed throughout the system, such as the ESP. The resulting states are also determined distributed by complex logic parts. Also solved solved, that is implemented in several places in the system, is a following error avoidance, which suppresses non-causal errors, as well as a multiple error handling.
  • the present invention provides a method for error management in a system having a plurality of components, wherein error conditions of the components can be displayed by means of status values.
  • a first status value is determined as a function of an error state of a first component and a second status value as a function of an error state of a second component and as a function of the first status value.
  • the present invention further provides an apparatus for error management in a system having a plurality of components that performs all steps of the method of the invention.
  • the computer program with program code means according to the invention is designed to perform all the steps of the method according to the invention when this computer program is carried out on a computer or a corresponding computing unit, in particular a device according to the invention.
  • the computer program product according to the invention with program code means which are stored on a computer-readable data carrier is provided for carrying out the method according to the invention if this computer program is carried out on a computer or a corresponding arithmetic unit, in particular a device according to the invention.
  • dependency graph (English: Failure Dependency Structure).
  • the dependency graph includes and depicts the dependencies between each of the monitored hardware components and signals of the system.
  • the dependency graph includes an association of monitoring algorithms with the monitored hardware components.
  • the approach according to the invention enables a collection of all monitoring results which are available from components of the system and makes it possible to determine the resulting hardware component and signal statuses. Furthermore, a recognition of subsequent errors is made possible to suppress implausible error memory entries. Such a process is also referred to as consequential error avoidance. Also a preparation of a multiple error treatment is made possible.
  • the inventive approach offers a number of implementation-independent advantages. This includes a central collection of all errors reported by monitoring algorithms. As a result, the clarity of the system is greatly increased.
  • the dependencies that are displayed in the dependency graph are highly project dependent.
  • the central definition of these dependencies greatly reduces the effort involved in project initiation and during the course of the project. As a rule, the requirements for the overall system change in the course of product development. The scope of system and software parts affected by these changes is very small.
  • the centralization of dependencies makes analysis much easier and involves far fewer people.
  • a tool-based analysis of the implementation of hardware dependencies is greatly simplified or made possible by the central definition of dependencies.
  • the product configuration is much easier.
  • the error rate is greatly reduced by the tool-based configuration.
  • the inventive approach also offers a number of implementation-relevant advantages.
  • very efficient algorithms can be used to further process the errors.
  • less of the very limited resources ROM, RAM and runtime or cycle time are consumed in a controller.
  • Graphic product configuration and automatic code generation reduce the risk of errors and greatly simplify product handling.
  • the status values indicate whether a value provided by a component is valid or invalid, and a second status value may be determined such that the second status value indicates that a value provided by the second component of the system is invalid if the first status value received from the first component of the system indicates that a value provided by the first component is invalid.
  • a second status value may be determined such that the second status value indicates that a value provided by the second component of the system is invalid if the first status value received from the first component of the system indicates that a value provided by the first component is invalid.
  • a further status value is determined as a function of an error state of the further component and depending on the first or a preceding status value.
  • the system has a virtual component, wherein an error state of the virtual component is determined from status values of a predetermined one of the (real) components according to a linking rule, and a virtual status value depending on the error state of the virtual component and dependent determined by the first status value.
  • each status value whose determination depends on a preceding status value is determined only once. By doing so, resources within the system can be saved without compromising the reliability or security of the system.
  • a status value as a function of which no further status value is determined in order to determine which status value, starting from the first status value, has first indicated that a value that can be provided by a component is invalid to determine a faulty component. It proves to be particularly appropriate that a part of the System that has the faulty component, degraded or disabled. This ensures optimal operation, especially of safety-relevant systems despite faulty components.
  • information about the faulty component is stored, which facilitates maintenance or fault analysis work.
  • the error conditions of the components are determined by executing monitoring algorithms.
  • Such monitoring algorithms can be used particularly effectively and quickly on the basis of a method according to the invention.
  • the linkage rule for determining the error state of a virtual component is an AND link. With this link troubleshooting can be accomplished in a particularly effective manner.
  • the status values further indicate whether a component-settable value is momentarily invalid, or whether a component is uninitialized, wherein the second status value may be determined to indicate that a value provided by the second component Value is invalid if a first status value indicates that the value provided by a first component is temporarily invalid or the first component is not initialized.
  • Fig. 1 shows a dependency graph according to a preferred embodiment of the present invention.
  • Fig. 2 shows another dependency graph according to another preferred embodiment of the present invention.
  • the method according to the invention and the device according to the invention can be represented in the form of a dependency graph.
  • the dependency graph forms a system with a plurality of components.
  • the dependency graph contains all the monitored components of the system. This includes all hardware components of the system as well as signals supplied by the hardware components.
  • the monitored components are represented as nodes in the dependency graph.
  • Dependencies between the components are represented in the dependency graph by connections between the nodes.
  • the dependency graph is directed and countercyclical. Directed means that a connection between two nodes of the dependency graph is always passed in one direction only. If arbitrary connections are followed from any of the nodes, then one neither returns to the output node, nor one of the other nodes is traversed more than once. The dependency graph is thus anti-cyclical.
  • Figures 1 and 2 show dependency graphs according to preferred embodiments of the present invention.
  • the nodes of the dependency graphs shown are represented as ellipses between which directed links exist. Also shown are the respective nodes associated monitoring, which may be prioritized with each other.
  • Fig. 1 shows a dependency graph according to an embodiment of the present invention.
  • the dependency graph depicts a system 100 having a plurality of components.
  • An error state or availability state of a first component 110 of the system 100 can be determined by means of one or a plurality of monitoring algorithms 111, 112, 113. Depending on the error state of the first component 110, a first status value 115 may be determined and transmitted to a second component 120.
  • the component 110 may be configured to provide a component value.
  • the component value may be, for example, a sensor signal, a control signal or a transmitted value.
  • the deliverable component value for example the sensor signal, may be valid or invalid.
  • the first status value 115 may indicate whether the value provided by the first component 110 is valid or invalid.
  • An error state of the second component 120 of the system 100 can be determined by means of one or a plurality of further monitoring algorithms 121, 122.
  • a second status value 125 may be determined and provided.
  • the second status value 125 may indicate whether a value provided by the second component 120 is valid or invalid.
  • the second status value 125 can be determined such that the second status value 125 indicates that a value that can be provided by the second component 120 is invalid if the first status value 115 indicates that a value provided by the first component 110 is invalid.
  • the second status value 125 is determined such that the second status value 125 can only indicate that a value that can be provided by the second component 120 is valid if the first status value 115 indicates that a value that can be provided by the first component 115 is valid is.
  • An error condition of a third component 130 of the system 100 may be determined using one or a plurality of monitoring algorithms 131, 132, 133. Depending on the error state of the third component 130 and the second status value 125, a third status value 135 may be determined and provided. The third status value 135 may indicate that a value provided by the third component 130 is valid or invalid. By determining the third status value 135 in response to the second status value 125, the third status value 135 may be determined such that the third status value 135 indicates that a value provided by the third component 130 is invalid when the second status value indicates 125 in that a value provided by the second component 120 is invalid.
  • the system 100 has a further second component 140 and a further third component 150, which are arranged parallel to the first and second components 120, 130.
  • the first status value 115 is additionally provided to the further second component 140.
  • An error state of the second further component 140 of the system 100 can be determined by means of a plurality of monitoring algorithms 141, 142, 143.
  • a second further status value 145 may be determined and provided.
  • the second additional status value 145 may indicate whether a value provided by the second further component 140 is valid or invalid.
  • the second further status value 145 can be determined in such a way that the second further status value 145 indicates that a value which can be provided by the second further component 140 is invalid if the second further status value 145 first status value 115 indicates that a value provided by the first component 110 is invalid.
  • An error condition of a third further component 150 of the system 100 can be determined by means of a plurality of monitoring algorithms 151, 152, 153.
  • a third further status value 155 may be determined and provided.
  • the third additional status value 155 may indicate whether a value provided by the third further component 150 is valid or invalid.
  • the third additional status value 155 may be determined such that the third additional status value 155 indicates that a value provided by the third further component 150 is invalid if the second other status value indicates 145, one of the second further status value Component 140 is invalidable.
  • a status value whose determination depends on a previous status value is not determined until the previous status value has been determined. For example, first the first status value 115 is determined. Thereafter, depending on the first status value 115 and the error state of the second component 120, the second status value 125 is determined. Subsequently, depending on the second status value 125 and the error state of the third component 130, the third status value 135 is determined.
  • the error management method according to the invention can be executed several times or as often as desired in chronological succession. For each execution, each status value 115, 125, 135, 145, 155 is determined only once, or each status value needs to be determined only once.
  • the status values 135, 155 can be evaluated in order to detect a faulty component of the system. This can be done, for example, with an evaluation device (not shown in the figures), which is designed to receive and evaluate the status values 135, 155. It can be determined here whether and, if so, which status value was the first to indicate that a value that can be provided by a component is invalid. A portion of the system 100 having the failed component may then be degraded or disabled. Also, information about the faulty component may be stored, for example, in a memory device (not shown in the figures).
  • the status values may further indicate whether a component-settable value is temporarily invalid or a component is not initialized.
  • the second status value 125 indicates that a value that can be provided by the second component 120 is currently invalid or that the second component 120 is uninitialized
  • the third status value 135 may not indicate that a value provided by the third component 130 is valid, but indicates that the value provided by the third component 130 is also invalid.
  • the system 100 may be, for example, an ESP.
  • the components 110, 120, 130, 140, 150 may be, for example, sensors, actuators, data transfer controllers, control unit components or signals that can be transmitted by such components.
  • the status values can be provided in any form, for example in the form of signals, which can be received by the dependent components.
  • node 110 may be associated with a controller ECU
  • node 120 may be associated with an A / D converter
  • node 130 may be associated with a wheel speed sensor VL
  • node 140 may be associated with a CAN
  • node 150 may be associated with a yaw rate sensor.
  • the node 110 is assigned among other things a monitoring of a total failure 111, a monitoring of the ROM 112 and a monitoring of the RAM 113.
  • the node 120 may be assigned a monitoring of a total failure 121 and a monitoring of an interference 122.
  • the node 130 may be assigned to monitor a total failure 131, monitor a gradient 132, and monitor a range of values 133.
  • the node 140 may be assigned a total failure monitor 141, a message "1" 142 monitor, and a message "2" 143 monitor.
  • the node 150 may be assigned a monitoring of a total failure 151, a monitoring of a gradient 152 and a monitoring of a value range 153.
  • the determination of the resulting hardware and signal states is considered.
  • the results of the node-own monitoring on the other hand, the status of the predecessor node. If a monitoring algorithm detects an error, the associated node is marked as invalid.
  • all so-called children of this node ie all nodes that can be reached by following the connections from this node, also become invalid. This inheritance of the detected error to the so-called child nodes is referred to as error propagation. This is necessary because none of the signals supplied by the failed hardware component can be used anymore.
  • a connection of the yaw rate sensor to which node 150 is assigned is realized in a specific project by means of the CAN protocol to which node 140 is assigned. If the failure of the CAN controller is detected by the node-specific monitoring Totalausfall 141, the node 140, which is assigned to the CAN, marked as invalid. Because the correct reception of signals of the CAN bus is no longer guaranteed, the node 150 assigned to the yaw rate is automatically marked as invalid. So there is an error propagation.
  • an error has been detected in a monitored component, an entry is made in an error memory (not shown in the figures) to reconstruct the error event.
  • This fault memory for example, can be analyzed later by a service person in a workshop. In order to enable a goal-oriented and smooth localization of the defective component - this falls under the keyword "smallest exchangeable unit" - the error memory may contain only causal errors and consequential errors as far as possible
  • a causal error is the error that is the actual reason for a failure
  • a following error is an error that is detected due to another error.
  • a dependent signal for example the yaw rate (at 150)
  • the yaw rate provides errors if the presupposed signal, or the prerequisite component, for example, the CAN (at 140) is defective.
  • the following scenario shows a simple example of a consequent error within node 130.
  • a connection to a wheel speed sensor of a vehicle is interrupted.
  • an outline of a cable is detected, which is detected by the node-specific monitoring total failure 131.
  • the measured wheel speed abruptly drops from 50 m / s to 0 m / s within 10 ms.
  • the resulting gradient of the signal of -5,000 m / s 2 is recognized as implausible (gradient monitoring 132).
  • the actual reason for the much too high gradient is the line break.
  • the following scenario shows an example of a following error at different nodes.
  • an invalid value is detected (at 130) by the monitoring of the wheel speed sensor (at 130) because the valid range of values is left by the interference.
  • Exceeding the permissible value range 133 is thus a follow-up error of the interference at the A / D converter 122.
  • Fig. 2 shows a dependency graph describing another embodiment of the present invention.
  • the system 100 already described with reference to FIG. 1 is expanded by a virtual component 260.
  • the virtual component 260 is not a real component but a virtual component that is included in the dependency graph to improve error detection in the system 100.
  • An error state of the virtual component 260 can be determined by means of a monitoring algorithm 261.
  • the monitoring algorithm may associate status values of a predetermined selection of the components 110, 120, 130, 140, 150 of the system 100 according to a linking rule to determine the error state of the virtual component 260.
  • the monitoring algorithm 261 could link the status value 135 of the third component 130 to the further second status value 145 of the further second component 140.
  • the link rule can be an AND link.
  • a virtual status value 265 is determined depending on the error state of the virtual component and, according to the embodiment shown in FIG. 2, depending on the first status value 115.
  • the virtual component 260 is assigned a node 260 of the dependency graph.
  • the node 260 may for example be assigned a virtual hardware component "3 wheel speeds” or “3 wheel speed sensors".
  • the node 260 may include a monitor 261 in the form of a number of defective wheel speeds.
  • the yaw rate sensor's status is set to "invalid,” as described above in connection with the determination of the resulting hardware. If the speed sensor on one of the wheels also fails, its status is also set to "invalid". If, as in the exemplary embodiment shown in FIG. 1, there is no virtual hardware component for this error combination, a target system state is determined only on the basis of the two individual statuses.
  • the RPM sensor on one of the wheels fails in the ESP, its status is set to "invalid.” If the speed sensors on two other wheels also fail, the ESP will no longer have enough information to safely access work. Therefore, the signal status of the virtual hardware component 260 "3 wheel speed sensors" is set to "invalid”. This information is used by downstream functionalities to deactivate the ESP, although theoretically the vehicle speed could still be calculated in a worse quality.
  • components, further components and virtual components can be arranged in any number and, as part of a directed dependency graph, in any connection with one another.
  • the present invention may be implemented in the form of software.
  • the inventive method offers a new concept for configuring hardware dependencies of dynamic systems.
  • the inventive concept of a FaMu re Dependency Structure is suitable for central error management in dynamic systems.
  • the inventive approach is by no means limited to the vehicle dynamics control ESP described. Rather, the use in all mechatronic embedded systems is conceivable.
  • the described examples from the field of application of the ESP are merely illustrative, but in no way limit the field of application of the invention.

Abstract

Ein Verfahren zur Fehlerverwaltung in einem System (100) mit einer Mehrzahl von Komponenten (110, 120), wobei Fehlerzustände der Komponenten mittels Statuswerten (115, 125) anzeigbar sind besteht darin, dass ein erster Statuswert (115) abhängig von einem Fehlerzustand einer ersten Komponente (110) und ein zweiter Statuswert (125) abhängig von einem Fehlerzustand einer zweiten Komponente (120) und abhängig von dem ersten Statuswert (115) bestimmt wird.

Description

Beschreibung
Titel
Verfahren und Vorrichtung zur Fehlerverwaltung
Die Erfindung betrifft ein Verfahren zur Fehlerverwaltung gemäß dem Oberbegriff des Anspruchs 1, eine entsprechende Vorrichtung gemäß dem Oberbegriff von Anspruch 12, sowie ein entsprechendes Computerprogramm und ein Computerprogrammprodukt.
Stand der Technik
Die DE 197 31 116 Al befasst sich mit einem Steuergerät für ein System. Das System ist mit Sensoren ausgestattet. Über Verbindungsleitungen können Messwerte der Sensoren zum Steuergerät hin übertragen werden. Das Steuersystem erhält somit Informa- tionen über Zustände des Systems.
Die DE 103 02 054 Al betrifft die Überprüfung von Komponenten einer Brennkraftmaschine. Jeder Komponente ist eine Diagnosefunktion zugeordnet, die jeweils über eine Schnittstelle mit einer zentralen Funktion kommuniziert.
Nachfolgend wird im Wesentlichen auf ein elektronisches Stabilitätsprogramm Bezug genommen, das beispielsweise im Automobilbereich eingesetzt werden kann. Das Verfahren oder die Vorrichtung sind jedoch nicht auf diese Anwendung beschränkt.
Im Elektronischen Stabilitätsprogramm (ESP; ESP = Elektronisches Stabilitätsprogramm) kommen verschiedene Hardwarekomponenten zum Einsatz. Unter dem Begriff Hardwarekomponente werden in diesem Zusammenhang Sensoren, Aktoren, Datenübertragungscontroller und Steuergerätekomponenten aller Art zusammengefasst. Bei den Datenübertragungscontrollern kann es sich beispielsweise um CAN oder Flex-Ray handeln. Unter die Steuergerätekomponenten fallen beispielsweise ROM, RAM, EEPROM oder A/D-Wandler.
Alle erwähnten Hardwarekomponenten sowie die Signale, die von den Hardwarekom- ponenten übertragen oder geliefert werden, werden während ihres Betriebes überwacht, um eventuelle Ausfälle zu erkennen. Ein aktueller Zustand einer Komponente oder eines Signals wird als Status bezeichnet. Mögliche Stati sind beispielsweise „gültig", „kurzzeitig ungültig", „nicht initialisiert" und „ungültig". Unter dem Status „nicht initialisiert" sind mehrere Stufen möglich.
Derzeit werden die Stati einzelner Komponenten von vielen Überwachungsalgorithmen dezentral bestimmt. Das bedeutet, dass die Überwachungsalgorithmen über das gesamte System, beispielsweise das ESP, verteilt sind. Die resultierenden Stati werden durch komplexe Logikteile ebenfalls verteilt ermittelt. Ebenfalls verteilt gelöst, das heißt an mehreren Stellen im System implementiert, ist eine Folgefehlervermeidung, durch die nicht-kausale Fehler unterdrückt werden, sowie eine Mehrfachfehlerbehandlung.
Diese Verteilung der Aufgaben und Verantwortlichkeiten erschwert erheblich eine Produktkonfiguration des Systems und eine Bearbeitung von Kundenprojekten. Darüber hinaus ist bei herkömmlichen Systemen ein Einsatz von Tools zur automatisierten Do- kumentationsgenerierung in den drei angesprochenen Bereichen, der Ermittlung der resultierenden Stati, der Folgefehlervermeidung sowie der Mehrfachfehlerbehandlung, nicht möglich.
Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren sowie eine Vorrichtung zur verbesserten Fehlerverwaltung in einem System mit einer Mehrzahl von Komponenten sowie ein entsprechendes Computerprogramm und ein Computerprogrammprodukt zu schaffen.
Technische Aufgabe
Diese Aufgabe wird gemäß einem Verfahren nach Anspruch 1, einer Vorrichtung gemäß Anspruch 12 sowie einem Computerprogramm und einem Computerprogrammprodukt gemäß den Ansprüchen 14 und 15 gelöst. Technische Lösung
Die vorliegende Erfindung schafft ein Verfahren zur Fehlerverwaltung in einem System mit einer Mehrzahl von Komponenten, wobei Fehlerzustände der Komponenten mittels Statuswerten anzeigbar sind. Dabei wird ein erster Statuswert abhängig von einem Fehlerzustand einer ersten Komponente und ein zweiter Statuswert abhängig von einem Fehlerzustand einer zweiten Komponente und abhängig von dem ersten Statuswert bestimmt.
Gemäß dem erfindungsgemäßen Verfahren sind Fehler innerhalb eines Gesamtsystems sehr schnell feststellbar, darstellbar und im gesamten System kommunizierbar.
Die vorliegende Erfindung schafft ferner eine Vorrichtung zur Fehlerverwaltung in ei- nem System mit einer Mehrzahl von Komponenten, die alle Schritte des erfindungsgemäßen Verfahrens durchführt.
Das erfindungsgemäße Computerprogramm mit Programmcodemitteln ist dazu ausgelegt alle Schritte des erfindungsgemäßen Verfahrens durchzuführen, wenn dieses Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere einer erfindungsgemäßen Vorrichtung, durchgeführt wird.
Das erfindungsgemäße Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, ist zur Durchführung des erfin- dungsgemäßen Verfahrens vorgesehen, wenn dieses Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere einer erfindungsgemäßen Vorrichtung, durchgeführt wird.
Ein wesentlicher Aspekt der Erfindung ist in einem so genannten Abhängigkeitsgraph darstellbar, (engl.: Failure Dependency Structure). Der Abhängigkeitsgraph beinhaltet und stellt die Abhängigkeiten zwischen den einzelnen überwachten Hardwarekomponenten und Signalen des Systems dar. Darüber hinaus beinhaltet der Abhängigkeitsgraph eine Zuordnung von Überwachungsalgorithmen zu den überwachten Hardwarekomponenten. Vorteilhafte Wirkungen
Aufbauend hierauf ermöglicht der erfindungsgemäße Ansatz eine Sammlung aller Cl- berwachungsergebnisse, die von Komponenten des Systems vorliegen und ermöglicht eine Ermittlung von resultierenden Hardwarekomponenten- und Signalstati. Ferner wird eine Erkennung von Folgefehlern ermöglicht, um unplausible Fehlerspeichereinträge zu unterdrücken. Ein solcher Vorgang wird auch als Folgefehlervermeidung bezeichnet. Auch wird eine Vorbereitung einer Mehrfachfehlerbehandlung ermöglicht.
Der erfindungsgemäße Ansatz bietet eine Reihe von implementierungsunabhängigen Vorteilen. Darunter fällt eine zentrale Sammlung aller von Überwachungsalgorithmen gemeldeten Fehler. Dadurch wird die Übersichtlichkeit des Systems stark erhöht. Die Abhängigkeiten, die in dem Abhängigkeitsgraph dargestellt werden, sind stark projekt- abhängig. Durch die zentrale Definition dieser Abhängigkeiten wird der Aufwand bei der Projektinitiierung und während des Projektverlaufs stark vermindert. In der Regel ändern sich die Anforderungen an das Gesamtsystem im Laufe der Produktentwicklung. Der Umfang der von diesen Änderungen betroffenen System- und Softwareteile ist sehr gering. Die Zentralisierung der Abhängigkeiten macht Analysen sehr viel einfa- eher und involviert wesentlich weniger Personen. Eine toolgestützte Analyse der Umsetzung der Hardwareabhängigkeiten wird durch die zentrale Definition der Abhängigkeiten stark vereinfacht bzw. ermöglicht. Die Produktkonfiguration wird deutlich erleichtert. Die Fehleranfälligkeit wird durch die toolgestützte Konfiguration stark reduziert.
Der erfindungsgemäße Ansatz bietet ferner eine Reihe von implementierungsrelevanten Vorteilen. So können sehr effiziente Algorithmen zum Einsatz kommen, um die Fehler weiterzuverarbeiten. Dadurch werden weniger von den sehr begrenzten Ressourcen ROM, RAM und Laufzeit bzw. Zykluszeit in einem Steuergerät verbraucht. Durch eine graphische Produktkonfiguration und automatische Code-Generierung wird die Fehleranfälligkeit reduziert und das Produkthandling stark vereinfacht.
Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche. Zweckmäßigerweise zeigen die Statuswerte an, ob ein von einer Komponente bereitstellbarer Wert gültig oder ungültig ist, wobei ein zweiter Statuswert derart bestimmt werden kann, dass der zweite Statuswert anzeigt, dass ein von der zweiten Komponente des Systems bereitstellbarer Wert ungültig ist, wenn der erste Statuswert, der von der ersten Komponente des Systems erhalten wurde, anzeigt, dass ein von der ersten Komponente bereitstellbarer Wert ungültig ist. Hiermit sind Statuswerte sehr schnell innerhalb des Systems kommunizierbar, wodurch insbesondere auch sicherheitsrelevante Statuswerte innerhalb eines Systems für sämtliche Komponenten bereitstellbar sind.
Es erweist sich als zweckmäßig, dass ein weiterer Statuswert abhängig von einem Fehlerzustand der weiteren Komponente und abhängig von dem ersten bzw. einem vorangehendem Statuswert bestimmt wird.
Gemäß einer besonders bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens weist das System eine virtuelle Komponente auf, wobei ein Fehlerzustand der virtuellen Komponente aus Statuswerten einer vorbestimmten der (realen) Komponenten gemäß einer Verknüpfungsvorschrift bestimmt wird, und ein virtueller Statuswert abhängig von dem Fehlerzustand der virtuellen Komponente und abhängig von dem ersten Statuswert bestimmt wird. Durch die Definition derartiger virtueller Komponenten und entsprechend zweckmäßiger Verknüpfungsvorschriften können Fehlerzustände in besonders effektiver Weise innerhalb des Systems kommuniziert werden.
Es erweist sich als zweckmäßig, dass ausgehend von dem ersten Statuswert jeder Statuswert, dessen Bestimmung von einem vorangegangenen Statuswert abhängt, nur ein einziges Mal bestimmt wird. Durch diese Maßnahme können Ressourcen innerhalb des Systems eingespart werden, ohne die Zuverlässigkeit bzw. Sicherheit des Systems zu beeinträchtigen.
Es erweist sich ferner als vorteilhaft, dass ein Statuswert, in Abhängigkeit von dem kein weiterer Statuswert bestimmt wird, ausgewertet wird, um festzustellen, welcher Statuswert, ausgehend von dem ersten Statuswert, als erstes angezeigt hat, dass ein von einer Komponente bereitstellbarer Wert ungültig ist, um so eine fehlerhafte Komponente zu bestimmen. Hierbei erweist es sich als besonders zweckmäßig, dass ein Teil des Systems, der die fehlerhafte Komponente aufweist, degradiert oder deaktiviert wird. Hiermit ist ein optimaler Betrieb insbesondere auch sicherheitsrelevanter Systeme trotz fehlerhafter Komponente gewährleistet.
Zweckmäßigerweise wird eine Information über die fehlerhafte Komponente gespeichert, wodurch Wartungs- oder Fehleranalysearbeiten erleichtert werden können.
Es erweist sich als vorteilhaft, dass die Fehlerzustände der Komponenten ermittelt werden, indem Überwachungsalgorithmen ausgeführt werden. Derartige Überwa- chungsalgorithmen sind auf der Grundlage eines erfindungsgemäßen Verfahrens besonders effektiv und schnell einsetzbar.
Vorteilhafterweise ist die Verknüpfungsvorschrift zur Bestimmung des Fehlerzustands einer virtuellen Komponente eine Und-Verknüpfung. Mit dieser Verknüpfung ist eine Fehlersuche in besonders effektiver Weise bewerkstelligbar.
Es erweist sich als zweckmäßig, dass die Statuswerte ferner anzeigen, ob ein von einer Komponente bereitstellbarer Wert kurzzeitig ungültig, oder ob eine Komponente nicht initialisiert ist, wobei der zweite Statuswert so bestimmt werden kann, dass dieser anzeigt, dass ein von der zweiten Komponente bereitstellbarer Wert ungültig ist, wenn ein erster Statuswert anzeigt, dass der von einer ersten Komponente bereitstellbare Wert kurzzeitig ungültig, oder die erste Komponente nicht initialisiert ist. Mittels dieser Maßnahmen können auch insbesondere kurzzeitige Ausfälle von Komponenten berücksichtigt werden.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
Es versteht sich, dass die vorstehend genannten und die nachstehend noch zu erläu- ternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen. Die Erfindung ist anhand von Ausführungsbeispielen in den folgenden Zeichnungen schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
Kurze Beschreibung der Zeichnungen
Fig. 1 zeigt einen Abhängigkeitsgraph gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung; und
Fig. 2 zeigt einen weitern Abhängigkeitsgraph gemäß einer weiteren bevorzugten Ausführungsform der vorliegenden Erfindung.
Das erfindungsgemäße Verfahren sowie die erfindungsgemäße Vorrichtung können in Form eines Abhängigkeitsgraphen dargestellt werden. Der Abhängigkeitsgraph bildet dabei ein System mit einer Mehrzahl von Komponenten ab. Der Abhängigkeitsgraph beinhaltet alle überwachten Komponenten des Systems. Darunter werden zum einem alle Hardwarekomponenten des Systems, als auch von den Hardwarekomponenten gelieferten Signale verstanden. Die überwachten Komponenten werden im Abhängigkeitsgraph als Knoten dargestellt. Abhängigkeiten zwischen den Komponenten sind im Abhängigkeitsgraph durch Verbindungen zwischen den Knoten dargestellt.
Der Abhängigkeitsgraph ist gerichtet und antizyklisch. Gerichtet bedeutet, dass eine Verbindung zwischen zwei Knoten des Abhängigkeitsgraphen immer nur in einer Richtung durchlaufen wird. Wird ausgehend von einem beliebigen der Knoten beliebigen Verbindungen gefolgt, so gelangt man weder zum Ausgangsknoten zurück, noch wird einer der anderen Knoten mehr als einmal durchlaufen. Der Abhängigkeitsgraph ist also antizyklisch.
Die Figuren 1 und 2 zeigen Abhängigkeitsgraphen gemäß bevorzugten Ausführungs- beispielen der vorliegenden Erfindung. Die Knoten der gezeigten Abhängigkeitsgraphen sind als Ellipsen dargestellt, zwischen denen gerichtete Verbindungen bestehen. Ebenfalls dargestellt sind den jeweiligen Knoten zugeordnete Überwachungen, die untereinander priorisiert sein können. Fig. 1 zeigt einen Abhängigkeitsgraph gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Der Abhängigkeitsgraph bildet ein System 100 mit einer Mehrzahl von Komponenten ab.
Ein Fehlerzustand oder Verfügbarkeitszustand einer ersten Komponente 110 des Systems 100 kann mittels eines oder einer Mehrzahl von Überwachungsalgorithmen 111, 112, 113 bestimmt werden. Abhängig von dem Fehlerzustand der ersten Komponente 110 kann ein erster Statuswert 115 bestimmt und an eine zweite Komponente 120 ü- bermittelt bzw. bereitgestellt werden. Im Betrieb kann die Komponente 110 ausgebildet sein, um einen Komponentenwert bereitzustellen. Bei dem Komponentenwert kann es sich beispielsweise um ein Sensorsignal, ein Steuersignal oder einen übertragenen Wert handeln. Abhängig von dem Fehlerzustand der Komponente 110, kann der bereitstellbare Komponentenwert, beispielsweise das Sensorsignal, gültig oder ungültig sein. Gemäß einem Ausführungsbeispiel kann der erste Statuswert 115 anzeigen, ob der von der ersten Komponente 110 bereitstellbare Wert gültig oder ungültig ist.
Ein Fehlerzustand der zweiten Komponente 120 des Systems 100 kann mittels eines oder einer Mehrzahl weiterer Überwachungsalgorithmen 121, 122 bestimmt werden. Abhängig von dem Fehlerzustand der zweiten Komponente 120 und abhängig von dem ersten Statuswert 115, der von der ersten Komponente bereitgestellt wird, kann ein zweiter Statuswert 125 bestimmt und bereitgestellt werden. Der zweite Statuswert 125 kann anzeigen, ob ein von der zweiten Komponente 120 bereitstellbarer Wert gültig oder ungültig ist. Indem der zweite Statuswert 125 auch abhängig von dem ersten Statuswert 115 bestimmt wird, kann der zweite Statuswert 125 derart bestimmt wer- den, das der zweite Statuswert 125 anzeigt, dass ein von der zweiten Komponente 120 bereitstellbarer Wert ungültig ist, wenn der erste Statuswert 115 anzeigt, dass ein von der ersten Komponente 110 bereitstellbarer Wert ungültig ist. Anders ausgedrückt, wird der zweite Statuswert 125 derart bestimmt, dass der zweite Statuswert 125 nur dann anzeigen kann, dass ein von der zweiten Komponente 120 bereitstellbarer Wert gültig ist, wenn der erste Statuswert 115 anzeigt, dass ein von der ersten Komponente 115 bereitstellbarer Wert gültig ist.
Ein Fehlerzustand einer dritten Komponente 130 des Systems 100 kann mittels eines oder einer Mehrzahl von Überwachungsalgorithmen 131, 132, 133 bestimmt werden. Abhängig von dem Fehlerzustand der dritten Komponente 130 und abhängig von dem zweiten Statuswert 125, kann ein dritter Statuswert 135 bestimmt und bereitgestellt werden. Der dritte Statuswert 135 kann anzeigen, dass ein von der dritten Komponente 130 bereitstellbarer Wert gültig oder ungültig ist. Indem der dritte Statuswert 135 ab- hängig von dem zweiten Statuswert 125 bestimmt wird, kann der dritte Statuswert 135 derart bestimmt werden, das der dritte Statuswert 135 anzeigt, dass ein von der dritten Komponente 130 bereitstellbarer Wert ungültig ist, wenn der zweite Statuswert 125 anzeigt, das ein von der zweiten Komponente 120 bereitstellbarer Wert ungültig ist.
Gemäß dem in Fig. 1 gezeigten Ausführungsbeispiel weist das System 100 eine weitere zweite Komponente 140 und eine weitere dritte Komponente 150 auf, die parallel zu der ersten und zweiten Komponente 120, 130 angeordnet sind. Der erste Statuswert 115 wird zusätzlich an die weitere zweite Komponente 140 bereitgestellt.
Ein Fehlerzustand der zweiten weiteren Komponente 140 des Systems 100 kann mittels einer Mehrzahl von Überwachungsalgorithmen 141, 142, 143 bestimmt werden. Abhängig von dem Fehlerzustand der zweiten weiteren Komponente 140 und abhängig von dem ersten Statuswert 115, der von der ersten Komponente bereitgestellt wird, kann ein zweiter weiterer Statuswert 145 bestimmt und bereitgestellt werden. Der zwei- te weitere Statuswert 145 kann anzeigen, ob ein von der zweiten weiteren Komponente 140 bereitstellbarer Wert gültig oder ungültig ist. Indem der zweite weitere Statuswert 145 abhängig von dem ersten Statuswert 115 bestimmt wird, kann der zweite weitere Statuswert 145 derart bestimmt werden, das der zweite weitere Statuswert 145 anzeigt, dass ein von der zweiten weiteren Komponente 140 bereitstellbarer Wert ungül- tig ist, wenn der erste Statuswert 115 anzeigt, das ein von der ersten Komponente 110 bereitstellbarer Wert ungültig ist.
Ein Fehlerzustand einer dritten weiteren Komponente 150 des Systems 100 kann mittels einer Mehrzahl von Überwachungsalgorithmen 151, 152, 153 bestimmt werden. Abhängig von dem Fehlerzustand der dritten weiteren Komponente 150 und abhängig von dem zweiten weiteren Statuswert 145, kann ein dritter weiterer Statuswert 155 bestimmt und bereitgestellt werden. Der dritte weitere Statuswert 155 kann anzeigen, ob ein von der dritten weiteren Komponente 150 bereitstellbarer Wert gültig oder ungültig ist. Indem der dritten weitere Statuswert 155 abhängig von dem zweiten weiteren Statuswert 145 bestimmt wird, kann der dritte weitere Statuswert 155 derart bestimmt werden, das der dritte weitere Statuswert 155 anzeigt, dass ein von der dritten weiteren Komponente 150 bereitstellbarer Wert ungültig ist, wenn der zweite weitere Statuswert 145 anzeigt, das ein von der zweiten weiteren Komponente 140 bereitstellbarer Wert ungültig ist.
Gemäß einem Ausführungsbeispiel wird ein Statuswert, dessen Bestimmung von einem vorangegangenen Statuswert abhängt, erst bestimmt, wenn der vorangegangene Statuswert bestimmt ist. Beispielsweise wird zuerst der erste Statuswert 115 bestimmt. Danach wird abhängig von dem ersten Statuswert 115 und dem Fehlerzustand der zweiten Komponente 120 der zweite Statuswert 125 bestimmt. Anschließend wird abhängig von dem zweiten Statuswert 125 und dem Fehlerzustand der dritten Komponente 130 der dritte Statuswert 135 bestimmt. Das erfindungsgemäße Verfahren zur Fehlerverwaltung kann mehrmals bzw. beliebig oft zeitlich nacheinander ausgeführt werden. Bei jeder Ausführung wird jeder Statuswert 115, 125, 135, 145, 155 nur ein einziges Mal bestimmt, bzw. muss jeder Statuswert nur ein einziges Mal bestimmt werden.
Gemäß einem Ausführungsbeispiel können die Statuswerte 135, 155, in Abhängigkeit von welchen kein weiterer Statuswert bestimmt wird (aber auch alle übrigen Statuswerte), ausgewertet werden, um eine fehlerhafte Komponente des Systems zu erkennen. Dies kann beispielsweise mit einer Auswerteeinrichtung (nicht gezeigt in den Figuren) erfolgen, die ausgebildet ist, um die Statuswerte 135, 155 zu empfangen und auszuwerten. Dabei kann festgestellt werden, ob und wenn ja welcher Statuswert als erster angezeigt hat, dass ein von einer Komponente bereitstellbarer Wert ungültig ist. Ein Teil des Systems 100, der die fehlerhafte Komponente aufweist, kann anschließend degradiert oder deaktiviert werden. Auch kann eine Information über die fehlerhafte Komponente, beispielsweise in einer Speichereinrichtung (nicht gezeigt in den Figuren) gespeichert werden.
Gemäß einem weiteren Ausführungsbeispiel können die Statuswerte ferner anzeigen, ob ein von einer Komponente bereitstellbarer Wert kurzzeitig ungültig oder ob eine Komponente nicht initialisiert ist. Zeigt beispielsweise der zweite Statuswert 125 an, dass ein von der zweiten Komponente 120 bereitstellbarer Wert kurzeitig ungültig ist oder dass die zweite Komponente 120 nicht initialisiert ist, so kann der dritte Statuswert 135 nicht anzeigen, dass ein von der dritten Komponente 130 bereitstellbarer Wert gültig ist, sondern zeigt an, das der von der dritten Komponente 130 bereitstellbare Wert ebenfalls ungültig ist.
Bei dem System 100 kann es sich beispielsweise um ein ESP handeln. Bei den Komponenten 110, 120, 130, 140, 150, kann es sich beispielsweise um Sensoren, Aktoren, Datenübertragungscontroller, Steuergerätekomponenten oder von solchen Komponenten übertragbare Signale handeln. Die Statuswerte können in beliebiger Form, bei- spielsweise in Form von Signalen, bereitgestellt werden, die von den abhängigen Komponenten empfangen werden können.
Der Knoten 110 kann beispielsweise einem Steuergerät ECU, der Knoten 120 einem A/D Wandler, der Knoten 130 einem Radgeschwindigkeitssensor VL, der Knoten 140 einem CAN und der Knoten 150 einem Gierratesensor zugeordnet sein. Dem Knoten 110 ist unter anderem eine Überwachung eines Totalausfalls 111, eine Überwachung des ROM 112 und eine Überwachung des RAM 113 zugeordnet. Dem Knoten 120 kann, unter anderem, eine Überwachung eines Totalausfalls 121 und eine Überwachung einer Einstreuung 122 zugeordnet sein. Dem Knoten 130 kann, unter anderem, eine Überwachung eines Totalausfalls 131, eine Überwachung eines Gradienten 132 und eine Überwachung eines Wertebereichs 133 zugeordnet sein. Dem Knoten 140 kann, unter anderem, eine Überwachung eines Totalausfalls 141, eine Überwachung einer Botschaft „1" 142 und eine Überwachung einer Botschaft „2" 143 zugeordnet sein. Dem Knoten 150 kann, unter anderem, eine Überwachung eines Totalausfalls 151, eine Überwachung eines Gradienten 152 und eine Überwachung eines Wertebereichs 153 zugeordnet sein.
Im Folgenden wird, anhand der in Fig. 1 gezeigten Prinzipdarstellung des Abhängigkeitsgraphen beschrieben, wie sich gemäß dem erfindungsgemäßen Ansatz die Auf- gaben einer Ermittlung der resultierenden Hardware- und Signalstati, einer Folgefehlervermeidung sowie einer Vorbereitung einer Mehrfachfehlerbehandlung realisieren lassen. Zuerst wird die Ermittlung der resultierenden Hardware- und Signalstati betrachtet. Bei der Ermittlung eines resultierenden Knotenstatus gibt es zwei Einflussfaktoren. Zum einen die Ergebnisse der Knoten-eigenen Überwachungen, zum anderen die Stati der Vorgängerknoten. Erkennt ein Überwachungsalgorithmus einen Fehler, so wird der zugehörige Knoten als ungültig markiert. Im gleichen Zuge werden alle sog. Kinder dieses Knoten, also alle Knoten, die durch Verfolgen der Verbindungen von diesem Knoten aus erreichbar sind, ebenfalls ungültig. Diese Vererbung des erkannten Fehlers an die sog. Kindsknoten wird als Fehlerpropagierung bezeichnet. Diese ist notwendig, da keines der Signale, die von der ausgefallenen Hardwarekomponente geliefert wer- den, mehr verwendet werden darf.
Beispielsweise ist eine Anbindung des Gierratensensors, dem der Knoten 150 zugeordnet ist, in einem bestimmten Projekt mittels des CAN- Protokolls, dem der Knoten 140 zugeordnet ist, realisiert. Wird der Ausfall des CAN-Controllers von der knotenei- genen Überwachung Totalausfall 141 erkannt, wird der Knoten 140, der dem CAN zugeordnet ist, als ungültig markiert. Weil der korrekte Empfang von Signalen des CAN- Busses nicht mehr gewährleistet ist, wird automatisch auch der Knoten 150, der der Gierrate zugeordnet ist, als ungültig markiert. Es erfolgt also eine Fehlerpropagierung.
Nun wird die Folgefehlervermeidung betrachtet. Wenn ein Fehler in einer überwachten Komponente erkannt wurde, erfolgt ein Eintrag in einen Fehlerspeicher (nicht gezeigt in den Figuren), um das Fehlerereignis rekonstruieren zu können. Dieser Fehlerspeicher kann beispielsweise zu einem späteren Zeitpunkt von einem Servicepersonal in einer Werkstatt analysiert werden. Um eine zielsichere und reibungslose Lokalisierung des defekten Bauteils zu ermöglichen - dies fällt unter das Stichwort „kleinste tauschbare Einheit" - darf der Fehlerspeicher nach Möglichkeit nur kausale Fehler und keine Folgefehler enthalten. Ein kausaler Fehler ist derjenige Fehler, der den eigentlichen Grund für einen Ausfall liefert. Ein Folgefehler ist ein Fehler, der auf Grund eines anderen Fehlers erkannt wird.
Zur Verdeutlichung lässt sich sagen, dass zur Ermittlung gültiger Signale Fehler propagiert werden müssen, wie oben in Bezug auf die Ermittlung der resultierenden Hardware- und Signalstati beschrieben ist. Bei der Befüllung des Fehlerspeichers müssen Fehler jedoch herausgefiltert werden.
Für die folgenden Beispiele wird angenommen, dass ein abhängiges Signal, beispiels- weise der Gierrate (bei 150), Fehler liefert, wenn das vorausgesetzte Signal, bzw. die vorausgesetzte Komponente, beispielsweise der CAN (bei 140) defekt ist.
Bezug nehmend auf Fig. 1 zeigt das folgende Szenario ein einfaches Beispiel für einen Folgefehler innerhalb des Knotens 130. Eine Verbindung zu einem Radgeschwindig- keitssensor eines Fahrzeugs wird unterbrochen. Beispielsweise erfolgt ein Abriss eines Kabels, der durch die knoteneigene Überwachung Totalausfall 131 erkannt wird. Dadurch fällt die gemessene Radgeschwindigkeit innerhalb von 10ms von 50 m/s abrupt auf 0 m/s ab. Der sich daraus ergebende Gradient des Signals von -5.000 m/s2 wird als unplausibel erkannt (Gradientenüberwachung 132). Der eigentliche Grund für den viel zu hohen Gradienten ist aber der Leitungsabriss.
Es kann jedoch auch zu Folgefehlern an verschiedenen Knoten kommen, die voneinander abhängig sind. Bezug nehmend auf Fig. 1 zeigt folgendes Szenario ein Beispiel für einen Folgefehler an unterschiedlichen Knoten. Beispielsweise erfolgt eine Ein- Streuung des A/D-Wandlers (120), was durch die Überwachung der Einstreuung (bei 122) erkannt wird. Weiterhin wird von der Überwachung des Radgeschwindigkeitssensors (bei 130) ein ungültiger Wert erkannt (bei 133), da durch die Einstreuung der gültige Wertebereich verlassen wird. Das überschreiten des zulässigen Wertebereichs 133 ist somit Folgefehler der Einstreuung am A/D-Wandler 122.
Folgefehler können aber auch vor dem kausalen Fehler auftreten. Beispielsweise fällt der CAN-Controller aus, wodurch das Gierratensignal, welches mittels des CAN übertragen wird, sehr schnell auf den Wert 0 abfällt. Die benötigte Zeit, um den Ausfall des CAN-Controllers zu erkennen, ist deutlich größer als die Zeit zur Erkennung des Gra- dientenfehlers. Dadurch ist es möglich, dass der Folgefehler „fehlerhafter Gradient der Gierrate", der durch die entsprechende Überwachung 152 am Knoten Gierrate 150 erkannt wird, zeitlich vor dem kausalen Fehler „Ausfall des CAN-Controllers" erfolgt, der durch die entsprechende Überwachung 141 am Knoten CAN 140 erkannt wird. Fig. 2 zeigt einen Abhängigkeitsgraphen, der ein weiteres Ausführungsbeispiel der vorliegenden Erfindung beschreibt. Gemäß diesem Ausführungsbeispiel ist das bereits anhand der Fig. 1 beschriebene System 100 um eine virtuelle Komponente 260 erweitert. Bei der virtuellen Komponente 260 handelt es sich nicht um eine reale Komponen- te sondern um eine virtuelle Komponente, die in den Abhängigkeitsgraphen aufgenommen wird, um die Fehlererkennung in dem System 100 zu verbessern.
Ein Fehlerzustand der virtuellen Komponente 260 kann mittels eines Überwachungsalgorithmus 261 bestimmt werden. Der Überwachungsalgorithmus kann Statuswerte einer vorbestimmten Auswahl der Komponenten 110, 120, 130, 140, 150 des Systems 100 gemäß einer Verknüpfungsvorschrift verknüpfen, um den Fehlerzustand der virtuellen Komponente 260 zu bestimmen. Beispielsweise könnte der Überwachungsalgorithmus 261 den Statuswert 135 der dritten Komponente 130 mit dem weiteren zweiten Statuswert 145 der weiteren zweiten Komponente 140 verknüpfen. Bei der Verknüp- fungsvorschrift kann es sich um eine UND-Verknüpfung handeln. Ein virtueller Statuswert 265 wird abhängig von dem Fehlerzustand der virtuellen Komponente und, gemäß dem in Fig. 2 gezeigten Ausführungsbeispiel, abhängig von dem ersten Statuswert 115 bestimmt.
Der virtuellen Komponente 260 ist ein Knoten 260 des Abhängigkeitsgraphen zugeordnet. Dem Knoten 260 kann beispielsweise eine virtuelle Hardwarekomponente „3 Radgeschwindigkeiten" bzw. „3 Raddrehzahlsensoren" zugeordnet sein. In diesem Fall kann der Knoten 260 eine Überwachung 261 in Form einer Anzahl defekter Radgeschwindigkeiten aufweisen.
Nun wird die Vorbereitung einer Mehrfachfehlerbehandlung betrachtet. Wie bereits erwähnt, werden Hardwarekomponenten während des laufenden Betriebs überwacht und es werden im Falle eines erkannten Fehlers deren Stati entsprechend gesetzt. Diese Stati können von nachgelagerten Funktionalitäten genutzt werden, um Teile des Systems, beispielsweise des ESP, die diese Hardwarekomponenten verwenden, zu degradieren oder zu deaktivieren. Unter Degradation wird das Umschalten zwischen verschiedenen Algorithmen innerhalb einer Funktionalität von hoher zu niedriger Qualität, beispielsweise das Umschalten von der Nutzung von Messgrößen auf die Nutzung von Schätzgrößen, verstanden. Durch diese so genannte Fehlerbehandlung wird eine Fehlfunktion des Gesamtsystems auf Grund der fehlerhaften Hardwarekomponente vermieden.
Für den Fall, dass mehrere Fehler nacheinander oder gleichzeitig auftreten, muss eine so genannte einfache Mehrfachfehlerbehandlung durchgeführt werden. Dabei werden im Normalfall die einzelnen Ziel-Systemzustände verglichen und derjenige, in welchem keine der ausgefallenen Hardwarekomponenten verwendet wird, wird als neuer Ziel- Systemzustand ausgewählt. Als Grundlage dafür werden die Stati der einzelnen Hardwarekomponenten ermittelt.
Bei einigen Fehlerkombinationen ist die Verfügbarkeit der Hardwarekomponenten derart eingeschränkt, dass statt der eben beschriebenen einfachen eine erweiterte Mehrfachfehlerbehandlung durchgeführt werden muss. Dabei werden auch Teilsysteme deaktiviert, die nach der einfachen Mehrfachfehlerbehandlung noch mit Schätzgrößen arbeiten könnten.
Um die Weiterverarbeitung der erkannten Fehler zu vereinfachen, sollen Einfachfehler und Mehrfachfehler dieselbe Schnittstelle nutzen. Um diese Anforderung zu erfüllen, können so genannte virtuelle Hardwarekomponenten gebildet werden. Signalstati der virtuellen Hardwarekomponenten werden durch eine logische „und"-Verknüpfung einzelner Stati anderer Hardwarekomponenten gebildet.
Stellt das System 100 beispielsweise ein ESP dar und fällt beispielsweise im ESP der Gierratensensor aus, der dem Knoten 150 zugeordnet ist, so wird der Status des Gier- ratensensors auf „ungültig" gesetzt, wie es oben in Verbindung mit der Ermittlung der resultierenden Hardware- und Signalstati beschrieben ist. Fällt zusätzlich der Drehzahlsensor an einem der Räder aus, so wird dessen Status ebenfalls auf „ungültig" gesetzt. Wenn, wie in dem in Fig. 1 gezeigten Ausführungsbeispiel keine virtuelle Hardwarekomponente für diese Fehlerkombination existiert, wird ein Ziel- Systemzustand nur auf Basis der beiden Einzelstati ermittelt.
Fällt im ESP der Drehzahlsensor an einem der Räder aus, so wird sein Status auf „ungültig" gesetzt. Fallen zusätzlich noch die Drehzahlsensoren an zwei weiteren Rädern aus, so stehen dem ESP nicht mehr genug Informationen zur Verfügung, um sicher zu arbeiten. Daher wird der Signalstatus der virtuellen Hardwarekomponente 260 „3 Raddrehzahlsensoren" auf „ungültig" gesetzt. Diese Information wird von nachgelagerten Funktionalitäten genutzt, um das ESP zu deaktivieren, obwohl die Fahrzeuggeschwindigkeit theoretisch noch, in einer schlechteren Güte, berechnet werden könnte.
Die anhand der Figuren beschriebenen Ausführungsbeispiele sind beispielhaft gewählt. Abhängig von einem zu realisierendem System können Komponenten, weitere Komponenten und virtuelle Komponenten in beliebiger Anzahl und, im Rahmen eines gerichteten Abhängigkeitsgraphen, in beliebiger Verknüpfung untereinander angeordnet werden.
Die vorliegende Erfindung kann in Form von Software umgesetzt werden. Das erfindungsgemäße Verfahren bietet ein neues Konzept zur Konfiguration von Hardwareabhängigkeiten von dynamischen Systemen. Das erfindungsgemäße Konzept einer FaMu- re Dependency Structure, ist zur zentralen Fehlerverwaltung in dynamischen Systemen geeignet. Der erfindungsgemäße Ansatz ist keineswegs auf die beschriebene Fahrdynamikregelung ESP beschränkt. Vielmehr ist der Einsatz in allen mechatronischen eingebetteten Systemen denkbar. Die beschriebenen Beispiele aus dem Einsatzbereich des ESP dienen lediglich der Erläuterung, beschränken aber in keiner Weise das Einsatzgebiet der Erfindung.

Claims

Ansprüche
1. Verfahren zur Fehlerverwaltung in einem System (100) mit einer Mehrzahl von Komponenten, wobei Fehlerzustände der Komponenten mittels Statuswerten anzeigbar sind,
d a d u r c h g e k e n n z e i c h n e t, d a s s
ein erster Statuswert (115) abhängig von einem Fehlerzustand einer ersten Komponente (110) und ein zweiter Statuswert (125) abhängig von einem Fehlerzu- stand einer zweiten Komponente (120) und abhängig von dem ersten Statuswert
(115) bestimmt wird.
2. Verfahren gemäß Anspruch 1, wobei die Statuswerte anzeigen, ob ein von einer Komponente bereitstellbarer Wert gültig oder ungültig ist und der zweite Status- wert (125) derart bestimmt wird, dass der zweite Statuswert anzeigt, dass ein von der zweiten Komponente (120) bereitstellbarer Wert ungültig ist, wenn der erste Statuswert (115) anzeigt, das ein von der ersten Komponente (110) bereitstellbarer Wert ungültig ist.
3. Verfahren gemäß einem der vorstehenden Ansprüche, wobei das System (100) eine weitere Komponente (140) aufweist, dadurch gekennzeichnet, dass ein weiterer Statuswert (145) abhängig von einem Fehlerzustand der weiteren Komponente und abhängig von dem ersten Statuswert (115) bestimmt wird.
4. Verfahren gemäß einem der vorstehenden Ansprüche, wobei das System (100) eine virtuelle Komponente (260) aufweist und ein Fehlerzustand der virtuellen Komponente aus Statuswerten einer vorbestimmten Auswahl der Komponenten (110, 120, 140) gemäß einer Verknüpfungsvorschrift bestimmt wird, und ein virtu- eller Statuswert (265) abhängig von dem Fehlerzustand der virtuellen Komponente und abhängig von dem ersten Statuswert (115) bestimmt wird.
5. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass ausgehend von dem ersten Statuswert (115) jeder Statuswert (125, 145,
265), dessen Bestimmung von einem vorangegangenen Statuswert abhängt, nur ein einziges Mal bestimmt wird.
6. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass ein Statuswert (135, 155, 265), in Abhängigkeit von dem kein weiterer Statuswert bestimmt wird, ausgewertet wird, um festzustellen, welcher Statuswert, ausgehend von dem ersten Statuswert (115), als erstes angezeigt hat, dass ein von einer Komponente bereitstellbarer Wert ungültig ist, um so eine fehlerhafte Komponente zu bestimmen.
7. Verfahren gemäß Anspruch 6, dadurch gekennzeichnet, dass ein Teil des Systems (100), der die fehlerhafte Komponente aufweist, degradiert oder deaktiviert wird.
8. Verfahren gemäß Anspruch 6, dadurch gekennzeichnet, dass eine Information über die fehlerhafte Komponente gespeichert wird.
9. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Fehlerzustände der Komponenten (110, 120, 140, 260) ermittelt werden, indem Überwachungsalgorithmen (111, 112, 113, 121, 122, 141, 142, 143, 261) ausgeführt werden.
10. Verfahren gemäß einem der Ansprüche 4 bis 9, dadurch gekennzeichnet, dass die Verknüpfungsvorschrift zur Bestimmung des Fehlerzustands der virtuellen Komponente (260) eine UND-Verknüpfung ist.
11. Verfahren gemäß einem der Ansprüche 2 bis 10, wobei die Statuswerte ferner anzeigen, ob ein von einer Komponente bereitstellbarer Wert kurzzeitig ungültig oder ob eine Komponente nicht initialisiert ist, wobei der zweite Statuswert (125) so bestimmt wird, dass der zweite Statuswert anzeigt, dass ein von der zweiten Komponente (120) bereitstellbarer Wert ungültig ist, wenn der erste Statuswert (115) anzeigt, das der von der ersten Komponente (110) bereitstellbare Wert kurzzeitig ungültig oder die erste Komponente nicht initialisiert ist.
12. Vorrichtung um alle Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 11 durchzuführen.
13. Vorrichtung gemäß Anspruch 12, dadurch gekennzeichnet, dass es sich bei den Komponenten um Sensoren, Aktoren, Datenübertragungscontroller, Steuergerätekomponenten oder von solchen Komponenten übertragbare Signale handelt.
14. Vorrichtung gemäß Anspruch 12, dadurch gekennzeichnet, dass es sich bei dem System um ein mechatronisch eingebettetes System handelt.
15. Computerprogramm mit Programmcode- Mitteln, um alle Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 11 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Rechnereinheit ausgeführt wird.
16. Computerprogrammprodukt mit Programmcode- Mitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens nach einem der Ansprüche 1 bis 11 durchzuführen, wenn das Computerprogrammprodukt auf einem Computer oder auf einer entsprechenden Rechnereinheit ausge- führt wird.
EP07820411A 2006-09-29 2007-09-20 Verfahren und vorrichtung zur fehlerverwaltung Withdrawn EP2078253A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006046399A DE102006046399A1 (de) 2006-09-29 2006-09-29 Verfahren und Vorrichtung zur Fehlerverwaltung
PCT/EP2007/059973 WO2008040641A2 (de) 2006-09-29 2007-09-20 Verfahren und vorrichtung zur fehlerverwaltung

Publications (1)

Publication Number Publication Date
EP2078253A2 true EP2078253A2 (de) 2009-07-15

Family

ID=39134362

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07820411A Withdrawn EP2078253A2 (de) 2006-09-29 2007-09-20 Verfahren und vorrichtung zur fehlerverwaltung

Country Status (6)

Country Link
US (1) US20100218047A1 (de)
EP (1) EP2078253A2 (de)
JP (1) JP5319534B2 (de)
CN (1) CN101535960B (de)
DE (1) DE102006046399A1 (de)
WO (1) WO2008040641A2 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009020151A1 (de) * 2009-05-06 2010-11-11 Siemens Aktiengesellschaft Verfahren zur Ermittlung und Bewertung von Kenngrößen einer elektrischen Energieversorgung
DE102009027375A1 (de) * 2009-07-01 2011-03-10 Robert Bosch Gmbh Diagnoseverfahren zum Durchführen einer Diagnose eines Systems
CN102404141B (zh) * 2011-11-04 2014-03-12 华为技术有限公司 一种告警抑制的方法及装置
US9021305B2 (en) 2012-10-17 2015-04-28 International Business Machines Corporation Processing main cause errors and sympathetic errors in devices in a system
CN104102551B (zh) * 2013-04-10 2017-06-06 北京中嘉时代科技有限公司 一种基于状态的应用监控与恢复算法与模型
FR3012098B1 (fr) * 2013-10-17 2017-01-13 Renault Sa Systeme et procede de controle de vehicule avec gestion de defauts
CN103674590B (zh) * 2013-11-09 2016-04-20 皖江新兴产业技术发展中心 半导体芯片全自动封装设备自动报警系统实现方法
US10089687B2 (en) * 2015-08-04 2018-10-02 Fidelity National Information Services, Inc. System and associated methodology of creating order lifecycles via daisy chain linkage
CN106559234B (zh) * 2015-09-28 2021-02-19 中兴通讯股份有限公司 控制消息发送方法及装置
US11568362B2 (en) * 2019-01-02 2023-01-31 International Business Machines Corporation Systems and methods for visualizing a trade life cycle and detecting discrepancies
US20200211110A1 (en) * 2019-01-02 2020-07-02 International Business Machines Corporation Systems and methods for visualizing a trade life cycle and detecting discrepancies
DE102022105248A1 (de) 2022-03-07 2023-09-07 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum bestimmen von obd-konformität eines ausgabesignals

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4053752A (en) * 1975-09-15 1977-10-11 International Business Machines Corporation Error recovery and control in a mass storage system
DE3526671A1 (de) * 1985-07-25 1987-01-29 Man Technologie Gmbh Antriebsstrang fuer kraftfahrzeuge
DE3730110A1 (de) * 1987-09-08 1989-03-16 Siemens Ag Druckeinrichtung mit einem elektrothermisch betriebenen druckkopf
JPH05257676A (ja) * 1992-03-11 1993-10-08 Hitachi Ltd ステータス管理方法
GB2268292A (en) * 1992-06-16 1994-01-05 Ibm Error handling in a state-free system
US5335979A (en) * 1992-10-09 1994-08-09 Mitsubishi Denki Kabushiki Kaisha Control device for vehicle including anti-skid braking system and power steering control system
US5581690A (en) * 1993-06-29 1996-12-03 Digital Equipment Corporation Method and apparatus for preventing the use of corrupt data in a multiple disk raid organized storage system
SE510029C2 (sv) * 1995-10-03 1999-04-12 Volvo Ab Diagnossystem i ett driftsystem för motorer jämte en diagnosfunktionsmodul (DF-modul) i ett driftsystem för motorer
US5948107A (en) * 1997-05-28 1999-09-07 Intel Corporation Method of handling errors in complex inheritance hierarchies
DE19731116A1 (de) * 1997-07-19 1999-01-28 Bosch Gmbh Robert Steuergerät für ein System und Verfahren zum Betrieb eines Steuergerätes
JP2000295238A (ja) * 1999-04-06 2000-10-20 Canon Inc ワイヤレス通信装置、その通信制御方法および記憶媒体
JP2001209561A (ja) * 2000-01-27 2001-08-03 Mitsubishi Electric Corp 異常処理方式及び異常処理方法
ATE454605T1 (de) * 2000-02-03 2010-01-15 Honeywell Int Inc Vorrichtung und verfahren für ein höhenmesssystem
US6808041B2 (en) * 2000-02-11 2004-10-26 Delphi Technologies, Inc. Method and system for providing secondary vehicle directional control through braking
US6654909B1 (en) * 2000-06-30 2003-11-25 Intel Corporation Apparatus and method for protecting critical resources against soft errors in high performance microprocessors
IT1320553B1 (it) * 2000-07-25 2003-12-10 Magneti Marelli Spa Dispositivo di controllo di una frizione di un veicolo.
JP2002135410A (ja) * 2000-10-26 2002-05-10 Kddi Research & Development Laboratories Inc アクセスネットワークシステム
EP1206120A1 (de) * 2000-11-10 2002-05-15 GRETAG IMAGING Trading AG Verminderung von Artefakten bei reproduzierten Bildern
DE10059758A1 (de) * 2000-11-30 2002-06-20 Bosch Gmbh Robert Verfahren zum Empfangen von Daten
ATE321723T1 (de) * 2001-09-03 2006-04-15 Inventio Ag Situationsabhängige reaktion im falle einer störung im bereich einer türe eines aufzugsystems
US7120901B2 (en) * 2001-10-26 2006-10-10 International Business Machines Corporation Method and system for tracing and displaying execution of nested functions
US7159217B2 (en) * 2001-12-20 2007-01-02 Cadence Design Systems, Inc. Mechanism for managing parallel execution of processes in a distributed computing environment
US6882918B2 (en) * 2001-12-27 2005-04-19 Caterpillar Inc Electric drive management system and method
EP1367488B1 (de) * 2002-05-31 2006-04-26 Sap Ag Verfahren und Rechneranordnung für vernetzte Aufgabenverwaltung
JP4143366B2 (ja) * 2002-08-29 2008-09-03 東芝三菱電機産業システム株式会社 プラント制御システム
DE10302054B4 (de) * 2003-01-21 2018-10-25 Robert Bosch Gmbh Verfahren zum Betreiben einer Brennkraftmaschine
US7245995B2 (en) * 2003-02-19 2007-07-17 Robert Bosch Gmbh Fault-tolerant vehicle stability control
DE10309815A1 (de) * 2003-03-05 2004-09-23 Francotyp-Postalia Ag & Co. Kg Verfahren zum Datenaustausch zwischen Datenverarbeitungseinheiten
US7117119B2 (en) * 2003-08-01 2006-10-03 Invensys Systems, Inc System and method for continuous online safety and reliability monitoring
US7933794B2 (en) * 2003-10-30 2011-04-26 International Business Machines Corporation Method and system for active monitoring of dependency models
US7584382B2 (en) * 2004-02-19 2009-09-01 Microsoft Corporation Method and system for troubleshooting a misconfiguration of a computer system based on configurations of other computer systems
US8311697B2 (en) * 2004-07-27 2012-11-13 Honeywell International Inc. Impact assessment system and method for determining emergent criticality
CN1266628C (zh) * 2004-08-11 2006-07-26 北京四方继保自动化股份有限公司 电力自动化系统中关键应用模块的多备一的实现方法
DE102005009707A1 (de) * 2005-03-03 2006-09-07 Dr. Johannes Heidenhain Gmbh Modulares numerisches Steuergerät
US20060290200A1 (en) * 2005-06-24 2006-12-28 Davison Kent E Wheel-end mounted multipurpose acceleration sensing device
US8600605B2 (en) * 2006-01-30 2013-12-03 GM Global Technology Operations LLC Distributed diagnostics architecture

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ATHANASOPOULOU E ET AL: "Decentralized Failure Diagnosis in Discrete Event Systems", AMERICAN CONTROL CONFERENCE, 2006 MINNEAPOLIS, MN, USA JUNE 14-16, 2006, PISCATAWAY, NJ, USA,IEEE, 14 June 2006 (2006-06-14), pages 5698 - 5703, XP010929949, ISBN: 978-1-4244-0209-0, DOI: 10.1109/ACC.2006.1657633 *
See also references of WO2008040641A2 *

Also Published As

Publication number Publication date
DE102006046399A1 (de) 2008-04-03
JP5319534B2 (ja) 2013-10-16
WO2008040641A2 (de) 2008-04-10
CN101535960A (zh) 2009-09-16
JP2010505165A (ja) 2010-02-18
CN101535960B (zh) 2014-12-03
WO2008040641A3 (de) 2008-08-28
US20100218047A1 (en) 2010-08-26

Similar Documents

Publication Publication Date Title
EP2078253A2 (de) Verfahren und vorrichtung zur fehlerverwaltung
EP1600831B1 (de) Verfahren und Vorrichtung zur Überwachung mehrerer Steuergeräte mittels einer Frage-Antwort-Kommunikation
EP2534011B1 (de) Fahrzeug-sensor-knoten
DE19933086B4 (de) Verfahren und Vorrichtung zur gegenseitigen Überwachung von Steuereinheiten
EP0512240B1 (de) System zur Steuerung eines Kraftfahrzeuges
EP1597643B1 (de) Vorrichtung und verfahren zur modellbasierten on-board-diagnose
WO1993009020A1 (de) Verfahren und vorrichtung zur fehlerbehandlung in elektronischen steuergeräten
EP2099667B2 (de) Verfahren zum sicherstellen oder aufrechterhalten der funktion eines komplexen sicherheitskritischen gesamtsystems
EP3661819B1 (de) Kontrollsystem für ein kraftfahrzeug, kraftfahrzeug, verfahren zur kontrolle eines kraftfahrzeugs, computerprogrammprodukt und computerlesbares medium
DE10223880A1 (de) Verfahren zur gegenseitigen Überwachung von Komponenten eines dezentral verteilten Rechnersystems
DE19500188B4 (de) Schaltungsanordnung für eine Bremsanlage
DE102006017302B4 (de) Verfahren und System zur Kontrolle einer Signalübertragung eines elektrischen Pedals
EP0886823B1 (de) Verfahren zur überprüfung der funktionsfähigkeit einer recheneinheit
DE102008009652A1 (de) Überwachungseinrichtung und Überwachungsverfahren für einen Sensor, sowie Sensor
EP3745217B1 (de) Vorrichtung zum überwachen einer datenverarbeitung und - übertragung in einem sicherheitssystems
EP3470939B1 (de) Verfahren und system zum überwachen der sicherheitsintegrität einer durch ein sicherheitssystem bereitgestellten sicherheitsfunktion
EP3470937B1 (de) Verfahren und vorrichtungen zum überwachen der reaktionszeit einer durch ein sicherheitssystem bereitgestellten sicherheitsfunktion
DE102008004206A1 (de) Anordnung und Verfahren zur Fehlererkennung und -behandlung in einem Steuergerät in einem Kraftfahrzeug
EP1733284B1 (de) Ablaufsteuerung von funktionen auf miteinander wechselwirkenden geräten
DE102012212680A1 (de) Verfahren und System zur fehlertoleranten Steuerung von Stellgliedern für eine begrenzte Zeit auf der Grundlage von vorberechneten Werten
EP1649373A2 (de) Verfahren und vorrichtung zur berwachung eines verteilten s ystems
DE102007046706A1 (de) Steuervorrichtung für Fahrzeuge
WO2007023106A2 (de) Verfahren zur systemdiagnose in technischen systemen
DE102019203783B4 (de) Verfahren, Programm und System zur Verwendung von Signalqualitätsanforderungen im Rahmen von Sicherheitskonzepten
DE102006020793A1 (de) Schaltungsanordnung und Verfahren zum Betrieb einer Schaltungsanordnung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090429

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20090827

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180404