DE102014103139B4

DE102014103139B4 - Parallelisierte Ausführung von Single-Core Steuerungssoftware auf Multi-Core Fahrzeugsteuergeräten

Info

Publication number: DE102014103139B4
Application number: DE102014103139.3A
Authority: DE
Inventors: c/o DENSO Automotive D. Kehr Sebastian; c/o DENSO Automotive D. Böddeker Bert; c/o TU Ilmenau Schäfer Günther; c/o Barcelona Supercom. Quinones Eduardo
Original assignee: Denso Automotive Deutschland GmbH
Current assignee: Denso Automotive Deutschland GmbH
Priority date: 2014-03-10
Filing date: 2014-03-10
Publication date: 2017-08-10
Anticipated expiration: 2034-03-11
Also published as: DE102014103139A1

Abstract

Die Erfindung betrifft ein Verfahren zur Portierung von Alt-Steuerungssoftware (100), die für ein Steuergerät (102) mit einem Einzel-Rechenkern (C0) entwickelt ist, auf ein Fahrzeugsteuergerät (103) mit mindestens zwei Rechenkernen (C1, C2, C3). In der Alt-Steuerungssoftware (100) sind Tasks (T-1, T-8, T-Cr) mit jeweils einem oder mehreren Ablaufteile (R_i) sowie eine Ausführungs-Rangfolge (106) für die Tasks enthalten. Es werden Vorrang-Beschränkungen (PC1, PC2, PC3) für schreibende und lesende Zugriffe auf gemeinsame persistente Speichervariablen (Va, Vb) ermittelt und schwache Vorrang-Beschränkungen (PC2, PCx, PCy) nach vorbestimmten Klassifizierungsregeln (109) identifiziert. Ein Ausführungsplans (105) für die Ausführung der Alt-Steuerungssoftware auf den zwei oder mehr Rechenkernen (C1, C2, C3) wird erzeugt, und zwar unter Parallelisierung von Ablaufteilen (R_11, R_81) mit schwachen Vorrang-Beschränkungen (PC2). Für jede schwache Vorrang-Beschränkung (PC2) wird die zugehörige persistente Speichervariable (Va) in einer getrennt verwalteten Datenbasis (108) gespeichert, die einen wartezeitfreien lesenden und schreibenden Zugriff zulässt.

Description

Die Arbeiten, die zu dieser Erfindung geführt haben, wurden gemäß der Finanzhilfevereinbarung Nr. 287519 im Zuge des Siebten Rahmenprogramms der Europäischen Union (RP7/2007-2013) gefördert.
Die Erfindung betrifft ein Verfahren zur Portierung von Alt-Steuerprogrammen, die für die Ausführung auf einem Einzel-Rechenkern (Single-Core) entwickelt sind, auf ein Fahrzeugsteuergerät (ECU) mit mindestens zwei Rechenkernen (Multi-Core).
Bisher sind keine zufriedenstellenden Verfahren zur Ausführung von Single-Core Steuerungssoftware auf Multi-Core Steuergeräten für den automotiven Einsatz bekannt, sodass auf eine Parallelisierung von Tasks weitgehend verzichtet wird und umfassende Teile der Alt-Steuerungssoftware häufig auf nur einem einzigen der mehreren Rechenkerne ausgeführt werden.
In der Praxis gibt es zwar Verfahren zur parallelisierten Ausführung von für Single-Core entwickelter Alt-Software auf Multi-Core Rechnern aus anderen Anwendungsbereichen, insbesondere aus dem Bereich der PC-Software. Diese Verfahren sind für die parallelisierte Ausführung von Steuerungssoftware von Fahrzeugen jedoch ungeeignet, da sie den besonderen Echtzeit- und Sicherheitsanforderungen nicht gerecht werden. In automobiler Software existiert ferner aufgrund zyklischer Ausführung kein fester Start- oder Endzeitpunkt, wie dies bei PC-Programmen typisch ist, was ebenfalls die Anwendung der hierzu vorbekannten Verfahren verhindert.
Allgemeine Informationen zur Parallelisierung von Single-Core Alt-Software auf Multi-Core Systeme finden sich beispielsweise in:

• Basicevic, I. et al.: An Approach to Parallelization of Legacy Software. In: Proceedings of the 2009 First IEEE Eastern European Conference on the Engineering of Computer Based Systems, 2009, S. 42–48; und
• Yohei Kanehagi et al.: Parallelization of Automotive Engine Control Software On Embedded Multi-core Processor Using OSCAR Compiler. In: Cool Chips XVI (COOL Chips), 2013, S. 1–3.

Es ist Aufgabe der vorliegenden Erfindung ein Verfahren zur parallelisierten Ausführung von (Single-Core) Alt-Steuerungssoftware auf einem Steuergerät mit mindestens zwei Rechenkernen aufzuzeigen, mit dem eine Effizienzsteigerung erreichbar ist. Ferner soll ein Softwareprodukt aufgezeigt werden, das das Verfahren ausführt. Die Erfindung löst diese Aufgabe durch die Merkmale der eigenständigen Ansprüche.
Fahrzeug-Steuerungssoftware weist einige Besonderheiten auf, die sie von anderen Softwareanwendungen unterscheiden. Beispielsweise treten zur Vermeidung von hohen Rechenverzögerungen nur sehr selten Schleifen oder Rekursionen auf. Falls Schleifen oder rekursive Funktionsaufrufe in der Alt-Steuerungssoftware enthalten sind, ist deren maximale Ausführungszahl und/oder Rekursionstiefe beschränkt. Um Daten zwischen verschiedenen Tasks und/oder deren Instanzen auszutauschen sind gemeinsame Speichervariablen definiert, auf die durch die verschiedenen Programmabschnitte zugegriffen werden kann.
Die Alt-Steuerungssoftware beinhaltet in der Regel eine Mehrzahl von Tasks (Aufgabenabschnitten). Diese Tasks führen verschiedene Aufgaben aus, wie bspw. das Ermitteln von aktuellen Messwerten und Fahrzeugparametern, deren Umwandlung in Steuer-Werte und ggfs. das Ansteuern von Aktuatoren des Fahrzeugs. Die Tasks sind in der Regel in Software-Komponenten zusammengefasst. Sie werden nach einem Interrupt (periodisch gesteuert), nach einem Ereignis (durch Events gesteuert) oder direkt durch das Betriebssystem (OS gesteuert) ausgeführt. Die Tasks weisen somit unterschiedliche Formen von Auslösern (Triggern) auf.
Die Verfahren gemäß der vorliegenden Offenbarung werden bevorzugt für Alt-Steuerungssoftware angewendet, die AUTOSAR-Komponenten enthält. AUTOSAR-Komponenten definieren Schnittstellen (Ports) für die Kommunikation. Komponenten enthalten Ablaufteile (sog. Runnables), welche durch diese Schnittstellen miteinander kommunizieren (Sender-Receiver, Client-Server). Tasks werden konfiguriert, wobei Ablaufteile (Runnables) den Tasks zugeordnet werden (Runnable-to-Task mapping).
In den Tasks wird auf flüchtige sowie persistente Speichervariablen zugegriffen. Flüchtige Speichervariablen sind meist für andere Tasks nicht zugreifbar, betreffen lediglich innere Rechenwerte eines Tasks und werden am Ende einer Einzel-Ausführung wieder freigegeben, d.h. zum Ende der Laufzeit einer Instanz eines Tasks.
Persistente Speichervariablen bleiben über die Laufzeiten mehrerer Task-Ausführungen hinweg und ggfs. für die gesamte Laufzeit der Steuerungssoftware im Speicher erhalten. Der Wert einer persistenten Speichervariablen kann sich dabei wiederholt ändern. Es können mehrfache Zugriffe von unterschiedlichen Tasks auf eine gemeinsame Speichervariable erfolgen. Alternativ oder zusätzlich können wiederholte Zugriffe von verschiedenen Instanzen desselben Tasks auf eine gemeinsame Speichervariable erfolgen. Bei der Ausführung der Alt-Steuerungssoftware auf einem Single-Core Steuergerät erfolgen die Zugriffe zwangsläufig sequenziell.
Die Tasks und/oder deren Instanzen können Schreib- und/oder Lesezugriffe ausführen. Im Fall von Speichervariablen, die für Messwerte oder Betriebsparameter am Fahrzeug dienen, gibt es in der Regel genau einen Task, der einen Schreibzugriff ausführt (Produzent) und einen oder mehrere weitere Tasks, die Lesezugriffe ausführen (Konsumenten).
In der für Single-Core Systeme entwickelten Alt-Steuerungssoftware werden die meisten Tasks durch Perioden-Trigger (der sog. Clock / einer Systemuhr) gestartet und so lange ausgeführt, bis ihre Verarbeitung abgeschlossen ist, wobei zwischenzeitige Präemption (In der Informatik auch als Verdrängung bezeichnet – English: Preemption) die Gesamtverarbeitungsdauer verlängern kann (siehe unten).
In der Regel ist ein Grundtakt für die Ausführung der periodisch gestarteten Tasks definiert, wobei die Tasks bei jedem n-ten Perioden-Trigger gestartet werden. Der Grundtakt ist grundsätzlich frei wählbar. Rein beispielhaft wird im Folgenden davon ausgegangen, dass der Grundtakt 1ms beträgt. Er könnte jedoch auch deutlich kürzer oder länger sein.
Es kann je nach Relevanz eines Tasks eine stark unterschiedliche Periodizität vorgesehen sein. Die Periodizität ist in der Regel als ein Vielfaches des Grundtaktes definiert. Als Periodizität können entsprechend Widerholungshäufigkeiten von weniger als 1 ms bis hin zu mehreren Sekunden vorgesehen sein.
Es können weiterhin in der Alt-Steuerungssoftware Tasks vorgesehen sein, die Event-basiert gestartet werden. Diese Tasks weisen also einen Event-Trigger auf. Eine Event-basierte Auslösung kann insbesondere in Abhängigkeit von einem momentanen Kurbelwinkelwert erfolgen.
Häufig ist eine Ausführungs-Rangfolge der Tasks in der Alt-Steuerungssoftware explizit definiert. Durch die Ausführungs-Rangfolge ist vorgegeben, welcher Task bei einer (Freigabe-)Kollision als nächster abzuarbeiten ist. Unter Freigabe-Kollision wird im Folgenden ein momentaner Zustand verstanden, bei dem mehr als ein Task gleichzeitig zur Ausführung ansteht. Verschiedene Varianten für das Auftreten von Kollisionen werden weiter unten erläutert.
Die Ausführungs-Rangfolge kann in beliebiger Darstellungsform vorliegen. In der Regel sind den Tasks Wichtigkeiten oder Prioritäten als Parameter zugeordnet. Alternativ oder zusätzlich können eine oder mehrere Ranglisten definiert sein, in denen jeweils für das Verhältnis von einem ersten und einem zweiten Task festgelegt ist, welcher von diesen den Vorrang hat. Alternativ können andere Mittel zur Festlegung einer Ausführungs-Rangfolge verwendet werden.
Innerhalb der Dauer eines Grundtaktes können bei einem Single-Core Steuergerät mehrere Tasks zur Ausführung anstehen, sodass es zu einer Binnen-Kollision innerhalb der Grundtaktdauer kommt. Dann werden diese Tasks gemäß der vorgegebenen Rangfolge nacheinander ausgeführt, d.h. es wird mit dem Task der höchsten Priorität bzw. des höchsten Ranges begonnen und anschließend mit dem Task der nächsten niedrigeren Priorität oder des nächst niedrigeren Ranges fortgefahren.
Wenn der letzte anstehende Task zum Beginn des nächsten Taktes noch nicht abgearbeitet wurde, kann es zu einer taktübergreifenden Kollision kommen.
Bei der Ausführung der Alt-Steuerungssoftware auf einem Einzel-Rechenkern kann stets nur ein einziger Task zu einem bestimmten Zeitpunkt abgearbeitet werden. Um sicherzustellen, dass hoch priorisierte Tasks (gerade bei taktübergreifenden Kollisionen) ohne Zeitverlust abgearbeitet werden, wird bei Single-Core Steuergeräten in der Regel eine Task-Sequenzierung mit Präemption ausgeführt (sog. „preemptive sequencing“). Die Präemption kann unter Anwendung der Ausführungs-Rangfolge erfolgen, oder unter Anwendung einer separat definierten Präemptiv-Rangfolge (Verdrängungs-Rangfolge).
Wenn zwei oder mehr Tasks konkurrierend zur Ausführung anstehen, wird anhand der jeweiligen Rangfolge entschieden, welcher Task den sofortigen Vorrang erhält. Wenn beispielsweise gerade ein niedrig priorisierter Task ausgeführt wird, und vor dessen Abarbeitung ein höher priorisierter Task zur Ausführung (neu) freigegeben wird, dann präemptiert (d.h. verdrängt) der hoch-priorisierte Task den niedrig-priorisierten Task. Das bedeutet, dass die Ausführung des niedrig priorisierten Tasks so lange unterbrochen wird, bis der höher priorisierte Task ausgeführt und voll abgearbeitet wurde. Erst danach wird die Verarbeitung des niedrig-priorisierten Tasks fortgesetzt. Mit anderen Worten wird bei einer Binnenkollision oder einer taktübergreifenden Kollision auf einem Singe-Core Steuergerät sofort der am höchsten priorisierte Task vom Prozessor verarbeitet, während die anderen Tasks pausiert werden. Die Präemption kann mehrstufig erfolgen, sodass mehrfache Unterbrechungsebenen entstehen.
Innerhalb jedes Tasks sind in der Alt-Steuerungssoftware ein oder mehrere Ablaufteile (englisch: Runnables) vorhanden. Diese Ablaufteile können explizit definiert oder durch Analyse ermittelbar sein. Die Ablaufteile werden auf einem Single-Core Steuergerät zwangsweise nacheinander, also sequenziell ausgeführt.
Die Sequenzierung der Tasks und der darin enthaltenen Ablaufteile ist in der Alt-Steuerungssoftware weitgehend festgelegt und ergibt bspw. aus dem Quellcode. Es gibt eine Makro-Sequenzierung und eine Mikro-Sequenzierung. Die Makro-Sequenzierung folgt aus dem Kontrollfluss der Tasks untereinander und ergibt sich implizit aus der Abarbeitung der Tasks gemäß der vorgegebenen Ausführungs- und/oder Präemptiv-Rangfolge (siehe oben). Die Mikro-Sequenzierung ist durch die Aufrufreihenfolge der Ablaufteile innerhalb eines Tasks vorgegeben.
Es gibt zwingende Abhängigkeiten, die bei der Entwicklung von Fahrzeug-Steuerungssoftware für die Festlegung der Mikro- und Makro-Sequenzierung berücksichtigt werden, um zu gewährleisten, dass im zeitlichen Verlauf ein gerichteter Datenfluss eingehalten wird. Dieser Datenfluss muss stets von Sensordaten ausgehen und mit der Ausgabe von Aktuator-Daten enden. Es handelt sich also um eine Von-Sensor-zu-Aktuator-Sequenzierung. Sie kann auch als Vom-Produzenten-zum-Konsumenten-Sequenzierung bezeichnet werden, wobei ein Produzent ein Ablaufteil ist, der ein von anderen Ablaufteilen genutztes Datenelement schreibt, und ein Konsument einer dieser anderen Ablaufteile ist, der auf das Datenelement zugreift. Wenn gegen diese Sequenzierung verstoßen würde, könnte es auf den Single-Core Steuergeräten zu Zugriffen auf noch nicht erzeugte Messwerte, zu Gegenkopplungen in den Regelkreisen oder zu unbestimmten Systemzuständen kommen. Die Von-Sensor-zu-Aktuator-Sequenzierung kann aus der im Code enthaltenen Mikro- und Makro-Sequenzierung rekonstruiert werden.
Die Mikro- und die Makro-Sequenzierung für die Ausführung einer Alt-Steuerungssoftware auf einem Single-Core Steuergerät können ggfs. analytisch ermittelt werden. Die Mikro-Sequenzierung (Kontrollfluss) kann beispielsweise unter Verwendung eines Compilers aus Programm-Code automatisch extrahiert werden.
Die Makro-Sequenzierung kann anhand der zugeordneten Zeit-Trigger und Task Prioritäten rekonstruiert werden.
Bei dem erfindungsgemäßen Verfahren werden die Ablaufteile der verschiedenen Tasks so weit wie möglich auf den zwei oder mehr Rechenkernen parallelisiert ausgeführt. Der Kontrollfluss und der gerichtete Datenfluss, d.h. die Makro-Sequenzierung und die Mikro-Sequenzierung der Alt-Steuerungssoftware, sollten insoweit beibehalten werden, wie dies zur Einhaltung der äußeren Anforderungen an die Steuerungssoftware erforderlich ist, insbesondere in Hinblick auf Robustheit, Vorhersagbarkeit des Verhaltens und Timing-Eigenschaften. Hierfür wird die Kommunikation (Datenweitergabe) zwischen den Ablaufteilen analysiert.
Es werden Vorrang-Beschränkungen für schreibende und lesende Zugriffe aus den Ablaufteilen auf gemeinsame persistente Speichervariablen in der Alt-Steuerungssoftware ermittelt. Diese Ermittlung kann grundsätzlich auf beliebige Weise erfolgen. Bevorzugt ist vorgesehen, dass innerhalb eines Tasks der Kontrollfluss mittels eines Compilers ermittelt wird. Aus dem Kontrollfluss werden zusammen mit den analytisch ermittelten Speicherzugriffen Vorrang-Beschränkungen extrahiert. Es kann dabei zur Vereinfachung des Verfahrens vorgesehen sein, dass nur Datenflussabhängigkeiten (von schreibenden zu lesenden Ablaufteilen) zu Vorrang-Beschränkungen führen.
Anhand von vorbestimmten Klassifizierungsregeln werden innerhalb der ermittelten Vorrang-Beschränkungen schwache und starke Vorrang-Beschränkungen identifiziert. Maßgeblich sind vor allem die als schwach klassifizierten Vorrang-Beschränkungen. Durch die Klassifizierungsregeln werden solche Vorrang-Beschränkungen ermittelt, die nur eine unwesentliche Auswirkung auf die Robustheit und/oder Vorhersagbarkeit der Steuerungssoftware haben.
Es wird ein Ausführungsplan für die Ausführung der Alt-Steuerungssoftware auf den zwei oder mehr Rechenkernen des (Multi-Core) Fahrzeugsteuergerätes erstellt, der eine Parallelisierung (auch) für diejenigen Ablaufteile vorsieht, zwischen denen eine schwache Vorrang-Beschränkung besteht. Die Erstellung des Ausführungsplans kann in beliebiger Weise erfolgen. Gemäß einer bevorzugten Ausführungsform wird eine listenbasierte Planung verwendet. Die Aufgabenteile werden zunächst in eine Liste einsortiert, wobei die Vorrang-Beschränkungen eine Ordnung über die Liste definieren. Anschließend werden die Aufgabenteile, entsprechend der Reihenfolge in der Liste, auf freie Prozessoren verteilt. Es kann dabei vorgesehen sein, dass die Ablaufteile der Alt-Steuerungssoftware auf neu oder abweichend definierte Tasks verteilt werden. Mit anderen Worten kann ein adaptiertes Runnable-to-Task-Mapping erzeugt werden.
Zusätzlich wird zu jeder schwachen Vorrang-Beschränkung eine zugehörige persistente Speichervariable in einer getrennt verwalteten Datenbasis eingerichtet. Es ist dabei vorteilhaft, wenn die Datenbasis einen wartezeitfreien lesenden und schreibenden Zugriff erlaubt.
Mit anderen Worten wird der zu einer schwachen Vorrang-Beschränkung gehörende Austausch von aktuellen Kommunikationsdaten, der auf einem Single-Core Steuergerät sequenziell ausgeführt wird (d.h. erst aktuelle Daten schreiben, dann die aktuellen Daten lesen bzw. erst Produzieren, dann aktuelle Daten Konsumieren), aufgetrennt und durch die Nutzung eines (etwas) älteren gepufferten Datenwertes ersetzt.
Diese Parallelisierung von Ablaufteilen unter Pufferung und Veränderung des Zeitrangs der ausgetauschten Daten führt zu einer drastischen Erhöhung der Parallelisierung. Im Vergleich zu einer unveränderten Beibehaltung der Kommunikationsbeziehungen zwischen den Ablaufteilen können erheblich mehr Ablaufteile zu jeweils früheren Zeitpunkten auf parallelen Rechenkernen ausgeführt werden. Folglich kann die Rechenleistung des Multi-Core Steuergeräts deutlich effizienter genutzt werden, sodass einfachere Hardware verwendbar ist und/oder der Stromverbrauch des Steuergeräts sinkt.
Die Verwendung geeigneter Klassifizierungsregeln für die Vorrang-Beziehungen stellt sicher, dass nur geeignete Ablaufteile parallelisiert werden.
Das erfindungsgemäße Verfahren kann zur Portierung der Alt-Steuerungssoftware in eine adaptierte Steuerungssoftware mit einem angepassten Multi-Core Ausführungsplan in einer beliebigen Softwareumgebung ausgeführt werden. Es kommen vor allem die Ausführung in einer Entwicklungsumgebung oder auf dem Multi-Core Steuergerät selbst in Betracht. Die adaptierte Software kann im Multi-Core Fahrzeugsteuergerät selbst erzeugt oder in dieses eingespielt und dort ausgeführt werden. Die Portierung und ggfs. die Einspielung können insbesondere durch ein Softwareprodukt erfolgen, welches das Portierungsverfahren automatisiert ausführt. Das Softwareprodukt kann die Alt-Steuerungssoftware als Eingangsprodukt übernehmen und eine parallelisierte Steuerungssoftware ausgeben, die auf das Multi-Core Fahrzeugsteuergerät übertragbar ist. Gegebenenfalls können Informationen über Aufbaut und/oder Struktur des Single-Core Steuergeräts und/oder des Multi-Core Fahrzeugsteuergeräts sowie der jeweiligen Konfigurationen bei der Portierung berücksichtigt und von dem Softwareprodukt verarbeitet werden.
Ein Task ist im Folgenden als ein separat ausführbarer Aufgabenabschnitt zu verstehen. Ein solcher Aufgabenabschnitt kann beispielsweise die Erzeugung eines aktualisierten Messwertes betreffen, wie beispielsweise die Ermittlung eines Druck- oder Temperaturwertes. Ferner kann ein Aufgabenabschnitt die Weiterverarbeitung eines Mess- oder Steuerwertes für eine Steueraufgabe betreffen, beispielweise, die Ermittlung eines Soll-Wertes aus einem Kennfeld oder die Vorgabe eines Timings für die Ansteuerung eines Kraftstoffinjektors.
Ein Ablaufteil ist ein separat ausführbares Programmelement innerhalb eines Tasks. Ein Ablaufteil beinhaltet eine Sequenz von Instruktionen, die durch die Laufzeitumgebung (run time environment – RTE, insbesondere eine AUTOSAR RTE) aufrufbar ist. Hierbei kann es sich beispielsweise um separat deklarierte Funktionen handeln, die einzelne Teil-Aufgaben innerhalb des Tasks ausführen.
Systemkritische Aufgaben oder die Messwert-Aktualisierung für besonders wichtige Parameter können in Tasks / Ablaufteilen bei einer kurzen Periodizität ausgeführt werden, bspw. als 1ms-Tasks oder 2ms-Tasks. Es können auch deutlich kürzere Wiederholungstakte vorgesehen sein. Weniger kritische Aufgaben oder Messwert-Aktualisierungen für sich nur träge ändernde physikalische Größen können bei einer deutlich längeren Periodizität ausgeführt werden, bspw. als 8ms-Tasks, 128ms-Tasks oder 1024ms-Tasks oder Ablaufteile.
Die durch Events, insbesondere durch die Erreichung von vorbestimmten Kurbelwinkelpositionen, ausgelösten Tasks haben in der Regel die höchsten Prioritäten in der Steuerungssoftware für Fahrzeuge. Sie sind häufig für das Motor-Management erforderlich und umfassen beispielsweise Steueraufgaben für das Kraftstoff-Fördersystem und die Kraftstoffinjektion.
Durch die Klassifizierungsregeln werden Ablaufteile in der Alt-Steuerungssoftware aufgefunden, die Produzent und Konsument eines zwischen ihnen ausgetauschten Datenelementes sind, wobei die Kommunikation zwischen Produzent und Konsument asynchron erfolgt und wobei Produzent und Konsument eine deutlich unterschiedliche Ausführungscharakteristik im Single-Core Ausführungsplan haben. Derart miteinander kommunikativ verbundene Ablaufteile kommen bei Einhaltung der für Fahrzeug-Steuerungssoftware gültigen Entwicklungsvorgaben nur in Programmstrukturen vor, die ein zeitunkritisches Datenflussprofil aufweisen, also beispielsweise außerhalb von geschlossenen Regelkreisen oder direkten Verkettungen von Steueranweisungen. Demzufolge ist bei solchen Ablaufteilen zu erwarten, dass eine Transformierung des zugehörigen Datenflusses unter Veränderung des Zeitrangs eines Datenelementes, das durch einen Konsumenten für die weitere Verarbeitung eingelesen wird, mit hoher Wahrscheinlichkeit ohne negative Auswirkung auf die Robustheit oder das äußere Steuerungsergebnis der Software, sodass eine Parallelisierung dieser Ablaufteile zur Effizienzsteigerung ausgenutzt werden kann. Dies gilt umso mehr, wenn der Produzenten-Ablaufteil bei einer sehr hohen Ausführungsfrequenz, also beispielsweise bei Intervallen von 10ms oder weniger ausgeführt wird.
Die Erfindung ist in den Zeichnungen beispielsweise und schematisch dargestellt. Es zeigen:
1: Eine Schemadarstellung der Portierung einer Alt-Steuerungssoftware auf ein Multi-Core Fahrzeugsteuergerät;
2: Beispiele von Tasks mit enthaltenen Ablaufteilen, Formen von Auslösern (Triggern) und einer Ausführungs-Rangfolge;
3: Schematische Darstellungen eines Kontrollflusses und einen Datenflusses für die in 2 dargestellten Tasks;
4 u. 5: Ausführungspläne für die Verarbeitung der Alt-Steuerungssoftware auf einem Single-Core und einem Multi-Core Steuergerät;
6: Einen Datenfluss zwischen zwei Tasks mit unterschiedlichen Formen von Auslösern,
7 u. 8: Beispiele für die Klassifizierung von schwachen Vorrang-Beschränkungen.
Die Erfindung betrifft ein Verfahren zur parallelisierten Ausführung von Alt-Steuerungssoftware (100), die für ein Steuergerät (102) mit einem Einzel-Rechenkern (C0) entwickelt ist, auf einem Fahrzeugsteuergerät (103) mit mindestens zwei Rechenkernen (C1, C2, C3, C4), welches in 1 illustriert ist. Die Alt-Steuerungssoftware (100) wird unter Erstellung eines neuen Ausführungsplans (105) (Multi-Core Schedule) für die Ausführung auf dem Multi-Core Fahrzeugsteuergerät (103) portiert. Ggfs. können aus dem Stand der Technik bekannte Adaptionen des Quellcodes vorgenommen werden, um eine parallelisierte Steuerungssoftware (101) zu erzeugen. Hierzu können insbesondere die Partitionierung der Alt-Steuerungssoftware (100) unter Separierung der enthaltenen Tasks und Ablaufteile gehören.
1 zeigt das Portierungsverfahren in einer Schemadarstellung. Das Verfahren kann insbesondere verwendet werden, um Alt-Steuerungssoftware, die nach einem AUTOSAR-Standard für ein Single-Core Steuergerät (102) entwickelt worden ist, auf dem Multi-Core Fahrzeugsteuergerät (103) auszuführen. Derartige Alt-Steuerungssoftware eignet sich besonders gut für die Portierung, da in den AUTOSAR-Standards strikte Vorgaben für den Datenaustausch, d.h. die Kommunikation, zwischen Tasks und den in den Tasks enthaltenen Ablaufteilen vorgegeben sind. Der AUTOSAR Virtual Function Bus (VFB) kann für das Auffinden von Vorrechts-Beschränkungen und die Anwendung der Klassifizierungsregeln (109) in automatisierter Weise analysiert werden, um Kommunikations-Ports, Sender-Receiver-Datenaustausch sowie zugeordnete persistente Speichervariablen zu ermitteln. Die Klassifizierungsregeln werten bevorzugt formale Strukturen in der Alt-Steuerungssoftware aus. Dementsprechend muss keine Kenntnis darüber bestehen, welchen physikalischen oder logischen Gehalt eine persistente Speichervariable hat, für die eine Vorrang-Beschränkung ermittelt und ggfs. als schwach identifiziert wird. Dies ermöglicht eine vollautomatisierte Durchführung des Portierungsverfahrens für unterschiedlichste Formen von Alt-Steuerungssoftware (100).
Im Weiteren wird davon ausgegangen, dass es sich bei der Alt-Steuerungssoftware (100) um eine AUTOSAR-konforme Anwendung mit einer Mehrzahl von Tasks (T-1, T-8, T-Cr) handelt, von denen einige bei einer jeweils vorbestimmten Periodizität (bspw. P = 1ms, P = 8ms) ausgeführt werden. Andere Tasks (T-Cr) können Event-basiert, insbesondere in Abhängigkeit von bestimmten Kurbelwinkelpositionen des Fahrzeugverbrennungsmotors gestartet werden. Für die Tasks ist eine Ausführungs-Rangfolge (106) in Form von zugeordneten Prioritätswerten und/oder Ranglisten festgelegt.
Eine Parallelisierung von Ablaufteilen in der AUTOSAR-Alt-Steuerungssoftware kann besonders für Vorrang-Beschränkungen in Bezug auf asynchrone Kommunikationsvorgänge durchgeführt werden. Hierzu zählt insbesondere eine Sender-Receiver-Kommunikation, wenn diese das Ablegen eines Datenelements zu einem Schreib-Zeitpunkt durch den Sender (Produzenten-Ablaufteil) in einer gemeinsam benutzten persistenten Speichervariable (Va, Vb) vorsieht und dieses Datenelement von dem Empfänger (Konsumenten-Ablaufteil) zu einem davon abweichenden Lese-Zeitpunkt ausgelesen wird, wobei der Lese-Zeitpunkt relativ zum Schreib-Zeitpunkt mit einer nicht oder variierend festgelegten Zeitverzögerung eintritt. Mit anderen Worten wird eine Parallelisierung von Ablaufteilen für solche Vorrang-Beschränkungen vorgesehen, bei denen ein Lese-Zeitpunkt asynchron auf einen Schreib-Zeitpunkt folgt.
Eine Parallelisierung eines solchen Produzenten-Ablaufteils mit einem oder mehreren Konsumenten-Ablaufteilen sieht vor, dass diese auf zwei unterschiedlichen Rechenkernen (C1, C2, C3) zeitparallel ausgeführt werden – und nicht, wie im Datenfluss auf dem Single-Core Steuerungsgerät vorgesehen, nacheinander. Durch die zeitliche Parallelisierung wird der Konsumenten-Ablaufteil also zu einem zeitlich nach vorn verlagerten Startpunkt aktiviert. Gleichzeitig wird der Zeitrang der von dem Konsumenten-Ablaufteil gelesenen Daten derart transformiert, dass nicht der aktuell von der momentanen Instanz des Produzenten-Ablaufteils erzeugte Wert, sondern ein zwischengespeicherter Wert der letzten vorhergehenden Instanz des Produzenten-Ablaufteils verwendet wird. Um dies zu ermöglichen wird die gemeinsame persistente Speichervariable in einer getrennt verwalteten Datenbasis (108) gespeichert, die einen parallelen lesenden und schreibenden Zugriff zulässt. Der Zugriff auf die persistente Speichervariable erfolgt dabei bevorzugt wartezeitfrei, sodass keine Schreib- oder Leseverzögerungen bei den parallelisierten Ablaufteilen entstehen. Ferner wird eine Parallelisierung nur für solche Ablaufteile durchgeführt, für die nach den Klassifizierungsregeln (109) eine schwache Vorrang-Beschränkung identifiziert wurde.
2 zeigt beispielhaft eine Alt-Steuerungssoftware (100) mit drei Tasks. Task (T-1) wird bei einer Periodizität (P) von 1ms, also sehr häufig ausgeführt. Dieser Task beinhaltet eine Mehrzahl von Ablaufteilen (R_11, R_12, R_13), in denen verschiedene Instruktionen enthalten sind, die gemäß der Aufrufreihenfolge (107) auf einem Single-Core Steuergerät sequenziell abgearbeitet wurden.
Der Task (T-8) enthält ebenfalls eine Mehrzahl von Ablaufteilen (R_81, R_82, R_83) mit einer vorgegebenen Aufrufreihenfolge und wird einer Periodizität (P) von 8ms ausgeführt.
Der Task (T-Cr) beinhaltet Ablaufteile (R_Cr1, R_Cr2, R_Cr3) und wird Event-basiert, hier bei Auftreten von bestimmten Kurbelwinkelpositionen ausgeführt.
Den Tasks (T-1, T-8, T-Cr) sind Prioritäten (Prio) zugeordnet, aus denen sich die Ausführungs-Rangfolge (106) und/oder eine Präemptiv-Rangfolge für die Ausführung auf dem Single-Core Steuergerät ergibt.
Durch eine Analyse der Ausführungs-Rangfolge (106) sowie der Aufrufreihenfolge (107) kann der reguläre Kontrollfluss (vgl. 3, links) ermittelt werden, aus der sich die (Makro- und Mikro-)Sequenzierung der Verarbeitung der einzelnen Ablaufteile (R_11 bis R_83) ergibt.
Durch eine Analyse der im Quellcode definierten Kommunikation zwischen den Ablaufteilen und/oder der vorgesehenen schreibenden und lesenden Zugriffe aus den Ablaufteilen (R_11 bis R_83) auf gemeinsame persistente Speichervariablen (Va, Vb) kann der Datenfluss zwischen den Ablaufteilen ermittelt werden, der hier beispielhaft in 3, rechts dargestellt ist.
Ablaufteil (R_11) in Task (T-1) ermittelt einen Messwert (M1) und schreibt diesen bei jeder Ausführung in die gemeinsame persistente Speichervariable (Va). Somit ist der Ablaufteil (R_11) ein Produzent in Bezug auf die gemeinsame Speichervariable (Va). Die Ablaufteile (R_12 und R_81) führen einen lesenden Zugriff auf die gemeinsame persistente Speichervariable (Va) aus, um unter Verwendung des darin abgelegten Datenwertes die Steuerwerte (A, B) zu erzeugen. Sie sind Konsumenten in Bezug auf die Speichervariable (Va).
Die Ablaufvariable (R_82) erfasst einen weiteren Messwert (M2) und legt diesen in einer weiteren gemeinsamen persistenten Speichervariable (Vb) ab. Auf diese wird durch den Ablaufteil (R_83) lesend zugegriffen, um einen weiteren Steuerwert (D) zu erzeugen. Auch der im Event-basiert ausgeführten Task (T-Cr) enthaltene Ablaufteil (R_Cr1) greift auf diese persistente Speichervariable (Vb) zu, um einen weiteren Steuerwert (E) zu erzeugen.
Aus dem rechten Teil von 3 ist ersichtlich, dass zwischen den dort auf eine gemeinsame persistente Speichervariable (Va, Vb) schreibend und lesend zugreifenden Ablaufteilen jeweils Vorrang-Beschränkungen (PC1, PC2, PC3, PC4) bestehen, die hier durch die mit Pfeilen dargestellte Datenflussrichtung (von-Sensor-zu-Aktuator-Sequenzierung) dargestellt sind.
Eine parallelisierte Ausführung von solchen über Vorrang-Beschränkungen miteinander verknüpften Ablaufteilen kann potenziell zu unbestimmten Systemzuständen führen. Dies ist beispielsweise dann zu erwarten, wenn Datenelemente in einem Konsumenten-Ablaufteil in konditionalen Anweisungen (beispielsweise if- oder while-Schleifen) oder innerhalb von geschlossenen Regelkreisen verwendet werden und zwischen Produzent und Konsument ein zeitkritisches Datenflussprofil exisitert. Es sollten also nur solche Ablaufteile parallelisiert werden, bei denen auch bei einer Veränderung des Datenflusses keine relevanten Beeinträchtigungen in Hinsicht auf das Steuerungsergebnis zu erwarten ist, bei denen folglich keine Anzeichen für eine Zeitkritikalität bestehen.
Dies wird erreicht, indem die ermittelten Vorrang-Beschränkungen (PC1 bis PC4) gemäß vorbestimmten Klassifizierungsregeln (109) in starke und schwache Vorrang-Beschränkungen unterteilt werden.
Die Klassifizierungsregeln können als automatisierbare Anweisungen in Form von Software hinterlegt und durch ein automatisiertes Portierungsprogramm ausgeführt werden, welches die Alt-Steuerungssoftware (100) übernimmt und eine parallelisierte Steuerungssoftware (101) mit einem neuerstellten Multi-Core Ausführungsplan (105) ausgibt.
4 und 5 zeigen einen Single-Core Ausführungsplan (104) und einen Multi-Core Ausführungsplan (105) in einer beispielhaften Vergleichsdarstellung.
In dem in 4 dargestellten Single-Core-Ablaufplan (104) werden alle Tasks (T-1, T-8 und T-Cr) gemäß der vorgegebenen Ausführungs-Rangfolge (106) (Prioritäten) sequenziell auf dem Rechenkern (C0) ausgeführt. Wenn innerhalb eines Grundtaktes (hier beispielsweise bei t = 0 und t = 8) zwei Tasks (T-1, T-8) konkurrierend zur Ausführung anstehen, so wird der höher priorisierte Task (T-1, Priorität: 0) zuerst ausgeführt. Nach dessen vollständiger Abarbeitung folgt dann die Verarbeitung des niedriger priorisierten Tasks (T-8, Priorität: --).
Die Event-basierten Tasks (T-Cr) werden in der Regel sofort nach dem Auftreten eines auslösenden Ereignisses (Cr-Event) gestartet. Wenn eine Präemption vorgesehen ist (s.o.), kann ein hoch priorisierter Task die Ausführung eines niedriger priorisierten Tasks ggf. unterbrechen (hier nicht dargestellt).
In dem in 5 dargestellten Multi-Core-Ausführungsplan (105) werden alle Ablaufteile innerhalb der Tasks (T-1, T-8, T-Cr) so weit wie möglich parallelisiert, d.h., auf unterschiedliche Rechenkerne (C1, C2, C3, C4) verteilt und zeitparallel ausgeführt. Eine Parallelisierung erfolgt ohne weiteres für solche Ablaufteile, zwischen denen keine Vorrang-Beschränkungen vorliegen, d.h., die untereinander keine Datenelemente austauschen und somit im Wesentlichen voneinander unabhängige Verarbeitungen ausführen. Solche Ablaufteile (R_11, R_12 und R_81, R_82), zwischen denen starke Vorrang-Beschränkungen (PC1, PC3) identifiziert wurden, werden sequentiell und in der Regel auf dem selben Rechenkern (C1, C3) ausgeführt.
Ablaufteile (R_11, R_81), zwischen denen eine schwache Vorrang-Beschränkung (PC2) identifiziert wurde, werden ebenfalls parallelisiert ausgeführt, wobei zwischen diesen Ablaufteilen (R_11, R_81) bzw. deren Instanzen ein adaptierter Datenfluss (X) vorgesehen wird.
6 zeigt einen Spezialfall eines Datenflusses zwischen zwei Ablaufteilen (R_11, R_Cr1) aus zwei Tasks (T-1, T-Cr) mit unterschiedlichen Formen von Auslösern (Perioden-Trigger vs. Event-Trigger). Auch hier handelt es sich um asynchrone Kommunikation. In diesem Fall produziert der periodisch ausgeführte Ablaufteil (R_11) bei jeder Ausführung ein Datenelement, das in einer gemeinsamen persistenten Speichervariablen (Vx) abgelegt und von dem Event-basiert ausgeführten Ablaufteil (R_Cr1) konsumiert wird. Andererseits produziert der Ablaufteil (R_Cr1) ein anderes Datenelement, das in einer Speichervariablen (Vy) abgelegt und von dem Ablaufteil (R_11) konsumiert wird. Zwischen diesen Ablaufteilen (R_11 und R_Cr1) besteht somit eine gegenseitige Abhängigkeit in Form von in beiden Richtungen vorliegenden Vorrang-Beschränkungen (PCx, PCy). Durch das erfindungsgemäße Portierungsverfahren können auch solche gegenseitigen Vorrang-Beschränkungen zwischen zwei Ablaufteilen, die durch unterschiedliche Formen von Auslösern gestartet werden, parallelisiert werden, und es kann auf eine Präemption zwischen diesen Ablaufteilen verzichtet werden – vorausgesetzt, dass die Vorrang-Beschränkungen (PCx, PCy) als schwach klassifiziert werden.
7 und 8 verdeutlichen zwei bevorzugte Klassifizierungsregeln, zur Bewertung einer Vorrang-Beschränkung als schwach. In 7 wird gemäß dem Single-Core-Ausführungsplan ein Produzenten-Ablaufteil (R_11) bei einer hohen Frequenz, hier beispielsweise einer Periodizität (P = 1ms) ausgeführt, wobei jedes Mal ein schreibender Zugriff auf eine gemeinsame persistente Speichervariable erfolgt. Ein konsumierender Ablaufteil (R_51) wird deutliche seltener ausgeführt, hier bei einer Periodizität (P = 5ms). Im Single-Core-Ausführungsplan würde die Ausführung des Ablaufteils (R_51) sequentiell nach der Ausführung des Ablaufteils (R_11) erfolgen, um den Von-Sensor-zu-Aktuator-Datenfluss einzuhalten. Die zwischen diesen Ablaufteilen (R_11, R_51) bestehende Vorrang-Beschränkung wird als schwach klassifiziert, da die Periodizität des Produzenten-Ablaufteils (R_11) ein X-faches, hier ein 5-faches, der Periodizität des Konsumenten-Ablaufteils (R_51) ist. Die Klassifizierungsregel kann allgemein so formuliert werden, dass eine Vorrang-Beschränkung zwischen zwei Ablaufteilen als schwach klassifiziert wird, wenn die Periodizität (P) des einen Ablaufteils mehr als das X-fache der Periodizität (P) des anderen Ablaufteils beträgt, wobei X ein vorbestimmter Grenzwert ist. Der Grenzwert X kann bevorzugt ein Faktor 3 oder größer sein.
Die stark unterschiedliche Häufigkeit der Ausführung der beiden zu der schwachen Vorrangbeschränkung gehörenden Ablaufteile stellt ein starkes Indiz dafür dar, dass zwischen den zugehörigen Steuerverfahren kein kritischer Zusammenhang besteht, so dass eine Transformation des Datenflusses zwischen diesen Ablaufteilen mit hoher Wahrscheinlichkeit keinen Einfluss auf die Robustheit und das äußere Steuerungsergebnis hat.
8 illustriert eine weitere bevorzugte Klassifizierungsregel. 8 zeigt zeigt einen Single-Core-Ausführungsplan für zwei Ablaufvariablen (R_11, R_Cr), die durch verschiedene Formen von Auslösern (Perioden-Trigger versus Event-Trigger) gestartet werden, in Analogie zu 6 und über einen etwas längeren Zeitbereich. Es ist ersichtlich, dass die Ausführung des Ablaufteils (R_Cr) vollkommen unabhängig von dem zeitlichen Auftreten des Ablaufteils (R_11) ist. Auch dies stellt ein Indiz dafür dar, dass zwischen diesen Ablaufteilen keine kritischen Kommunikationen erfolgen. Ferner wird der Ablaufteil (R_11) mit einer hohen Frequenz, hier mit einer Periodizität von (P = 1ms) ausgeführt.
Die zugehörige Klassifizierungsregel kann allgemein so formuliert werden, dass eine Vorrang-Beschränkung (PCx, PCy) zwischen zwei Ablaufteilen als schwach klassifiziert wird, wenn die Ablaufteile (R_11, R_Cr) durch unterschiedliche Formen von Auslösern (Perioden-Trigger versus Event-Trigger) gestartet werden.
Eine weitere bevorzugte Klassifizierungsregel sieht vor, dass eine Vorrang-Beschränkung zwischen zwei Ablaufteilen als schwach klassifiziert wird, wenn die Periodizität des einen Tasks nicht ein natürliches Vielfaches der Periodizität des anderen Tasks ist. Ein Beispiel hierfür wäre, wenn ein erster Task alle 20ms und ein zweiter Task alle 1024ms ausgeführt wird oder wenn die Periodizitäten 20ms gegenüber 48ms betragen. Solche Tasks bzw. die darin enthaltenen Ablaufteile können untereinander kein synchronisiertes Steuerverhalten aufweisen, so dass eine parallelisierte Ausführung (die ohnehin nur vergleichsweise selten in Frage kommen wird, nämlich bei jedem Auftreten eines kleinsten gemeinsamen Vielfachen der Periodizitäten), keine negativen Auswirkungen haben wird.
Die technische Umsetzung des erfindungsgemäßen Verfahrens kann in unterschiedlicher Weise erfolgen. Die Alt-Steuerungssoftware kann bereits eine eindeutige Definition von Tasks, darin enthaltenen Ablaufteilen, Ausführungsrangfolgen sowie Aufrufreihenfolgen, enthalten. Alternativ oder zusätzlich können diese Merkmale durch eine Analyse und ein eventuelles Reverse Modelling der Alt-Steuerungssoftware ermittelt werden. Dabei kann insbesondere vorgesehen sein, dass die Alt-Steuerungssoftware partitioniert wird, wobei die enthaltenen Tasks und Ablaufteile separiert und für jeden Ablaufteil alle schreibenden und lesenden Zugriffe auf persistente Speichervariablen ermittelt werden.
Eine Vorrang-Beschränkung für den Zugriff auf eine gemeinsame persistente Speichervariable zwischen zwei Ablaufteilen kann insbesondere dann ermittelt werden, wenn ein schreibender Zugriff in der Alt-Steuerungssoftware von einem Produzenten-Ablaufteil vor einem lesenden Zugriff durch einen Konsumenten-Ablaufteil zu erfolgen hat.
In der Praxis sind verschiedene Möglichkeiten für die Schaffung einer separat verwalteten Datenbasis (108) bekannt. Eine solche Datenbasis kann insbesondere in einem Arbeitsspeicher (RAM) angelegt und verwaltet werden, der von allen beteiligten Rechenkernen (C1–C4) zugreifbar ist.
Ein wartezeitfreier Zugriff auf eine dort gespeicherte persistente Speichervariable kann bevorzugt dadurch erreicht werden, dass für jede Speichervariable ein Haupt-Speicherwert und mindestens ein Puffer-Speicherwert angelegt werden, wobei ein Puffer-Speicherwert lesend zugreifbar ist, während ein Schreibzugriff auf den Haupt-Speicherwert erfolgt. In einem solchen Fall kann also ein Konsumenten-Ablaufteil, der auf einem ersten Rechenkern (C1) ausgeführt wird, lesend auf einen letzten Wert in dem Puffer-Speicherwert zugreifen, während gleichzeitig ein parallelisiert ausgeführter Produzenten-Ablaufteil einen neuen aktualisierten Wert in den Haupt-Speicherwert schreibt. Der Inhalt des Puffer-Speicherwerts kann bevorzugt nach jedem Schreibzugriff auf den aktualisierten Wert des zugehörigen Haupt-Speicherwerts angeglichen werden. Eine Angleichung kann in beliebiger Weise erfolgen, beispielweise durch Kopieren von Zellinhalten und/oder durch Verändern von Speicheradressierungen / Zeigern.
Alternativ oder zusätzlich kann die getrennt verwaltete Datenbasis (108) für eine persistente Speichervariable eine einzige Speicherzelle mit atomarem Zugriff vorsehen. Mit einer einzelnen Speicherzelle kann eine einzelne physische Zelle gemeint sein. Zugriffe darauf sind immer atomar, d.h. sie werden vom Prozessor in einem einzigen Taktschritt ausgeführt. Inkonsistenzen durch gleichzeitiges Schreiben und Lesen einer Variablen treten nicht auf.

Es gibt jedoch Datentypen, die mehr als eine Speicherzelle belegen (64 Bit Ganzzahl auf 32 Bit Architektur). In diesem Fall kann atomarer Zugriff durch zusätzliche Mechanismen garantiert / geschützt werden. BEZUGSZEICHENLISTE

100	Alt-Steuerungssoftware	Legacy control software
101	Parallelisierte Steuerungssoftware	Parallelized control software
102	Single-Core Steuergerät	Single-Core control unit
103	Multi-Core Steuergerät	Multi-Core control unit
104	Ausführungsplan (Single-Core)	Schedule (single-Core)
105	Ausführungsplan	Schedule (Multi-Core)
106	Ausführungs-Rangfolge	Execution order
107	Aufrufreihenfolge	Calling order
108	Separat verwaltete Datenbasis	Separately managed data base
109	Klassifizierungsregeln	Classification rules
C...	Rechenkern	(Processor-)Core
I/O	Eingabe / Ausgabe	Input / Output
X	Adaptierter Datenfluss	Adapted data flow
T-1	1ms-Task (periodisch)	1ms-Task (periodical)
T-8	8ms-Task (periodisch)	8ms-Task (periodical)
T-Cr	Cr-Task (Cr-ausgelöst)	Cr-Task (Cr triggered)
R_i	Ablaufteil	Runnable
PCi	Vorrang-Beschränkung	Precedence constraint
M1	Messwert	Measured value
M2	Messwert	Measured value
Va	Persistente Speichervariable	Persistent storage variable
Vb	Persistente Speichervariable	Persistent storage variable
A	Steuerwert	Control value
B	Steuerwert	Control value
D	Steuerwert	Control value
E	Steuerwert	Control value
P	Periodizität	Periodicity

Claims

Verfahren zur automatisierten Portierung und Parallelisierung von Alt-Steuerungssoftware (100), die für ein Steuergerät (102) mit einem Einzel-Rechenkern (C0) entwickelt ist, auf ein Fahrzeugsteuergerät (103) mit mindestens zwei Rechenkernen (C1, C2, C3), wobei das Verfahren in einer beliebigen Softwareumgebung ausgeführt wird und zumindest die folgenden Schritte umfasst: – Ermitteln einer Mehrzahl von Tasks (T-1, T-8, T-Cr), wobei von den Tasks (T-1, T-8, T-Cr) einige bei einer jeweils vorbestimmten Periodizität (P) auszuführen sind, und wobei eine Ausführungs-Rangfolge (106) für die Tasks vorgesehen ist, und wobei innerhalb jeden Tasks (T-1, T-8, T-Cr) jeweils ein oder mehrere Ablaufteile (R_i) mit einer vorgegebenen Aufrufreihenfolge (107) vorgesehen sind, – Ermitteln von schreibenden und lesenden Zugriffen auf persistente Speichervariablen (Va, Vb), wobei genau ein Task einen Schreibzugriff (Produzent) und ein weiterer Task einen Lesezugriff (Konsument) ausführt, – Ermittlung, ob eine schwache Vorrang-Beschränkung (PC2, PCx, PCy) besteht, wobei eine Vorrang-Beschränkung als schwach klassifiziert wird, wenn – ein Ablaufteil aus einem Produzenten-Task auf eine gemeinsame Speichervariable (Va, Vb) nur schreibend und ein anderer Ablaufteil aus einem Konsumenten-Task auf die gemeinsame Speichervariable nur lesend zugreift und eine Datenflussabhängigkeit vom schreibenden zum lesenden Ablaufteil besteht, und wenn – die Periodizität (P) des Ablaufteils aus dem Produzenten-Task, mehr als das X-fache der Periodizität (P) des Ablaufteils aus dem Konsumenten-Task, beträgt, wobei X ein vorbestimmter Grenzwert mit dem Wert 3 oder größer ist, ODER – die Periodizität (P) des Ablaufteils aus dem Produzenten-Task nicht ein natürliches Vielfaches der Periodizität (P) des Ablaufteils aus dem Konsumenten-Task ist (P = 5ms vs. P = 1024ms), ODER – die Ablaufteile (R_11, R_Cr) mit unterschiedlichen Formen von Auslösern (Perioden-Trigger, Event-Trigger) gestartet werden, – Erstellung eines Ausführungsplans (105) für die Ausführung der Alt-Steuerungssoftware auf den zwei oder mehr Rechenkernen (C1, C2, C3) unter Parallelisierung von Ablaufteilen (R_11, R_81) mit schwachen Vorrang-Beschränkungen (PC2), – Für jede schwache Vorrang-Beschränkung (PC2) Speicherung der zugehörigen persistenten Speichervariablen (Va) in einer getrennt verwalteten Datenbasis (108).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Alt-Steuerungssoftware unter Anwendung folgender Schritte partitioniert wird: – Separieren der in der Alt-Steuerungssoftware enthaltenen Tasks (T-1, T-8, T-Cr) und Ablaufteile (R_i), – Für jeden Ablaufteil (R_i) Ermitteln aller schreibenden und lesenden Zugriffe auf persistente Speichervariablen (Va, Vb).
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die getrennt verwaltete Datenbasis (108) einen wartezeitfreien lesenden und schreibenden Zugriff gestattet.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in der getrennt verwalteten Datenbasis (108) für eine persistente Speichervariable ein Haupt-Speicherwert und mindestens ein Puffer-Speicherwert angelegt werden, wobei ein Puffer-Speicherwert lesend zugreifbar ist während ein Schreibzugriff auf den Haupt-Speicherwert erfolgt.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass nach einem schreibenden Zugriff der Inhalt eines Puffer-Speicherwertes auf den aktualisierten Wert des zugehörigen Haupt-Speicherwerts angeglichen wird.
Verfahren nach einem der vorhergehenden Ansprüche, dass die getrennt verwaltete Datenbasis (108) für eine persistente Speichervariable (Va, Vb) eine einzige Speicherzelle mit atomarem Zugriff vorsieht.
Softwareprodukt zur Portierung einer Alt-Steuerungssoftware (100), die für ein Steuergerät (102) mit einem Einzel-Rechenkern (C0) entwickelt ist, in eine parallelisierte Steuerungssoftware (101), die auf einem Fahrzeugsteuergerät (103) mit mindestens zwei Rechenkernen (C1, C2, C3) ausführbar ist, dadurch gekennzeichnet, dass das Softwareprodukt ein Verfahren nach einem der vorhergehenden Ansprüche ausführt.
Softwareprodukt nach Anspruch 8, dadurch gekennzeichnet, dass das Softwareprodukt dazu ausgebildet ist, als Eingangsprodukt die Alt-Steuerungssoftware (100) zu übernehmen und die parallelisierte Steuerungssoftware (101) auszugeben, die auf das Fahrzeugsteuerungsgerät (103) übertragbar ist.