DE10229676B4 - Verfahren zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms - Google Patents

Verfahren zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms Download PDF

Info

Publication number
DE10229676B4
DE10229676B4 DE10229676A DE10229676A DE10229676B4 DE 10229676 B4 DE10229676 B4 DE 10229676B4 DE 10229676 A DE10229676 A DE 10229676A DE 10229676 A DE10229676 A DE 10229676A DE 10229676 B4 DE10229676 B4 DE 10229676B4
Authority
DE
Germany
Prior art keywords
functionalities
functionality
state
system state
computer program
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.)
Expired - Lifetime
Application number
DE10229676A
Other languages
English (en)
Other versions
DE10229676A1 (de
Inventor
Mathias Bieringer
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
Priority to DE10229676A priority Critical patent/DE10229676B4/de
Priority to US10/600,895 priority patent/US7729785B2/en
Publication of DE10229676A1 publication Critical patent/DE10229676A1/de
Application granted granted Critical
Publication of DE10229676B4 publication Critical patent/DE10229676B4/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/10Requirements analysis; Specification techniques

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Regulating Braking Force (AREA)
  • Control By Computers (AREA)
  • Programmable Controllers (AREA)

Abstract

Verfahren zur Steuerung und/oder Regelung eines Systems, das verschiedene mögliche Systemzustände (30) einnehmen kann, mittels eines multitaskingfähigen Computerprogramms (22) auf einem Rechengerät (21) eines Steuergeräts (20), umfassend die nachfolgenden vor dem eigentlichen Ablauf des Computerprogramms (22) auszuführenden Verfahrensschritte: – Unterteilen des Computerprogramms (22) in mehrere funktional zusammenhängende Funktionalitäten (X); – Definition von möglichen Betriebszuständen (A, B, C) für die Funktionalitäten (X); – Definition der möglichen Systemzustände (30) des Systems, indem den Funktionalitäten (X) für jeden Systemzustand (30) vorgebbare Betriebszustände (A, B, C) zugeordnet werden; – Ermitteln von Abhängigkeit der Funktionalitäten (X) untereinander, wobei eine erste Funktionalität von einer zweiten Funktionalität abhängig ist, wenn mindestens eine Eingangsgröße (Ein_i) der ersten Funktionalität in der zweiten Funktionalität ermittelt wird, dadurch gekennzeichnet, dass das System in einem ersten Systemzustand betrieben wird und während der Laufzeit des Computerprogramms (22): – Fehler (11, 12) in dem System erkannt werden; – anhand der Fehler (11, 12) ein Fehlerzustand (13) des Systems ermittelt wird; – in Abhängigkeit des Fehlerzustands (13) ein zweiter Systemzustand und eine Strategie (14) zum Übergang in den zweiten Systemzustand ermittelt wird; – überprüft wird, ob die den zweiten Systemzustand charakterisierenden Funktionalitäten die für den zweiten Systemzustand geforderten Betriebszustände (A, B, C) aufweisen und – in den zweiten Systemzustand übergegangen wird, wenn die den zweiten Systemzustand charakterisierenden Funktionalitäten die für den zweiten Systemzustand geforderten Betriebszustände (A, B, C) aufweisen.

Description

  • Stand der Technik
  • Die vorliegende Erfindung betrifft ein Verfahren zur Steuerung und/oder Regelung eines Systems nach dem Oberbegriff des Anspruchs 1.
  • Aus dem Stand der Technik ist bspw. ein Computerprogramm zur Steuerung und/oder Regelung eines Fahrdynamiksystems (sog. elektronisches Stabilitätsprogramm, ESP) eines Kraftfahrzeugs bekannt. Das Fahrdynamiksystem kann verschiedene mögliche Systemzustände einnehmen. Mögliche Systemzustände sind bspw. ein Normalbetrieb (ESP_normal), ein erster eingeschränkter Betrieb (Backup_ABS), in dem ein Fahrzeugregler (FZR) des ESP nicht und lediglich ein Antiblockiersystem (ABS) funktionsfähig ist, ein zweiter eingeschränkter Betrieb (Backup_EBD), in dem lediglich ein System zur Verteilung der Bremskraft (Electronic Brake Distribution, EBD) funktionsfähig ist, um zumindest ein Überbremsen der Räder an der Hinterachse zu verhindern, und ein fehlerhafter Zustand (FailSafe), in dem alle wesentlichen Sicherheitsfunktionen des ESP, insbesondere FZR, ABS und EBD, ausgefallen sind. Um sicherheitskritische Fahrsituationen zu vermeiden, werden einem Fahrer des Kraftfahrzeugs die verschiedenen Systemzustände, zumindest aber die Zustände, in denen nur noch eine eingeschränkte bzw. eine fehlerhafte Funktion des Systems gegeben ist, bspw. akustisch oder optisch mittels Warnlampen mitgeteilt. Das Computerprogramm ist auf einem Rechengerät, das insbesondere als ein Prozessor ausgebildet ist, eines Steuergeräts zur Steuerung und/oder Regelung des Fahrdynamiksystems ablauffähig.
  • Nach dem Stand der Technik wird das Computerprogramm zur Steuerung und/oder Regelung des Fahrdynamiksystems in einem vorgebbaren Zeitraster, d. h. lediglich in einer einzigen Zeitscheibe, zyklisch abgearbeitet. Die Funktionsaufrufe innerhalb des Computerprogramms erfolgen also in einer vorgegebenen Reihenfolge nacheinander. Die Reihenfolge wird derart vorgegeben, dass die Eingangsgrößen der Funktionen vor deren Ausführung zur Verfügung stehen. Bei Eingangsgrößen, die von anderen Funktionen berechnet werden, müssen also diese anderen Funktionen zunächst ausgeführt werden, bevor die Funktion ausgeführt werden kann, welche die in den anderen Funktionen berechneten Eingangsgrößen benötigt.
  • Aus dem Stand der Technik ist es des Weiteren bekannt, Computerprogramme zur Steuerung und/oder Regelung eines Systems auf einem multitaskingfähigen Betriebssystem auszuführen, und das Computerprogramm statt in einem einzigen in verschiedenen Zeitrastern abzuarbeiten. Das bedeutet jedoch, dass die Funktionen des Computerprogramms nicht mehr in einer strikt festgelegten Reihenfolge abgearbeitet werden und dass nunmehr andere Vorkehrungen getroffen werden müssen, um sicherzustellen, dass die Eingangsgrößen der Funktionen vor deren Ausführung zur Verfügung stehen.
  • Den Funktionen des Computerprogramms werden verschiedene Prioritäten zugeordnet. Sicherheitsrelevanten Funktionen wird eine höhere Priorität zugeordnet als anderen Funktionen. Höherpriore Funktionen werden in kürzeren Zeitrastern ausgeführt, d. h. in Zeitrastern, die häufiger wiederholt werden, wohingegen weniger sicherheitsrelevante Funktionen mit einer niedrigeren Priorität in längeren Zeitrastern abgearbeitet werden, die seltener wiederholt werden. Insbesondere muss sichergestellt werden, dass die Eingangsgrößen der Funktionen immer zum richtigen Zeitpunkt vorliegen, d. h. eine Funktion, die bspw. in einem 5 ms-Zeitraster abgearbeitet wird und Eingangsgrößen aus einem 40 ms-Zeitraster benötigt, darf erst dann ausgeführt werden, nachdem das 40 ms-Zeitraster bereits abgearbeitet wurde und die erforderlichen Eingangsgrößen berechnet wurden.
  • Ferner ist aus der DE 199 24 461 A1 eine objektorientierte Werkzeugmaschinensteuerung durch einen Mikroprozessor bekannt. Als Systemzustände können dabei die Initialisierungsphase der Steuerung einerseits und der reguläre Betrieb der Steuerung andererseits betrachtet werden. Das auf dem Mikroprozessor ablaufende Programm ist vorab in Funktionalitäten unterteilt worden, die verschiedene Betriebszustände haben können. Für einen Wechsel in einen Betriebszustand „regulärer Betrieb der Steuerung” sind entsprechende Betriebszustände der Funktionalitäten erforderlich. Gemäß den vorab ermittelten Abhängigkeiten der Funktionalitäten untereinander haben übergeordnete Funktionalitäten die Meldungen der untergeordneten abzuwarten. Das Erkennen von Fehlern während des laufenden Betriebs und Übergangsstrategien hin zu verschiedenen bestimmte Fehler berücksichtigenden Systemzuständen und zurück sind in dieser Druckschrift jedoch nicht beschrieben.
  • Schließlich beschreibt die US 6,219,590 B1 eine Regelung für Gebäude-Klimaanlagen mittels eines Mikroprozessor-Programms. Dabei führt das Erkennen von Fehlern zu einer Änderung des Regelungsverfahrens; nach Behebung des Fehlers schaltet das Programm auf Normalbetrieb zurück. Dies ist jedoch nur eine sehr einfache Lösung, vor allem weil in dieser Druckschrift keine Abhängigkeiten der verschiedenen Funktionalitäten voneinander vorgesehen sind. Daher wird keine Strategie für den Übergang in einen zweiten Systemzustand ermittelt, und der Übergang in den zweiten Systemzustand setzt nicht voraus, dass zunächst die beteiligten Funktionalitäten überprüft werden, ob sie die geforderten Betriebszustände aufweisen, bevor ein definierter Systemübergang erfolgen darf.
  • Der vorliegenden Erfindung liegt die Aufgabe zugrunde, bei komplexen sicherheitskritischen Steuer- und Regelungssystemen, die mittels eines multitaskingfähigen Computerprogramms arbeiten, die Verfügbarkeit und Sicherheit der Steuerung und/oder Regelung zur Laufzeit zu gewährleisten bzw. zu erhöhen.
  • Zur Lösung dieser Aufgabe schlägt die vorliegende Erfindung ein Verfahren mit den Merkmalen des Anspruchs 1 vor.
  • Vorteile der Erfindung
  • Das erfindungsgemäße Verfahren zur Steuerung und/oder Regelung eines Systems, das verschiedene Systemzustände einnehmen kann, mittels eines multitaskingfähigen Computerprogramms ermöglicht es, das Computerprogramm in verschiedenen Zeitscheiben eines multitaskingfähigen Betriebssystems unter Berücksichtigung der vorhandenen Abhängigkeiten der Funktionalitäten untereinander und weiterer Randbedingungen flexibel und schnell zu steuern. Eine Erweiterung des Computerprogramms durch Hinzufügen weiterer Funktionalitäten ist problemlos möglich.
  • Erfindungsgemäß wird das Computerprogramm also in mehrere funktional zusammenhängende Einheiten, sog. Funktionalitäten, unterteilt. Für jede der Funktionalitäten werden zulässige Betriebszustände definiert. Die Definition der zulässigen Betriebszustände kann bspw. aufgrund von praktischen Erfahrungen, aufgrund von Simulationen oder aufgrund von theoretischen Überlegungen erfolgen. Des Weiteren werden die Systemzustände, welche das System einnehmen kann, definiert. Jeder Systemzustand ist dadurch charakterisiert, dass mindestens eine Funktionalität einen bestimmten Betriebszustand aufweist, d. h. mindestens einer der Betriebszustände einen vorgebbaren Wert einnimmt. Zur Definition der möglichen Systemzustände werden den Betriebszuständen für jeden Systemzustand bestimmte Werte zugeordnet.
  • Die Funktionalitäten des Computerprogramms werden aufgeteilt in voneinander abhängige Funktionalitäten einerseits und voneinander unabhängige Funktionalitäten andererseits. So ist bspw. eine erste Funktionalität von einer zweiten Funktionalität abhängig, wenn mindestens eine Eingangsgröße der ersten Funktionalität in der zweiten Funktionalität ermittelt wird. Die ermittelten Abhängigkeiten werden in dem Steuergerät abgelegt, so dass im Rahmen der Steuerung des Ablaufs des Computerprogramms auf die ermittelten Abhängigkeiten zugegriffen werden kann. Diese Abhängigkeiten der einzelnen Funktionalitäten zueinander bestimmen nämlich gemäß der vorliegenden Erfindung entscheidend den Zeitpunkt, zu dem eine Funktionalität von einem Betriebszustand in einen anderen Betriebszustand wechseln kann und somit, wann das Gesamtsystem von einem Systemzustand in einen anderen Systemzustand übergehen kann.
  • Sobald sämtliche Eingangsgrößen einer bestimmten Funktionalität, durch die ein bestimmter Systemzustand charakterisiert wird, vorliegen, kann der Betriebszustand dieser Funktionalität gewechselt werden. Dies gilt auch für alle weiteren Funktionalitäten, durch die der Systemzustand außerdem noch charakterisiert ist. Erst wenn sämtliche Funktionalitäten in den entsprechenden Betriebszustand gewechselt sind (und wenn evtl. weitere vorgebbare Randbedingungen erfüllt sind), geht das System in den gewünschten Systemzustand über. Anders ausgedrückt, wird der gewünschte Systemzustand bzw. werden die diesen Systemzustand charakterisierenden Betriebszustände der Funktionalitäten erst dann zentral vorgegeben, wenn die ermittelten Abhängigkeiten zwischen den Funktionalitäten und weitere Randbedingungen erfüllt sind.
  • Es wird vorgeschlagen, dass zur Berücksichtigung der ermittelten Abhängigkeiten zwischen den Funktionalitäten die mindestens eine Eingangsgröße für die erste Funktionalität nicht durch Abarbeitung der zweiten Funktionalität, sondern auf andere Weise ermittelt wird. Die andere Weise zur Ermittlung der mindestens einen Eingangsgröße für die erste Funktionalität umfasst eine Modellierung der Eingangsgröße aus anderen Größen, eine Ermittlung einer Ersatzgröße und/oder eine Ermittlung der Eingangsgröße anhand eines alternativen Algorithmus.
  • Ferner wird vorgeschlagen, dass die Betriebszustände von einen bestimmten Systemzustand charakterisierenden Funktionalitäten in Abhängigkeit von mindestens einem in dem System aufgetretenen Fehler vorgegeben werden. Demnach werden also Fehlerzustände in dem System erkannt und lokalisiert. Die aufgetretenen Fehler in dem System wirken sich auf die Auswahl und die Vorgabe eines bestimmten Systemzustands aus. Außerdem werden diejenigen Eingangsgrößen, auf die sich der Fehlerzustand auswirkt, entsprechend gekennzeichnet (Eingangsgrößen-Statussignal). Der ausgewählte Systemzustand und der Status der Eingangsgrößen wird dann bei der Auswahl und Vorgabe der Betriebszustände der einzelnen Funktionalitäten, welche den vorgegebenen Systemzustand charakterisieren, berücksichtigt. Es wird eine Strategie entwickelt, wie die einzelnen Funktionalitäten in die für den ausgewählten Systemzustand erforderlichen Betriebszustände unter Berücksichtigung der ermittelten Abhängigkeiten zwischen den Funktionalitäten überführt werden können. Wenn alle den Systemzustand charakterisierenden Funktionalitäten die erforderlichen Betriebszustände aufweisen, ist der Übergang des Systems in den vorgegebenen Systemzustand abgeschlossen.
  • Schließlich wird vorgeschlagen, dass die Betriebszustände von einen bestimmten Systemzustand charakterisierenden Funktionalitäten in Abhängigkeit von den Ist-Betriebszuständen der Funktionalitäten vorgegeben werden. Demnach wird anhand der Ist-Betriebszustände der Funktionalitäten der momentane Ist-Systemzustand ermittelt. Außerdem wird der Ist-Betriebszustand bei der Steuerung der Betriebszustände untereinander berücksichtigt, so dass bspw. einer bestimmten Funktionalität erst dann ein neuer Soll-Betriebszustand vorgegeben wird, wenn mindestens eine andere Funktionalität einen erforderlichen Betriebszustand eingenommen hat. In einem Fahrdynamiksystem eines Kraftfahrzeugs wird bspw. einem Fahrzeugregler erst dann ein neuer Soll-Betriebszustand vorgegeben, wenn der Betriebszustand eines ABS-Reglers den Übergang von einer eingeschränkten zu einer vollen Funktionsfähigkeit vollzogen hat.
  • Gemäß einer vorteilhaften Weiterbildung der vorliegenden Erfindung wird vorgeschlagen, dass ein für den zweiten Systemzustand geforderter Betriebszustand durch eine Betriebszustandsvariable definiert wird, die verschiedene Betriebszustandswerte annehmen kann. Jeder Funktionalität ist eine Betriebszustandsvariable zugeordnet, die je nach Betriebsstellung der Funktionalität unterschiedliche Betriebszustandswerte annimmt. Je nachdem, welchen Betriebszustandswert die Betriebszustandsvariable einer Funktionalität aufweist, steht die Funktionalität bspw. in vollem Umfang, eingeschränkt oder überhaupt nicht, zur Verfügung.
  • Die verschiedenen Betriebszustände einer Funktionalität können bspw. dadurch bedingt sein, dass bei der Ausführung der Funktionalität noch nicht alle erforderlichen Eingangsgrößen zur Verfügung stehen. Falls es in einem solchen Fall nicht möglich sein sollte, vorab entsprechende Funktionalitäten zur Berechnung dieser Eingangsgrößen auszuführen, muss die Funktionalität mit Eingangsgrößen ausgeführt werden, die mittels eines alternativen Algorithmus oder durch Modellierung aus anderen Größen ermittelt wurden. Das kann jedoch dazu führen, dass die Funktionalität nicht in vollem Umfang, sondern lediglich eingeschränkt zur Verfügung steht. Falls die fehlenden Eingangsgrößen nicht modelliert oder anderweitig berechnet werden können, kann es sogar vorkommen, dass die Funktionalität überhaupt nicht zur Verfügung steht.
  • Die Betriebszustandsvariable kann die Stellungen ”volle Funktionalität”, ”eingeschränkte Funktionalität” und ”keine Funktionalität” entsprechende Betriebszustandswerte annehmen.
  • Es wird des Weiteren vorgeschlagen, dass zur Berücksichtigung der ermittelten Abhängigkeiten zwischen den Funktionalitäten die Abarbeitung der einen bestimmten Systemzustand charakterisierenden Funktionalitäten derart zeitlich gestaffelt wird, dass die zweite Funktionalität zur Ermittlung der mindestens einen Eingangsgröße für die erste Funktionalität vor der ersten Funktionalität abgearbeitet wird.
  • Des Weiteren werden zwei besonders vorteilhafte Verwendungen des erfindungsgemäßen Verfahrens zur Steuerung und/oder Regelung eines Systems mittels eines multitaskingfähigen Computerprogramms vorgeschlagen. Zum einen wird vorgeschlagen, das Verfahren zur Steuerung und/oder Regelung eines Systems in einem Fahrzeug, insbesondere in einem Kraftfahrzeug, zu verwenden. Insbesondere wird vorgeschlagen, das Verfahren zur Steuerung und/oder Regelung eines Fahrdynamiksystems in einem Kraftfahrzeug zu verwenden. Zum anderen wird vorgeschlagen, das Verfahren zur Steuerung und/oder Regelung eines Systems in einem Gebäude zu verwenden. Insbesondere wird vorgeschlagen, das Verfahren zur Steuerung und/oder Regelung eines Alarmsystems, eines Heizungs- und Klimatisierungssystems und/oder eines Zugangskontrollsystems in einem Gebäude zu verwenden.
  • Zeichnungen
  • Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben. sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen der Erfindung, die in der Zeichnung dargestellt sind. Dabei bilden alle beschriebenen oder dargestellten Merkmale für sich oder in beliebiger Kombination den Gegenstand der Erfindung, unabhängig von ihrer Zusammenfassung in den Patentansprüchen oder deren Rückbeziehung sowie unabhängig von ihrer Formulierung bzw. Darstellung in der Beschreibung bzw. in der Zeichnung. Es zeigen:
  • 1 verschiedene Systemzustände eines Systems;
  • 2 eine Funktionalität eines multitaskingfähigen Computerprogramms zur Steuerung und/oder Regelung eines Systems;
  • 3 ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens gemäß einer bevorzugten Ausführungsform; und
  • 4 ein Steuergerät
  • Beschreibung der Ausführungsbeispiele
  • Die vorliegende Erfindung betrifft ein multitaskingfähiges Computerprogramm zur Steuerung und/oder Regelung eines Systems. Das Computerprogramm ist auf einem Rechengerät, insbesondere auf einem Mikroprozessor, eines Steuergeräts zur Steuerung und/oder Regelung des Systems ablauffähig. Das multitaskingfähige Computerprogramm wird in mehreren unterschiedlichen Zeitrastern abgearbeitet. Zwar wiederholen sich die einzelnen Zeitraster zyklisch, insgesamt betrachtet wird das Computerprogramm aber nicht zyklisch abgearbeitet.
  • Das Computerprogramm ist in mehrere Aufgabenprogramme (sog. Tasks) unterteilt, denen verschiedene Prioritäten zugeordnet sind. Tasks mit sicherheitsrelevanten Aufgaben werden höhere Prioritäten zugeordnet als solchen Tasks, die keine sicherheitsrelevanten Aufgaben haben. Die höher prioren Tasks werden in kürzeren Zeitrastern ausgeführt, d. h. sie werden pro Zeiteinheit häufiger abgearbeitet als die nieder prioren Tasks.
  • Die Unterteilung des Computerprogramms in mehrere Tasks betrifft die softwaretechnische Realisierung des Computerprogramms. Auf der funktionalen Ebene ist das Computerprogramm in mehrere funktional zusammenhängende Einheiten, sog. Funktionalitäten, unterteilt. Eine Funktionalität kann eine oder mehrere Tasks umfassen. Bei einem Computerprogramm zur Steuerung und/oder Regelung eines Fahrdynamiksystems (elektronisches Stabilitätsprogramm, ESP) in einem Kraftfahrzeug sind Funktionalitäten bspw. ein Antiblockiersystem (ABS), durch das ein Blockieren der Räder beim Bremsen verhindert wird, oder ein Fahrzeugregler (FZR), der auf die einzelnen Räder gezielt Bremseingriffe vornimmt, um die Fahrdynamik des Kraftfahrzeugs zu erhalten.
  • Aufgrund der Tatsache, dass bei einem multitaskingfähigen Computerprogramm die Funktionsaufrufe nicht einfach nacheinander erfolgen und somit nicht einfach durch die Reihenfolge der Aufrufe sichergestellt werden kann, dass die Eingangsgrößen einer Funktionalität von einer zuvor ausgeführten Funktionalität bereits ermittelt worden sind, müssen bei multitaskingfähigen Computerprogrammen andere Vorkehrungen getroffen werden, um sicherzustellen, dass den auszuführenden Funktionalitäten die erforderlichen Eingangsgrößen immer richtig vorliegen. So darf bspw. eine Funktionalität, die in einer 5 ms-Task aufgerufen wird und die Eingangsgrößen aus einer 40 ms-Task benötigt, beim ersten Aufruf erst dann ausgeführt werden, wenn die 40 ms-Task bereits berechnet wurde.
  • Ein wichtiger Aspekt der vorliegenden Erfindung ist es, dass jedem der Systemzustände bzw. jedem (zulässigen) Übergang von einem ersten Systemzustand zu einem zweiten Systemzustand Übergangsbedingungen zugeordnet sind, und der Ablauf des Computerprogramms derart gesteuert wird, dass das System erst dann in den zweiten Systemzustand überführt wird, wenn alle dem Übergang in den zweiten Systemzustand zugeordneten Übergangsbedingungen erfüllt sind. Wenn die Übergangsbedingung bspw. darin besteht, dass sämtliche Eingangsgrößen einer den zweiten Systemzustand charakterisierenden Funktionalität zur Verfügung stehen, kann anhand des erfindungsgemäßen Verfahrens sichergestellt werden, dass das Gesamtsystem tatsächlich erst dann von dem ersten Systemzustand in den zweiten Systemzustand überführt wird, wenn alle erforderlichen Eingangsgrößen vorliegen.
  • Die verschiedenen Systemzustände 30 sind in 1 am Beispiel eines Fahrdynamiksystems (ESP) dargestellt. Es sind u. a. die nachfolgenden Systemzustände 30 möglich:
    • – „FullSystem”: Normalbetrieb, volle Funktionsfähigkeit des Fahrdynamiksystems;
    • – „Backup_ABS”: Nur Antiblockiersystem (ABS), kein Fahrzeugregler (FZR) aktiv, eingeschränkte Funktionsfähigkeit;
    • – „Backup_EBD”: Nur elektronische Bremskraftverteilung (Electronic Brake Distribution, EBD) aktiv, eingeschränkte Funktionsfähigkeit;
    • – „FailSafe”: FZR, ABS, EBD inaktiv, keinerlei Funktionsfähigkeit des Systems; und
    • – „XYZ”: ein beliebig anderer Systemzustand.
  • Die Übergänge zwischen den Systemzuständen sind mit dem Bezugszeichen 31 bezeichnet.
  • In 2 ist eine Funktionalität X dargestellt, welche die Eingangsgrößen Ein_i und die Ausgangsgrößen Aus_i aufweist. Zwischen den Eingangsgrößen Ein_i und den Ausgangsgrößen Aus_i ist ein in horizontaler Richtung verschiebbarer Schieber vorgesehen, der drei verschiedene Betriebszustände A, B, C der Funktionalität X repräsentiert. Durch Verschieben des Schiebers kann der Betriebszustand A, B, C der Funktionalität X gewechselt werden.
  • Die verschiedenen Systemzustände 30 des Systems sind dadurch charakterisiert, dass mindestens eine der Funktionalitäten X des Systems einen vorgebbaren Betriebszustand A, B, C aufweist. Aus der Summe der Betriebszustände A, B, C der Funktionalitäten X ergibt sich somit der entsprechende Systemzustand 30 des Gesamtsystems. Jeder Funktionalität X des Computerprogramms ist eine Betriebszustandsvariable zugeordnet, die verschiedene Betriebszustandswerte, die jeweils einem bestimmten Betriebszustand A, B, C der Funktionalität X entsprechen, annehmen kann.
  • Das Umschalten einer Funktionalität X in einen anderen Betriebszustand A, B, C kann bspw. erforderlich sein, wenn nicht alle zur Ausführung der Funktionalität X erforderlichen Eingangsgrößen Ein_i vorliegen. Zunächst kann versucht werden, den Ablauf dieser Funktionalität X so weit hinauszuzögern, bis alle erforderlichen Eingangsgrößen Ein_i vorliegen, d. h. bis andere Funktionalitäten X, in denen die erforderlichen Eingangsgrößen Ein_i ermittelt wurden, ausgeführt worden sind. Es sind jedoch Situationen denkbar, in denen ein Hinauszögern der Ausführung einer Funktionalität X, bis alle erforderlichen Eingangsgrößen Ein_i vorliegen, nicht möglich ist. In einem solchen Fall können die fehlenden Eingangsgrößen Ein_i auch anhand anderer Größen modelliert oder mittels eines alternativen Algorithmus berechnet werden. Es ist auch denkbar, statt der fehlenden Eingangsgröße Ein_i eine andere Größe, die bereits zur Verfügung steht, zur Ausführung der Funktionalität X heranzuziehen. Alle diese Maßnahmen, die ergriffen werden können, falls eine erforderliche Eingangsgröße Ein_i nicht zur Verfügung steht, führen letzten Endes jedoch mehr oder weniger zu einer Einschränkung der Funktionsfähigkeit der Funktionalität, was durch einen Wechsel des Betriebszustandes A, B, C ausgedrückt wird.
  • In 3 wird ein Verfahren zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms beispielhaft anhand eines Fahrdynamiksystems in einem Kraftfahrzeug beschrieben. Dieses Verfahren und insbesondere die vorliegende Erfindung kann jedoch für beliebige Systeme eingesetzt werden, die durch ein multitaskingfähiges Computerprogramm gesteuert und/oder geregelt werden. Eine weitere Einsatzmöglichkeit, die hier ausdrücklich angesprochen wird, ist der Einsatz des erfindungsgemäßen Verfahrens zur Steuerung des Ablaufs eines Computerprogramms zur Steuerung und/oder Regelung eines Alarmsystems, eines Heizungs- und Klimatisierungssystems und/oder eines Zugangskontrollsystems in einem Gebäude, also an den Einsatz des erfindungsgemäßen Verfahrens im Bereich des Gebäudemanagements.
  • In einem Funktionsblock 1 wird die sog. Plattform-Software (PSW) überwacht. Unter Plattform-Software wird der hardwarenahe Teil des Computerprogramms zur Steuerung und/oder Regelung des Fahrdynamiksystems verstanden. In einem Funktionsblock 2 wird die Anwender-Software (ASW) überwacht. Unter Anwender-Software wird bei einem Fahrdynamiksystem bspw. die ABS-Regelung oder der Fahrzeugregler (FZR) verstanden. Die Funktionsblöcke 1 und 2 dienen zur Erkennung von Fehlern 11, 12 in den entsprechenden Softwareteilen. Ein möglicher Fehler 11, 12, der in den Funktionsblöcken 1 und 2 erkannt werden könnte, wäre bspw. ein Sensorfehler, der es verhindert, dass eine bestimmte Eingangsgröße Ein_i, die zur Berechnung einer Funktionalität X erforderlich ist, zur Verfügung steht.
  • Die in den Funktionsblöcken 1 und 2 erkannten Fehler 11, 12 werden an einen Funktionsblock 3 übermittelt, der als ein Makro realisiert ist. In dem Funktionsblock 3 wird anhand der in den Funktionsblöcken 1 und 2 ermittelten Fehler 11, 12 ein entsprechender Fehlerzustand 13 des Systems ermittelt. Dieser Fehlerzustand 13 wird von dem Funktionsblock 3 an einen weiteren Funktionsblock 4 übertragen, der als Failure Processing System (FPS) bezeichnet wird. In dem Funktionsblock 4 wird unter Berücksichtigung der ermittelten Fehlerzustände 13 eine entsprechende Strategie zum Übergang in den zweiten Systemzustand, genauer gesagt, eine Strategie zum gezielten Wechseln der Betriebszustände A, B, C der den zweiten Systemzustand charakterisierenden Funktionalitäten, ermittelt. Die in dem Funktionsblock 4 ermittelte Strategie 14 zum Umschalten der Betriebszustände A, B, C der Funktionalitäten X zum Übergang in den zweiten Systemzustand, wird an einen Funktionsblock 5 übermittelt. Genauer gesagt, werden von dem Funktionsblock 4 an den Funktionsblock 5 gemäß der ermittelten Strategie 14 nacheinander verschiedene Soll-Betriebszustände derjenigen Funktionalitäten übermittelt, die den zweiten Systemzustand charakterisieren. Die ermittelte Strategie 14 repräsentiert also einem Soll-Systemzustand, in dem vorliegenden Ausführungsbeispiel den zweiten Systemzustand.
  • Die in dem Funktionsblock 3 ermittelten Fehlerzustände 13 werden außerdem an einen Funktionsblock 6 übertragen, in welchem der Status der Eingangsgrößen Ein_i der Funktionalitäten X durch Setzen eines sog. Invalid Bit gekennzeichnet wird. Für jede Eingangsgröße Ein_i der Funktionalitäten X des Computerprogramms ist ein eigenes Statussignal in Form des Invalid Bit vorgesehen. Wenn also in den Funktionsblöcken 1 oder 2 ein Sensorfehler 11, 12 detektiert wurde, werden diejenigen Eingangsgrößen Ein_i, die von dem Sensorfehler 11, 12 beeinträchtigt werden, durch Setzen oder Löschen des Invalid Bit entsprechend gekennzeichnet. Das Statussignal 15 wird ebenfalls an den Funktionsblock 5 übertragen.
  • In einem Funktionsblock 7 wird der Ist-Systemzustand 16 ermittelt und ebenfalls an den Funktionsblock 5 übertragen. Am Beispiel eines Fahrdynamiksystems umfasst der Ist-Systemzustand 16 den Zustand des Fahrdynamiksystems an sich, aber auch den Fahrzustand des Kraftfahrzeugs. In einem Funktionsblock 8 werden die Abhängigkeiten 17 der Betriebszustände A, B, C bzw. der Funktionalitäten X untereinander ermittelt. Die ermittelten Abhängigkeiten 17 werden ebenfalls an den Funktionsblock 5 übermittelt.
  • In dem Funktionsblock 5 werden Soll-Betriebszustände 18 in Abhängigkeit der von den Funktionsblöcken 4, 6, 7, 8 erhaltenen Größen 14, 15, 16, 17 aufbereitet. Insbesondere wird in dem Funktionsblock 5 überprüft, ob die Betriebszustandsvariablen der Funktionalitäten X die für den zweiten Systemzustand geforderten Betriebszustandswerte aufweisen, d. h. ob sich die den zweiten Systemzustand charakterisierenden Funktionalitäten in den geforderten Betriebszuständen befinden. Die Funktionsblöcke 4 bis 8 sind in einem übergeordneten Funktionsblock 9 zusammengefasst, der als Controller Release System (CRS) bezeichnet wird.
  • Falls in dem Funktionsblock 5 festgestellt wird, dass die Betriebszustandsvariablen die geforderten Betriebszustandswerte aufweisen, d. h. sich die Funktionalitäten, welche den zweiten Systemzustand charakterisieren, in den geforderten Betriebszuständen befinden, gibt der Funktionsblock 5 einen oder mehrere Soll-Betriebszustände 18 vor und übermittelt diese an einen Funktionsblock 10. In dem Funktionsblock 10 ist die Anwendersoftware (ASW) und eine Sicherheitssoftware (SIS) sowie eine Offsetaufbereitung enthalten. Die ASW entspricht dem Reglerteil der Software (z. B. zur ABS-, ASR- oder Motormomentenregler). Die entsprechenden Funktionalitäten in dem Funktionsblock 10 werden dann in den Soll-Betriebszustand 18 geschaltet. Der Ist-Betriebszustand 19 wird von dem Funktionsblock 10 an die Funktionsblöcke 7 und 8 übermittelt. Dort werden sie zur Ermittlung des Ist-Systemzustandes in Funktionsblock 7 und zur Ermittlung der Abhängigkeiten der Funktionalitäten X untereinander in Funktionsblock 8 herangezogen.
  • Beim Übergang von einem Betriebszustand A, B, C in einen anderen können prinzipiell zwei unterschiedliche Arten von Übergängen unterschieden werden:
    • – Der Übergang von einem Betriebszustand niedriger Priorität zu einem Betriebszustand höherer Priorität wie bspw. der Übergang von ABS_Vollsystem zu ABS_Off. Dieser Übergang erfolgt unmittelbar, damit es zu keinen weiteren eventuell fehlerhaften Ansteuerungen kommen kann.
    • – Der Übergang von einem Betriebszustand höherer Priorität zu einem Betriebszustand niedrigerer Priorität, wie bspw. von ABS_Off zu ABS_Vollsystem. In diesem Fall wird der Übergang von dem Soll- zu dem Ist-Betriebszustand durch die Funktionalität selbst bestimmt. Dabei muss der Ist-Betriebszustand solange voll funktionsfähig bleiben, bis der Soll-Betriebszustand erreicht ist. Während der Umschaltphase von dem Ist-Betriebszustand in den Soll-Betriebszustand werden beide Betriebszustände parallel berechnet. Somit bestimmt die Funktionalität selbst, wann der Übergang erfolgen soll. Zu beachten ist, dass während der Übergangsphase akustische oder optische Warnhinweise weiterhin ausgegeben werden müssen. Seitens des FPS (Failure Processing System) in Funktionsblock 4 werden keine Warnhinweise mehr ausgegeben, da durch einen Reset der in den Funktionsblöcken 1 oder 2 erkannte Fehler 11, 12 bereits zurückgesetzt wurde.
  • In 4 ist ein Steuergerät in seiner Gesamtheit mit dem Bezugszeichen 20 bezeichnet. Das Steuergerät 20 dient zur Steuerung und/oder Regelung eines Systems, das verschiedene mögliche Systemzustände einnehmen kann, insbesondere eines Fahrdynamiksystems in einem Kraftfahrzeug. Das Steuergerät 20 umfasst ein Rechengerät 21, das als ein Mikroprozessor ausgebildet ist. Auf dem Rechengerät 21 ist ein in mehrere funktional zusammenhängende Funktionalitäten unterteiltes multitaskingfähiges Computerprogramm 22 ablauffähig. Das Computerprogramm 22 dient zur Steuerung und/oder Regelung des Systems nach dem erfindungsgemäßen Verfahren, wenn es auf dem Rechengerät 21 abläuft. Des Weiteren sind in dem Steuergerät 20 Mittel 23 zur Koordination des Ablaufs des Computerprogramms 22 vorgesehen. Die Mittel 23 sind als ein Steuerprogramm ausgebildet, das ebenfalls auf dem Rechengerät 21 ablauffähig ist. Das Computerprogramm 22 und das Steuerprogramm 23 sind auf einem Speicherelement 24 abgespeichert, das bspw. als ein Flash-Memory ausgebildet ist. Zur Abarbeitung des Computerprogramms 22 und des Steuerprogramms 23 werden diese entweder als Ganzes oder abschnittsweise über eine Datenverbindung 25 an das Rechengerät 21 übermittelt. Ebenso können in der Gegenrichtung über die Datenverbindung 25 Ergebnisse von Berechnungen, die in dem Rechengerät 21 ausgeführt wurden, oder andere Daten an das Speicherelement 24 übermittelt und dort abgespeichert werden. Das Steuerprogramm 23 dient zur Ausführung des erfindungsgemäßen Verfahrens, wenn es auf dem Rechengerät 21 ausgeführt wird.

Claims (4)

  1. Verfahren zur Steuerung und/oder Regelung eines Systems, das verschiedene mögliche Systemzustände (30) einnehmen kann, mittels eines multitaskingfähigen Computerprogramms (22) auf einem Rechengerät (21) eines Steuergeräts (20), umfassend die nachfolgenden vor dem eigentlichen Ablauf des Computerprogramms (22) auszuführenden Verfahrensschritte: – Unterteilen des Computerprogramms (22) in mehrere funktional zusammenhängende Funktionalitäten (X); – Definition von möglichen Betriebszuständen (A, B, C) für die Funktionalitäten (X); – Definition der möglichen Systemzustände (30) des Systems, indem den Funktionalitäten (X) für jeden Systemzustand (30) vorgebbare Betriebszustände (A, B, C) zugeordnet werden; – Ermitteln von Abhängigkeit der Funktionalitäten (X) untereinander, wobei eine erste Funktionalität von einer zweiten Funktionalität abhängig ist, wenn mindestens eine Eingangsgröße (Ein_i) der ersten Funktionalität in der zweiten Funktionalität ermittelt wird, dadurch gekennzeichnet, dass das System in einem ersten Systemzustand betrieben wird und während der Laufzeit des Computerprogramms (22): – Fehler (11, 12) in dem System erkannt werden; – anhand der Fehler (11, 12) ein Fehlerzustand (13) des Systems ermittelt wird; – in Abhängigkeit des Fehlerzustands (13) ein zweiter Systemzustand und eine Strategie (14) zum Übergang in den zweiten Systemzustand ermittelt wird; – überprüft wird, ob die den zweiten Systemzustand charakterisierenden Funktionalitäten die für den zweiten Systemzustand geforderten Betriebszustände (A, B, C) aufweisen und – in den zweiten Systemzustand übergegangen wird, wenn die den zweiten Systemzustand charakterisierenden Funktionalitäten die für den zweiten Systemzustand geforderten Betriebszustände (A, B, C) aufweisen.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Fehler (11, 12) zur Laufzeit nicht verfügbare Eingangsgrößen (Ein_i) umfassen und in dem zweiten Systemzustand nicht verfügbare Eingangsgrößen – anhand anderer Größen modelliert, – mittels alternativer Algorithmen berechnet, oder – durch andere verfügbare Größen ersetzt werden.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein für den zweiten Systemzustand geforderter Betriebszustand (A, B, C) durch eine Betriebszustandsvariable definiert wird, die verschiedene Betriebszustandswerte annehmen kann.
  4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass zur Berücksichtigung der ermittelten Abhängigkeiten zwischen den Funktionalitäten (X) die Abarbeitung der einen bestimmten Systemzustand charakterisierenden Funktionalitäten (X) derart zeitlich gestaffelt wird, dass die zweite Funktionalität zur Ermittlung der mindestens einen Eingangsgröße (Ein_i) für die erste Funktionalität vor der ersten Funktionalität abgearbeitet wird.
DE10229676A 2002-06-27 2002-06-27 Verfahren zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms Expired - Lifetime DE10229676B4 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE10229676A DE10229676B4 (de) 2002-06-27 2002-06-27 Verfahren zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms
US10/600,895 US7729785B2 (en) 2002-06-27 2003-06-20 Method and controller for program control of a computer program having multitasking capability

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10229676A DE10229676B4 (de) 2002-06-27 2002-06-27 Verfahren zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms

Publications (2)

Publication Number Publication Date
DE10229676A1 DE10229676A1 (de) 2004-01-29
DE10229676B4 true DE10229676B4 (de) 2013-05-29

Family

ID=29796092

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10229676A Expired - Lifetime DE10229676B4 (de) 2002-06-27 2002-06-27 Verfahren zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms

Country Status (2)

Country Link
US (1) US7729785B2 (de)
DE (1) DE10229676B4 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005032056A1 (de) * 2004-07-22 2006-05-11 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH Fahrzeugführungssystem mit zentralem Steuergerät für sämtliche Fahrzeugführungsfunktionen
US7664841B2 (en) * 2005-12-07 2010-02-16 International Business Machines Corporation Selective activation of TCP/IP link and traffic
US9086688B2 (en) * 2013-07-09 2015-07-21 Fisher-Rosemount Systems, Inc. State machine function block with user-definable actions on a transition between states

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3872421T2 (de) * 1987-04-08 1992-12-03 Hitachi Ltd Steuersystem fuer kategorisierte motorzustaende.
DE19500957A1 (de) * 1994-07-19 1996-01-25 Bosch Gmbh Robert Verfahren zur Steuerung von technischen Vorgängen oder Prozessen
EP0990966A2 (de) * 1998-10-04 2000-04-05 Husky Injection Molding Systems Ltd. Integrierte Steuerungsstation für eine Spritzgussanlage
DE19924461A1 (de) * 1999-05-28 2000-11-30 Heidenhain Gmbh Dr Johannes Verfahren zum synchronisierten Hochlauf einer Steuerung
US6219590B1 (en) * 1998-04-03 2001-04-17 Johnson Controls Technology Co. State machine controller for operating variable air volume terminal units of an environmental control system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS57181938A (en) * 1981-04-30 1982-11-09 Hitachi Ltd Engine control device
US5086385A (en) * 1989-01-31 1992-02-04 Custom Command Systems Expandable home automation system
US5646843A (en) * 1990-02-05 1997-07-08 Caterpillar Inc. Apparatus and method for surface based vehicle control system
US6745089B2 (en) * 2000-02-01 2004-06-01 California Institute Of Technology Adaptable state based control system
US7085692B2 (en) * 2001-10-11 2006-08-01 Xerox Corporation Learning systems and methods for market-based control of smart matter

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3872421T2 (de) * 1987-04-08 1992-12-03 Hitachi Ltd Steuersystem fuer kategorisierte motorzustaende.
DE19500957A1 (de) * 1994-07-19 1996-01-25 Bosch Gmbh Robert Verfahren zur Steuerung von technischen Vorgängen oder Prozessen
US6219590B1 (en) * 1998-04-03 2001-04-17 Johnson Controls Technology Co. State machine controller for operating variable air volume terminal units of an environmental control system
EP0990966A2 (de) * 1998-10-04 2000-04-05 Husky Injection Molding Systems Ltd. Integrierte Steuerungsstation für eine Spritzgussanlage
DE19924461A1 (de) * 1999-05-28 2000-11-30 Heidenhain Gmbh Dr Johannes Verfahren zum synchronisierten Hochlauf einer Steuerung

Also Published As

Publication number Publication date
DE10229676A1 (de) 2004-01-29
US20040059772A1 (en) 2004-03-25
US7729785B2 (en) 2010-06-01

Similar Documents

Publication Publication Date Title
DE3518105C2 (de)
DE4334260C2 (de) Steuervorrichtung für ein Fahrzeug mit einer Antiblockier-Bremseinrichtung und einer Servolenkeinrichtung
DE10223880B4 (de) Verfahren zur gegenseitigen Überwachung von Komponenten eines dezentral verteilten Rechnersystems
EP2972601B1 (de) Verfahren zur risikoabgrenzung von fehlern in einem redundanten sicherheitsrelevanten steuerungssystem für ein kraftfahrzeug
EP2715462B1 (de) Verfahren zum betreiben eines sicherheitssteuergeräts
EP2099667B2 (de) Verfahren zum sicherstellen oder aufrechterhalten der funktion eines komplexen sicherheitskritischen gesamtsystems
EP2422244B1 (de) Sicherheitssteuerung und verfahren zum steuern einer automatisierten anlage
EP0976012A1 (de) Mikroprozessorsystem für sicherheitskritische regelungen
DE19509150C2 (de) Verfahren zum Steuern und Regeln von Fahrzeug-Bremsanlagen sowie Fahrzeug-Bremsanlage
DE102015110958A1 (de) Ausfallverwaltung in einem Fahrzeug
DE102011005844A1 (de) Automatische Steuerung eines Fahrzeugs
EP1521697B1 (de) Verfahren zum sicherstellen oder aufrechterhalten der funktion eines komplexen sicherheitskritischen gesamtsystems
EP2732347B1 (de) Verfahren und system zur dynamischen verteilung von programmfunktionen in verteilten steuerungssystemen
DE69916772T2 (de) Steuervorrichtung eine automatischen Maschine
WO2017080793A2 (de) Verfahren zum betrieb eines mehrkernprozessors
DE10229676B4 (de) Verfahren zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms
DE2722435A1 (de) Sicherheitsschaltung bei blockiergeschuetzten und lastabhaengigen fahrzeugbremsanlagen
DE10229686A1 (de) Verfahren und Steuergerät zur Steuerung des Ablaufs eines multitaskingfähigen Computerprogramms
DE102007046706A1 (de) Steuervorrichtung für Fahrzeuge
DE102017218274A1 (de) Lenkungssteuersystem für ein Lenksystem eines Kraftfahrzeuges sowie Verfahren zum Betreiben eines Lenkungssteuersystems
DE102004058996A1 (de) Verfahren und Fahrfunktionssystem zum Überführen von sicherheitsrelevanten Fahrfunktionen eines Fahrzeugs in den sicheren Zustand
DE102012212680A1 (de) Verfahren und System zur fehlertoleranten Steuerung von Stellgliedern für eine begrenzte Zeit auf der Grundlage von vorberechneten Werten
DE102020200414A1 (de) Verfahren und Vorrichtung zum Rekonfigurieren eines automatisiert fahrenden Fahrzeugs in einem Fehlerfall
DE102016112332B4 (de) Verfahren und vorrichtung zum überwachen eines reglerblocks zum ansteuern eines stellantriebs, insbesondere eines stellantriebs eines lenksystems
DE102017212560A1 (de) Verfahren zum ausfallsicheren Durchführen einer sicherheitsgerichteten Funktion

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8125 Change of the main classification

Ipc: G05B 19/048 AFI20051017BHDE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R082 Change of representative
R020 Patent grant now final

Effective date: 20130830

R084 Declaration of willingness to licence
R071 Expiry of right