WO2008040645A1 - Verfahren und vorrichtung zur bestimmung eines zielzustands - Google Patents

Verfahren und vorrichtung zur bestimmung eines zielzustands Download PDF

Info

Publication number
WO2008040645A1
WO2008040645A1 PCT/EP2007/059985 EP2007059985W WO2008040645A1 WO 2008040645 A1 WO2008040645 A1 WO 2008040645A1 EP 2007059985 W EP2007059985 W EP 2007059985W WO 2008040645 A1 WO2008040645 A1 WO 2008040645A1
Authority
WO
WIPO (PCT)
Prior art keywords
state
components
system state
highest priority
determining
Prior art date
Application number
PCT/EP2007/059985
Other languages
English (en)
French (fr)
Inventor
Philipp Woerz
Mathias Bieringer
Alexander Schaefer
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 US12/308,202 priority Critical patent/US20100037229A1/en
Priority to JP2009530837A priority patent/JP2010506278A/ja
Priority to EP07820420A priority patent/EP2079624A1/de
Publication of WO2008040645A1 publication Critical patent/WO2008040645A1/de

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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
    • B60W30/00—Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units
    • B60W30/02—Control of vehicle driving stability
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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/00—Details 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/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/029—Adapting to failures or work around with other constraints, e.g. circumvention by avoiding use of failed parts
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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/00—Details 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
    • B60W2050/0001—Details of the control system
    • B60W2050/0002—Automatic control, details of type of controller or control system architecture
    • B60W2050/0016—State machine analysis
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT 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/00—Details 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
    • B60W2050/0062—Adapting control system settings
    • B60W2050/0075—Automatic parameter input, automatic initialising or calibrating means
    • B60W2050/009—Priority selection

Definitions

  • the invention relates to a method for determining a target state according to the preamble of claim 1, a corresponding device according to the preamble of claim 12, a computer program and a computer program product.
  • DE 102 23 368 A1 describes a method with which system states of a control unit can be determined from read environmental conditions.
  • ESP Electronic Stability Programs
  • 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.
  • the ECU components include, for example, ROM, RAM, EEPROM or A / D converter. All mentioned hardware components and the signals transmitted or supplied by the hardware components are monitored during their operation to detect any failures.
  • 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.
  • system states which can be taken in the event of a fault.
  • a system state is the combination of the states of all components present in the system. The components are, for example, regulators, model calculations, monitoring or signal conditioning.
  • the driver e.g. With the so-called passive push-button “Pata” or “ESP-off", you can selectively deactivate individual parts of the ESP functional scope.
  • This driver request can generally be called a "trigger.”
  • the trigger is treated with separate algorithms as opposed to errors.
  • a manufacturer of the system or a manufacturer of a higher-level system can make further specifications.
  • the car manufacturer can program the ESP control unit in such a way that certain functions are deactivated because the end customer has not separately ordered and paid for them. Also these wishes of the manufacturer can be classified in the category "Trigger".
  • Trigger the destination status is determined distributed in the ESP. This distribution of tasks and responsibilities makes the product configuration of the ESP and the processing of customer projects difficult.
  • the use of tools for the automated generation of documentation in the three areas mentioned is not possible.
  • the present invention provides a method for determining a target state in a multi-component system, wherein system states of different priorities are selectable in the system, depending on availability of the components. According to the method of the invention, it is determined whether a system state of highest priority can be selected. If the highest priority system state is selectable, the system state of highest priority is determined as the destination state. If the highest priority system state is not selectable, then a determination is made as to whether a system state of next highest priority is selectable and determining the system state of next highest priority as the destination state if the system state of next highest priority is selectable.
  • the present invention further provides an apparatus for determining a target condition in a multi-component system that performs all steps of the method of the invention. - A -
  • 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.
  • An essential aspect of the invention is a so-called release manager, also called system release manager, in which all available system levels are defined. In addition, for each system level, those signals are listed that are required for the operation of the respective level.
  • Influencing factors include, for example, errors and specifications. Errors include, for example, errors in the system's own sensors or actuators as well as errors in sensors or actuators of third-party systems. Specifications include, for example, specifications made by the driver or the manufacturer. Defaults or triggers made by the driver naturally occur during operation of the system. Specifications made by the manufacturer may occur during production or during repair in garages. These too represent triggers to perform a system configuration. All these requirements must be evaluated in such a way that safe operation with the highest possible system availability is ensured at all times.
  • the invention offers a number of implementation-independent advantages. This includes, for example, that defined system levels can only be assumed in a so-called inhibit handler. Other than the defined system levels are not possible. Furthermore, all system levels and the conditions under which the levels can be taken can be defined centrally. This greatly increases the clarity of the system. Dependencies that are stored in the System Release Manager are strongly project-dependent. The central definition of these dependencies greatly reduces the effort involved in project initiation and during the course of the project.
  • the invention also offers a number of implementation-relevant advantages. For example, very efficient algorithms are used, with which errors and triggers can be further processed. This consumes less of the very limited resources of ROM, RAM and runtime or cycle time in a controller.
  • a lower or lowest priority system state is determined to be the destination state if the next higher priority system state is not selectable.
  • the target state with the best possible priority can easily be selected or set at any time in a simple manner, whereby a gradual check of the system states in the order of their priorities (with decreasing priority) can be carried out.
  • the steps of the determination be made based on a central allocation table, the central allocation table being for each System state defines which of the components must be available for the system state to be selectable.
  • this measure enables a central definition, review, readjustment and retrievability of all possible system states.
  • the steps of determining include a step of analyzing whether the components required according to the central allocation table for the respective system state are available.
  • the different priorities correspond to different availability of the system, whereby advantageously the highest priority system state corresponds to a maximum availability of the system.
  • a selectability of the highest priority system state a first set of available components, and for a next higher priority system state selectability, a second set of available components be required, where the second set may be a subset of the first set. This measure allows an optimal tuning or grading of the respective states to each other.
  • the target state of the system in response to a change in availability of one of the components, is retrieved based on the highest priority system state. This ensures that an optimal system setting is possible at any time.
  • a change in availability of one of the components may be due to a malfunction of the components, an intervention of an operator of the system and / or a specification of a manufacturer of the system.
  • This allows the inventive method an adaptation of the system to the most likely disorders or changes to be considered.
  • FIG. 1 shows a flowchart of a method according to a preferred embodiment of the present invention
  • Fig. 2 is a block diagram of an apparatus according to another preferred embodiment of the present invention.
  • Fig. 3 shows an allocation table according to another preferred embodiment of the present invention.
  • FIG. 1 is a flow chart illustrating a method for determining a target state in a multi-component system according to a preferred embodiment Embodiment of the present invention. Depending on the availability of the components, system states of different priorities can be selected in the system.
  • a system state of highest priority it is determined whether a system state of highest priority can be selected.
  • the highest priority system state is selectable when all the components of the system required to select that system state are available. If the highest priority system state is selectable, i. H. all required components are available, then in a method step 104 the system state of highest priority is determined as destination state. In this case, the method can be terminated without carrying out further method steps.
  • the highest priority system state is not selectable, i. H. If not all required components are available, then it is determined in a method step 112 whether a system state of the next higher priority can be selected.
  • the next highest priority system state is selectable if all the components of the system required to select that system state are available. Typically, fewer or different components are required for the next highest priority system state than for the higher priority system state. For example, the next highest priority system state may require a subset of the components required for the higher priority system state. If the next higher priority system state is selectable, i. H. if all the components required for this system state are available, in a method step 114 the system state of the next higher priority is determined as destination state. In this case, the procedure can be ended.
  • system state of the next highest priority can not be selected, then in further method steps (not shown in the figures) further system states with respectively lower priorities can be checked for their selectability. It is checked in terms of priorities, in descending order, whether a system state is selectable. If a system state can be selected, this system state is selected as the destination state. Otherwise, it is determined whether the system state with the next lower priority can be selected. The procedure is continued until a selectable system state has been determined and determined as the destination state. If no system state of higher priority can be selected, that is to say the system state of the next higher priority can not be selected with reference to FIG. 1, then in a further method step 124 a system state of lowest priority can be determined as the destination state. For example, the lowest priority system state may be determined as a target state whenever insufficient components are available to select a higher priority system state.
  • the method steps 102, 104, 112, 114, 124 can be carried out centrally in the system.
  • a central allocation table (shown in FIG. 3) can be used for this purpose, in which it is defined for each system state which of the components must be available in order for the respective system state to be selectable. Using the central allocation table, it is possible to analyze whether the components required according to the central allocation table for the respective system state are available.
  • the different priorities of the system states may correspond to different availabilities of the system, with the highest priority system state corresponding to the highest availability of the system.
  • a change in the availability of a component can be done, for example, by a malfunction of the component, an intervention of an operator of the system or a specification of a manufacturer of the system.
  • a subsequently required determination of a new target state can be carried out by carrying out the method according to the invention again. Referring to FIG. 1, this means that starting from the first method step 102, a new destination state is determined.
  • FIG. 2 is a block diagram illustrating a device 200 for determining a target state in a multi-component system.
  • FIG. 2 shows a system having a first component 230 whose availability in the system can be displayed by means of a first availability signal 235, a second component 240 whose availability can be displayed by means of a second availability signal 245, and a third component 250 whose availability by means of a second component third availability signal 255 can be displayed shown.
  • the device 200 may be implemented as a unit, not distributed, in the system.
  • the device 200 is configured to receive the availability signals 235, 245, 255.
  • the device 200 may include an allocation table 262.
  • the allocation table 262 all possible system states are defined. Further, in the mapping table 262, for each system state, it is defined which of the components 230, 240, 250 must be available for the particular system state to be selectable. For example, all components 230, 240, 250 may be required to select the highest priority system state.
  • the device 200 is designed to determine, using the allocation table 262 and by evaluating the availability signals 235, 245, 255, which system state defined in the allocation table 262 can be selected. Furthermore, the device 200 is designed to determine the system state as target state, which, on the basis of the available components, can be selected and additionally has the highest priority of all selectable system states.
  • the device 200 has means for displaying the target state in the form of a target state signal 265.
  • the components 230, 240, 250 can be sensors, actuators, data transfer controllers, control unit components or signals that can be transmitted by such components.
  • the system may be a dynamic system such as a mechatronically embedded system.
  • the device 200 or the allocation table 262 can be implemented in the form of a system release manager, which defines all system levels.
  • the System Release Manager determines, at system level, the signals required to operate this level.
  • FIG. 3 shows a table, which may be the allocation table 262 described in FIG.
  • the table has three columns and five rows. The last column is divided into three subcolumns. In the first column, beginning with field 301, the possible system states are defined. In the second column, which begins with field 302, the signals, components and triggers required for the respective system state are defined. These are collectively referred to as "guards".
  • the third column beginning with field 303, defines states of the components of the system that depend on the signals, components, and triggers defined in the second column. Such dependent components may be an ABS system listed in the first subcolumn 304, an ASR system listed in the second subcolumn 305, or an ESP system listed in the third subcolumn 306.
  • the second line beginning with field 307, describes a "system state 3" for which, according to field 308, the components “yaw rate”, “motor interface”, “4 speed sensors” and “! Pata” must be available Field 309, the component ABS in the “on” state, according to field 310, the component ASR in the “on” state and according to field 311, the component ESP in the "on” state.
  • the third line describes a "System State 2" for which the "Motor Interface” and “4 Speed Sensors” components must be available according to Field 313 so that according to Field 314 the ABS component is in the "backup” state, According to field 315, the component ASR is in the state “backup” and according to field 316 the component ESP is in the state "off”.
  • the fourth line beginning with field 317, describes a "System State 1" for which the "4 Speed Sensors” component must be available in accordance with block 318, so that according to block 319, the ABS component is in the "backup” state, according to field 320 Component ASR in the state “off” and according to field 321, the component ESP in the state "off”.
  • the fifth row starting with field 322 describes a "System State 0" for which no component needs to be available according to field 323.
  • the ABS component is in the "off” state, according to box 325 is the component ASR in the "off” state and according to field 326, the ESP component is in the "off” state.
  • system states 307, 312, 317, 322 there are four system states 307, 312, 317, 322 stored according to their respective priorities in the table shown in FIG.
  • the priorities correspond to a system availability.
  • the system states 307, 312, 317, 322 are sorted in descending order in the table.
  • this table is traversed from top to bottom and the required signals 308, 313, 318, 323 analyzed. If all parts of the corresponding guards are available or fulfilled in a strategy, this is the new target strategy and the search is aborted.
  • the guards 302 include signals, for example the yaw rate, as well as triggers, for example Pata, as well as the availability of actuators, for example hydraulic valves. This shows that the Inhibit Handler makes no difference between these Guard elements. This greatly simplifies the inhibit handler because a solution algorithm can be used for all types.
  • the invention can be implemented in software.
  • the method according to the invention is a new concept for the management of system states of dynamic systems. This method involves the determination of the operating state, which is allowed and desired under the given boundary conditions and also has the highest system availability.
  • the inventive approach is not limited to the vehicle dynamics control ESP. Rather, the use in all mechatronic embedded systems is conceivable. Such systems are in addition to the ESP, for example, the products ABS and ASR.
  • the described embodiments from the field of application of the ESP are merely illustrative, but in no way limit the field of application of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Human Computer Interaction (AREA)
  • Stored Programmes (AREA)
  • Feedback Control In General (AREA)
  • Hardware Redundancy (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

Ein Verfahren zur Bestimmung eines Zielzustands in einem System mit mehreren Komponenten, wobei in dem System, abhängig von einer Verfügbarkeit der Komponenten, Systemzustände unterschiedlicher Prioritäten auswählbar sind, umfasst einen Schritt des Ermittelns (102), ob ein Systemzustand höchster Priorität auswählbar ist, einen Schritt des Bestimmens (104) des Systemzustands höchster Priorität als Zielzustand, wenn der Systemzustand höchster Priorität auswählbar ist sowie einen Schritt des Ermittelns (112), ob ein Systemzustand nächst höherer Priorität auswählbar ist, wenn der Systemzustand höchster Priorität nicht auswählbar ist, und Bestimmens (114) des Systemzustands nächst höherer Priorität als Zielzustand, wenn dieser Zustand auswählbar ist.

Description

Beschreibung
Titel
Verfahren und Vorrichtung zur Bestimmung eines Zielzustands
Die Erfindung betrifft ein Verfahren zur Bestimmung eines Zielzustands gemäß dem Oberbegriff des Anspruchs 1, eine entsprechende Vorrichtung gemäß dem Oberbegriff von Anspruch 12, ein Computerprogramm sowie ein Computerprogrammprodukt.
Stand der Technik
Die DE 102 23 368 Al beschreibt ein Verfahren, mit dem sich Systemzustände eines Steuergeräts aus eingelesenen Umgebungsbedingungen ermitteln lassen.
Die DE 103 54 659 Al beschreibt ein Verfahren, gemäß dem jedes einer Mehrzahl von interagierenden Geräten eine Betriebsart vorschlägt und aus allen vorgeschlagenen Betriebsarten eine gemeinsame Betriebsart auswählt wird.
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.
In elektronischen Stabilitätsprogrammen (ESP) 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. AIIe erwähnten Hardwarekomponenten und die Signale, die von den Hardwarekomponenten ü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.
Da es sich beim ESP um ein sicherheitsrelevantes System handelt, ist es erforderlich, dass bei Störungen im Betrieb ein sicherer Zustand mit maximaler Restverfügbarkeit eingestellt wird. Daher enthält das ESP diverse Rückfallebenen, allgemein als Systemzustände bezeichnet, die im Falle einer Störung eingenommen werden können. Als Systemzustand wird die Kombination der Zustände aller im System vorhandenen Komponenten verstanden. Bei den Komponenten handelt es sich beispielsweise um Regler, Modellrechnungen, Überwachungen oder Signalaufbereitungen.
Dabei ist unerheblich, an welcher Stelle im Gesamtsystem Fahrzeug diese Störungen auftreten. Mögliche Fehlerquellen sind ESP-eigene Sensoren und Aktoren, aber auch Signale, die von Fremdsystemen, beispielsweise über CAN zur Verfügung gestellt oder entgegengenommen werden. Welche der Ebenen eingenommen wird, sog. Zielzu- stand, richtet sich nach der Art der Störung.
Ein anderer Faktor, der den Zielzustand beeinflusst, ist ein Bediener des Systems. Im Beispiel des ESP ist dies der Fahrer, der z.B. mit dem sog. Passiv-Taster „Pata" oder „ESP-off", einzelne Teile des ESP-Funktionsumfangs gezielt deaktivieren kann. Dieser Fahrerwunsch kann allgemein als „Trigger" bezeichnet werden. Der Trigger wird im heutigen ESP im Gegensatz zu Fehlern mit separaten Algorithmen behandelt.
Analog dazu kann ein Hersteller des Systems oder ein Hersteller eines übergeordneten Systems weitere Vorgaben treffen. Im Beispiel des ESP kann der Automobilhersteller am Ende einer Fertigung das ESP-Steuergerät derart programmieren, dass gewisse Funktionen deaktiviert werden, weil der Endkunde diese nicht gesondert bestellt und bezahlt hat. Auch diese Wünsche des Herstellers kann man in die Kategorie „Trigger" einordnen. Derzeit wird im ESP der Zielzustand verteilt ermittelt. Diese Verteilung der Aufgaben und Verantwortlichkeiten erschwert eine Produktkonfiguration des ESP und die Bearbeitung von Kundenprojekten stark. Darüber hinaus ist der Einsatz von Tools zur automatisierten Dokumentationsgenerierung in den drei angesprochenen Bereichen nicht möglich.
Technische Aufgabe
Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren sowie eine Vorrichtung zur verbesserten Bestimmung eines Zielzustands in einem System mit mehreren Komponenten sowie ein entsprechendes Computerprogramm und ein Computerprogrammprodukt zu schaffen.
Technische Lösung
Diese Aufgabe wird mit einem Verfahren gemäß Anspruch 1, einer Vorrichtung gemäß Anspruch 12 sowie einem Computerprogramm und einem Computerprogrammprodukt gemäß den Ansprüchen 15 und 16 gelöst.
Die vorliegende Erfindung stellt ein Verfahren zur Bestimmung eines Zielzustands in einem System mit mehreren Komponenten zur Verfügung, wobei in dem System, abhängig von einer Verfügbarkeit der Komponenten, Systemzustände unterschiedlicher Prioritäten auswählbar sind. Gemäß dem erfindungsgemäßen Verfahren wird ermittelt, ob ein Systemzustand höchster Priorität auswählbar ist. Wenn der Systemzustand höchster Priorität auswählbar ist, erfolgt ein Bestimmen des Systemzustands höchster Priorität als Zielzustand. Wenn der Systemzustand höchster Priorität nicht auswählbar ist, erfolgt ein Ermitteln, ob ein Systemzustand nächst höchster Priorität auswählbar ist und ein Bestimmen des Systemzustands nächst höchster Priorität als Zielzustand, wenn der Systemzustand nächst höchster Priorität auswählbar ist.
Die vorliegende Erfindung schafft ferner eine Vorrichtung zur Bestimmung eines Zielzustands in einem System mit mehreren Komponenten, die alle Schritte des erfindungsgemäßen Verfahrens durchführt. - A -
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 erfindungsgemäßen Verfahrens vorgesehen, wenn dieses Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit, insbesondere einer erfindungs- gemäßen Vorrichtung, durchgeführt wird.
Ein wesentlicher Aspekt der Erfindung ist ein sogenannter Freigabemanager, auch System Release Manager genannt, in dem alle verfügbaren Systemebenen definiert sind. Zusätzlich sind für jede Systemebene diejenigen Signale aufgelistet, die für den Betrieb der jeweiligen Ebene benötigt werden.
Vorteilhafte Wirkungen
Der erfindungsgemäße Ansatz ermöglicht es, jederzeit den Systemzustand zu ermit- teln, der im Hinblick auf bestimmte Einflussfaktoren noch eingenommen werden kann. Unter Einflussfaktoren sind beispielsweise Fehler und Vorgaben zu verstehen. Fehler umfassen beispielsweise Fehler in systemeigener Sensorik oder Aktorik als auch Fehler in Sensorik oder Aktorik von Fremd-Systemen. Vorgaben umfassen beispielsweise Vorgaben, die vom Fahrer oder vom Hersteller gemacht werden. Vorgaben bzw. Trig- ger, die vom Fahrer gemacht werden, treten naturgemäß während des laufenden Betriebs des Systems auf. Vorgaben, die vom Hersteller gemacht werden, können während der Produktion oder während der Reparatur in Werkstätten auftreten. Auch diese stellen Trigger dar, um eine System konfigu ratio n durchzuführen. All diese Anforderungen müssen derart ausgewertet werden, dass zu jeder Zeit ein sicherer Betrieb mit höchstmöglicher Systemverfügbarkeit gewährleistet ist.
Die Erfindung bietet eine Reihe implementierungsunabhängiger Vorteile. Darunter fällt z.B., dass ausschließlich in einem sog. Inhibit Handler definierte Systemebenen eingenommen werden können. Andere als die definierten Systemebenen sind nicht möglich. Ferner können alle Systemebenen und die Bedingungen, unter denen die Ebenen eingenommen werden können, an zentraler Stelle definiert werden. Dadurch wird die Cl- bersichtlichkeit des Systems stark erhöht. Abhängigkeiten, die im System Release Manager abgelegt werden, sind stark projektabhä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 auch 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 einfacher 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. Es bietet sich eine deutlich verbesserte Möglichkeit zur automatischen Erstellung der Dokumentation. Eine explizite Defi- nition der erlaubten Systemzustände ermöglicht automatisiertes Testen und bildet eine Grundlage zur einfacheren Reduktion der Komplexität.
Die Erfindung bietet ferner eine Reihe implementierungsrelevanter Vorteile. So kommen sehr effiziente Algorithmen zum Einsatz, mit denen Fehler und Trigger weiterver- arbeitet werden können. Dadurch werden weniger von den sehr begrenzten Ressourcen ROM, RAM und Laufzeit oder Zykluszeit in einem Steuergerät verbraucht.
Vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens sind Gegenstand der Unteransprüche.
Zweckmäßigerweise wird ein Systemzustand niedrigerer oder niedrigster Priorität als Zielzustand bestimmt, wenn der Systemzustand nächsthöherer Priorität nicht auswählbar ist. Mit dieser Maßnahme ist in einfacher Weise zu jedem Zeitpunkt der Zielzustand mit der bestmöglichen Priorität auswählbar bzw. einstellbar, wobei eine stufenweise Überprüfung der Systemzustände in der Reihenfolge ihrer Prioritäten (mit absteigender Priorität) durchführbar ist.
Es wird bevorzugt, dass die Schritte des Ermitteins basierend auf einer zentralen Zuordnungstabelle durchgeführt werden, wobei die zentrale Zuordnungstabelle für jeden Systemzustand definiert, welche der Komponenten verfügbar sein müssen, damit der jeweilige Systemzustand auswählbar ist. Diese Maßnahme ermöglicht insbesondere eine Zentraldefinition, Überprüfung, Neueinstellung und Abrufbarkeit sämtlicher möglicher Systemzustände.
Zweckmäßigerweise umfassen die Schritte des Ermitteins einen Schritt des Analysie- rens, ob die gemäß der zentralen Zuordnungstabelle für den jeweiligen Systemzustand erforderlichen Komponenten verfügbar sind.
Hierbei entsprechen die unterschiedlichen Prioritäten unterschiedlichen Verfügbarkeiten des Systems, wobei vorteilhafterweise der Systemzustand höchster Priorität einer höchsten Verfügbarkeit des Systems entspricht.
Es ist bevorzugt, dass für eine Auswählbarkeit des Systemszustands höchster Priorität eine erste Menge an verfügbaren Komponenten, und für eine Auswählbarkeit des Systemzustands nächst höherer Priorität eine zweite Menge an verfügbaren Komponenten erforderliche ist, wobei die zweite Menge eine Teilmenge der ersten Menge sein kann. Diese Maßnahme ermöglicht ein optimales Abstimmen bzw. Abstufen der jeweiligen Zustände zueinander.
Zweckmäßigerweise sind für eine Auswählbarkeit des Systemzustands niedrigster Priorität keine verfügbaren Komponenten erforderlich. Dies ermöglicht insbesondere unter bestimmten Umständen einen Notlaufbetrieb.
Gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens wird in Reaktion auf eine Änderung einer Verfügbarkeit einer der Komponenten der Zielzustand des Systems, ausgehend von dem Systemzustand höchster Priorität, erneut ermittelt. Hierdurch kann gewährleistet werden, dass eine optimale Systemeinstellung jederzeit möglich ist.
Zweckmäßigerweise kann eine Änderung einer Verfügbarkeit einer der Komponenten durch eine Störung der Komponenten, einen Eingriff eines Bedieners des Systems und/oder eine Vorgabe eines Herstellers des Systems erfolgen. Hiermit erlaubt das erfindungsgemäße Verfahren eine Anpassung des Systems an die wahrscheinlichsten Störungen bzw. zu berücksichtigenden Änderungen.
Zweckmäßigerweise ist mittels des Zielzustands anzeigbar, welche Funktionalitäten des Systems betriebsbereit sind. Dies ermöglicht eine besonders übersichtliche Darstellung der Funktionalitäten, wodurch die Handhabbarkeit des Systems erleichtert ist. Bei diesen Funktionalitäten handelt es sich bevorzugterweise um Regler, Modellrechnungen, Überwachungen oder Signalaufbereitungen.
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äuternden 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 Zeichnung ausführlich beschrieben.
Kurze Beschreibung der Zeichnungen
Fig. 1 zeigt ein Flussdiagramm eines Verfahrens gemäß einer bevorzugten Ausfüh- rungsform der vorliegenden Erfindung;
Fig. 2 zeigt ein Blockschaltbild einer Vorrichtung gemäß einer weiteren bevorzugten Ausführungsform der vorliegenden Erfindung;
Fig. 3 zeigt eine Zuordnungstabelle gemäß einer weiteren bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 1 zeigt ein Flussdiagramm zur Darstellung eines Verfahrens zur Bestimmung eines Zielzustands in einem System mit mehreren Komponenten, gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung. Abhängig von einer Verfügbarkeit der Komponenten, können in dem System Systemzustände unterschiedlicher Prioritäten ausgewählt werden.
In einem ersten Verfahrensschritt 102 wird ermittelt, ob ein Systemzustand höchster Priorität auswählbar ist. Der Systemzustand höchster Priorität ist dann auswählbar, wenn alle für die Auswahl dieses Systemzustandes erforderlichen Komponenten des Systems verfügbar sind. Ist der Systemzustand höchster Priorität auswählbar, d. h. es sind alle erforderlichen Komponenten verfügbar, so wird in einem Verfahrensschritt 104 der Systemzustand höchster Priorität als Zielzustand ermittelt. In diesem Fall kann das Verfahren beendet werden, ohne weitere Verfahrensschritte auszuführen.
Ist der Systemzustand höchster Priorität jedoch nicht auswählbar, d. h. es sind nicht alle erforderlichen Komponenten verfügbar, so wird in einem Verfahrensschritt 112 ermittelt, ob ein Systemzustand nächsthöherer Priorität auswählbar ist. Der Systemzustand nächsthöherer Priorität ist dann auswählbar, wenn alle für die Auswahl dieses Systemzustandes erforderlichen Komponenten des Systems verfügbar sind. Typischerweise sind für den Systemzustand nächst höherer Priorität weniger bzw. andere Komponenten erforderlich als für den Systemzustand höherer Priorität. Beispielsweise kann für den Systemzustand nächsthöherer Priorität eine Teilmenge, der für den Systemzustand höherer Priorität erforderlichen Komponenten, erforderlich sein. Wenn der Systemzustand nächsthöherer Priorität auswählbar ist, d. h. es sind alle für diesen Systemzustand erforderlichen Komponenten verfügbar, wird in einem Verfahrensschritt 114 der Systemzustand nächsthöherer Priorität als Zielzustand bestimmt. In diesem Fall kann das Verfahren beendet werden.
Wenn der Systemzustand nächsthöherer Priorität nicht auswählbar ist, so können in weiteren Verfahrensschritten (nicht gezeigt in den Figuren) weitere Systemzustände mit jeweils niedrigeren Prioritäten auf ihre Auswählbarkeit überprüft werden. Es wird dabei, bzgl. der Prioritäten, in absteigender Reihenfolge überprüft, ob ein Systemzustand auswählbar ist. Ist ein Systemzustand auswählbar, so wird dieser Systemzustand als Zielzustand ausgewählt. Andernfalls wird ermittelt, ob der Systemzustand mit nächst niedrigerer Priorität auswählbar ist. Das Verfahren wird solange durchgeführt, bis ein auswählbarer Systemzustand ermittelt und als Zielzustand bestimmt wurde. Ist kein Systemzustand höherer Priorität auswählbar, also ist bezogen auf Fig. 1 der Systemzustand nächsthöherer Priorität nicht auswählbar, so kann in einem weiteren Verfahrensschritt 124 ein Systemzustand niedrigster Priorität als Zielzustand bestimmt werden. Beispielsweise kann der Systemzustand niedrigster Priorität immer dann als Zielzustand bestimmt werden, wenn nicht genügend Komponenten verfügbar sind, um einen Systemzustand höherer Priorität auszuwählen.
Die Verfahrensschritte 102, 104, 112, 114, 124 können an zentraler Stelle im System ausgeführt werden. Beispielsweise kann dazu eine zentrale Zuordnungstabelle (gezeigt in Fig. 3) eingesetzt werden, in der für jeden Systemzustand definiert ist, welche der Komponenten verfügbar sein müssen, damit der jeweilige Systemzustand auswählbar ist. Unter Verwendung der zentralen Zuordnungstabelle kann analysiert werden, ob die gemäß der zentralen Zuordnungstabelle für den jeweiligen Systemzustand erforderlichen Komponenten verfügbar sind.
Die unterschiedlichen Prioritäten der Systemzustände können unterschiedlichen Verfügbarkeiten des Systems entsprechen, wobei der Systemzustand höchster Priorität einer höchsten Verfügbarkeit des Systems entspricht.
Tritt eine Änderung in einer Verfügbarkeit einer Komponente ein, so kann es erforderlich sein, den gerade aktuellen Zielzustand zu überprüfen bzw. einen neuen Zielzustand zu bestimmen. Eine Änderung einer Verfügbarkeit einer der Komponenten kann beispielsweise durch eine Störung der Komponente, einen Eingriff eines Bedieners des Systems oder eine Vorgabe eines Herstellers des Systems erfolgen. Eine daraufhin erforderliche Bestimmung eines neuen Zielzustands kann erfolgen, indem das erfindungsgemäße Verfahren erneut durchgeführt wird. Bezogen auf Fig. 1 bedeutet dies, dass ausgehend von dem ersten Verfahrensschritt 102 ein neuer Zielzustand bestimmt wird.
Der Zielzustand kann definieren, welche Funktionalitäten des Systems betriebsbereit sind. Bei den Funktionalitäten kann es sich beispielsweise um Regler, Modellrechnungen, Überwachungen oder Signalaufbereitungen handeln. Fig. 2 zeigt ein Blockschaltbild zur Darstellung einer Vorrichtung 200 zur Bestimmung eines Zielzustands in einem System mit mehreren Komponenten. Beispielhaft ist in Fig. 2 ein System mit einer ersten Komponente 230, deren Verfügbarkeit im System mittels eines ersten Verfügbarkeitssignals 235 anzeigbar ist, einer zweiten Komponente 240, deren Verfügbarkeit mittels eines zweiten Verfügbarkeitssignals 245 anzeigbar ist und einer dritten Komponente 250, deren Verfügbarkeit mittels eines dritten Verfügbarkeitssignals 255 anzeigbar ist, gezeigt. Die Vorrichtung 200 kann als eine Einheit, also nicht verteilt, in dem System realisiert sein. Die Vorrichtung 200 ist ausgebildet, um die Verfügbarkeitssignale 235, 245, 255 zu empfangen. Die Vorrichtung 200 kann eine Zuordnungstabelle 262 aufweisen. In der Zuordnungstabelle 262 sind alle möglichen Systemzustände definiert. Ferner ist in der Zuordnungstabelle 262 für jeden Systemzustand definiert, welche der Komponenten 230, 240, 250 verfügbar sein müssen, damit der jeweilige Systemzustand auswählbar ist. Beispielsweise, kann es erforderlich sein, dass alle Komponenten 230, 240, 250 verfügbar sind, damit der Systemzustand höchs- ter Priorität ausgewählt werden kann.
Die Vorrichtung 200 ist ausgebildet, um unter Verwendung der Zuordnungstabelle 262 und durch eine Auswertung der Verfügbarkeitssignale 235, 245, 255 zu ermitteln, welcher in der Zuordnungstabelle 262 definierte Systemzustand ausgewählt werden kann. Ferner ist die Vorrichtung 200 ausgebildet, um denjenigen Systemzustand als Zielzustand zu bestimmen, der, aufgrund der verfügbaren Komponenten, ausgewählt werden kann und zusätzlich die höchste Priorität aller auswählbaren Systemzustände aufweist. Die Vorrichtung 200 weist Mittel auf, um den Zielzustand in Form eines Zielzustands- signals 265 anzuzeigen.
Beispielsweise kann es sich bei den Komponenten 230, 240, 250 um Sensoren, Aktoren, Datenübertragungscontroller, Steuergerätekomponenten oder von solchen Komponenten übertragbare Signale handeln. Bei dem System kann es sich beispielsweise um ein dynamisches System wie ein mechatronisch eingebettetes System handeln.
Die Vorrichtung 200 bzw. die Zuordnungstabelle 262 kann in Form eines System Release Manager realisiert werden, der alle Systemebenen definiert. Darüber hinaus werden durch den System Release Manager, je Systemebene, diejenigen Signale festgelegt, die für einen Betrieb dieser Ebene notwendig sind. Anhand der bereits erwähnten Fig. 3 wird ein einfaches Beispiel einer Zustandsdefiniti- on im System Release Manager beschrieben. Die Fig. 3 zeigt eine Tabelle, bei der es sich um die in Fig. 2 beschriebene Zuordnungstabelle 262 handeln kann.
Die Tabelle weist drei Spalten und fünf Zeilen auf. Die letzte Spalte ist in drei Unterspalten unterteilt. In der ersten Spalte, die mit dem Feld 301 beginnt, werden die möglichen Systemzustände definiert. In der zweiten Spalte, die mit dem Feld 302 beginnt, werden die für den jeweiligen Systemzustand benötigten Signale, Komponenten und Trigger definiert. Diese werden gesammelt als "guards" bezeichnet. In der dritten Spalte, die mit dem Feld 303 beginnt, werden Zustände der Komponenten des Systems definiert, die von den in der zweiten Spalte definierten Signalen, Komponenten und Triggern abhängen. Bei solchen abhängigen Komponenten kann es sich um ein in der ersten Unterspalte 304 aufgeführtes ABS-System, um ein in der zweiten Unterspalte 305 aufgeführtes ASR-System oder um ein in der dritten Unterspalte 306 aufgeführtes ESP-System handeln.
Die zweite Zeile, die mit dem Feld 307 beginnt, beschreibt einen „Systemzustand 3", für den gemäß Feld 308 die Komponenten „Gierrate", „Motorschnittstelle", „4 Drehzahl- sensoren" und „!Pata" verfügbar sein müssen, damit gemäß Feld 309 die Komponente ABS im Zustand „an", gemäß Feld 310 die Komponente ASR im Zustand „an" und gemäß Feld 311 die Komponente ESP im Zustand „an" ist.
Die dritte Zeile, die mit dem Feld 312 beginnt, beschreibt einen „Systemzustand 2", für den gemäß Feld 313 die Komponenten „Motorschnittstelle" und „4 Drehzahlsensoren" verfügbar sein müssen, damit gemäß Feld 314 die Komponente ABS im Zustand „backup", gemäß Feld 315 die Komponente ASR im Zustand „backup" und gemäß Feld 316 die Komponente ESP im Zustand „aus" ist.
Die vierte Zeile, die mit dem Feld 317 beginnt, beschreibt einen „Systemzustand 1", für den gemäß Feld 318 die Komponente „4 Drehzahlsensoren" verfügbar sein muss, damit gemäß Feld 319 die Komponente ABS im Zustand „backup", gemäß Feld 320 die Komponente ASR im Zustand „aus" und gemäß Feld 321 die Komponente ESP im Zustand „aus" ist. Die fünfte Zeile, die mit dem Feld 322 beginnt, beschreibt einen „Systemzustand 0", für den gemäß Feld 323 keine Komponente verfügbar sein muss. Gemäß Feld 324 befindet sich die Komponente ABS im Zustand „aus", gemäß Feld 325 befindet sich die Komponente ASR im Zustand „aus" und gemäß Feld 326 befindet sich die Komponente ESP im Zustand „aus".
In dem anhand von Fig. 3 beschriebenen Beispiel existieren vier Systemzustände 307, 312, 317, 322, die gemäß ihren jeweiligen Prioritäten in der in Fig. 3 gezeigten Tabelle abgelegt sind. Die Prioritäten entsprechen einer Systemverfügbarkeit. In der Tabelle sind die Systemzustände 307, 312, 317, 322 absteigend sortiert. Zur Ermittlung der resultierenden Zielstrategie wird diese Tabelle von oben nach unten durchlaufen und die benötigten Signale 308, 313, 318, 323 analysiert. Sind bei einer Strategie alle Teile des zugehörigen guards verfügbar, bzw. erfüllt, so ist dies die neue Zielstrategie, und die Suche wird abgebrochen.
Wie aus der Tabelle ersichtlich ist, sind bei den guards 302 sowohl Signale, beispielsweise die Gierrate, als auch Trigger, beispielsweise Pata, als auch Verfügbarkeit von Aktoren, bspw. Hydraulikventilen, aufgeführt. Dies zeigt, dass der Inhibit Handler kei- nen Unterschied zwischen diesen Guard- Elementen macht. Dadurch wird der Inhibit Handler erheblich vereinfacht, weil ein Lösungsalgorithmus für alle Typen verwendet werden kann.
Im Folgenden werden zur Erläuterung einige Beispiele aufgeführt, die auf der in Fig. 3 beschriebenen Tabelle basieren.
Wenn der Gierratesensor und alle Drehzahlsensoren an den Rädern sowie die Motorschnittstelle gültige Signale liefern, dann wird „Strategie 3" ausgewählt. Die Suche nach der Zielstrategie ist anschließend beendet.
Wenn im System kein Fehler vorliegt und der Fahrer den Passivtaster Pata drückt, so wird „Strategie 2" ausgewählt. Das liegt daran, dass die Bedingungen für „Strategie 3" nicht erfüllt sind, denn Passivtaster darf hierbei nicht gedrückt sein. Wenn ein Drehzahlsensor an einem Rad ausfällt, dann beginnt die Suche nach einer realisierbaren Strategie wieder bei der obersten Strategie. Da die Strategien 3 bis 1 jeweils diesen Sensor als gültig voraussetzen, wird „Strategie 0" ausgewählt. Dieser Systemzustand kann prinzipiell immer eingenommen werden, da für ihn keine Signale vorausgesetzt werden. Hierbei werden alle Komponenten 304, 305, 306 des Systems deaktiviert. Daher wird dieser Zustand als „FailSafe" bezeichnet.
Die Erfindung kann in Software umgesetzt werden. Bei dem erfindungsgemäßen Verfahren handelt es sich um ein neues Konzept zur Verwaltung von Systemzuständen dynamischer Systeme. Dieses Verfahren beinhaltet die Bestimmung des Betriebszustands, welcher unter den gegebenen Randbedingungen erlaubt und gewünscht ist und darüber hinaus die höchste Systemverfügbarkeit aufweist.
Der erfindungsgemäße Ansatz ist nicht auf die Fahrdynamikregelung ESP beschränkt. Vielmehr ist der Einsatz in allen mechatronischen eingebetteten Systemen denkbar. Solche Systeme sind neben dem ESP beispielsweise auch die Produkte ABS und ASR. Die beschriebenen Ausführungsbeispiele 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 Bestimmung eines Zielzustands (265) in einem System mit mehreren Komponenten (230, 240, 250; 308, 313, 318, 323), wobei in dem System, abhängig von einer Verfügbarkeit der Komponenten, Systemzustände (307, 312, 317, 322) unterschiedlicher Priorität auswählbar sind, wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist:
Ermitteln (102), ob ein Systemzustand (307) höchster Priorität auswählbar ist;
Bestimmen (104) des Systemzustands höchster Priorität als Zielzustand (265), wenn der Systemzustand höchster Priorität auswählbar ist;
Ermitteln (112), ob ein Systemzustand (312) nächsthöherer Priorität auswählbar ist, wenn der Systemzustand höchster Priorität nicht auswählbar ist, und Bestim- men (114) des Systemzustands nächsthöherer Priorität als Zielzustand (265), wenn dieser auswählbar ist.
2. Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass ein Systemzustand (322) niedrigerer oder niedrigster Priorität als Zielzustand (265) bestimmt wird, wenn der Systemzustand (312) nächsthöherer Priorität nicht auswählbar ist.
3. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Schritte des Ermitteins (102, 112) basierend auf einer zentralen Zuordnungstabelle (262) durchgeführt werden, wobei die zentrale Zuordnungstabelle für jeden Systemzustand (307, 312, 317, 322) definiert, welche der Komponenten
(230, 240, 250; 308, 313, 318, 323) verfügbar sein müssen, damit der jeweilige Systemzustand auswähl bar ist.
4. Verfahren gemäß Anspruch 3, dadurch gekennzeichnet, dass die Schritte des Ermitteins (102, 112) einen Schritt des Analysierens, ob die gemäß der zentralen Zuordnungstabelle (262) für den jeweiligen Systemzustand erforderlichen Komponenten (230, 240, 250; 308, 313, 318, 323) verfügbar sind, umfassen.
5. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die unterschiedlichen Prioritäten unterschiedlichen Verfügbarkeiten des Systems entsprechen, wobei der Systemzustand (307) höchster Priorität einer höchsten Verfügbarkeit des Systems entspricht.
6. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass für eine Auswählbarkeit des Systemzustands (307) höchster Priorität eine erste Menge an verfügbaren Komponenten (308) und für eine Auswählbarkeit des Systemzustands (312) nächsthöherer Priorität eine zweite Menge an verfügba- ren Komponenten (313) erforderlich ist, wobei die zweite Menge eine Teilmenge der ersten Menge sein kann.
7. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass für eine Auswählbarkeit des Systemzustands (322) niedrigster Priorität kei- ne verfügbaren Komponenten (323) erforderlich sind.
8. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass in Reaktion auf eine Änderung einer Verfügbarkeit einer der Komponenten (230, 240, 250; 308, 313, 318, 323) der Zielzustand (265) des Systems, ausge- hend von dem Systemzustand (307) höchster Priorität, erneut ermittelt wird.
9. Verfahren gemäß Anspruch 8, dadurch gekennzeichnet, dass eine Änderung einer Verfügbarkeit einer der Komponenten (230, 240, 250; 308, 313, 318, 323) durch eine Störung der Komponente, einen Eingriff eines Bedieners des Systems und/oder eine Vorgabe eines Herstellers des Systems erfolgen kann.
10. Verfahren gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass mittels des Zielzustands (265) anzeigbar ist, welche Funktionalitäten (304, 305, 306) des Systems betriebsbereit sind.
11. Verfahren gemäß Anspruch 10, dadurch gekennzeichnet, dass es sich bei den Funktionalitäten (304, 305, 306) des Systems um Regler, Modellrechnungen, Cl- berwachungen oder Signalaufbereitungen handelt.
12. Vorrichtung (200) um alle Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 11 durchzuführen.
13. Vorrichtung (200) gemäß Anspruch 12, dadurch gekennzeichnet, dass es sich bei den Komponenten (230, 240, 250; 308, 313, 318, 323) um Sensoren, Aktoren,
Datenübertragungscontroller, Steuergerätekomponenten oder von solchen Komponenten übertragbare Signale handelt.
14. Vorrichtung (200) 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 aus- gefü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 Computerprogrammpro- dukt auf einem Computer oder auf einer entsprechenden Rechnereinheit ausgeführt wird.
PCT/EP2007/059985 2006-10-05 2007-09-20 Verfahren und vorrichtung zur bestimmung eines zielzustands WO2008040645A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/308,202 US20100037229A1 (en) 2006-10-05 2007-09-20 Method and Device for Determining a Target State
JP2009530837A JP2010506278A (ja) 2006-10-05 2007-09-20 目標状態を定める方法、および、目標状態を定めるための装置
EP07820420A EP2079624A1 (de) 2006-10-05 2007-09-20 Verfahren und vorrichtung zur bestimmung eines zielzustands

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006047141A DE102006047141A1 (de) 2006-10-05 2006-10-05 Verfahren und Vorrichtung zur Bestimmung eines Zielzustands
DE102006047141.5 2006-10-05

Publications (1)

Publication Number Publication Date
WO2008040645A1 true WO2008040645A1 (de) 2008-04-10

Family

ID=38996501

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/059985 WO2008040645A1 (de) 2006-10-05 2007-09-20 Verfahren und vorrichtung zur bestimmung eines zielzustands

Country Status (5)

Country Link
US (1) US20100037229A1 (de)
EP (1) EP2079624A1 (de)
JP (1) JP2010506278A (de)
DE (1) DE102006047141A1 (de)
WO (1) WO2008040645A1 (de)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0475406A2 (de) * 1990-09-13 1992-03-18 Mazda Motor Corporation Multiplexübertragungssystem
EP1077410A1 (de) * 1999-08-14 2001-02-21 International Business Machines Corporation Intelligente Fehlerverwaltung
DE10223368A1 (de) 2002-05-25 2003-12-04 Bosch Gmbh Robert Verfahren zur Verarbeitung von Zuständen eines Steuergeräts
DE10354659A1 (de) 2003-11-22 2005-06-16 Robert Bosch Gmbh Festlegung einer gemeinsamen Betriebsart für kooperierende Geräte
DE102005055173A1 (de) * 2004-11-19 2006-05-24 Denso Corp., Kariya Fahrzeugnetzwerksystem und Netzwerkkomponente

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10290502A (ja) * 1997-04-15 1998-10-27 Toyota Motor Corp クリープトルク制御装置
JP4234251B2 (ja) * 1999-03-15 2009-03-04 三菱重工パーキング株式会社 機械設備における遠隔故障診断システム
US7137119B1 (en) * 2000-05-02 2006-11-14 Microsoft Corporation Resource manager architecture with resource allocation utilizing priority-based preemption
JP2002041142A (ja) * 2000-07-27 2002-02-08 Denso Corp 監視システム、フェールセーフシステム及び記録媒体
JP4066609B2 (ja) * 2001-03-19 2008-03-26 日産自動車株式会社 車両用走行制御装置の状態表示装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0475406A2 (de) * 1990-09-13 1992-03-18 Mazda Motor Corporation Multiplexübertragungssystem
EP1077410A1 (de) * 1999-08-14 2001-02-21 International Business Machines Corporation Intelligente Fehlerverwaltung
DE10223368A1 (de) 2002-05-25 2003-12-04 Bosch Gmbh Robert Verfahren zur Verarbeitung von Zuständen eines Steuergeräts
DE10354659A1 (de) 2003-11-22 2005-06-16 Robert Bosch Gmbh Festlegung einer gemeinsamen Betriebsart für kooperierende Geräte
DE102005055173A1 (de) * 2004-11-19 2006-05-24 Denso Corp., Kariya Fahrzeugnetzwerksystem und Netzwerkkomponente

Also Published As

Publication number Publication date
DE102006047141A1 (de) 2008-04-10
JP2010506278A (ja) 2010-02-25
US20100037229A1 (en) 2010-02-11
EP2079624A1 (de) 2009-07-22

Similar Documents

Publication Publication Date Title
EP2146262B1 (de) Verfahren zum Bestimmen fehlerhafter Komponenten in einem System
EP1597643B1 (de) Vorrichtung und verfahren zur modellbasierten on-board-diagnose
EP2099667B2 (de) Verfahren zum sicherstellen oder aufrechterhalten der funktion eines komplexen sicherheitskritischen gesamtsystems
DE102011005844A1 (de) Automatische Steuerung eines Fahrzeugs
EP2422244A1 (de) Sicherheitssteuerung und verfahren zum steuern einer automatisierten anlage
WO1998028692A1 (de) Verfahren zur überprüfung der funktionsfähigkeit einer recheneinheit
WO2005040838A1 (de) System und verfahren zum testen von steuervorgängen bei einem fahrzeug
DE102012221277A1 (de) Fahrzeugsteuervorrichtung
EP2592504B1 (de) Verfahren zur Abschätzung eines Ressourcenverbrauchs bei der Erzeugung eines Steuergeräteprogrammcodes
DE102009034242A1 (de) Verfahren und Vorrichtung zum Prüfen eines Steuergeräts eines Fahrzeugs
EP2079624A1 (de) Verfahren und vorrichtung zur bestimmung eines zielzustands
EP1649373A2 (de) Verfahren und vorrichtung zur berwachung eines verteilten s ystems
EP4168865A1 (de) Verfahren zum steuern eines automatisierungssystems mit visualisierung von programmobjekten eines steuerprogramms des automatisierungssystems und automatisierungssystem
DE10036391B4 (de) Fahrzeug-Überwachungssystem
DE102020200414A1 (de) Verfahren und Vorrichtung zum Rekonfigurieren eines automatisiert fahrenden Fahrzeugs in einem Fehlerfall
WO2007065585A1 (de) Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten
DE102009027369A1 (de) Verfahren sowie System zur Ansteuerung von mindestens einem Aktuator
DE10063934A1 (de) Verfahren und Vorrichtung zur Überwachung und Abschaltung von Steuereinheiten in einem Netzwerk und Netzwerk
DE102019134872B4 (de) Verbesserung der Betriebsparameter eines Rechensystems im Fahrzeug
EP3622451A1 (de) Produktreifebestimmung eines technischen systems und insbesondere eines autonom fahrenden fahrzeugs
DE10220812A1 (de) Verfahren und Vorrichtung zur Überwachung der Funktionsweise eines Systems
DE102010031323A1 (de) Verfahren und Vorrichtung zum Betreiben einer Brennkraftmaschine
DE19622041C2 (de) Verfahren zur Überwachung einer Recheneinheit
DE102020212287A1 (de) Verwendung von Signalintegritäten in Embedded Systemen
EP4363981A1 (de) Verfahren und vorrichtung zum rekonfigurieren einer systemarchitektur eines automatisiert fahrenden fahrzeugs

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2007820420

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2009530837

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 12308202

Country of ref document: US