-
HINTERGRUND DER ERFINDUNG
-
Die vorliegenden Lehren beziehen sich auf eine Controllerfunktionalität.
-
Ausfallfehler bei Controllern erfordern schnelle Reaktionen, um den Fehler zu korrigieren, um Operationen, insbesondere kritische und Sicherheitsoperationen, fortzusetzen. Ein Frame-Überlauf tritt auf, wenn die Verarbeitungsverzögerung eines Signals seine Abtastperiode an dem Controller überschreitet, und wird als Controllerfehler identifiziert. Unter solchen Bedingungen versucht das System entweder ein Abschalten, um ein unerwünschtes Verhalten, das mit dem verspäteten Steuerbefehl in Verbindung steht, zu verhindern, oder setzt es den Controller in der Hoffnung einer Erholung von dem Fehler zurück.
-
In einem Abschaltezustand wird der Controller abgeschaltet und ist das Merkmal nicht mehr verfügbar, während der Fehler auftritt; wenn das Merkmal jedoch eine kritische Operation umfasst, wäre ein Abschaltezustand keine bevorzugte Option, da das Merkmal für den fortgesetzten Betrieb des Fahrzeugs erforderlich ist.
-
In einem Rücksetzzustand muss das System warten, bis sich der Controller selbst zurücksetzt. Bei einem Rücksetzzustand gibt es eine Zeitdauer, während der die Controllerfunktionalität nicht verfügbar ist. Dass die Funktionalität des Controllers während einer Zeitdauer nicht verfügbar ist, ist in Bezug auf kritische/Sicherheitsmerkmale nicht erwünscht, da der Controller selbst in einem Ausfallzustand ausfallbetriebsfähig sein sollte. Daher wird ein Verfahren benötigt, um die Funktionalität während eines Frame-Überlaufs fortzusetzen, um den Betrieb fortzusetzen.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Ein Vorteil einer Ausführungsform ist ein ununterbrochener Betrieb von Merkmalen, die während eines Frame-Überlaufzustands durch einen Controller gesteuert werden. Die Technik identifiziert den Task, der den Frame-Überlauf am meisten betrifft, aus der Vielzahl von Tasks und teilt Funktionen innerhalb des Tasks anderen Tasks neu zu, die während des Frame-Überlaufzustands eine langsamere Zykluszeit aufweisen als der Task, der den Überlaufzustand verursacht. Als Ergebnis wird dem Task, der den Frame-Überlaufzustand verursacht, ermöglicht, sich selbst zu korrigieren, indem Funktionen innerhalb seines erwarteten Arbeitszyklus abgeschlossen werden, da einige seiner jeweiligen Funktionen temporär in anderen Tasks ausgeführt werden, die mit langsameren Raten laufen, was ermöglicht, dass dieser jeweilige Task seinen erwarteten Arbeitszyklus aufrechterhält. Die Tasks teilen weiterhin Funktionen neu zu, bis der Frame-Überlaufzustand korrigiert ist. Nach der Korrektur wird jeder Task in seiner ursprünglichen Konfiguration wieder hergestellt.
-
Eine Ausführungsform zieht ein Verfahren zum adaptiven Rekonfigurieren von Controllerfunktionen während eines Frame-Überlaufs in Betracht. Es wird ein Frame-Überlaufzustand detektiert. Es wird ein jeweiliger Task aus einer Vielzahl von Tasks als größter zum Frame-Überlauf Beitragender identifiziert. Es wird ein Verminderungsmodus, der dem identifizierten Task zugehörig ist, identifiziert, um den Frame-Überlauf zu korrigieren. Funktionen innerhalb des identifizierten Tasks werden einem zweiten Task neu zugeteilt, bis der Frame-Überlaufzustand korrigiert ist. Die neu zugeteilten Funktionen werden innerhalb des jeweiligen Tasks als Funktion des identifizierten Modus identifiziert.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist ein beispielhaftes allgemeines Blockdiagramm einer Steuersystemarchitektur.
-
2 ist ein Flussdiagramm für ein Verfahren einer Technik eines Frame-Überlaufs und einer Detektion.
-
3 ein beispielhaftes Blockdiagramm zur Neuzuteilung einer Funktion innerhalb Tasks.
-
DETAILLIERTE BESCHREIBUNG
-
1 veranschaulicht ein allgemeines Blockdiagramm eines beispielhaften Steuersystems. Das System umfasst einen Controller 12, der Datensignale von einer Vielzahl von Sensoren 14 empfängt. Basierend auf Datensignalen, die von der Vielzahl von Sensoren 14 empfangen werden, gibt der Controller 12 Steuersignale an Aktoren 16 aus. Die Aktoren 16 modifizieren danach die Fahrzeugfunktionalität gemäß dem Controller 12 übertragenen Steuersignal.
-
Ein Frame-Überlauf ist ein Zustand, wenn der Controller 12 erfährt, dass die Verarbeitungszeit länger als die Datennachladeperiode ist, und er die eingehenden Daten nicht mit der Rate verarbeiten kann, mit der die Daten dem Controller 12 geliefert werden. Dies kann auftreten, wenn Betriebszustände des Fahrzeugs (z. B. die Motordrehzahl) zu Steuerungsberechnungserhöhungen führen, wodurch die Anzahl von durch den Controller angeforderten Lesevorgängen erhöht wird, was andere Berechnungen mit niedrigerer Priorität, die eine längere Verarbeitungsverzögerung erfahren, nach außerhalb schieben kann, wenn die Verarbeitungsfähigkeit des Controllers 12 erreicht ist. Der Zustand kann auch auftreten, wenn sich die Temperatur eines Prozessors in dem Controller 12 erwärmt und sich die Verarbeitungsfähigkeiten verringern. Bei beiden Zuständen schaltet sich der Controller 12 entweder ab, setzt sich selbst zurück oder unterbricht, wobei Funktionen innerhalb eines jeweiligen Tasks fallen gelassen werden. Bei solchen Zuständen geht die Funktionalität des Merkmals entweder dauerhaft oder temporär verloren. Wenn beispielsweise ein Frame-Überlauf auftritt, bei dem die Funktion innerhalb des Tasks eine Beschleunigung eines Fahrzeugs betrifft, kann dann eine Beschleunigungsanforderung durch den Fahrer ignoriert werden, wenn die Funktion eine ist, die durch den Task aufgrund des Frame-Überlaufs fallen gelassen wird. Dies kann zu einer Kundenunzufriedenheit oder zu einem Bringen des Fahrzeugs zum Kundendienst führen, da der Fahrer annimmt, dass das Fahrzeug nicht korrekt arbeitet.
-
2 veranschaulicht ein Flussdiagramm für ein Verfahren zum Detektieren eines Frame-Überlaufs und Korrigieren des Frame-Überlaufs. In Schritt 20 werden eingehende Daten von Sensoren und ähnlichen Einrichtungen durch den Controller empfangen.
-
In Schritt 21 misst der Controller die Task-Reaktionszeit und ermittelt, ob ein Frame-Überlauf in dem Controller auftritt. Eine Task-Reaktionszeit ist als die Zeitdauer zwischen dem Start des Tasks und dem Ende des Tasks einschließlich aller Störungen, wie beispielsweise Unterbrechungen, Scheduler-Verriegelung, Bevorrechtigung durch andere Tasks mit höherer Priorität etc., definiert. Ein Frame-Überlauf wird durch Vergleichen der Task-Reaktionszeit und der Dauer des jeweiligen Tasks ermittelt. Eine Task-Ausführungszeit ist als die Zeitdauer definiert, in der der Task seinen Betrieb ohne Fehler und Störungen abschließt. Jedem Task wird eine vorbestimmte erwartete Ausführungszeit zugeordnet, um Arbeitsbelastungserhöhungen zu berechnen. Bei einer normalen Ausführung kann die Task-Reaktionszeit variieren, sollte jedoch nicht die Task-Dauer überschreiten.
-
Um lästige Zählwerte eines Überlaufs zu verringern, wenn die tatsächliche Reaktionszeit die Task-Dauer nur um eine kleine Anzahl von Malen überschreitet, werden Schwellenwerte verwendet. Es kann ein Schwellenwert verwendet werden, um einige Messungsstörungen zu filtern. Bei der Verwendung eines Schwellenwerts wird jedem Task eine vorbestimmte Anzahl von zulässigen Frame-Überläufen zugeordnet. Der Schwellenwert ist vorzugsweise eine ganze Zahl, die ausdrückt, wie oft ein Frame überläuft, wonach der Frame-Überlauf korrigiert werden muss. Alternativ kann eine nicht ganzzahlige Zahl verwendet werden. Jedes Mal, wenn ein Frame-Überlauf detektiert wird, wird ein Zählwert für diesen Task als Frame-Überlauf erhöht. Für einige Steuerfunktionen wird eine geringere Menge an Frame-Überläufen aufgrund von Überabtastung zugelassen; wenn allerdings der Schwellenwert erreicht wird, muss die Arbeitsbelastung angepasst werden, um eine stabile Steuerung aufrechtzuerhalten.
-
In Schritt 22 wird der Überlaufzählwert basierend darauf aktualisiert, ob die Bedingungen in Schritt 21 zur Aktualisierung des Überlaufzählwerts erfüllt sind.
-
In Schritt 23 wird ermittelt, ob der Überlaufzählwert größer als ein Zählwert-Schwellenwert ist. Wenn der Gesamtzählwert größer als der Zählwert-Schwellenwert ist, fährt die Routine mit Schritt 24 fort. Wenn ermittelt wird, dass der Überlaufzählwert-Schwellenwert nicht überschritten wird, springt die Routine zu Schritt 20 zurück, in dem der Controller die Überwachung hinsichtlich eines Frame-Überlaufs fortsetzt.
-
In Schritt
24 wird die Arbeitsbelastungswirksamkeit für jeden Task ermittelt, um unter allen Tasks den Task zu identifizieren, der eine größte Erhöhung der Ausführungszeit einführt. Die Anweisung umfasst, unter allen Tasks den Task zu identifizieren, der die bedeutendste Erhöhung seiner Ausführungszeit verursacht, und einige seiner Funktionen anderen Tasks neu zuzuteilen, die mit niedrigeren Raten laufen, bis der Frame-Überlauf verschwindet. Um dies zu erreichen, wird für jeden Task ein Arbeitsbelastungsfaktor ermittelt. Der Arbeitsbelastungsfaktor wird durch die folgende Formel ermittelt:
wobei current_execution_time
i die tatsächliche Ausführungszeit für Task (i) ist und expected_execution_time die für Task (i) erwartete vorbestimmte Ausführung ist.
-
Für jeden jeweiligen Task wird ein jeweiliger Arbeitsbelastungsfaktor in Form eines Prozentsatzes identifiziert. Einem Task wird eine Kategorie zugeordnet, die das Niveau des Arbeitsbelastungsfaktors dieses Tasks darstellt. Zum Beispiel ist für den berechneten Arbeitsbelastungsfaktor von Task Tsk1, der in einen Bereich von 0–2% fällt, die zugeordnete Kategorie ”C1_Tsk1”; wenn der Arbeitsbelastungsfaktor innerhalb eines Bereichs von 2%–7% liegt, ist die Kategorie ”C2_Tsk1”. Ähnlich ist, wenn der berechnete Arbeitsbelastungsfaktor für Task Tsk2 innerhalb eines Bereichs von 0%–6% liegt, die zugeordnete Kategorie ”C1_Tsk2”. Es sei angemerkt, dass die Bereiche, wie sie hierin beispielhaft beschrieben sind, und sowohl die Bereiche als auch die zugeordneten Kategorien unterschiedlich konfiguriert sein können.
-
Nachdem jeder der Arbeitsbelastungsfaktoren berechnet und jedem eine Kategorie zugeordnet wurde, wird eine Tabelle erzeugt, die die jedem Arbeitsbelastungsfaktor für jeden Task zugeordnete Kategorie identifiziert. Die Tabelle bringt auch einen Controller-Laufzeitverminderungsmodus für jede Kategorie in Verbindung. Der Verminderungsmodus gibt an, wie die Funktionen auf verschiedene Tasks verteilt werden. Die Tabelle ist veranschaulicht wie folgt:
| Kategorie | T_H | Modus |
| C1_Tsk1 | Tsk1 | M11 |
| C1_Tsk2 | Tsk2 | M12 |
| C2_Tsk1 | Tsk1 | M21 |
| ... | ... | ... |
Tabelle 1
-
In Schritt 25 wird der Task mit dem höchsten Arbeitsbelastungsfaktor identifiziert.
-
Der Arbeitsbelastungsfaktor wird dann verwendet, um die Kategorie zu ermitteln.
-
Dies identifiziert eindeutig einen einzelnen Eintrag in Tabelle 1, was zu einem Laufen des Zielverminderungsmodus für den Controller führt. Wie es in Tabelle 1 gezeigt ist, wird, wenn eine Arbeitsbelastungserhöhung von 6%, die Task Tsk1 zugehörig ist, als die größte Ausführungszeitänderung aufweisend, was zu dem Frame-Überlauf führt, identifiziert wird, die Kategorie dann als C2_Tsk1 ermittelt, und daher wird der Modus M21 als der Verminderungsmodus des Controllers identifiziert.
-
In Schritt 26 werden basierend auf dem identifizierten Modus zugehörige Tasks identifiziert, die jeweilige Funktionen ausführen, die auch als Runnables bekannt sind. Basierend auf den zugehörigen Tasks, die für den jeweiligen Modus ausgeführt werden, werden Funktionen neu zugeteilt, indem Funktionen in jeweiligen Tasks ausgeführt werden und verhindert wird, dass Funktionen in anderen Tasks ausgeführt werden. 3 veranschaulicht ein beispielhaftes Blockdiagramm zur Neuzuteilung von Funktionen, um Frame-Überläufe abzubauen. Kasten 50 stellt eine beispielhafte Tabelle einer erwarteten Arbeitsbelastung dar, die die erwarteten Arbeitsbelastungen identifiziert. Kasten 51 stellt eine beispielhafte Tabelle einer erwarteten Arbeitsbelastung dar, die die aktuellen Arbeitsbelastungen identifiziert.
-
Ein Frame-Überlaufdetektionsmodul 52 überprüft Daten von sowohl der Tabelle 50 einer erwarteten Arbeitsbelastung als auch der Tabelle 51 einer aktuellen Arbeitsbelastung und identifiziert den jeweiligen Task, der den Frame-Überlauf verursacht wie oben beschrieben.
-
Ein Modusauswahlmodul 53 empfängt einen Eingang von der Tabelle 50 einer erwarteten Arbeitsbelastung, der Tabelle 51 einer aktuellen Arbeitsbelastung, einer Modusauswahltabelle 54 und dem Frame-Überlaufdetektionsmodul 52 und ermittelt, in welchen Modus sich die Routine begeben sollte, um den Frame-Überlauf zu korrigieren.
-
In Kasten 55 wird der ausgewählte Modus identifiziert und wird der jeweilige Ziel-Task oder werden die jeweiligen Ziel-Tasks 56 zur Ausführung ausgewählt, um Funktionen anderen Tasks neu zuzuteilen, um den Frame-Überlauf abzubauen. Der identifizierte Ziel-Task weist eine langsamere Zykluszeit (Ausführungszeit) auf, was zum Empfangen und Verarbeiten der Daten mehr Zeit bereitstellt als der ursprüngliche Task. Wenn beispielsweise der Task, der den Frame-Überlauf verursacht, alle 5 ms Daten liest und verarbeitet, kann der Ziel-Task alle 10 ms Daten lesen und verarbeiten. Als Ergebnis werden nur alle 10 ms Daten erhalten, was nicht nur die Menge an Daten, die durch den Prozessor über eine Zeitdauer empfangen werden, reduziert, sondern dem Prozessor mehr Zeit gewährt, um Daten zu verarbeiten, die Daten von neu zugeteilten Funktionen umfassen.
-
Basierend auf dem ausgewählten Modus wird oder werden ein oder mehrere Tasks
56 ausgeführt. Die Tasks umfassen konditionale Operanden, die ermitteln, welche Funktionen ausgeführt werden sollten und bei welchen Funktionen die Ausführung mit dem Task verhindert werden sollte. Nachstehend ist ein beispielhafter Task veranschaulicht, der den Frame-Überlauf verursacht:
-
Nachfolgendes umfasst ein Beispiel des Ziel-Tasks, der verwendet wird, um den Frame-Überlauf zu reduzieren:
-
Bei den obigen Beispielen verursacht Task Tsk1 den Frame-Überlauf, was angibt, dass der aktuelle Prozessor die Menge an Daten, die unter dem aktuellen Schema verarbeitet wird, nicht handhaben kann, und wird Modus M11 durch das Modusauswahlmodul als der Modus identifiziert, der verwendet wird, um den Frame-Überlauf zu korrigieren. Wie es bei dem ursprünglichen Task Tsk2 gezeigt ist, werden die Funktionen R15 und R16 immer ausgeführt, es sei denn, Modus M11 wird aktiviert. Daher wird, wenn ein durch Task Tsk1 verursachter Frame-Überlauf auftritt, Modus M11 aktiviert und müssen bestimmte Funktionen in Task Tsk1 verringert werden, damit der Task den Frame-Überlauf korrigiert; andernfalls fährt der Task mit dem Betrieb in einem Frame-Überlaufmodus fort. Als Ergebnis werden die Funktionen R15 und R16 zu einem anderen Task (z. B. Tsk2) verschoben, der im Vergleich zu Task Tsk1 eine langsamere Zykluszeit aufweist.
-
Wie es in Task Tsk2 gezeigt ist, werden die Funktionen R15 und R16 nur ausgeführt, wenn Modus M11 ausgewählt ist. Das heißt, wenn Modus M11 nicht aktiviert wird, führt Task Tsk2 die Funktionen R15 und R16 nicht aus; wenn jedoch Modus M11 aktiviert wird, führt Task Tsk2 die Funktionen R15 und R16, die temporär von Task Tsk1 fallen gelassen wurden, aus. Dies ermöglicht, dass die Funktionen R15 und R16, die alle 5 ms ausgeführt wurden, alle 10 ms ausgeführt werden. Als Ergebnis werden, anstatt die Funktionen R15 und R16 vollständig fallen zu lassen, die Funktionen R15 und R16 als Teil eines anderen Tasks mit einer langsameren Zykluszeit ausgeführt, was ermöglicht, dass die Funktionen weiterhin ausgeführt werden, und dem Task Tsk1 zugehörigen Frame-Überlauf ermöglicht, sich selbst zu korrigieren, da dieser temporär weniger Funktionen ausführen muss.
-
Es sei auch angemerkt, dass in Task Tsk2, um die zusätzliche Arbeitsbelastung der Funktionen R15 und R16 zu übernehmen, die Funktionen R22 und R23 in Task Tsk2 nicht ausgeführt werden, während Modus M11 aktiviert ist. Diese jeweiligen Funktionen werden einem anderen Task, beispielsweise Tsk3, neu zugeteilt, sodass Task Tsk2 nicht aufgrund der zusätzlichen Arbeitsbelastung der Funktionen R15 und R16 zurückfällt und einen Frame-Überlauf verursacht. Daher werden im Gegensatz zu einem Fallenlassen der Funktionen R22 und R23 diese Funktionen einem anderen Task Tsk3, der mit einer langsameren Zykluszeit als Task Tsk2 arbeitet, neu zugeteilt. Wenn sich der Frame-Überlauf nicht selbst korrigiert hat, kann Tsk3 Funktionen einem Task mit nächstlangsamerer Zykluszeit neu zuteilen. Dies wird fortgesetzt, bis der Frame-Überlauf in Bezug auf den Task, der den Frame-Überlauf ursprünglich verursacht hat, was Task Tsk1 ist, korrigiert ist.
-
Sobald der Frame-Überlauf korrigiert ist, stellt sich das System selbst wieder in die ursprüngliche Konfiguration her. Als Ergebnis wird der jeweilige Modus deaktiviert und arbeitet jeder Task gemäß der ursprünglichen Konfiguration vor dem Frame-Überlauf. Die Task-Struktur wird durch eine Analyse während der Entwurfsstufen des Controllers offline definiert. Folglich werden alle Neuzuteilungen von Funktionen zu einem anderen Task zuvor bedacht und vor der Realisierung in dem Controller gründlich analysiert. Die nachstehende Tabelle veranschaulicht ein Beispiel für eine Neuzuteilungstabelle, die den betroffenen Modus, den betroffenen Task (task_source), die jeweiligen Funktionen in dem Task, die bei der Neuzuteilung betroffen sind (Runnables), und den Ziel-Task (task_target), dem die betroffenen Funktionen neu zugeteilt werden, veranschaulicht:
| Modus | T_src | Runnables | T_tgt |
| M11 | Tsk1
Tsk2 | R15, R16
R22, R24 | Tsk2
Tsk3 |
| M12 | Tsk2 | R22, R24 | Tsk4 |
| ... | ... | ... | ... |
Tabelle 2
-
Unter erneuter Bezugnahme auf 2 werden in Schritt 27, wie es in den obigen Absätzen beschrieben ist, jeweilige Funktionen in anderen Tasks neu zugeteilt, während der Frame-Überauf vorliegt. Solange ein jeweiliger Modus identifiziert wird, können jeweilige Merkmale innerhalb jeweiliger Tasks unter den darin dargelegten Bedingungen ausgeführt werden, müssen jedoch nicht.
-
In Schritt 28 wird ermittelt, ob der Frame-Überlauf korrigiert wurde. Wenn der Frame-Überlauf nicht korrigiert wurde, erfolgt ein Rücksprung zu Schritt 27, um die Neuzuteilung von Funktionen zwischen Tasks basierend auf dem identifizierten Modus fortzusetzen. Wenn in Schritt 28 ermittelt wird, dass der Überlauf nicht korrigiert wurde, fährt die Routine mit Schritt 29 fort, in dem das System wieder in seine ursprüngliche Konfiguration hergestellt wird, wenn kein Frame-Überlauf vorliegt. Eine Wiederherstellung in seine ursprüngliche Konfiguration erfolgt durch Deaktivieren des jeweiligen Modus, der gewählt wurde, um den Frame-Überlauf zu korrigieren. Als Ergebnis wird das Neuzuteilungsschema aktiviert und basierend auf einem jeweiligen durch das Modusauswahlmodul identifizierten Modus konfiguriert. Die in jedem Task dargelegten Bedingungen werden zu einem Entwurfszeitpunkt vorbestimmt, und die Ermittlung, welche Funktionen in jedem Task auszuführen oder nicht auszuführen sind, ist durch den aktuell aktivierten Modus dargelegt.
-
Der hierin beschriebene Vorteil ist ein Ausführungsschema, das vorbestimmt wird, um Funktionen innerhalb eines Controllers neu zuzuteilen, um einen Frame-Überlauf zu korrigieren, ohne Funktionen dauerhaft fallen lassen zu müssen. Die Funktionen werden neu zugeteilt, allerdings werden eher Funktionen einer anderen Zykluszeit neu zugeteilt, um Arbeitsbelastungen innerhalb eines jeweiligen Tasks zu verringern, der den Frame-Überlauf verursacht, was dem Task ermöglicht, hinsichtlich seiner aktuellen Arbeitsbelastung aufzuholen. Die erneute Zuteilung von Funktionen zu einer nächstlangsameren Zykluszeit sollte für einen Benutzer des Systems, wie beispielsweise einen Fahrer eines Fahrzeugs, nicht wahrnehmbar sein, da die Funktionen weiterhin ausgeführt werden, jedoch nur temporär mit einem nächstlangsameren Zeitintervall ausgeführt werden.
-
Während bestimmte Ausführungsformen der vorliegenden Erfindung ausführlich beschrieben wurden, wird der Fachmann, den diese Erfindung betrifft, verschiedene alternative Entwürfe und Ausführungsformen zum Ausführen der Erfindung, wie sie durch die folgenden Ansprüche definiert ist, erkennen.
