-
Die Erfindung betrifft ein computerimplementiertes Verfahren und eine elektronische Steuereinheit für eine deterministische Datenkommunikation in einem partitionierten eingebetteten System, beispielsweise in einem partitionierten eingebetteten System einer offenen Systemarchitektur für die Automobiltechnik (AUTOSAR - Automotive Open System Architecture). Die Software des eingebetteten Systems umfasst eine Mehrzahl von Softwareclustern, die Funktionstasks und clusterübergreifende Kommunikationstasks umfassen. Der Softwarecluster des eingebetteten Systems umfasst eine Mehrzahl von Funktionstasks. Ferner umfassen die Softwarecluster des eingebetteten Systems eine Mehrzahl von clusterübergreifenden Kommunikationstasks zur Kommunikation zwischen den verschiedenen Softwareclustern.
-
In einem klassischen AUTOSAR-basierten Softwaresystem wird die Kommunikation von Daten zwischen den verschiedenen Softwaretask im Allgemeinen innerhalb der Task durchgeführt: gleich nach Beginn der Task für die Daten, die verbraucht werden, und kurz vor Beendigung der Task für die Daten, die erzeugt werden. Dieses herkömmliche Prinzip auf ein partitioniertes System anzuwenden, bedeutet, dass jede Task einer Partition mit jeder Task einer anderen Partition interagieren/kommunizieren kann.
-
Das vorstehend beschriebene herkömmliche Verhalten wirft Probleme in Bezug auf ein deterministisches Verhalten der Kommunikation zwischen den verschiedenen Tasks auf, da die Dauer und der Jitter einer einzelnen Task typischerweise Schwankungen aufweisen. Zum Beispiel ist die Kommunikation zwischen zwei Tasks aufgrund von Jitter oder variierender Laufzeit der Tasks üblicherweise nicht deterministisch. Für Softwarecluster (einen Satz von Tasks), die mit einem anderen Softwarecluster kommunizieren, stellt die logische Ausführungszeit (LET - Logical Execution Time) zwar Determinismus bereit, aber nur für jede einzelne Task, nicht für ein vollständiges System und in stabiler Weise über sukzessive Projekt-Aktualisierungen (d. h. Aktualisierungen von Taskinhalten). Insbesondere in Mehrkernsystemen könnte dies zu unberechenbaren Verzögerungen in der Kommunikation zwischen den verschiedenen Softwareclustern führen. Ein anderes Problem der herkömmlichen Kommunikation zwischen den verschiedenen Softwareclustern besteht darin, dass die Daten, die in verschiedenen Funktionstasks verbraucht werden, so oft erfasst werden, wie sie verwendet werden, und dies daher zu einer Instabilität und Inkonsistenz innerhalb der Softwarecluster führt. Ähnlich führen Daten, die in verschiedenen Funktionstasks erzeugt werden, zu mehreren Kommunikationen mit den Verbrauchern, was ebenfalls zu möglichen Inkonsistenzen führt.
-
Außerdem ermöglicht die herkömmliche Kommunikationsarchitektur keine Optimierung auf der Systemebene (Multicluster-Ebene), so dass beispielsweise die softwareclusterinterne Produktionsrate für die clusterübergreifende Kommunikation verwendet wird, selbst wenn für den verbrauchenden Softwarecluster eine niedrigere Produktionsrate genügen würde. Außerdem wird im herkömmlichen System keine vollständige Entkopplung zwischen den verschiedenen Softwareclustern erreicht, und eine Aktualisierung eines Softwareclusters kann funktionelle Auswirkungen auf einen anderen (stabilen) haben, wenn die Erzeugung einer Ausgabe von einer Task zu einer anderen verschoben wird und eine Verzögerung der Kommunikationsdaten einführt (oder entfernt).
-
Die Aufgabe der vorliegenden Offenbarung besteht daher in der Schaffung eines computerimplementierten Verfahrens und einer elektronischen Steuereinheit, die eine vorteilhafte deterministische Datenkommunikation in einem partitionierten eingebetteten System bereitstellen.
-
Die Aufgabe wird durch ein computerimplementiertes Verfahren mit den Merkmalen des unabhängigen Anspruchs und durch eine elektrische Steuereinheit erreicht, die Mittel umfasst, die zum Ausführen des computerimplementierten Verfahrens gemäß dem unabhängigen Anspruch verwendet werden. Vorteile und Ausführungsformen des Verfahrens und der elektronischen Steuereinheit werden in den abhängigen Ansprüchen spezifiziert.
-
Es wird ein computerimplementiertes Verfahren für eine deterministische Datenkommunikation in einem partitionierten eingebetteten System spezifiziert, wobei das partitionierte eingebettete System Software umfasst. Die Software des eingebetteten Systems umfasst eine Mehrzahl von Softwareclustern mit Funktionstasks und clusterübergreifenden Kommunikationstasks. Gemäß der vorliegenden Offenbarung sind die Funktionstasks zum Ausführen von Funktionstasks innerhalb des entsprechenden Softwareclusters mit bereitgestellten Daten im partitionierten eingebetteten System ausgelegt, und die clusterübergreifenden Kommunikationstasks sind zum Ausführen von clusterübergreifenden Kommunikationstasks zwischen den verschiedenen Softwareclustern des partitionierten eingebetteten Systems ausgelegt. Das computerimplementierte Verfahren für die deterministische Datenkommunikation im partitionierten eingebetteten System umfasst die folgenden Schritte:
- - Bereitstellen eines Ausführungsplans, der vordefinierte Funktionsfenster für Funktionstasks einer Mehrzahl der Softwarecluster umfasst. Der Ausführungsplan definiert die verschiedenen Funktionsfenster, während der die Funktionstasks der Mehrzahl von Softwareclustern während des Betriebs des partitionierten eingebetteten Systems ausgeführt werden. Der Ausführungsplan ist daher zum Erfüllen der gewünschten Tasks des partitionierten eingebetteten Systems ausgelegt.
- - Bereitstellen von dedizierten clusterübergreifenden Kommunikationsfenstern im Ausführungsplan für Kommunikationstasks der Mehrzahl der Softwarecluster, wobei die clusterübergreifenden Kommunikationsfenster von den Funktionsfenstern verschieden sind. Mit anderen Worten umfasst der Ausführungsplan ferner die clusterübergreifenden Kommunikationsfenster, in welchen die vordefinierten clusterübergreifenden Kommunikationstasks ausgeführt werden. Die clusterübergreifenden Kommunikationstasks stellen die notwendige Datenkommunikation zwischen den verschiedenen Softwareclustern bereit. Die gesendeten Daten werden danach zum Beispiel in einer Funktionstask eines entsprechenden anderen Softwareclusters verwendet. Mit anderen Worten lesen die clusterübergreifenden Kommunikationstasks Daten von anderen Softwareclustern zur Eingabe in die Funktionstasks aus, und die clusterübergreifenden Kommunikationstasks schreiben Ausgaben für andere Softwarecluster als Ausgabedaten der Funktionstasks. Die Kommunikationsdaten können daher zum Beispiel die gewünschte Kommunikation von einer Funktionstask bereitstellen, die eine Ausgabe als eine gewünschte Eingabe in eine andere Funktionstask für einen anderen Softwarecluster schreibt. Gemäß der vorliegenden Offenbarung sind die clusterübergreifenden Kommunikationsfenster von den Funktionsfenstern verschieden/unabhängig. Dies bedeutet, dass die clusterübergreifenden Kommunikationsfenster nicht mit den Funktionsfenstern verbunden sind. Es kann zum Beispiel in Betracht gezogen werden, dass die clusterübergreifenden Kommunikationsfenster sich in ganz anderen Zeitschlitzen im Gesamtausführungsplan als die Zeitschlitze der Funktionsfenster befinden. Es ist daher möglich, die clusterübergreifenden Kommunikationsfenster wie gewünscht im Gesamtausführungsplan zu platzieren, um die gewünschte deterministische Kommunikation unabhängig von der Ausführung der Funktionstasks während der Funktionsfenster zu erstellen.
- - Ausführen des Plans während des Betriebs des partitionierten eingebetteten Systems, wobei die Funktionstasks der Softwarecluster in den vordefinierten Funktionsfenstern ausgeführt werden, und wobei die clusterübergreifenden Kommunikationstasks der Softwarecluster für clusterübergreifende Kommunikation in den dedizierten clusterübergreifenden Kommunikationsfenstern ausgeführt werden, wodurch die deterministische Datenkommunikation im partitionierten eingebetteten System für clusterübergreifende Kommunikation realisiert wird.
-
Während des Betriebs des partitionierten eingebetteten Systems wird der Ausführungsplan des partitionierten eingebetteten Systems, was bedeutet, dass die Funktionstasks der Softwarecluster in den vordefinierten Funktionsfenstern ausgeführt werden, und wobei die clusterübergreifenden Kommunikationstasks der Softwarecluster für clusterübergreifende Kommunikation in den dedizierten clusterübergreifenden Kommunikationsfenstern ausgeführt werden. Zum Beispiel wird eine Funktionstask innerhalb eines ersten Softwareclusters ausgeführt, wodurch Ausgabedaten generiert werden. Danach wird eine zweite Funktionstask innerhalb des ersten Softwareclusters ausgeführt, wodurch andere Ausgabedaten generiert werden. Danach wird eine clusterübergreifende Kommunikationstask des ersten Softwareclusters ausgeführt, wodurch die beiden Ausgabedaten der zwei vorherigen Funktionstasks an einen zweiten Softwarecluster kommuniziert werden, der die Daten an mindestens eine seiner internen Funktionstasks kommuniziert. Gemäß der vorliegenden Offenbarung ist es daher möglich, eine sehr spezifische deterministische Kommunikation zwischen den verschiedenen Softwareclustern zu erstellen, die die gewünschte Kommunikation zwischen verschiedenen Softwareclustern ohne jegliche Datenbeschädigung während der Ausführung der verschiedenen Funktionstasks ermöglicht. Dies ist möglich, da die Kommunikation zwischen den verschiedenen Softwareclustern nur während der vordefinierten clusterübergreifenden Kommunikationsfenster mit der clusterübergreifenden Kommunikationstask erfolgt, so dass die erforderlichen Eingabe- und Ausgabedaten der verschiedenen Funktionstasks stets für die erforderliche Funktionstask bereitgestellt werden, so dass die Gesamtausführung des partitionierten eingebetteten Systems realisiert und ohne jegliche Datenverzögerung oder Datenbeschädigung erreicht wird. Die clusterübergreifenden Kommunikationsfenster können im Ausführungsplan in koordinierter Weise auf Systemebene (Multicluster-Ebene) in einer vordefinierten und stabilen Position positioniert werden. Sie können selbst über Kerne in einem Mehrkernsystem oder selbst über verschiedene Vorrichtungen in einem System mit mehreren Mikroprozessoren und/oder mehreren Mikrocontrollern in einer fortlaufenden und synchronisierten Reihenfolge disponiert werden. Die clusterübergreifenden Kommunikationstasks in den clusterübergreifenden Kommunikationsfenstern können verhältnismäßig kurze dedizierte Ausführungsfenster (kurze Laufzeit) und wahrscheinlich eine hohe Priorität aufweisen, um ein reproduzierbares und deterministisches Verhalten des partitionierten eingebetteten Systems zu erreichen. Das beschriebene computerimplementierte Verfahren bewirkt daher ein sehr deterministisches Verhalten hinsichtlich Datenkommunikation im partitionierten eingebetteten System. Es ist daher möglich, dass das gesamte System einen hohen Grad an Datendeterminismus aufweist.
-
Gemäß der vorliegenden Offenbarung wird die Freiheit von zeitlicher Interferenz zwischen Kommunikationen der verschiedenen Softwarecluster erhöht, und die Möglichkeit unabhängiger Freigaben und Validierungen verschiedener Softwarecluster im partitionierten eingebetteten System wird weiter erhöht. Ferner ist es gemäß der vorliegenden Offenbarung möglich, ein definiertes Zeitverhalten zur Eingabe und Ausgabe zwischen den verschiedenen Softwareclustern zu implementieren, und somit ist es möglich, die Anzahl von Kopien in den Speicher der verschiedenen Softwarecluster zu reduzieren, was Mikroprozessor-/Mikrocontrollerressourcen des partitionierten eingebetteten Systems einspart. Ein anderer Vorteil des computerimplementierten Verfahrens gemäß der vorliegenden Offenbarung besteht darin, dass es einen Top-down-Ansatz für die Auslegung der Softwarecluster und der Kommunikation zwischen ihnen durch eine vorherige Fixierung der clusterübergreifenden Kommunikationsfenster für das vollständige System ermöglicht.
-
Gemäß einer Ausführungsform verwendet das partitionierte eingebettete System eine offene Systemarchitektur für die Automobiltechnik (AUTOSAR - Automotive Open System Architecture). Die Implementierung des Verfahrens gemäß der vorliegenden Offenbarung ist besonders einfach, wenn das partitionierte eingebettete System die AUTOSAR-Architektur verwendet.
-
Gemäß einer Ausführungsform weisen die Funktionstasks der Softwarecluster eine bestimmte Priorität auf, und die clusterübergreifenden Kommunikationstasks der Softwarecluster weisen eine bestimmte Priorität auf, wobei die Priorität der clusterübergreifenden Kommunikationstasks der Softwarecluster höher ist als die Priorität der Funktionstasks der Softwarecluster, so dass eine der clusterübergreifenden Kommunikationstasks vor einer der Funktionstasks ausgeführt wird, falls sie um Ressourcen konkurrieren. Gemäß dieser Ausführungsform werden die Kommunikationstasks vor Funktionstasks ausgeführt. Dies gewährleistet, dass die Datenkommunikation zwischen den verschiedenen Softwareclustern und zwischen den verschiedenen Funktionstasks die erforderliche hohe Qualität, den erforderlichen hohen Determinismus und die erforderliche hohe Reproduzierbarkeit aufweist. Es ist daher möglich, sicherzustellen, dass alle Funktionstasks die erforderlichen Eingabedaten vor ihrer Ausführung aufweisen.
-
Gemäß einer Ausführungsform umfassen die Softwarecluster ein clusterübergreifendes Kommunikationsfenster für Eingabekommunikation und/oder ein clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation, wobei in den clusterübergreifenden Kommunikationsfenstern für Eingabekommunikation die clusterübergreifenden Kommunikationstasks Eingabedaten auslesen und in den clusterübergreifenden Kommunikationsfenstern für Ausgabekommunikation die clusterübergreifenden Kommunikationstasks Ausgabedaten schreiben. Mit anderen Worten sind die clusterübergreifenden Kommunikationsfenster gemäß dieser Ausführungsform in clusterübergreifende Kommunikationsfenster für Eingabekommunikation und in clusterübergreifende Kommunikationsfenster für Ausgabekommunikation getrennt. Dies ermöglicht eine gewünschte Trennung für dedizierte clusterübergreifende Kommunikationsfenster für Eingabekommunikation und eine dedizierte Trennung für clusterübergreifende Kommunikationsfenster für Ausgabekommunikation. Falls gemäß einer Ausführung nur eine Eingabekommunikation erforderlich ist, dann kann ein dediziertes clusterübergreifendes Kommunikationsfenster für Eingabekommunikation im Gesamtausführungsplan vorgesehen werden, und falls nur eine Ausgabekommunikation erforderlich ist, dann kann ein dediziertes clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation im Gesamtplan vorgesehen werden. Dies ermöglicht eine noch bessere und genauere deterministische Kommunikation im gesamten partitionierten eingebetteten System. Gemäß einer Ausführungsform ist es zum Beispiel möglich, dass auf ein clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation unmittelbar ein clusterübergreifendes Kommunikationsfenster für Eingabekommunikation folgt. In diesem Fall folgt die Eingabekommunikation unmittelbar auf die Ausgabekommunikation, so dass die gewünschte Eingabe für die Funktionstask bereitgestellt wird und dass die gewünschte Ausgabe an die erforderlichen Funktionstasks eines anderen Softwareclusters gesendet wird.
-
Gemäß einer Ausführungsform umfasst ein Mikroprozessor des partitionierten eingebetteten Systems eine Mehrzahl von Kernen, und wobei die clusterübergreifenden Kommunikationstasks Kommunikation zwischen den verschiedenen Kernen des Mikroprozessors bereitstellen. Gemäß dieser Ausführungsform wird das computerimplementierte Verfahren gemäß der vorliegenden Offenbarung zum Bereitstellen der erforderlichen deterministischen Datenkommunikation zwischen verschiedenen Kernen des Mikroprozessors des partitionierten eingebetteten Systems verwendet. Verschiedene Softwarecluster können auf verschiedenen Kernen des Mikroprozessors ausgeführt werden. Diese verschiedenen Softwarecluster erfordern Kommunikation über verschiedene Kerne des Mikroprozessors mit dem computerimplementierten Verfahren gemäß der vorliegenden Offenbarung, der die Kommunikationsfenster zum Beispiel auf den verschiedenen Kernen aufweist, so dass die deterministische Kommunikation zwischen den verschiedenen Softwareclustern auf den verschiedenen Kernen des Mikroprozessors möglich ist. Gemäß dieser Ausführungsform ist daher die deterministische und sehr spezifische Kommunikation zwischen der Mehrzahl der verschiedenen Kerne des Mikroprozessors möglich.
-
Gemäß einer anderen Ausführungsform umfasst das partitionierte eingebettete System eine Mehrzahl von Mikroprozessoren und/oder Mikrocontrollern, wobei jeder der Mikroprozessoren/Mikrocontroller eine Mehrzahl von Kernen aufweisen kann. Mit dem Softwarecluster im partitionierten eingebetteten System mit den dedizierten clusterübergreifenden Kommunikationsfenstern auf jedem Mikroprozessor ist die deterministische Datenkommunikation zwischen den verschiedenen Mikroprozessoren und zwischen den Kernen der verschiedenen Mikroprozessoren möglich. Daher ist im gesamten partitionierten eingebetteten System eine deterministische, spezifische und stabile Datenkommunikation während des Betriebs des partitionierten eingebetteten Systems möglich.
-
Gemäß einer Ausführungsform sind alle der clusterübergreifenden Kommunikationsfenster nur auf einem spezifischen Kern eines Mehrkern-/Mehrprozessorsystems vorgesehen. Gemäß dieser Ausführungsform umfasst der Mikroprozessor mehrere Kerne, und alle der clusterübergreifenden Kommunikationsfenster für die clusterübergreifenden Kommunikationstasks sind spezifisch nur auf einem Kern vorgesehen. Dies ermöglicht eine verhältnismäßig einfache Auslegung und Zuweisung der verschiedenen clusterübergreifenden Kommunikationstasks des eingebetteten Systems. Gemäß dieser Ausführungsform besteht keine Notwendigkeit einer Synchronisation zwischen den verschiedenen Kernen, wenn eine Aktualisierung für eine clusterübergreifende Kommunikationstask erforderlich ist, was die Komplexität des Systems reduziert. Ferner können gemäß dieser Ausführungsform Konflikte im Falle synchroner Aktualisierungen für verschiedene Kerne vermieden werden.
-
Gemäß einer Ausführungsform sind die verschiedenen clusterübergreifenden Kommunikationsfenster auf verschiedenen Kernen des Mikroprozessors/Systems vorgesehen. Gemäß dieser Ausführungsform umfasst der Mikroprozessor verschiedene Kerne, und auf diesen Kernen sind die verschiedenen clusterübergreifenden Kommunikationsfenster für die clusterübergreifenden Kommunikationstasks vorgesehen. Zum Beispiel umfasst jeder Kern der verschiedenen Kerne des Mikroprozessors mindestens ein dediziertes clusterübergreifendes Kommunikationsfenster für die gewünschten clusterübergreifenden Kommunikationstasks. Das Gruppieren der Funktionstasks und der clusterübergreifenden Kommunikationstasks desselben Softwareclusters auf demselben Kern ermöglicht eine vorteilhafte Steuerung des Flusses zwischen den clusterübergreifenden Kommunikationsfenstern und den Funktionstasks und verbessert die Planung des kompletten Tasks-Setup. Es ermöglicht eine kernlokale Zuweisung des Speichers, was die Leistungen verbessert.
-
Gemäß einer Ausführungsform folgt mindestens ein Funktionsfenster auf die dedizierten clusterübergreifenden Kommunikationsfenster für Eingabe- oder Ausgabekommunikation oder geht diesen voraus. Mit anderen Worten folgt nach einem clusterübergreifenden Kommunikationsfenster für Eingabekommunikation mindestens ein Funktionsfenster für eine Funktionstask, und/oder mindestens ein Funktionsfenster für eine Funktionstask geht einem clusterübergreifenden Kommunikationsfenster für Ausgabekommunikation voraus. Zum Beispiel beginnt eine Periode von fünf Millisekunden des Ausführungsplans mit einem dedizierten clusterübergreifenden Kommunikationsfenster für Eingabekommunikation, auf das ein erstes Funktionsfenster für eine erste Funktionstask folgt, auf das wiederum ein zweites Funktionsfenster für eine zweite Funktionstask folgt, auf das wiederum ein drittes Funktionsfenster für eine dritte Funktionstask folgte, worauf ein dediziertes clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation folgt, das diese spezifische Periode zum Beispiel auf einem Kern eines Mikroprozessors des eingebetteten Systems abschließt. Gemäß dieser Ausführungsform ist es daher möglich, die erforderlichen Eingabedaten während des dedizierten clusterübergreifenden Kommunikationsfensters für Eingabedaten auszulesen und danach die erforderliche Funktionstask mit den ausgelesenen Eingabedaten auszuführen und nach der erfolgreichen Ausführung der Funktionstasks die erforderlichen Ausgabedaten während des dedizierten clusterübergreifenden Kommunikationsfensters für Ausgabekommunikation in andere Softwarecluster zu schreiben. Insgesamt ist die Kommunikation zwischen den verschiedenen Softwareclustern und den verschiedenen Kernen von verschiedenen Mikroprozessoren des eingebetteten Systems sehr stabil und deterministisch. Gemäß dieser Ausführungsform bestehen die Vorteile darin, dass das System und das Verfahren hinsichtlich Platzierung versus Intervalle flexibler sind. Es genügt, zu gewährleisten, dass alle Funktionstasks die erforderlichen Ausgabedaten vor Beginn des dedizierten clusterübergreifenden Kommunikationsfensters für Ausgabekommunikation erzeugt haben und dass alle Funktionstasks die erforderlichen Eingabedaten nach dem Ende des dedizierten clusterübergreifenden Kommunikationsfensters für Eingabekommunikation auslesen. Die tatsächliche Verwendung der Daten kann von einer Funktionstask ohne Auswirkungen auf die Kommunikationstasks zu einer anderen verschoben werden, solange diese Bedingung gewährleistet ist.
-
Gemäß einer Ausführungsform umfasst der Ausführungsplan Ausführungsperioden, in welchen vordefinierte Funktionstasks ausgeführt werden, und wobei jede Ausführungsperiode nur ein clusterübergreifendes Kommunikationseingabefenster und nur ein clusterübergreifendes Kommunikationsausgabefenster umfasst. Mit anderen Worten gibt es für jede Ausführungsperiode ein dediziertes clusterübergreifendes Kommunikationseingabefenster und ein dediziertes clusterübergreifendes Kommunikationsausgabefenster für Eingabekommunikation und Ausgabekommunikation. Das clusterübergreifende Kommunikationseingabefenster ist gemäß einer Ausführungsform an Beginn der Ausführungsperiode und das dediziertes clusterübergreifendes Kommunikationsausgabefenster ist gemäß einer Ausführungsform am Ende der Ausführungsperiode. Die Funktionsfenster für die vordefinierten Funktionstasks sind gemäß einer Ausführungsform zwischen dem clusterübergreifenden Kommunikationseingabefenster und dem clusterübergreifenden Kommunikationsausgabefenster. Vor der ersten Funktionstask wird das clusterübergreifende Kommunikationseingabefenster mit der clusterübergreifenden Kommunikationseingabetask ausgeführt, so dass alle erforderlichen Eingabedaten für die vordefinierten Funktionstasks von anderen Softwareclustern ausgelesen werden. Danach werden die Funktionstasks ausgeführt, die Eingabedaten verwenden und Ausgabedaten erzeugen. Danach wird das clusterübergreifende Kommunikationsausgabefenster mit der clusterübergreifenden Kommunikationsausgabetask ausgeführt, um die Ausgabedaten von der ausgeführten Funktionstask in andere Softwarecluster zu schreiben. Gemäß dieser Ausführungsform ist die gesamte Architektur des eingebetteten Systems vorteilhaft einfach und robust.
-
Gemäß einer Ausführungsform umfasst der Ausführungsplan Ausführungsperioden, in welchen vordefinierte Funktionstasks ausgeführt werden, und wobei jede Ausführungsperiode ein oder mehrere clusterübergreifende Kommunikationseingabefenster und/oder ein oder mehrere clusterübergreifende Kommunikationsausgabefenster umfasst. Gemäß dieser Ausführungsform ist die Anzahl von clusterübergreifenden Kommunikationseingabefenstern und/oder clusterübergreifenden Kommunikationsausgabefenstern innerhalb einer Ausführungsperiode nicht begrenzt, was bedeutet, dass die Ausführungsperioden mehr als ein clusterübergreifendes Kommunikationseingabefenster und/oder mehr als ein clusterübergreifendes Kommunikationsausgabefenster aufweisen können. Zum Beispiel beginnt eine Ausführungsperiode mit einem clusterübergreifenden Kommunikationseingabefenster, auf das zum Beispiel zwei Funktionsfenster folgen, worauf ein clusterübergreifendes Kommunikationseingabefenster folgt, auf das ein weiteres Funktionsfenster folgt, worauf ein clusterübergreifendes Kommunikationsausgabefenster folgt, das die Ausführungsperiode abschließt. Gemäß dieser Ausführungsform ist es daher möglich, Daten für die spezifischen Funktionstasks während der definierten clusterübergreifenden Kommunikationseingabefenster oder während der definierten clusterübergreifenden Kommunikationsausgabefenster beispielsweise selbst inmitten der Ausführungsperiode auszulesen oder zu schreiben. Es ist daher möglich, verschiedene Kommunikationsschlitze zwischen verschiedenen Softwareclustern innerhalb einer Periode bereitzustellen. Diese Ausführungsform ermöglicht eine große Freiheit für die Auslegung des Ausführungsplans für verschiedene Tasks des eingebetteten Systems. Ferner ermöglicht sie vorteilhafte schnelle Kommunikationspfade zwischen den verschiedenen Softwareclustern.
-
Gemäß einer Ausführungsform sind mindestens zwei clusterübergreifende Kommunikationsfenster über mindestens zwei Kerne des Mikroprozessors synchronisiert. Falls zum Beispiel der Mikroprozessor zwei Kerne umfasst, führen die beiden Kerne parallel verschiedene Funktionstasks des Plans aus. Gemäß dieser Ausführungsform weisen die verschiedenen Pläne der verschiedenen Kerne die clusterübergreifenden Kommunikationsfenster in denselben Zeitschlitzen auf. Dies führt zu einer parallelen Ausführung der clusterübergreifenden Kommunikationstasks über die verschiedenen Kerne des Mikroprozessors. Diese Ausführungsform stellt den Vorteil einer verhältnismäßig einfachen Architektur des gesamten partitionierten eingebetteten Systems bereit. Falls außerdem clusterübergreifende Kommunikationseingabetasks verschiedener Kerne simultan sind und clusterübergreifende Kommunikationsausgabetasks verschiedener Kerne simultan sind, besteht keine Gefahr eines gleichzeitigen Zugriffs aus dieselben Daten, und daher besteht keine Gefahr von Inkonsistenz.
-
Gemäß einem weiteren Aspekt der vorliegenden Offenbarung wird eine elektronische Steuereinheit für eine deterministische Datenkommunikation spezifiziert. Die elektronische Steuereinheit gehört zu einem partitionierten eingebetteten System, wobei das eingebettete System eine Mehrzahl von Softwareclustern mit Funktionstasks und clusterübergreifenden Kommunikationstasks umfasst, wobei die elektronische Steuereinheit Mittel umfasst, die zum Ausführen eines des vorstehenden computerimplementierten Verfahren ausgelegt sind. Es ist denkbar, dass die elektronische Steuereinheit eine elektronische Steuereinheit für einen Antriebsstrang eines Fahrzeugs, beispielsweise eines batteriebetriebenen Fahrzeugs, sein kann. Es ist auch denkbar, dass die elektronische Steuereinheit in einer Serverarchitektur des Elektrofahrzeugs implementiert ist. Gemäß einer anderen Ausführungsform umfasst die elektronische Steuereinheit mehrere Steuereinheiten, zum Beispiel eine Hauptsteuerung oder einen Fahrzeugserver, die das gesamte partitionierte eingebettete System beispielsweise eines Fahrzeugs bilden.
-
Weitere vorteilhafte Ausführungsformen der vorliegenden Offenbarung gehen aus der detaillierten Beschreibung der beispielhaften Ausführungsformen in Verbindung mit den Figuren hervor.
-
In den Figuren stellt
- 1 eine herkömmliche clusterübergreifende Kommunikation zwischen zwei Softwareclustern schematisch dar,
- 2 stellt eine clusterübergreifende Kommunikation zwischen zwei Softwareclustern gemäß einer ersten beispielhaften Ausführungsform schematisch dar,
- 3 stellt zwei Details von Ausführungsplänen gemäß zwei verschiedenen Ausführungsformen schematisch dar,
- 4 stellt einen ersten Ausführungsplan gemäß einer ersten beispielhaften Ausführungsform schematisch dar,
- 5 stellt einen zweiten Ausführungsplan gemäß einer zweiten beispielhaften Ausführungsform schematisch dar,
- 6 stellt einen dritten Ausführungsplan gemäß einer dritten beispielhaften Ausführungsform schematisch dar,
- 7 stellt einen vierten Ausführungsplan gemäß einer vierten beispielhaften Ausführungsform schematisch dar,
- 8 stellt einen fünften Ausführungsplan gemäß einer fünften beispielhaften Ausführungsform schematisch dar.
-
1 stellt ein erstes Diagramm 100 von Datenkommunikation zwischen zwei verschiedenen Softwareclustern 110, 120 dar. Das erste Diagramm 100 umfasst einen ersten Cluster A 110 und einen zweiten Cluster B 120. Der Cluster A 110 umfasst ein Intervall A1 112 und ein Intervall A2 114 und ein Intervall A3 116. Der Cluster B 120 umfasst ein Intervall B1 122, ein Intervall B2 124 und ein Intervall B3 126. Das Intervall A1 112 führt eine erste Funktionstask aus und erzeugt Ausgabedaten. Diese Ausgabedaten DA1 werden für das Intervall B1 122 und das Intervall B3 126 bereitgestellt. Das Intervall A2 114 führt danach eine zweite Funktionstask aus, die Ausgabedaten DA2 erzeugt. Diese Ausgabedaten DA2 werden für das Intervall B3 126 bereitgestellt. Das letzte Intervall A3 116 des Clusters A 110 liest Eingabedaten des Intervalls B2 124 des Clusters B 120 aus und führt danach eine dritte Funktionstask aus. Das Intervall B1 122 des Clusters B 120 liest Eingabedaten DA1 aus, die im Intervall A1 112 erzeugt wurden. Das Intervall B1 122 führt danach eine Funktionstask aus. Das Intervall B2 124 führt eine Funktionstask aus, die Ausgabedaten DB2 erzeugt. Diese Ausgabedaten DB2 werden für das Intervall A3 116 des Clusters A 110 bereitgestellt. Das Intervall B3 126 des Clusters B 120 liest die Eingabedaten DA1 und DA2 des Intervalls A1 112 und des Intervalls A2 des Clusters A 110 aus. Das erste Diagramm 100 veranschaulicht die Schwierigkeit der Kommunikation zwischen verschiedenen Clustern 110, 120. Beide Cluster können z. B. auf separaten Kernen gleichzeitig ausgeführt werden. Daten, die in einem Cluster erzeugt wurden, sollten zur Ausführung verschiedener Tasks bereits an den anderen Cluster übertragen worden sein, aber die Task wurde bereits mit alten oder falschen Daten ausgeführt, die aufgrund der verschiedenen Kommunikationsschlitze eingegeben wurden. Die gesamte Kommunikation zwischen verschiedenen Softwareclustern gemäß dieser Ausführungsform ist nicht deterministisch und kann zu unberechenbaren Verzögerungen in der Kommunikation zwischen Softwareclustern führen. Ein anderes Problem besteht darin, dass die Daten, die in verschiedenen Intervallen verbraucht werden, so oft erfasst werden, wie sie verwendet werden, und dies daher zu Instabilität und Inkonsistenz innerhalb der Softwarecluster führt.
-
2 stellt ein zweites Diagramm 150 einer clusterübergreifenden Kommunikation gemäß einer ersten beispielhaften Ausführungsform dar. Das zweite Diagramm 150 umfasst einen ersten Softwarecluster 152 und einen zweiten Softwarecluster 154. Die Softwarecluster 152, 154 umfassen verschiedene Softwarekomponenten 156, die zum Beispiel Softwareblöcke sind. Ferner umfassen die Softwarecluster 152, 154 verschiedene Funktionstasks 158, die innerhalb von Funktionsfenstern (nicht dargestellt) ausgeführt werden. Die verschiedenen Funktionstasks 158 erfordern verschiedene Softwarekomponenten 156 für ihre Tasks, dies ist mit der Verbindung zwischen den verschiedenen Funktionstasks 158 und den verschiedenen Softwarekomponenten 156 dargestellt. Ferner stellen kleine Pfeile zwischen den Funktionstasks 158 innerhalb eines Softwareclusters 152, 154 eine mögliche Datenkommunikation zwischen den verschiedenen Funktionstasks 158 innerhalb eines Softwareclusters 152, 154 dar. Das zweite Diagramm 150 umfasst ferner clusterübergreifende Kommunikationsausgabetasks 160 und clusterübergreifende Kommunikationseingabetasks 162, die innerhalb von clusterübergreifenden Kommunikationsfenstern (nicht dargestellt) ausgeführt werden. Die clusterübergreifenden Kommunikationsausgabetasks 160 schreiben Ausgabedaten von einem Softwarecluster 154, 152 in einen anderen Softwarecluster 152, 154. Die clusterübergreifenden Kommunikationseingabetasks 162 lesen Eingabedaten von einem anderen Softwarecluster 154, 152 für den eigenen Softwarecluster 152, 154 aus. Der softwareclusterübergreifende Datenfluss ist in 2 mit den Pfeilen zwischen den clusterübergreifenden Kommunikationstasks 160, 162 dargestellt. Die ausgelesenen Eingabedaten werden danach für die Funktionstasks 158 bereitgestellt. Und Daten, die von Funktionstasks 158 erzeugt werden, werden danach für clusterübergreifende Kommunikationsausgabetasks 160 zur clusterübergreifende Kommunikation bereitgestellt. Die clusterübergreifenden Kommunikationstasks 160, 162 unterscheiden sich von den Funktionstasks 158 im Gesamtausführungsplan, wie in 2 zu sehen ist. Diese Unabhängigkeit ermöglicht die gewünschte deterministische Kommunikation zwischen den verschiedenen Softwareclustern 152, 154 insbesondere im Gegensatz zu der Kommunikation zwischen Softwareclustern, die in 1 dargestellt ist.
-
3 stellt ein drittes Diagramm 200 dar, das ein erstes Detail 210 eines Ausführungsplans gemäß einer herkömmlichen Ausführungsform und ein zweites Detail 220 eines Ausführungsplans gemäß einer zweiten beispielhaften Ausführungsform der vorliegenden Offenbarung umfasst. Das erste Detail 210 stellt die Ausführung von Tasks innerhalb einer ersten Periode 211 dar. Die Tasks werden innerhalb von Funktionsfenstern 212 ausgeführt. Eine Taskausführung 213 innerhalb des Funktionsfensters 212 ist in 2 als graue Rechtecke dargestellt. Ferner werden innerhalb des Funktionsfensters 212 Daten an die Funktionstask und von den Funktionstasks kommuniziert. Das erste Detail 210 stellt für die Datenkommunikation Pfeile für Dateneingabe 214 und Pfeile für Datenausgabe 215 dar. Die Dateneingabepfeile 214 zeigen zu den Funktionsfenstern 212 hin, und die Datenausgabepfeile 215 zeigen von den Funktionsfenstern 212 weg. Wie im ersten Detail 210 zu sehen ist, ist die Kommunikation zwischen den verschiedenen Tasks nicht deterministisch, was zu instabilen Datenaltern zur Taskausführung aufgrund von Jitter-Problemen führen kann. Im Gegensatz dazu stellt das zweite Detail 220 eine hochdeterministische Datenkommunikation zwischen den verschiedenen Tasks gemäß der vorliegenden Offenbarung dar. Das zweite Detail 220 umfasst zwei zweite Perioden 221, innerhalb derer Funktionsfenster 222, clusterübergreifende Kommunikationseingabefenster 224 und clusterübergreifende Kommunikationsausgabefenster 226 platziert sind. Das zweite Detail 220 umfasst ferner eine dritte Periode 228, innerhalb derer andere Funktionsfenster 222, ein anderes clusterübergreifendes Kommunikationseingabefenster 224 und ein anderes clusterübergreifendes Kommunikationsausgabefenster 226 platziert sind, die zu einem weiteren Softwarecluster gehören können. Innerhalb der Funktionsfenster 222 werden Funktionstasks 223 ausgeführt, innerhalb der clusterübergreifenden Kommunikationseingabefenster 224 werden clusterübergreifende Kommunikationseingabetasks 225 ausgeführt, und innerhalb der clusterübergreifenden Kommunikationsausgabefenster 226 werden clusterübergreifende Kommunikationsausgabetasks 227 ausgeführt. Die spezifische Taskausführung ist im zweiten Detail 220 mit grauen oder schwarzen Rechtecken dargestellt. Die clusterübergreifenden Kommunikationstasks 225, 227 weisen ferner entsprechende Pfeile auf. Mit den spezifischen Kommunikationsfenstern 224, 226 ist eine hochdeterministische Datenkommunikation zwischen verschiedenen Softwareclustern oder selbst verschiedenen Kernen oder elektronischen Steuereinheiten innerhalb des eingebetteten Systems möglich.
-
4 stellt einen ersten Ausführungsplan 300 dar. Der erste Ausführungsplan 300 umfasst Funktionsfenster 320 und clusterübergreifende Kommunikationsfenster 310. Die Funktionsfenster 320 werden für Funktionstasks (nicht dargestellt) disponiert, die während der Funktionsfenster 320 ausgeführt werden. Die clusterübergreifenden Kommunikationsfenster 310 werden im Ausführungsplan 300 für Kommunikationstasks (nicht dargestellt) zwischen verschiedenen Softwareclustern implementiert. Verschiedene Softwarecluster können verschiedene Funktionsfenster 320 und entsprechend verschiedene Funktionstasks umfassen, die während der verschiedenen Funktionsfenster 320 ausgeführt werden. Ferner umfassen die Softwarecluster verschiedene clusterübergreifende Kommunikationsfenster 310, während derer die verschiedenen clusterübergreifenden Kommunikationstasks zur Kommunikation zwischen den verschiedenen Softwareclustern ausgeführt werden. Wie in 4 zu sehen ist, sind die clusterübergreifenden Kommunikationsfenster 310 im ersten Ausführungsplan 300 verschieden/unabhängig von den verschiedenen Funktionsfenstern 320 platziert, was bedeutet, dass die clusterübergreifenden Kommunikationsfenster 310 nur für spezifische clusterübergreifende Kommunikationstasks reserviert sind. Daher ist eine hochdeterministische Kommunikation zwischen den verschiedenen Softwareclustern im eingebetteten System möglich. Die verschiedenen Funktionstasks können während der verschiedenen Funktionsfenster 320 ausgeführt werden und die Ausgabedaten erzeugen. Danach werden die erzeugten Ausgabedaten während einer Ausführung einer clusterübergreifenden Kommunikationstask in einem clusterübergreifenden Kommunikationsfenster 310 zum Beispiel an eine andere Funktionstask in einem anderen Funktionsfenster 320 gesendet. Gemäß dieser Ausführungsform ist daher eine hochdeterministische und spezifische Kommunikation zwischen den verschiedenen Softwareclustern des partitionierten eingebetteten Systems beispielsweise einer AUTOSAR-basierten Softwarearchitektur möglich.
-
5 stellt einen zweiten Ausführungsplan 400 dar. Der zweite Ausführungsplan 400 umfasst zwei verschiedene Pläne. Beide Pläne werden in einem Mehrkern-Mikroprozessor verwendet. Der Mikroprozessor, der zur Ausführung des zweiten Ausführungsplans 400 verwendet wird, umfasst einen ersten Kern A2 410, einen zweiten Kern A3 420 und einen dritten Kern B0 430. Jeder Kern weist einen dedizierten Plan auf, der clusterübergreifende Kommunikationsfenster 310 und Funktionsfenster 320 umfasst. Der Unterschied zwischen den beiden Plänen, die im zweiten Ausführungsplan 400 dargestellt sind, liegt darin, dass im oberen Plan alle clusterübergreifenden Kommunikationsfenster 310 nur im ersten Kern A2 410 disponiert werden. Gemäß dieser Ausführungsform werden alle clusterübergreifenden Kommunikationstasks auf dem ersten Kern A2 410 ausgeführt. Der untere Plan des zweiten Ausführungsplans 400 zeigt, dass alle Kerne clusterübergreifende Kommunikationsfenster 310 umfassen. Daher werden die clusterübergreifenden Kommunikationstasks, die während der clusterübergreifenden Kommunikationsfenster 310 ausgeführt werden, auf allen der verschiedenen Kerne 410, 420, 430 ausgeführt.
-
6 stellt einen dritten Ausführungsplan 500 dar. Auch der dritte Ausführungsplan 500 weist hier zwei verschiedene Pläne auf. Der obere Plan weist clusterübergreifende Kommunikationsfenster 310 und Funktionsfenster 320 auf. Die clusterübergreifenden Kommunikationsfenster 310 umfassen ein clusterübergreifendes Kommunikationsfenster für Eingabekommunikation 510 und ein clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation 520. Das clusterübergreifende Kommunikationsfenster für Eingabekommunikation 510 und das clusterübergreifende Kommunikationsfenster für Ausgabekommunikation 520 sind in 6 mit zwei Dreiecken dargestellt, wobei ein Dreieck das clusterübergreifende Kommunikationsfenster für Eingabekommunikation 510 anzeigt und das andere Dreieck das clusterübergreifende Kommunikationsfenster für Ausgabekommunikation 520 anzeigt. Der obere Plan in 6 zeigt, dass das clusterübergreifende Kommunikationsfenster für Eingabekommunikation 510 und das clusterübergreifende Kommunikationsfenster für Ausgabekommunikation 520 im clusterübergreifenden Kommunikationsfenster 310 miteinander kombiniert sind, was bedeutet, dass die Ausgabekommunikation und die Eingabekommunikation nacheinander ausgeführt werden, bevor eine Funktionstask in einem Funktionsfenster 320 ausgeführt wird. Wie im unteren Plan von 6 zu sehen ist, sind das clusterübergreifende Kommunikationsfenster für Eingabekommunikation 510 und das clusterübergreifende Kommunikationsfenster für Ausgabekommunikation 520 über den gesamten Plan getrennt. Mit anderen Worten beginnt der Plan, wie in 6 zu sehen ist, mit einem clusterübergreifenden Kommunikationsfenster für Eingabekommunikation 510, das zum Beispiel Eingabedaten für verschiedene Funktionstasks ausliest. Danach führt der Plan in verschiedenen Funktionsfenstern 320 verschiedene Funktionstasks aus, und die Periode wird durch ein clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation 520 abgeschlossen, das Ausgabedaten für einen spezifischen Softwarecluster schreibt. Der untere Plan von 6 zeigt ein dediziertes clusterübergreifendes Kommunikationsfenster für Eingabekommunikation 510 und ein dediziertes clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation 520, die eine hochdeterministische Auslegung des Gesamtplans ermöglichen, wie in Bezug auf erforderliche Eingabedaten und/oder in Bezug auf bereitgestellte Ausgabedaten gewünscht.
-
7 stellt einen vierten Ausführungsplan 600 dar. Auch der vierte Ausführungsplan 600 ist hier in einen oberen Plan und in einen unteren Plan getrennt. Der vierte Ausführungsplan 600 weist wiederum verschiedene clusterübergreifende Kommunikationsfenster 310 auf, die ein clusterübergreifendes Kommunikationsfenster für Eingabekommunikation 510 und ein clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation 520 umfassen. Ferner umfasst der vierte Ausführungsplan 600 Funktionsfenster 320 für Funktionstasks. Der vierte Ausführungsplan 600, wie in 7 dargestellt, umfasst ferner eine erste Ausführungsperiode 610, eine zweite Ausführungsperiode 620 und eine dritte Ausführungsperiode 630. Die erste Ausführungsperiode 610 ist zum Beispiel eine Ausführungsperiode von fünf Millisekunden, die zweite Ausführungsperiode 620 ist zum Beispiel eine Ausführungsperiode von zehn Millisekunden, und die dritte Ausführungsperiode 630 ist zum Beispiel eine Ausführungsperiode von 20 Millisekunden. Dies wird durch die Klammern angezeigt, die in 7 dargestellt sind. Wie im oberen Plan zu sehen ist, umfassen die erste Ausführungsperiode 610, die zweite Ausführungsperiode 620 und die dritte Ausführungsperiode 630 nur ein clusterübergreifendes Kommunikationsfenster für Eingabekommunikation 510 und nur ein clusterübergreifendes Kommunikationsfenster für Ausgabekommunikation 520. Dies ist für jeden Kern 410, 420, 430 der Fall. Der untere Plan, wie in 7 dargestellt, unterscheidet sich darin, dass es innerhalb verschiedener Ausführungsperioden möglich ist, dass mehrere clusterübergreifende Kommunikationsfenster für Eingabekommunikation 510 oder mehrere clusterübergreifende Kommunikationsfenster für Ausgabekommunikation 520 bereitgestellt und ausgeführt werden können. Es ist daher möglich, Eingabedaten mehr als einmal innerhalb einer Ausführungsperiode auszulesen oder Ausgabedaten mehr als einmal innerhalb einer Ausführungsperiode zu schreiben und daher verschiedene Daten zu verschiedenen Zeitpunkten zu kommunizieren.
-
8 stellt einen fünften Ausführungsplan 700 dar. Der fünfte Ausführungsplan 700 umfasst ebenfalls einen oberen Plan und in einen unteren Plan. Der Unterschied im fünften Ausführungsplan 700 gegenüber den anderen Ausführungsplänen liegt darin, dass die die clusterübergreifenden Kommunikationsfenster für Eingabekommunikation 510 und/oder die clusterübergreifenden Kommunikationsfenster für Ausgabekommunikation 520 nicht immer über die Kerne 410, 420, 430 synchronisiert sind, was im unteren Plan dargestellt ist. Im oberen Plan sind die clusterübergreifenden Kommunikationsfenster für Eingabekommunikation 510 und/oder die clusterübergreifende Kommunikationsfenster für Ausgabekommunikation 520 über die Kerne 410, 420, 430 synchronisiert.
