DE102019201309A1

DE102019201309A1 - Computerimplementiertes Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit

Info

Publication number: DE102019201309A1
Application number: DE102019201309.0A
Authority: DE
Inventors: Bert Böddeker; Sebastian Kehr
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2019-02-01
Filing date: 2019-02-01
Publication date: 2020-08-06

Abstract

Bei der vorliegenden Erfindung wird in dem computerimplementierten Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit eine Hierarchie von LET(Logical Execution Time)-Intervallen mit unterschiedlicher Periodendauer festgelegt, wobei zumindest ein LET-Intervall mit der kürzeren Periodendauer ohne gemeinsame Teiler zumindest ein Wurzelknoten in der Hierarchie ist, dem jeweiligen LET-Intervall mit der kürzeren Periodendauer in der hierarchischen Staffelung die höhere Hierarchiestufe zugewiesen ist, das LET-Intervall mit den kleinsten Mehrfachperiode direkter Kindknoten in der Hierarchie ist und das Hierarchie-Festlegen abgeschlossen ist, wenn alle LET-Intervalle mit unterschiedlicher Periodendauer in die Hierarchie integriert sind. In diesem Verfahren erfolgt ein Ausführen einer Wirkkette in der Kraftfahrzeugsteuereinheit, bei der Tasks in LET-Intervallen mit unterschiedlicher Periodendauer ausgeführt werden, wobei zwischen gekoppelten LET-Intervallen, die in der Hierarchie direkt miteinander verbunden sind, die direkte Kommunikation, vorzugsweise entsprechend der RMS(rate monotonic scheduling)-Ablaufplanung, verwendet wird, wobei bei zwei gekoppelten LET-Intervallen das LET-Intervall mit der höheren Hierarchiestufe als erzeugendes LET-Intervall und das LET-Intervall mit der niedrigeren Hierarchiestufe als empfangendes LET-Intervall festgelegt werden, und zwischen nicht gekoppelten LET-Intervallen, die in der Hierarchie nicht direkt miteinander verbunden sind oder von empfangendem zu erzeugendem LET-Intervall, die zeitbasierte Kommunikation entsprechend dem LET-Paradigma verwendet wird. Durch ein derartiges Verfahren ergeben sich kurze Ansprechzeiten und ein deterministischer Datenfluss des Steueralgorithmus in Systemen mit gemischter Periodizität bei der Ausführung von Tasks.

Description

Technisches Gebiet
Die vorliegende Erfindung bezieht sich auf ein computerimplementiertes Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit, auf ein System zur Datenverarbeitung mit Mitteln zur Ausführung der Schritte des Verfahrens, auf ein Computerprogramm mit Befehlen, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das Verfahren auszuführen, auf ein computerlesbares Speichermedium mit Befehlen, die bei der Ausführung durch einen Computer diesen veranlassen, das Verfahren auszuführen sowie auf eine Verwendung des computerimplementierten Verfahrens.
Stand der Technik
Das primäre Anwendungsgebiet dieser Erfindung ist eine Steuersoftware für Kraftfahrzeugsteuereinheiten, insbesondere für einen Kraftübertragungsweg des Kraftfahrzeugs.
Bei eingebetteter Steuerungssoftware auf dem Gebiet der Kraftfahrzeugtechnik ist eine typische Organisationsform für die Tasksysteme eine gemischte Periodizität. Anders ausgedrückt werden Wirkketten auf einem Mehrkernrechner gleichzeitig in unterschiedlichen Perioden oder in Erwiderung auf sporadische Ereignisse ausgeführt. Auf einem Einzelkernrechner treten ähnliche Effekte durch verschiedene Prioritäten von Tasks und durch die mit höheren Prioritäten im Zusammenhang stehenden Unterbrechungen der Tasks auf. Wirkketten mit den gleichen Bedingungen für die Auslösung werden in Tasks gruppiert. Diese Tasks können durch periodische Zeitereignisse oder sporadische Ereignisse ausgelöst werden. Die Tasks können mit unterschiedlicher Priorität abgearbeitet werden. Das bedeutet, dass eine Task mit höherer Priorität präemptiv in Bezug auf die Ausführung einer Task mit geringerer Priorität wirken kann, das heißt die Task mit höherer Priorität kann die Task mit niedrigerer Priorität unterbrechen.
Die Besonderheit bei einem Mehrkernsystem besteht darin, dass Tasks gleichzeitig auf unterschiedlichen Kernen abgearbeitet werden können. Zwischen Wirkketten, denen unterschiedlichen Tasks zugewiesen sind, erfolgt die Kommunikation über Puffer. Der Inhalt der Puffer kann zwischen den Tasks entweder nach dem Schreiben direkt (explizit) oder am Ende und am Beginn der Ausführung der Tasks (implizit) ausgetauscht werden. Für einen derartigen Datenaustausch wird auf den Industriestandard AutoSAR verwiesen, wobei beispielhaft der AutoSAR-Standard 4.4.0 vom 31.10.2018 angegeben wird.
In der nachfolgenden Beschreibung wird unter „direkter Kommunikation“ die explizite und implizite Kommunikation zusammengefasst. Dieses ist im Unterschied zur zeitgesteuerten Kommunikation (timed communication) zu sehen. Bei diesem Ansatz entsprechend der vorliegenden Erfindung erfolgt ein Schreiben am Ende eines Intervalls und ein Lesen am Anfang des Intervalls, was eine Erweiterung der impliziten Kommunikation darstellt.
Da den Wirkkettenentsprechend dem Stand der Technik unterschiedliche Tasks mit unterschiedlichen Ablaufplänen zugewiesen sind, hängt der Datenfluss zwischen den unterschiedlichen Wirkketten in kritischer Weise von der Reihenfolge der Ausführung der Tasks ab. Die Reihenfolge der Ausführung hängt wiederum von der Taskpriorität und der Ausführungszeit von jeder Task ab. Beim Auftreten von Jitter zur Ausführungszeit der Task können sich Änderungen beim Datenfluss ergeben, woraus nichtdeterministische Effekte resultieren, wodurch Ausgangsgrößen am Steuergerät nicht reproduzierbar bereitgestellt werden können. Laufzeitunterschiede machen sich stärker bei Mehrkernsystemen bemerkbar, bei denen Tasks in Echtzeit gleichzeitig ausgeführt werden.
Ein Beispiel für die Ablaufplanung entsprechend dem Rate-Monotonic-Scheduling (RMS-Ablaufplanung), die in AutoSAR-Systemen, bevorzugt bei Kraftübertragungswegen, Verwendung findet, ist in 1 dargestellt.
Ziel der RMS-Ablaufplanung ist das Vorsehen von kurzen Ansprechzeiten des Steueralgorithmus in Systemen von gemischter Periodizität von Tasks. Zu diesem Zweck ist in 1 über der Zeit in Millisekunden die Ausführung der 1-Millisekunden-Tasks, der 2-Millisekunden-Tasks, der 3-Millisekunden- Tasks und der 4-Millisekunden-Tasks dargestellt. Die RMS-Ablaufplanung ist ein Prioritätszuweisungsalgorithmus, der in Echtzeitbetriebssystemen (RTOS-Realtime Operating Systems) mit einer statischen Prioritäts-Ablaufplanung Verwendung findet. Die statischen Prioritäten werden entsprechend der Dauer des Zyklus (der Periode) der Task zugewiesen. Im Ergebnis ergibt sich aus einer kürzeren Periode eine Task mit höherer Priorität.
Die Ablaufplanung bei Echtzeitbetriebssystemen ist gewöhnlich präemptiv. Die tatsächliche Ausführung einer Task ist in 1 grau hinterlegt. Die Diagramme beginnen zum Zeitpunkt von 2 Millisekunden. Die periodische Ausführung der Instanzen der Task ist nummeriert. Zum Beispiel werden die einzelnen Instanzen der 2-Millisekunden-Task mit 1 bis 5 bezeichnet.
Auf Grund der unterschiedlichen Priorisierung erfolgt der Start der Ausführung der Tasks zeitverzögert. Dieses ist durch die grauen Pfeile gezeigt. Beispielweise erfolgt die Ausführung der ersten 2-Millisekunden-Task nach dem Abschluss der Ausführung der zweiten 1-Millisekunden-Task. In diesem Beispiel haben alle Tasks von 1 Millisekunde eine kürzere Periodendauer als die Task von 3-Millisekunden. Daher wird die 1 - Millisekunden-Task mit höherer Priorität ausgeführt. Dieses schlägt sich beispielsweise zum Zeitpunkt von 5 Millisekunden nieder, wo in der ersten 4-Millisekunden-Task eine Unterbrechung für die Ausführung der fünften 1-Millisekunden-Task auftritt.
Kurzfassung der Erfindung
Technisches Problem
Die vorliegende Erfindung hat die Aufgabe, bei computerimplementierten Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit kurze Ansprechzeiten und gleichzeitig reproduzierbare, deterministische Datenflüsse des Steueralgorithmus in Systemen vorzusehen, bei denen eine gemischte Periodizität bei der Ausführung von Tasks vorliegt, wobei bevorzugt auch Mehrkehrsystem unterstützt werden sollen.
Lösung des Problems
Diese Aufgabe wird durch ein computerimplementiertes Verfahren zum Betreiben einer Kraftfahrzeugsteuereinrichtung, ein System zur Datenverarbeitung, ein Computerprogramm, ein computerlesbares Speichermedium und eine Verwendung des computerimplementierten Verfahrens entsprechend den unabhängigen Ansprüchen gelöst. Erfindungsgemäße Weiterbildungen sind Gegenstand der Unteransprüche.
Entsprechend der vorliegenden Erfindung wird ein computerimplementiertes Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit mit folgenden Schritten vorgesehen: Festlegen einer Hierarchie von LET(Logical Execution Time)-Intervallen mit unterschiedlicher Periodendauer, wobei zumindest ein LET-Intervall mit der kürzeren Periodendauer ohne gemeinsame Teiler ein Wurzelknoten in der Hierarchie ist, dem jeweiligen LET-Intervall mit der kürzeren Periodendauer in der hierarchischen Staffelung die höhere Hierarchiestufe zugewiesen ist, das LET-Intervall mit den kleinsten Mehrfachperiode direkter Kindknoten in der Hierarchie ist und das Hierarchie-Festlegen abgeschlossen ist, wenn alle LET-Intervalle mit unterschiedlicher Periodendauer in die Hierarchie integriert sind, und Ausführen einer Wirkkette in der Kraftfahrzeugsteuereinheit, bei der Tasks in LET-Intervallen mit unterschiedlicher Periodendauer ausgeführt werden, wobei zwischen gekoppelten LET-Intervallen, die in der Hierarchie direkt miteinander verbunden sind, die direkte Kommunikation verwendet wird, wobei der Datenfluss vom erzeugenden LET-Intervall zu einem gleichzeitig aktivierten empfangenden LET-Intervall unter Verzögerung des Starts der Task des empfangenden LET-Intervalls erfolgt. Hierbei kann erzeugend und empfangend den Eltern- und Kindknoten der Hierarchie entsprechen und/oder bei zwei gekoppelten LET-Intervallen das LET-Intervall mit der höheren Hierarchiestufe als erzeugendes LET-Intervall und das LET-Intervall mit der niedrigeren Hierarchiestufe als empfangendes LET-Intervall festgelegt werden. Darüber hinaus kann zwischen nicht gekoppelten LET-Intervallen, die in der Hierarchie nicht direkt miteinander verbunden sind, sowie vorzugsweise ebenfalls von empfangendem zu erzeugendem LET-Intervall, die zeitbasierte Kommunikation entsprechend dem LET-Paradigma verwendet werden. Durch ein derartiges Verfahren lassen sich die Latenzzeiten gegenüber reiner LET-basierter Kommunikation verringern.
Bei der Festlegung, dass das LET-Intervall mit der kleinsten Mehrfachperiode direkter Kindknoten in der Hierarchie ist, wird bevorzugt, dass der Periodenunterschied einen festgelegten Grenzwert nicht überschreitet.
Bevorzugt ist ferner bei der vorliegenden Erfindung, zwischen der Aktivierung und dem Start von Tasks zu unterscheiden. Periodische Tasks werden zu fest definierten periodischen Zeitpunkten aktiviert. Bei der RMS-Ablaufplanung oder einem anderen prioritätenbasierten Tasksystem verzögert sich aber der Start einer Task so lange, bis keine andere Task mit höherer Priorität mehr läuft. Dieses Prinzip wird in der vorliegenden Erfindung beim monoton gekoppelten LET-Schema verwendet. Wenn gekoppelte LET-Intervalle den gleichen Aktivierungszeitpunkt haben, wie zum Beispiel die 1-Millisekunden-Task und die 2-Millisekunden-Task zu einem Zeitpunkt 4 ms (siehe Beschreibung der Ausführungsbeispiele), so soll der Start der 2-Millisekunden-Task verzögert werden, bis die 1-Millisekunden-Task ihr Ergebnis in den Kommunikationspuffer geschrieben hat. Im Unterschied zur RMS-Ablaufplanung nach dem Stand der Technik erfolgt dieses bevorzugt auch zwischen verschiedenen Rechenkernen eines Mehrkernprozessors.
Eine weitere Verringerung der Latenzzeit ist bei dem erfindungsgemäßen computerimplementierten Verfahren erzielbar, wenn in dem LET-Intervall am Ende der Ausführung der Wirkkette nach dem Abarbeiten der letzten Task der Wirkkette die direkte Kommunikation verwendet wird.
Bei den vorstehenden computerimplementierten Verfahren wird bevorzugt, dass die Kraftfahrzeugsteuereinheit zumindest zwei Rechenkerne hat, dass die festgelegte Hierarchie von LET-Intervallen einen minimalen Schnitt mit zumindest einer ersten und einer zweiten Partition bzw. hierarchischen Staffelung aufweist, und dass beim Ausführen der Wirkkette in der Kraftfahrzeugsteuereinheit in LET-Intervallen mit unterschiedlicher Periodendauer die Tasks der ersten Partition bzw. hierarchischen Staffelung zeitgleich mit den Tasks der zweiten Partition bzw. hierarchischen Staffelung und/oder die Tasks einer der Partitionen bzw. hierarchischen Staffelungen auf verschiedenen Rechenkernen der Kraftfahrzeugsteuereinheit ausgeführt werden. Durch ein derartiges Verfahren lässt sich die Mehrkernleistung effizient nutzen.
Erfindungsgemäß wird ein System zur Datenverarbeitung mit Mitteln zur Ausführung der Schritte des vorstehenden computerimplementierten Verfahrens bevorzugt. Dabei wird stärker bevorzugt, wenn das System zur Datenverarbeitung die Kraftfahrzeugsteuereinheit ist. Im Ergebnis kann eine gerätetechnische Ausstattung mit geringer Latenzzeit zur Verfügung gestellt werden.
Darüber hinaus sieht die vorliegende Erfindung ein Computerprogramm mit Befehlen vor, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das vorstehende, computerimplementierte Verfahren auszuführen.
Erfindungsgemäß kann ferner ein computerlesebares Speichermedium mit Befehlen bereitgestellt werden, die bei der Ausführung durch einen Computer diesen veranlassen, das vorstehende, computerimplementierte Verfahren auszuführen.
Bei der vorliegenden Erfindung kann das vorstehende, computerimplementierte Verfahren auf einem eingebetteten System mit direkter Kommunikation und RMS-Ablaufplanung verwendet, wobei die Kommunikation zwischen gekoppelten Intervallen der RMS-Ablaufplanung als Kommunikation zwischen gekoppelten LET-Intervallen beibehalten wird und die Kommunikation zwischen Tasks, die nicht zu einem Paar gekoppelter Intervalle gehören, ersetzt wird. Damit ist eine einfache Migration von bestehenden eingebetteten System möglich.
Bei der vorstehend beschriebenen Verwendung können bei der Festlegung gekoppelter LET-Intervalle Prioritätsstufen verwendet werden und Tasks auf der gleichen Prioritätsstufe in gekoppelte LET-Intervalle überführt werden, so dass die Migration mit geringem Aufwand möglich ist.
In dem Fall, in dem bei der vorstehend beschriebenen Verwendung das eingebettete System einen Einzelkernprozessor aufweist, kann durch die Ausführungsreihenfolge auf dem Einzelkernprozessor festgelegt werden, welches LET-Intervall erzeugend und welches LET-Intervall empfangend ist. Dadurch ist der Migrationsaufwand gering.
Bei der erfindungsgemäßen Verwendung werden besonders die Migration und Ausführung auf einem Mehrkernprozessor bevorzugt.
Bei der vorliegenden Erfindung wird besonders bevorzugt, dass die Kommunikation zwischen sporadischen und periodischen Tasks nach LET stattfindet. Dabei erfolgen die Schreib-/Lese-Zugriffe an den Intervallgrenzen des LET-Intervalls
Figurenliste
Unter Bezugnahme auf die beiliegenden Zeichnungen und die entsprechende detaillierte Beschreibung wird die vorliegende Erfindung detaillierter im Zusammenhang mit weiteren Aufgaben, Merkmalen und Vorteilen beschrieben.

1 zeigt die RMS-Ablaufplanung entsprechend dem Stand der Technik.
Die 2A und 2B zeigen schematisch den Aufbau einer Einzelkern-Kraftfahrzeugsteuereinheit und einer Mehrkern-Kraftfahrzeugsteuereinheit für das computerimplementierte Verfahren entsprechend der vorliegenden Erfindung.
Die 3A und 3B zeigen die RMS-Ablaufplanung mit impliziter Kommunikation und die mit dieser in Zusammenhang stehenden Nachteile im Datenfluss als Vergleichsbeispiel.
Die 4A und 4B zeigen die Verwendung eines LET-Schemas nach dem Stand der Technik als Verbesserung der Kommunikation in Bezug auf die direkte oder implizierte Kommunikation in der RMS-Ablaufplanung als Vergleichsbeispiel.
Die 5A und 5B zeigen den Vorteile RMS-Ablaufplanung in Bezug auf das LET-Schema nach dem Stand der Technik als Vergleichsbeispiele.
6 zeigt die LET-Intervallhierarchiefestlegung bei dem erfindungsgemäßen, gekoppelten, monotonen LET-Schema.
Die 7A und 7B zeigen die Datenflüsse für das gekoppelte, monotone LET-Schema entsprechend der vorliegenden Erfindung ohne Jitter und mit Jitter im Vergleich zu den 4A und 4B, die das LET-Schema nach dem Stand der Technik darstellen.
8A zeigt als Vergleichsbeispiel die Nachteile des LET-Schemas nach dem Stand der Technik bei einem Vierkernprozessor, während 8B die Anwendung des erfindungsgemäßen, gekoppelten, monotonen LET-Schemas bei einem Vierkernprozessor zeigt.
9 zeigt das erfindungsgemäße, gekoppelte, monotone LET-Schema bei einem Vierkernprozessor mit erhöhter Last.

Beschreibung der Ausführungsbeispiele
Nachfolgend wird das computerimplementierte Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit detaillierter beschrieben.
Die 2A und 2B zeigen schematisch den Aufbau einer Einzelkern-Kraftfahrzeugsteuereinheit und einer Mehrkern-Kraftfahrzeugsteuereinheit für das computerimplementierte Verfahren entsprechend der vorliegenden Erfindung.
Wie es in 2A gezeigt ist, weist die Einzelkern-Kraftfahrzeugsteuereinheit 10 beispielhaft einen RAM 12 und den Einzelkern-Prozessor C0. Die Einzelkern-Kraftfahrzeugsteuereinheit 10 kommuniziert mit der Fahrzeugumgebung, wie z.B. mit Sensoren und Betätigungseinrichtungen, über eine Eingabe/Ausgabe-Schnittstelle 16 und diese ist so gestaltet, dass Steuerungssoftware 19 nach dem AUTOSAR-Standard nach einer Einzelkernablaufplanung 18 ausgeführt werden kann. Beispielhaft ist angegeben, dass durch die Steuerungssoftware Wirkketten definiert sind, die eine 1-Millisekunden-Task, eine 2-Millisekunden-Task, eine 3-Millisekunden-Task und eine 4-Millisekunden-Task verwenden.
In einer Variante der Kraftfahrzeugsteuereinheit, wie diese in 2B gezeigt ist, weist eine Mehrkern-Kraftfahrzeugsteuereinheit 20 beispielhaft einen RAM 22 und Prozessorkerne C0, C1, C2 und C3 auf. Die Mehrkern-Kraftfahrzeugsteuereinheit 20 kommuniziert mit der Fahrzeugumgebung, wie z.B. mit Sensoren und Betätigungseinrichtungen, über eine Eingabe/Ausgabe-Schnittstelle 26 und diese ist so gestaltet, dass Steuerungssoftware 29 nach dem AUTOSAR-Standard nach einer Mehrkernablaufplanung 28 ausgeführt werden kann. Beispielhaft ist angegeben, dass durch die Steuerungssoftware Wirkketten definiert sind, die eine 1-Millisekunden-Task, die auf dem Kern C0 ausführbar ist, eine 2-Millisekunden-Task, die auf dem Kern C1 ausführbar ist, eine 3-Millisekunden-Task, die auf dem Kern C2 ausführbar ist, und eine 4-Millisekunden-Task, die auf dem Kern C3 ausführbar ist, verwenden.
Bei der Einzelkern-Kraftfahrzeugsteuereinheit 10 aus 2A kann bei der Betrachtung als Vergleichsbeispiel zu der später beschriebenen Erfindung in Bezug auf das computerimplementierte Verfahren die RMS-Ablaufplanung nach dem Stand der Technik zum Einsatz gelangen.
Diese RMS-Ablaufplanung hat jedoch Nachteile, wie es in den 3A und 3B gezeigt ist. Beispielhaft ist in den 3A und 3B der Datenfluss mit direkter (impliziter) Kommunikation von der 1-Millisekunden-Task über die 3-Millisekunden-Task zur 2-Millisekunden-Task gezeigt. Im Hinblick auf die Bezeichnung von impliziter und expliziter Kommunikation wird auf den vorstehend genannten AUTOSAR-Standard Bezug genommen. Im Folgenden wird nicht zwischen direkter und impliziter Kommunikation unterschieden und die direkte Kommunikation mit zeitabhängiger Kommunikation verglichen.
Wie es auf 3A ersichtlich ist, startet die Wirkkette bei 3-Millisekunden bei der Ausführung der dritten 1-Millisekunden-Task, geht über die erste 3-Millisekunden-Task zur zweiten 2-Millisekunden-Task und benötigt für die Ausführung der gesamten Wirkkette eine Zeit von t_3A. Im Gegensatz zur ersten 3-Millisekunden-Task in 3A, bei der die Ausführung nicht präemptiv erfolgen muss, ist in 3B die erste 3-Millisekunden-Task geringfügig verlängert. Da in 3B bis zum Abschluss der Ausführung der ersten 3-Millisekunden-Task auf das komplette Ausführen der vierten 1-Millisekunden-Task und der zweiten 2-Millisekunden-Task, die beide eine höhere Priorität haben, gewartet werden muss, endet die Ausführung der ersten 3-Millisekunden-Task erst in der Nähe von 5 Millisekunden. Dadurch ergibt sich der in 3B gezeigte geänderte Datenfluss, bei dem erst die dritte 2-Millisekunden-Task in der Reihenfolge 1-Millisekunden-Task, 3-Millisekunden-Task und 2-Millisekunden-Task, die aufeinanderfolgend ausgeführt werden, die Wirkkette zum Abschluss bringt. Somit ergibt sich eine Zeit von t_3B, die mit dem Abschluss nach 6 Millisekunden deutlich länger als die Zeitdauer t_3A in 3A ist. Besonders problematisch ist dabei, dass die Wirkkette über unterschiedliche Instanzen der 2-Millisekunden-Task läuft.
Zur Vermeidung derartiger nichtdeterministischer Datenflüsse ist aus dem Stand der Technik das LET-Schema bekannt. Dieses kann sowohl bei Einzelkern-Kraftfahrzeugsteuereinheit 10 als auch bei Mehrkern-Kraftfahrzeugsteuereinheit 20, wie diese beispielhaft in den 2A und 2B gezeigt ist, zum Einsatz gelangen.
Entsprechend dem LET-Schema nach dem Stand der Technik als Vergleichsbeispiel erfolgt die gesamte Kommunikation zwischen unterschiedlichen LET-Intervallen zu vorbestimmten Zeitpunkten. Dabei spezifiziert ein LET-Intervall ein Zeitintervall für die Ausführung von Wirkketten. Eingangsdaten von anderen Teilen der Wirkkette werden logisch zum Startzeitpunkt des Intervalls aus einen globalen Puffer gelesen und Ausgangsdaten zu anderen Wirkketten werden logisch zum Ende des Intervalls in einen globalen Puffer geschrieben. Hierbei ist die tatsächliche physische Ausführung der Wirkkette unabhängig, solange die Ausführung der Wirkkette innerhalb des LET-Intervalls stattfindet. In ähnlicher Weise kann die tatsächliche physikalische Kommunikation zu unterschiedlichen Zeitpunkten stattfinden, solange der Datenfluss gewährleistet ist, d.h. die Reihenfolge der logischen Kommunikation zwischen den Befehlen sichergestellt ist.
Der Vorteil beim LET-Schema nach dem Stand der Technik besteht im hardwareunabhängigen deterministischen Datenfluss in Echtzeitsystemen, wodurch Race-Conditions verhindert werden.
Beispielhaft wird in Abgrenzung zur RMS-Ablaufplanung aus den 3A und 3B in den 4A und 4B ein Vergleichsbeispiel entsprechend dem Stand der Technik für das LET-Schema in 4A ohne Jitter und in 4B mit Jitter beschrieben.
Es ist hier zu beachten, dass in diesem Beispiel jede Task in einem LET-Intervall in einer Periode ausgeführt wird, die die Länge der Task-Periode ist. Beim Start erfolgt die Taskaktivierung und ein Ende bewirkt das Starten des nächsten Intervalls. Intervallgrenzen sind als vertikale Linien für die jeweiligen Tasks 1-Millisekunden-Task, 2-Millisekunden-Task, 3 Millisekunde-Task und 4-Millisekunden-Task gezeigt. Während bei der RMS-Ablaufplanung entsprechend der 3A und 3B die direkte oder implizite Kommunikation entsprechend der Ausführungsreihenfolge erfolgt, wird bei der zeitbasierten Kommunikation beim LET-Schema entsprechend dem Vergleichsbeispiel des Standes der Technik aus den 4A und 4B die Kommunikation entsprechend den logischen Schreib- und logischen Lese-Zeitpunkten in den LET-Intervallgrenzen verzögert.
Der Vorteil bei dem LET-Schema nach dem Stand der Technik ist die Garantie eines identischen Datenflusses unabhängig von Jitter und sogar unabhängig von der Hardwareplattform, wodurch der Einsatz sowohl bei einer Einzelkern-Kraftfahrzeugsteuereinheit 10 als auch bei einer Mehrkern-Kraftfahrzeugsteuereinheit 20, wie diese beispielhaft in den 2A und 2B gezeigt sind, begünstigt sind.
Genauer gesagt sind in 4A ohne Jitter die Kommunikation der ersten 3-Millisekunden-Task bis zu Beginn von 3 Millisekunden, die Kommunikation der dritten 2-Millisekunden-Task bis über den Zeitpunkt von 6 Millisekunden hinaus und der Output der dritten 2-Millisekunden-Task bis zu Beginn des Zeitpunktes von 8 Millisekunden verzögert. Dieses erfolgt in gleicher Weise in 4B mit Jitter und somit verlängerter Ausführung der ersten 3-Millisekunden-Task, sodass unabhängig von Jitter eine hohe Funktionssicherheit abgesichert wird.
Ein Merkmal des LET-Schemas nach dem Stand der Technik ist der Zeitdeterminismus, der greift, solange eine Taskausführung innerhalb des dafür vorgesehenen LET-Intervalls möglich ist. Im Vergleich zur direkten Kommunikation bei der RMS-Ablaufplanung führt das LET-Schema nach dem Stand der Technik mit der zeitabhängigen Kommunikation zu größeren Latenzzeiten. Dieses kann am besten dem Beispiel aus den 5A und 5B entnommen werden.
In 5B ist das LET-Schema für die Wirkkette von 5 Millisekunden bis zum Ende von 11 Millisekunden dargestellt. Für die den Prioritäten folgende Wirkkette von der 1-Millisekunde-Task über die 2-Millisekunde-Task zur 4-Millisekunde-Task ergibt sich eine Ausführungszeit von t_5B. Im Vergleich dazu ist die Ausführungsform t_5A entsprechend der direkten Kommunikation aus 5A deutlich kürzer.
Somit haben sowohl die RMS-Ablaufplanung mit direkter oder impliziter Kommunikation aus dem Stand der Technik als auch das LET-Schema aus dem Stand der Technik ihre Nachteile. Während das LET-Schema einen Zeitdeterminismus sicherstellt und eine einfache Migration zu unterschiedlichen Hardwareplattformen, einschließlich Mehrkernprozessoren, ermöglicht, kann diese die Latenzzeit der Steuerung drastisch erhöhen, das heißt die Zeit, bis eine Steuerungsantwort auf eine Sensoreingabe berechnet wird. Dieses tritt insbesondere dann auf, wenn unterschiedliche Tasks in unterschiedlichen LET-Intervallen zum Ergebnis der Ausgabe beitragen.
Beim LET-Schema kann eine Optimierung für kurze Latenzzeiten durch zufällige Variationen erfolgen, wie es zum Beispiel in dem Artikel IEEE Real-Time and embedded Technology and Applications Symposium (RTAS), Sebastian Kerr E.Q. (2017) Parcus: Energy-aware and Robust-Parallelization of AUTOSAR Legacy Applications beschrieben ist.
Zur Überraschung der Erfinder der vorliegenden Erfindung konnte ein Verfahren zum Reduzieren der Latenz in LET-Anwendungen aufgrund eines neuen Konzepts der Hierarchiebildung von LET-Intervallen aufgefunden werden. Dieses erfindungsgemäße Verfahren, auf das sich nachfolgend als „gekoppeltes, monotones LET-Schema“ bezogen wird, erfolgt bevorzugt zweistufig:

1. Erzeugen einer Hierarchie zwischen den LET-Intervallen und
2. Anwenden von definierten Kommunikations- und Ablaufregeln zwischen den H ierarch istufen.

Bei dem Erzeugen der Hierarchie gelangt der LET-Intervall mit der kürzesten Periode in die Wurzel der Hierarchie. Dieses ist in 6 gezeigt, wo LET-Intervalle von einer Millisekunde in der Wurzel vorgesehen sind. Die vorliegende Erfindung ist nicht darauf beschränkt und es können alternativ mehrere Wurzelknoten vorgesehen sein.
Beim Anwenden der Kommunikationsregeln erfolgt die direkte Kommunikation entsprechend der hierarchischen Staffelung bzw. den Partitionen, in 6 beispielsweise die direkte Kommunikation von dem 1-Millisekunden-Intervall zu dem 3-Millisekunden-Intervall und die direkte Kommunikation von dem 4-Millisekunden-Intervall zu dem 2-Millisekunden-Intervall. Wenn eine direkte Kommunikation zwischen zwei LET-Intervallen erfolgt, muss diese durch die Ablaufplanung der empfangenden Tasks geschützt werden, was sich in einem verzögerten Start niederschlägt, wie es vorstehend beschrieben wurde.
Um die vorliegende Erfindung besser zu veranschaulichen, wird angenommen, dass jeder Task genau ein periodisches LET-Intervall zugeordnet wird. Jedes LET-Intervall wird mit der Periode der Tasks wiederholt, die in diesem enthalten sind. Dem LET-Intervall ist somit die Periode inhärent.
Die Hierarchiebildung für LET-Intervalle, wie diese beispielhaft in 6 gezeigt ist, erfolgt unter folgender Maßgabe: Die LET-Intervalle mit der kürzesten Periode ohne gemeinsamen Teiler werden der oder die Wurzelknoten. Die LET-Intervalle mit den kleinsten Mehrfachperioden werden die direkten Kindknoten. Dieses wird wiederholt, bis alle LET-Intervalle in der Hierarchie integriert sind. Dabei werden nur kleine Vielfache, wie 2, 3, berücksichtigt. Vielfache wie 10 führen zu keinen neuen Kanten der Hierarchie.
Am Beispiel von 6 ergibt sich somit, dass eine direkte Kommunikation von dem 1-Millisekunden-Intervall zu dem 3-Millisekunden-Intervall möglich ist, während die hierarchische Staffelung bzw. Partition vom 1-Millisekunden-Intervall über den 2-Millisekunden-Intervall zum 4-Millisekunden-Intervall erfolgt.
Bei mehreren Wurzelknoten kann z.B. sowohl der den 2-Millisekunden-Intervall als auch der den 3-Millisekunden-Intervall ein Wurzelknoten sein, wenn beispielsweise keine 1-Millisekunden-Tasks existiert.
LET-Intervalle, die durch eine Verbindung entlang der Hierarchie verbunden sind, werden als gekoppelt bezeichnet. Von zwei gekoppelten LET-Intervallen wird das LET-Intervall, das in der Hierarchie höher ist, als erzeugendes LET-Intervall bezeichnet und wird das LET-Intervall, das in der Hierarchie niedriger ist, als empfangendes LET-Intervall bezeichnet.
Das Verständnis von gekoppelten LET-Intervallen ist eine Implementierung des Konzepts der starken Abhängigkeiten, wie dieses beispielsweise in der deutschen Patentanmeldung DE 10 2014 103 139 B4 beschrieben ist.
Im Gegensatz zum LET-Schema nach dem Stand der Technik, bei dem ausschließlich eine zeitabhängige Kommunikation erfolgt, wird beim gekoppelten, monotonen LET-Schema nach der vorliegenden Erfindung eine direkte Kommunikation zwischen gekoppelten LET-Intervallen nach folgender Maßgabe eingeführt:

Die direkte Kommunikation wird von Tasks und ausführbaren Entitäten des erzeugenden LET-Intervalls zu Tasks und ausführbaren Entitäten des gleichzeitig mit dem erzeugenden LET-Intervall aktivierten, empfangenden LET-Intervalls implementiert. Bevorzugt kopiert das erzeugende LET-Intervall die Ergebnisse in den Puffer des empfangenden LET-Intervalls, sobald die erzeugenden Tasks beendet wurden. Der Start von Tasks und ausführbaren Entitäten des empfangenden LET-Intervalls wird innerhalb des LET-Intervalls verzögert, um den Datenabhängigkeiten mit den Tasks und den ablauffähigen Entitäten des erzeugenden LET-Intervalls Rechnung zu tragen.

Eine mögliche Implementierung der vorliegenden Erfindung wird nachfolgend aufgezeigt:

Wenn alle Tasks in dem erzeugenden LET-Intervall beendet wurden, werden ihre Ergebnisse zu den Eingangspuffern der Tasks des gleichzeitig mit dem erzeugenden LET-Intervall aktivierten, empfangenden LET-Intervalls kopiert. Die zeitabhängige Kommunikation mit anderen LET-Intervallen ändert sich dadurch nicht. Die Aktivierung aller Tasks im empfangenden LET-Intervall wird verzögert, bis die Tasks der erzeugenden LET-Intervalle beendet wurden.

Eine sorgfältiger durchkonstruierte Implementierung gestattet das Ineinander-Verschachteln der Ausführung zwischen zwei gekoppelten LET-Intervallen. Die Tasks des empfangenden LET-Intervalls können bereits gestartet werden, wenn alle seine Eingangsdaten verfügbar sind, selbst wenn einige Tasks der erzeugenden Task noch laufen, solange die laufenden Tasks keine notwendigen Daten für die empfangende Task erzeugen.
Wenn die vorliegende Erfindung bei einer Migration von einem traditionellen, eingebetteten System mit direkter Kommunikation und RMS-Ablaufplanung erfolgt, kann bei einer einfachen Implementierung die ursprüngliche Ablaufplanung erneut verwendet werden, die Kommunikation entlang der gekoppelten LET-Intervalle beibehalten werden und lediglich die Kommunikation zwischen den Tasks, die nicht zu einem Paar von gekoppelten LET-Intervallen gehören, ersetzt werden. In diesem Fall der Migration kann die Definition der gekoppelten LET-Intervalle die Prioritäten verwenden. Die Tasks mit der gleichen Priorität können in gekoppelte LET-Intervalle übertragen werden. Der Ablauf der Ausführung auf einem einzigen Kern definiert dann, welches LET-Intervall erzeugend und welches empfangend ist. Für die RMS-Ablaufplanung des ursprünglichen Einzelkernprozessors führt dieses zu dem Ergebnis, das in 7A und 7B gezeigt ist. Nach der Umwandlung in ein monoton hierarchisches LET-Schema kann die Software nun auch auf einer Mehrkernsteuereinheit ausgeführt werden.
Die Start der Tasks, die im empfangenden LET-Intervall ausgeführt werden, kann dynamisch implementiert werden, das heißt unter Verwendung von Sperren, oder statisch ausgeführt werden, zum Beispiel auf der Grundlage einer Analyse der Ausführungszeit für den schlechtesten Fall.
Ein Beispiel für die Implementierung des erfindungsgemäßen, gekoppelten monotonen LET-Schema ist in 7A ohne Jitter und in 7B mit Jitter gezeigt. Hierbei ist die direkte Kommunikation entlang der gekoppelten LET-Intervalle durch „D“ bezeichnet, während die zeitbasierte Kommunikation zwischen den nicht gekoppelten LET-Intervallen durch „T“ bezeichnet ist. Solange alle Tasks innerhalb ihrer LET-Intervalle enden, ändern Jitter und die Ausführung auf einem Mehrkernprozessor (was nachfolgend unter Bezug auf 8B dargestellt wird) nicht den Datenfluss. Die gesamte Latenzzeit ist in den 7A und 7B entsprechend der vorliegenden Erfindung t_7A und t_7B und somit die gleiche wie die nach der RMS-Ablaufplanung nach dem Stand der Technik entsprechend 3B. Wie es der rechten Seite in 7B ab 8 Millisekunden entnommen werden kann, erfolgt die Abfolge der gekoppelten LET-Intervalle von dem 1-Millisekunden-Intervall über das 2-Millisekunden-Intervall zum 4-Millisekunden-Intervall in gleicher Weise wie bei der RMS-Ablaufplanung entsprechend dem Vergleichsbeispiel nach dem Stand der Technik von 5A.
Nachfolgend wird auf den Vergleich zwischen dem LET-Schema nach dem Stand der Technik in 8A und der vorliegenden Erfindung in 8B auf einem Vierkernprozessor Bezug genommen. Entsprechend dem LET-Schema aus 8A nach dem Stand der Technik wird bei der Abfolge 1-Millisekunden-Task, 3-Millisekunden-Task, 2-Millisekunden-Task eine Zeit t_8A bis zu Beginn von 8 Millisekunden benötigt.
Im Gegensatz dazu wird in 8B, in der das gekoppelte, monotone LET-Schema der vorliegenden Erfindung entsprechend einer Variante gezeigt ist, der Datenfluss auf dem Vierkernprozessor dargestellt. Die Kommunikation sowohl zwischen der 1-Millisekunden-Task und der 3-Millisekunden-Task als auch die Kommunikation am Ende der dritten 2-Millisekunden-Task und dem angenommenen Ende der Wirkkette erfolgt in 8B direkt, so dass die Zeit t_8B1 erhalten werden kann. Somit kann bei dem erfindungsgemäßen monoton gekoppelten LET-Schema aus 8B eine geringere Latenz als beim dem LET-Schema aus dem Vergleichsbeispiel aus 8A erzielt werden.
Für die finale Ausgabe, zum Beispiel zu einer Betätigungseinrichtung, wird bevorzugt direkte Kommunikation verwendet. Wenn ein exakt reproduzierbares Timing der Ausgabe notwendig ist, kann eine zeitbasierte Kommunikation beim Lesen des Sensors und beim Ausgeben zur Betätigungseinrichtung verwendet werden.
Die vorliegende Erfindung hat, wie es in 9 gezeigt ist, sogar bei erhöhter Last Vorteile. in 9 ist die Ausführung eines Beispiels eines erfindungsgemäßen gekoppelten, monotonen LET-Schemas bei einem Vierkernprozessor gezeigt, wobei die Last aller Tasks um 2,5 erhöht ist (oder die Taktfrequenz um 1/2,5 verringert ist).
Aus 9 sind nochmals die Vorteile der Erfindung ersichtlich. Diese bestehen in einem deterministischen Datenfluss, einer einfachen Migrationsmöglichkeit auf einen Mehrkernprozessor mit guter Ausnutzung der Mehrkernleistung (alle Tasks werden gleichzeitig ausgeführt) und in kurzen Latenzzeiten.
Somit wird bei der vorliegenden Erfindung in dem computerimplementierten Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit eine Hierarchie von LET(Logical Execution Time)-Intervallen mit unterschiedlicher Periodendauer festgelegt, wobei zumindest ein LET-Intervall mit der kürzeren Periodendauer ohne gemeinsame Teiler zumindest ein Wurzelknoten in der Hierarchie ist, dem jeweiligen LET-Intervall mit der kürzeren Periodendauer in der hierarchischen Staffelung die höhere Hierarchiestufe zugewiesen ist, das LET-Intervall mit den kleinsten Mehrfachperiode direkter Kindknoten in der Hierarchie ist und das Hierarchie-Festlegen abgeschlossen ist, wenn alle LET-Intervalle mit unterschiedlicher Periodendauer in die Hierarchie integriert sind. In diesem Verfahren erfolgt ein Ausführen einer Wirkkette in der Kraftfahrzeugsteuereinheit, bei der Tasks in LET-Intervallen mit unterschiedlicher Periodendauer ausgeführt werden, wobei zwischen gekoppelten LET-Intervallen, die in der Hierarchie direkt miteinander verbunden sind, die direkte Kommunikation, vorzugsweise entsprechend der RMS(rate monotonic scheduling)-Ablaufplanung, verwendet wird, wobei bei zwei gekoppelten LET-Intervallen das LET-Intervall mit der höheren Hierarchiestufe als erzeugendes LET-Intervall und das LET-Intervall mit der niedrigeren Hierarchiestufe als empfangendes LET-Intervall festgelegt werden, und zwischen nicht gekoppelten LET-Intervallen, die in der Hierarchie nicht direkt miteinander verbunden sind oder von empfangendem zu erzeugendem LET-Intervall, die zeitbasierte Kommunikation entsprechend dem LET-Paradigma verwendet wird. Durch ein derartiges Verfahren ergeben sich kurze Ansprechzeiten und ein deterministischer Datenfluss des Steueralgorithmus in Systemen mit gemischter Periodizität bei der Ausführung von Tasks.
Bezugszeichenliste

10: Einzelkern-Kraftfahrzeugsteuereinheit
12: RAM
C0: Einzelkernprozessor
16: Eingabe/Ausgabe-Schnittstelle
18: Einzelkernablaufplanung
19: Steuerungssoftware
20: Mehrkern-Kraftfahrzeugsteuereinheit
22: RAM
C0, C1, C2, C3: Mehrkernprozessoren
26: Eingabe/Ausgabe-Schnittstelle
28: Mehrkernablaufplanung
29: Steuerungssoftware

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102014103139 B4 [0053]

Claims

Computerimplementiertes Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit mit den Schritten Festlegen einer Hierarchie von LET(Logical Execution Time)-Intervallen mit unterschiedlicher Periodendauer, wobei zumindest ein LET-Intervall mit der kürzeren Periodendauer ohne gemeinsame Teiler ein Wurzelknoten in der Hierarchie ist, dem jeweiligen LET-Intervall mit der kürzeren Periodendauer in der hierarchischen Staffelung die höhere Hierarchiestufe zugewiesen ist, das LET-Intervall mit den kleinsten Mehrfachperiode direkter Kindknoten in der Hierarchie ist und das Hierarchie-Festlegen abgeschlossen ist, wenn alle LET-Intervalle mit unterschiedlicher Periodendauer in die Hierarchie integriert sind, und Ausführen einer Wirkkette in der Kraftfahrzeugsteuereinheit, bei der Tasks in LET-Intervallen mit unterschiedlicher Periodendauer ausgeführt werden, wobei a) zwischen gekoppelten LET-Intervallen, die in der Hierarchie direkt miteinander verbunden sind, die direkte Kommunikation verwendet wird, wobei der Datenfluss vom erzeugenden LET-Intervall zu einem gleichzeitig aktivierten empfangenden LET-Intervall unter Verzögerung des Starts der Task des empfangenden LET-Intervalls erfolgt, wobei erzeugend und empfangend den Eltern- und Kindknoten der Hierarchie entsprechen, wobei bei zwei gekoppelten LET-Intervallen das LET-Intervall mit der höheren Hierarchiestufe als erzeugendes LET-Intervall und das LET-Intervall mit der niedrigeren Hierarchiestufe als empfangendes LET-Intervall festgelegt werden, und b) zwischen nicht gekoppelten LET-Intervallen, die in der Hierarchie nicht direkt miteinander verbunden sind, sowie von empfangendem zu erzeugendem LET-Intervall die zeitbasierte Kommunikation entsprechend dem LET-Paradigma verwendet wird.
Computerimplementiertes Verfahren nach Anspruch 1, wobei in dem LET-Intervall am Ende der Ausführung der Wirkkette nach dem Abarbeiten der letzten Task der Wirkkette die direkte Kommunikation verwendet wird.
Computerimplementiertes Verfahren zum Betreiben einer Kraftfahrzeugsteuereinheit nach einem der vorhergehenden Ansprüche, wobei die Kraftfahrzeugsteuereinheit zumindest zwei Rechenkerne hat, wobei die festgelegte Hierarchie von LET-Intervallen einen minimalen Schnitt mit zumindest einer ersten und einer zweiten Partition aufweist, und wobei beim Ausführen der Wirkkette in der Kraftfahrzeugsteuereinheit in LET-Intervallen mit unterschiedlicher Periodendauer die Tasks der ersten Partition zeitgleich mit den Tasks der zweiten Partition und/oder die Tasks einer der Partitionen auf verschiedenen Rechenkernen der Kraftfahrzeugsteuereinheit ausgeführt werden.
System zur Datenverarbeitung mit Mitteln zur Ausführung der Schritte des Verfahrens nach einem der Ansprüche 1 bis 3.
System zur Datenverarbeitung, wobei dieses die Kraftfahrzeugsteuereinheit ist.
Computerprogramm mit Befehlen, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das Verfahren nach einem der Ansprüche 1 bis 3 auszuführen.
Computerlesebares Speichermedium mit Befehlen, die bei der Ausführung durch einen Computer diesen veranlassen, das Verfahren nach einem der Ansprüche 1 bis 3 auszuführen.
Verwendung eines computerimplementierten Verfahren nach einem der Ansprüche 1 bis 3 auf einem eingebetteten System mit direkter Kommunikation und RMS-Ablaufplanung, wobei die Kommunikation zwischen gekoppelten Intervallen der RMS-Ablaufplanung als Kommunikation zwischen gekoppelten LET-Intervallen beibehalten wird und die Kommunikation zwischen Tasks, die nicht zu einem Paar gekoppelter Intervalle gehören, ersetzt wird.
Verwendung nach Anspruch 8, wobei bei der Festlegung gekoppelter LET-Intervalle Prioritätsstufen verwendet werden und Tasks auf der gleichen Prioritätsstufe in gekoppelte LET-Intervalle überführt werden.
Verwendung nach Anspruch 9, wenn dieser nicht von Anspruch 3 abhängt, wobei das eingebettete System einen Einzelkernprozessor aufweist und durch die Ausführungsreihenfolge auf dem Einzelkernprozessor festgelegt wird, welches LET-Intervall erzeugend und welches LET-Intervall empfangend ist.
Verwendung nach einem der Ansprüche 8 bis 10 zur Migration und Ausführung auf einem Mehrkernprozessor.