-
Die
vorliegende Erfindung betrifft allgemein ein Softwaresystem von
elektronischen Steuereinheiten bzw. ECUs zur Verwendung in einem
Fahrzeug.
-
In
den letzten Jahren ist eine Softewarestruktur, wie zum Beispiel
die eine in der japanischen Patentoffenlegungsschrift JP-A-2001-109628,
zum Verbessern eines Wirkungsgrads einer Wiederverwendung einer
Anwendungssoftware auf verschiedenen unterschiedlichen Plattformen
vorgeschlagen worden.
-
Das
heisst, bei der zuvor offenbarten Softwarestruktur ist jede von
mehreren Komponenten in der Anwendungssoftware dazu ausgelegt, eine Schnittstelle
und ein Hauptteil aufzuweisen, um eine bestimmte Funktion zu realisieren,
und wird verwendet, um die Anwendungssoftware in einem Rahmen zusammenzusetzen,
dass die Komponenten in der Anwendungssoftware voneinander unabhängig arbeiten.
Auf diese Weise werden sowohl die Wiederverwendung der Anwendungssoftware
als auch die Unabhängigkeit
von Plattformen (Hardware) realisiert.
-
Weiterhin
wird die Wiederverwendung der Software unter Verwendung eines Ansatzes
eines unabhängigen
Triggerentwurfs zugelassen, dass ein Trigger, das heisst eine Ereignisroutine
(zum Beispiel ein Typ eines Skriptprogramms), zum Triggern eines Verfahrens
in der Komponente für
jede der Komponenten unabhängig
entworfen ist.
-
Jedoch
kann bei einem Entwerfen eines Fahrzeugsteuersystems die Wiederverwendung
der Software nicht durch ledigliches Entwerfen des Triggers unabhängig für alle der
Komponenten realisiert werden. Dies ist so, da der Softwareentwurf
von jedem der Trigger eine entsprechende Hardware verwenden muss,
die jeden der zu berücksichtigenden Trigger
erzeugt.
-
Zum
Beispiel wird, wenn ein Trigger periodisch erzeugt wird, das heisst
wenn eine bestimmte Funktion, die von dem Trigger zu triggern ist,
periodisch verwendet wird, eine Zeitgeberfunktion eines Mikroprozessors
verwendet, um allgemein Erzeugungszeitpunkte für den Trigger zu geben. Weiterhin wird,
wenn der Trigger synchron zu einer Funktion verwendet wird, die
durch eine andere ECU realisiert ist, eine Synchronität eines
zeitlich triggernden Kommunikationsprotokolls, wie zum Beispiel
FlexRay, zum Triggern verwendet. Das heisst, der Zeitgeber in einer
Kommunikationssteuervorrichtung wird zum Beispiel, wenn der Trigger
periodisch synchron zu einer Funktion verwendet wird, die durch
eine andere ECU realisiert ist, zum Erzeugen des Triggers verwendet.
Weiterhin wird, wenn der Trigger synchron zu einer Steueranforderung
von einer Funktion verwendet wird, die durch eine andere ECU realisiert
ist, ein Empfangen der Steueranforderung über ein Netz zum Erzeugen des
Triggers verwendet.
-
Deshalb
ist in dem Triggerentwurf des Fahrzeugsteuerverfahrens ein Berücksichtigen
der entsprechenden Hardware für
alle der zuvor beschriebenen Fälle
erforderlich. Als ein Ergebnis muss, wenn die Hardware zum Realisieren
einer bestimmten Funktion (das heisst zum Realisieren einer Anwendungssoftware)
geändert
wird, der entsprechende Trigger neu entworfen werden.
-
Im
Hinblick auf die zuvor beschriebenen und andere Probleme ist es
eine Aufgabe der vorliegenden Erfindung, ein Softwaresystem einer
Fahrzeug-ECU bzw. elektronischen Fahrzeugsteuereinheit eines zu
schaffen, das ohne ein neues Entwerfen eines Triggers wieder verwendet
werden kann, wenn eine entsprechende Hardware des Triggers ersetzt wird.
-
Diese
Aufgabe wird mit den in Anspruch 1 und 4 angegebenen Maßnahmen
gelöst.
-
Weitere
vorteilhafte Ausgestaltungen der vorliegenden Erfindung sind Gegenstand
der abhängigen
Ansprüche.
-
Gemäß einem
Aspekt der vorliegenden Erfindung weist das Softwaresystem zur Verwendung in
einer elektronischen Fahrzeugsteuereinheit eines Fahrzeugsteuernetzes
mehrere Softwarekomponenten zum mindestens Ausführen von mehreren Fahrzeugsteuerfunktionen
an der elektronischen Fahrzeugsteuereinheit auf. Die mehreren Aufgaben,
die von einer Software der elektronischen Steuereinheit in der elektronischen
Fahrzeugsteuereinheit gestartet werden, sind jeweils mehreren Funktionstriggern zugewiesen
und jeder der mehreren Funktionstrigger wird durch mindestens eine
der mehreren Aufgaben im Zusammenwirken mit jedem der mehreren Funktionstrigger
zum Ausführen
der mehreren Fahrzeugsteuerfunktionen aufgerufen. Auf diese Weise
wird der Funktionsentwurf des Softwaresystems unabhängig von
der Hardware ausgeführt.
Anders ausgedrückt
wird die Wiederverwendung des Softwaresystems bezüglich einer
unterschiedlichen Hardware aufgrund der Unabhängigkeit des Softwaresystems von
dem Hardwareentwurf erleichtert.
-
Zum
Beispiel sind eine Ereignisaufgabe und periodische Aufgaben zum
Aufrufen durch einen Ereignistrigger, der aus der Hardware, wie
zum Beispiel einem Fahrzeugsteuernetz oder einer elektronischen Fahrzeugsteuereinheit,
abgeleitet wird, oder zum Aufrufen durch periodische Trigger vorgesehen,
die aus einer Zeitgeberfunktion der elektronischen Fahrzeugsteuereinheit
oder einem Synchronisationszeitgeber des Fahrzeugsteuernetzes abgeleitet
werden.
-
In
diesem Fall können
die periodischen Aufgaben eine Betriebsinformation bezüglich Betriebsbedingungen
in den mehreren Softwarekomponenten halten und müssen die periodischen Aufgaben nicht
die Funktionstrigger ausgeben, wenn die Betriebsinformation einen
Nichtbetrieb der mehreren Softwarekomponenten anzeigt. Deshalb wird
die Betriebskonsistenz zwischen dem Betrieb von jeweiligen Funktionen
und entsprechenden "lauffähigen Einheiten" gewährleistet,
die tatsächlich
funktionale Betriebe des Softwaresystems durchführen.
-
Weiterhin
kann die vorliegende Erfindung als eine Entwurfsmethodik mit einer
Software zur Verwendung in der ECU dargestellt sein.
-
Das
heisst, das Verfahren eines Entwerfens eines Softwaresystems, das
in mehreren elektronischen Steuereinheiten eines Fahrzeugsteuernetzes verwendet
wird, beinhaltet Schritte eines Teilens von Fahrzeugsteuerfunktionen
in mehrere Softwarekomponenten, eines Strukturierens der mehreren
Softwarekomponenten in hierarchische Schichten, eines Entwerfens
einer Ausführungsfolge
der mehreren Softwarekomponenten durch Zuweisen eines Funktionstriggers
zu jeder der mehreren Softwarekomponenten, eines Realisierens von
jeder der mehreren Softwarekomponenten an den elektronischen Steuereinheiten,
eines Vorbereitens von strukturierten Detailfunktionen für jede der
mehreren Softwarekomponenten auf der Grundlage einer Analyse einer Funktion
von jeder der mehreren Softwarekomponenten, eines Einstellens von
Funktionstriggern zum Ausführen
der strukturierten Detailinformationen und eines Entwerfens einer
Softwareaufgabenanordnung durch Zuweisen der Funktionstrigger zu
den Softwareaufgaben. Auf diese Weise wird der Softwareentwurf ausschließlich unabhängig von
den Zwängen und/oder
Einschränkungen
einer Zielhardware ausgeführt.
Deshalb wird die Wiederverwendung der Komponenten in dem Softwaresystem
erleichtert.
-
Die
vorliegende Erfindung wird nachstehend anhand von Ausführungsbeispielen
unter Bezugnahme auf die beiliegende Zeichnung näher erläutert.
-
Es
zeigt:
-
1 ein
Blockschaltbild einer funktionalen Struktur eines Fahrzeugsteuernetzsystems
gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
2 ein
Zeitablaufdiagramm einer Verfahrensfolge von jeweiligen Komponenten,
die in 1 gezeigt sind;
-
3 ein
Blockschaltbild des Fahrzeugsteuernetzsystems gemäß dem Ausführungsbeispiel
der vorliegenden Erfindung;
-
4 ein
Blockschaltbild des Fahrzeugsteuernetzsystems im Zusammenwirken
mit den Komponenten, die in 2 gezeigt
sind;
-
5 ein
Blockschaltbild von funktionalen Strukturen der Komponenten im Zusammenwirken mit
Aktivierungstriggern;
-
6 ein
Zeitablaufdiagramm von lauffähigen
Einheiten im Zusammenwirken mit Triggern und Aufgaben in einer Motor-ECU;
und
-
7 ein
Blockschaltbild von Softwareaufgaben im Zusammenwirken mit Triggern
und lauffähigen
Einheiten.
-
Nachstehend
wird ein Ausführungsbeispiel der
vorliegenden Erfindung unter Bezugnahme auf die beiliegende Zeichnung
näher beschrieben.
-
1 zeigt
ein Blockschaltbild eines Teils einer funktionalen Struktur eines
Fahrzeugsteuernetzsystems. Es gibt verschiedene andere Funktionen, die
in dem Fahrzeugsteuernetzsystem zusätzlich zu den Funktionen enthalten
sind, die hierin dargestellt sind. Jedoch sind lediglich Funktionen,
die in der Beschreibung der vorliegenden Erfindung verwendet werden,
in 1 gezeigt.
-
Wie
es in 1 gezeigt ist, gibt es als Funktionen bzw. Komponenten,
die in dem Fahrzeugsteuernetzsystem enthalten sind, zum Beispiel
einen Fahrzeugkoordinator 101 in der obersten Kette und einen
Fahrzeugbewegungskoordinator 102 abwärts von ihm. Ein Antriebsstrangkoordinator 103 wird
abwärts
des Fahrzeugbewegungskoordinators 102 verwendet und weiterhin
werden abwärts
des Antriebsstrangkoordinators 103 eine Motorsteuerkomponente 104 und
eine Getriebesteuerkomponente 105 verwendet. Weiterhin
wird in dem Fahrzeugbewegungskoordinator 102 zusätzlich zu
dem Antriebsstrangkoordinator 103 ebenso eine Bremssteuerkomponente 106 verwendet.
-
Der
Fahrzeugkoordinator 101 berechnet eine erforderliche Betriebsgröße, die
ein Fahrer von dem Fahrzeug anfordert, wie zum Beispiel eine erforderliche
Beschleunigungs- und Verzögerungsgeschwindigkeit
und eine erforderliche Gierrate, auf der Grundlage einer Information über Fahrerzustände (Gaspedal-
und Bremspedalbetätigungen)
und leitet das Ergebnis zu dem unteren Fahrzeugbewegungskoordinator 102.
-
Der
Fahrzeugbewegungskoordinator 102 berechnet eine augenblickliche
Fahrzeugbewegungsanforderung, um stabil eine Anforderung einer Fahrzeugbewegung
auf der Grundlage einer Fahreranforderung zu erzielen, die von dem
oberen Fahrzeugkoordinator 101 weitergeleitet wird. Zum Beispiel
leitet er erforderliche Werte, wie zum Beispiel ein erforderliches
Achsendrehmoment und ein erforderliches Steuerdrehmoment, zu dem
Antriebsstrangkoordinator 103 bzw. der Bremssteuerkomponente 106.
-
Der
Antriebsstrangkoordinator 103 berechnet erforderliche Werte,
wie zum Beispiel ein erforderliches Motordrehmoment und einen erforderlichen Gang,
die zum Realisieren der erforderlichen Werte, wie zum Beispiel ein
erforderliches Achsendrehmoment, erforderlich sind, das von dem
Fahrzeugbewegungskoordinator 102 in einer oberen Hierarchie
weitergeleitet wird, und leitet diese zu der Motorsteuerkomponente 104 bzw.
der Getriebesteuerkomponente 105. Auf diese Weise steuern
die Steuerkomponenten 104 und 105 Zielaktoren,
wie zum Beispiel eine Motordrossel und ein Automatikgetriebe (hier
im weiteren Verlauf als AT bezeichnet), um die erforderlichen Werte
zu realisieren.
-
Ähnlich führt die
Bremssteuerkomponente 106 das zuvor beschriebene Steuern
durch, um das erforderliche Antriebsdrehmoment zu realisieren, das von
dem oberen Fahrzeugbewegungskoordinator 102 weitergeleitet
wird. Zum Beispiel bewirkt sie, dass die jeweiligen Räder eine
Bremskraft durch Ansteuern von Motoren zum Pumpenansteuern und verschiedenen
Steuerventilen in einem ABS-Aktor erzeugen.
-
2 zeigt
eine Darstellung eines Zeitablaufdiagramms der jeweiligen Komponenten,
die die funktionale Fahrzeugstruktur bilden, die in 1 gezeigt
ist.
-
Der
Fahrzeugkoordinator 101 wird durch einen Funktionstrigger 211 aktiviert,
der periodisch erzeugt wird, und führt eine Verarbeitung in einer
vorbestimmten Dauer T1 durch. In dieser Dauer wird eine Steueranforderung
von dem Fahrzeugkoordinator 101 an dem Fahrzeugbewegungskoordinator 102 in
einer unteren Hierarchie erzeugt und wird eine erforderliche Betriebsgröße, die
der Fahrer von dem Fahrzeug anfordert, übertragen.
-
Der
Fahrzeugbewegungskoordinator 102 aktiviert eine Steueranforderung,
die von dem Fahrzeugkoordinator 101 erzeugt wird, als einen
Funktionstrigger 212 und führt eine Verarbeitung in einer vorbestimmten
Dauer T2 durch. In dieser Dauer wird eine Steueranforderung von
dem Fahrzeugbewegungskoordinator 102 an dem unteren Antriebsstrangkoordinator 103 und
der Bremssteuerkomponente 106 erzeugt und werden erforderliche
Werte, wie zum Beispiel ein erforderliches Raddrehmoment und ein
erforderliches Steuerdrehmoment, übertragen.
-
Der
Antriebsstrangkoordinator 103 aktiviert die Steueranforderung,
die von dem Fahrzeugbewegungskoordinator 102 erzeugt wird,
als einen Funktionstrigger 213 und führt eine vorbestimmte Verarbeitung
in einer vorbestimmten Dauer T3 durch. In dieser Dauer wird eine
Steueranforderung von dem Antriebsstrangkoordinator 103 an
der unteren Motorsteuerkomponente 104 und Getriebesteuerkomponente 105 erzeugt
und werden erforderliche Werte, wie zum Beispiel ein erforderliches
Motordrehmoment und ein erforderlicher Geschwindigkeitsänderungsschritt, übertragen.
-
Die
Motorsteuerkomponente 104 wird durch einen Funktionstrigger 214 unberücksichtigt
eines Erzeugungszeitpunkts einer Steueranforderung, die von dem
Fahrzeugbewegungskoordinator 102 erzeugt wird, unabhängig und
periodisch erzeugt und führt
eine Verarbeitung in einer vorbestimmten Dauer T4 durch.
-
Die
Getriebesteuerkomponente 105 wird durch einen Funktionstrigger 215 unberücksichtigt
eines Erzeugungszeitpunkts einer Steueranforderung, die von dem
Fahrzeugbewegungskoordinator 102 erzeugt wird, unabhängig und
periodisch erzeugt und führt
eine Verarbeitung in einer vorbestimmten Dauer T5 durch.
-
Ähnlich wird
die Bremssteuerkomponente 106 durch einen Funktionstrigger 216 unberücksichtigt
eines Erzeugungszeitpunkts einer Steueranforderung, die von dem Fahrzeugbewegungskoordinator 102 erzeugt
wird, unabhängig
und periodisch erzeugt und führt
eine Verarbeitung in einer vorbestimmten Dauer T6 durch.
-
3 zeigt
ein Blockschaltbild des Fahrzeugsteuernetzsystems. ECUs bzw. elektronische Steuereinheiten 301 bis 304 sind über eine
Kommunikationsleitung 305 miteinander verbunden, um das Netz
auszubilden, und steuern das gesamte Fahrzeug durch gegenseitige
Kommunikationsdaten.
-
Die
Motor-ECU 301 steuert den Motor. Die AT-ECU 302 steuert
das Automatikgetriebe. Die Brems-ECU 303 steuert die Bremse.
Die Fahrzeugbewegungs-ECU 304 führt Berechnungen zum Stabilisieren
der Bewegung des Fahrzeugs durch und sendet erforderliche Werte
zu den jeweiligen ECUs 301 bis 304. Die ECUs 301 bis 304,
die bei dem Steuern des Fahrzeugs betroffen sind, sind mit der Kommunikationsleitung 305 verbunden
und führen
Kommunikationen durch.
-
4 zeigt
ein Beispiel einer verteilten Anordnung der Funktionen bzw. Komponenten,
die die in 2 gezeigte funktionale Struktur
in den ECUs 301 bis 304 bilden, die das in 3 gezeigte
Fahrzeugsteuernetzsystem bilden.
-
In 4 werden
der Fahrzeugkoordinator 101 und der Fahrzeugbewegungskoordinator 102 in der
Fahrzeugbewegungs-ECU 304 verwendet und wird die Bremssteuerkomponente 106 in
der Brems-ECU 303 verwendet, werden der Antriebsstrangkoordinator 103 und
die Motorsteuerkomponente 104 in der Motor-ECU 301 verwendet
und wird die Getriebesteuerkomponente 105 in der AT-ECU 302 verwendet.
-
Obgleich
in der vorhergehenden Beschreibung jede Funktion, das heisst Komponente,
lediglich in einer ECU verwendet wird, muss sie nicht immer in lediglich
einer ECU verwendet werden. Das heisst, eine Funktion kann in zwei
oder mehr Module geteilt sein, um von mehreren ECUs realisiert zu
werden.
-
5 zeigt
die Struktur von Funktionen, die analysiert werden, um die jeweiligen
Funktionen des Antriebsstrangkoordinators 103 und der Motorsteuerkomponente 104 zu
verfeinern, die in der Motor-ECU 301 verwendet werden,
und Aktivierungstrigger der Funktionen.
-
Wenn
Funktionen, die in dem Antriebsstrangkoordinator 103 enthalten
sind, detailliert analysiert und strukturiert werden, werden sie
in Programmsteuerlogiken 501 bis 504 geteilt.
Jede der derart geteilten Funktionen entspricht einer Ausführungseinheit
bezüglich
einer Software und die Ausführungseinheit
wird als eine lauffähige
Einheit bzw. RE bezeichnet. Ähnlich
wird die Motorsteuerkomponente 104 in REs 505 bis 509 geteilt.
-
Die
Pfeile 514 bis 522 in der Darstellung zeigen den
Fluss von Daten und stellen das Weiterleiten von Berechnungsergebnissen
in den REs 501 bis 504 und den REs 505 bis 508 zu
einer nächsten
RE und ebenso einer Ausführungsfolge
von REs dar. Der Pfeil 514 stellt eine Steueranforderung
von dem Fahrzeugbewegungskoordinator 102, welcher bezüglich des
Antriebsstrangkoordinators 103 übergeordnet ist, und eine Schnittstelle
bzw. I/F zwischen Komponenten dar.
-
Ähnlich stellt
der Pfeil 518 eine Steueranforderung von dem Antriebsstrangkoordinator 103 zu der
Motorsteuerkomponenten 104 dar. Die Pfeile 510 bis 513 stellen
Funktionstrigger dar, die die REs 501 bis 509 ausführen; die
REs 501 und 502 werden von einem Funktionstrigger 510 ausgeführt, die
REs 503 und 504 werden von einem Funktionstrigger 511 ausgeführt, die
REs 505 bis 507 werden von einem Funktionstrigger 512 ausgeführt und
die REs 508 und 509 werden von einem Funktionstrigger 513 ausgeführt.
-
Der
Funktionstrigger 510 ist ein Trigger (PT_EVENT_Trigger),
der synchron zu einem Empfangen einer Steueranforderung von dem
Fahrzeugbewegungskoordinator 102 getriggert wird, welcher bezüglich des
Antriebsstrangkoordinators 103 übergeordnet ist. Der Funktionstrigger 511 ist
ein Trigger (PT_8m_Trigger), der alle 8 Millisekunden getriggert wird.
Der Funktionstrigger 512 ist ein Trigger (PT_4m_Trigger),
der alle 4 Millisekunden getriggert wird. Der Funktionstrigger 513 ist
ebenso ein Trigger (PT_8m_Trigger), der alle 8 Millisekunden getriggert wird.
-
6 zeigt
ein Zeitablaufdiagramm einer Beziehung zwischen den REs 501 bis 509,
die in der Motor-ECU 301 realisiert sind, und der Funktionstrigger 510 bis 513 und
Aufgaben, die diese ausführen. 7 zeigt
ein Blockschaltbild der Entsprechungen zwischen Aufgaben (Softwareaufgaben) 601 bis 603 und
den Funktionstriggern 510 bis 513 und den Entsprechungen
zwischen den Funktionstriggern 510 bis 513 und
den REs 501 bis 509, die von diesen laufen gelassen
werden.
-
Die
Aufgaben 601 bis 603 werden durch Software, wie
zum Beispiel ein OS bzw. Betriebssystem, das in jeder ECU ausgeführt wird,
aktiviert, und, wie es in 6 gezeigt
ist, bewirken die Softwaretrigger 604 bis 606,
dass die Aufgaben aktiviert werden. Diese Softwaretrigger 604 bis 606 werden
durch Hardware getriggert. Zum Beispiel werden die Softwaretrigger 605 und 606 durch
einen internen Zeitgeber eines Mikrocomputers oder durch einen synchronen
Zeitgeber der Kommunikationsleitung 305 getriggert, wenn
die Kommunikationsleitung ein zeitlich getriggerter Typ, wie zum
Beispiel FlexRay, ist.
-
Zum
Beispiel wird, wie es in 6 gezeigt ist, als ein Ausführungstrigger
der Ereignisaufgabe 601, die eine Unterbrechungsverarbeitung
ausführt, der
Softwaretrigger 604 (Trigger_Event_A) verwendet, der auf
das Empfangen von Netzdaten getriggert wird.
-
In 6 sind
den Softwaretriggern 605 und 606 und den periodischen
Aufgaben 602 und 603 tiefgestellte Indizes (a
bis d) hinzugefügt.
Die tiefgestellten Indizes sind dazu gedacht, ein leichtes Verständnis einer
Entsprechung zwischen den Softwaretriggern 605 und 606,
die wiederholt in einem Intervall eines festen Zyklus getriggert
werden, und den periodischen Aufgaben 602 und 603 zuzulassen,
die auf der Grundlage von diesen betrieben werden.
-
Wie
es in 7 gezeigt ist, sind den Funktionstriggern 510 bis 513,
die bewirken, dass die REs 501 bis 509 arbeiten,
die Aufgaben 601 bis 603 zugewiesen (diesen zugehörig) und
werden die REs 501 bis 509 von den Funktionstriggern 510 bis 513 laufen gelassen.
-
Ein
Softwareentwurfsverfahren in dem vorliegenden Ausführungsbeispiel
wird unter Bezugnahme auf die zuvor beschriebenen 1 bis 6 beschrieben.
-
In
der Fahrzeugsteuerentwicklung wird als ein erster Schritt die funktionale
Struktur entworfen, wie sie in 1 gezeigt
ist. Beim Entwerfen der funktionalen Struktur werden die Funktion
des gesamten Fahrzeugs, das in Module geteilt ist, dann Schnittstellen
für überwachbare
Größen (zum
Beispiel die Fahrzeuggeschwindigkeit) des Fahrzeugs, die zum Berechnen
zum Erzielen der Funktion erforderlich sind, erforderliche Werte
von anderen Funktionen und erforderliche Werte an anderen Funktionen
festgelegt. Weitere Komponenten werden auf der Grundlage der Schnittstellen
und geteilten funktionalen Modulen gebildet und eine Beziehung zwischen
den Komponenten wird für
eine hierarchische Struktur definiert. In dem vorliegenden Ausführungsbeispiel
wird, wie es in 1 gezeigt ist, als ein Beispiel
eine funktionale Struktur zum Erzielen des Antreibens und Bremsens eines
Fahrzeugs und einer Stabilität
unter Verwendung von diesen in eine hierarchische Struktur gebracht.
-
Weiterhin
werden, um zuzulassen, dass die Funktion des gesamten Fahrzeugs
normal arbeitet, Bedingungen und ein Zeitpunkt eines Ausführens der jeweiligen
Komponenten, das heisst eine Ausführungsfolge, entworfen. Genauer
gesagt werden Trigger und Funktionstrigger, um die jeweiligen Komponenten
zu aktivieren, zugewiesen. Bedingungen eines Triggerns der Funktionstrigger
werden in der Form von Ereignissen, wie zum Beispiel periodischen
Anforderungen und Steueranforderungen definiert. 2 zeigt
eine Ausführungsfolge
in dem vorliegenden Ausführungsbeispiel.
Die Funktionstrigger 211 bis 216 der Komponenten
werden lediglich von dem Standpunkt einer Funktionsrealisierung
ohne Berücksichtigung
der Hardware in irgendeinem Sinne eingestellt.
-
Nach
einem Entwurf der funktionalen Struktur werden die Komponenten an
den ECUs 301 bis 304 in dem Fahrzeugsteuernetzsystem
realisiert. Zum Beispiel werden in dem vorliegenden Ausführungsbeispiel,
da das Fahrzeugsteuernetzsystem strukturiert ist, wie es in 3 gezeigt
ist, die Komponenten verwendet, wie sie in 4 gezeigt
sind.
-
An
diesem Punkt werden Daten bestimmt, die durch das Netz fließen. In
dem vorliegenden Ausführungsbeispiel
werden Steueranforderungen, die der Fahrzeugbewegungskoordinator 102 zu
der Bremssteuerkomponente 106 und dem Antriebsstrangkoordinator 103 sendet,
und eine Steueranforderung, die der Antriebsstrangkoordinator 103 zu
der Getriebesteuerkomponente 105 sendet, über das Netz
ausgetauscht.
-
Obgleich
es in der Darstellung nicht gezeigt ist, ist das Fahrzeug mit verschiedenen
Sensoren zum Überwachen
von Zustandsgrößen des
Fahrzeugs versehen. Die verschiedenen Sensoren sind mit jeder ECU 301 bis 304 verbunden
und Signale, die von den Sensoren erfasst werden, werden verwendet,
um Steuergrößen in jeder
Komponente zu berechnen. Derartige überwachbare Größen des Fahrzeugs
werden über
das Netz kommuniziert und welche überwachbare Größe kommuniziert
wird, wird abhängig
von der Anordnung von Funktionen entschieden.
-
Nach
einem Realisieren der Komponenten in jeder der ECUs 301 bis 304 wird
ein Softwareentwurf durchgeführt.
In dem vorliegenden Ausführungsbeispiel
wird als ein Beispiel eines Softwareentwurfs ein Softwareentwurf
der Motor-ECU 301 beschrieben.
-
Da
der Antriebsstrangkoordinator 103 und die Motorsteuerkomponente 104 in
der Motor-ECU 301 verwendet werden, wie es in 4 gezeigt
ist, werden nach einem Durchführen
einer Analyse nach einem Verfeinern von Funktionen, die in jeder
der Komponenten enthalten sind, REs als Ausführungseinheiten der jeweiligen
Funktionen strukturiert und werden weitere Funktionstrigger, um
jede der REs auszuführen,
eingestellt. 5 zeigt eine Softwarestruktur
von derartigen REs, Triggern, einer Komponente und eines Koordinators.
-
Wie
es in der Verarbeitungsfolge in 2 gezeigt
ist, wird der Antriebsstrangkoordinator 103 mit einer Steueranforderung
von dem oberen Fahrzeugbewegungskoordinator 102 als ein
Trigger ausgeführt.
Die Steueranforderung sind die Daten 514 in 5 und
ein Trigger, der synchron zu dem Erzeugen der Anforderung getriggert
wird, entspricht dem Funktionstrigger 510. Wenn der Funktionstrigger 510 getriggert
wird, wird der Antriebsstrangkoordinator 103 ausgeführt. Das
heisst, die REs 501 bis 504, die den Antriebsstrangkoordinator 103 bilden,
werden ausgeführt.
-
Jedoch
werden zu einem Ausführungszeitpunkt
einer Komponente alle der REs in der Komponente nicht immer gleichzeitig
ausgeführt.
Zum Beispiel wird ein Fall betrachtet, in dem eine RE, die erwünschte Berechnungen
auf der Grundlage von Temperaturen und dergleichen durchführt, in
einem Teil von Komponenten vorhanden ist, die alle 16 Millisekunden
ausgeführt
werden. Da ein Temperatursensor normalerweise eine langsame Reaktion
aufweist, das heisst die Erzeugungsfrequenz eines erfassten Signals
ist langsam, ist es bedeutungslos, Berechnungen unter Verwendung
von Daten, die eine niedrige Frequenz aufweisen, in dem schnellen Zyklus
von 16 Millisekunden ausführen.
Deshalb kann lediglich die RE, die erwünschte Berechnungen auf der
Grundlage von Temperaturen und dergleichen durchführt, alle
100 Millisekunden Berechnungen durchführen und leitet das Ergebnis
zu anderen REs, die alle 16 Millisekunden arbeiten. Dies ist mit dem
Steuern der Komponente selbst überhaupt
nicht problematisch und wird ebenso zu einem Verringern von Verarbeitungslasten
bezüglich
der CPU beitragen.
-
Deshalb
ist es, wenn REs durch Verfeinern von Funktionen strukturiert worden
sind, die in den Komponenten enthalten sind, wie es zuvor beschrieben
worden ist, mit dem Ergebnis, dass die Frequenzen der Funktionen
auf der Grundlage von Funktionen und dergleichen in der oberen Hierarchie
an den betroffenen Funktionen bestimmt werden, erwünscht, einen
Funktionstriggeraufbau in Übereinstimmung
mit Funktionen in der oberen Hierarchie durchzuführen.
-
In
dem vorliegenden Ausführungsbeispiel werden
aus den REs, die den Antriebsstrangkoordinator 103 bilden,
die REs 501 und 502 von dem Ereignistrigger 510,
welcher ein Funktionstrigger eines Ereignistyps ist, synchron zu
einer Steueranforderung aus einer oberen Komponente ausgeführt und werden
andere REs 503 und 504 von dem periodischen Trigger 511,
welcher ein Funktionstrigger ist, periodisch alle 8 Millisekunden
getriggert ausgeführt. Das
gleiche gilt ebenso für
die Motorsteuerkomponente 104. Aus den REs, die die Motorsteuerkomponente 104 bilden,
werden die REs 505, 506 und 507 von dem
periodischen Trigger 512, welcher ein Funktionstrigger
ist, periodisch alle 4 Millisekunden getriggert ausgeführt und
werden die REs 508 und 509 von dem periodischen
Trigger 513, welcher ein Funktionstrigger ist, periodisch
alle 8 Millisekunden getriggert ausgeführt. Diese Funktionstrigger
werden lediglich von dem Standpunkt einer Funktionsrealisierung ohne
Berücksichtigung
bezüglich
Hardware eingestellt.
-
Nachdem
ein detaillierter Aufbau (das Teilen von Funktionen und ein Entwurf
von Funktionstriggern) von Funktionen, die in jeder ECU realisiert
sind, entschieden worden ist, wird ein Aufgabenentwurf durchgeführt, um
Funktionstrigger in jeder Aufgabe zu verwenden, wie es in 6 gezeigt
ist. In dem vorliegenden Ausführungsbeispiel
werden als Aufgaben die Ereignisaufgabe 601, die periodische
Aufgabe 602 und die periodische Aufgabe 603 eingestellt. Diese
Aufgaben entsprechen den Softwaretriggern 604 bis 606 und
werden von dem OS oder dergleichen aktiviert und die Softwaretrigger 604 bis 606 werden
durch Hardware getriggert. Der Softwaretrigger 604 als
Ereignistrigger wird auf das Empfangen von Netzdaten getriggert.
Eine Steueranforderung von dem Fahrzeugbewegungskoordinator 102,
der dem Antriebsstrangkoordinator 103 übergeordnet ist, wird über das
Netz gebracht, da der Fahrzeugbewegungskoordinator 102 in
der Fahrzeugbewegungs-ECU 304 verwendet wird, und der Softwaretrigger 604 wird
synchron zu dem Empfangen von Netzdaten aktiviert.
-
Deshalb
arbeitet die Ereignisaufgabe 601, die mit dem Softwaretrigger 604 als
ein Triggerfaktor arbeitet, synchron zu der Steueranforderung (Netzdatenempfang)
von dem Fahrzeugbewegungskoordinator 102.
-
Die
Softwaretrigger 605 und 606 als periodische Trigger
werden von einer Zeitgeberfunktion des Mikrocomputers getriggert.
In dem vorliegenden Ausführungsbeispiel
wird der Softwaretrigger 605 alle 4 Millisekunden getriggert
und wird der Softwaretrigger 606 alle 8 Millisekunden getriggert.
Der periodische Trigger kann ein Trigger sein, der von dem synchronen
Zeitgeber getriggert wird, wenn die Kommunikationsleitung 305 ein
zeitlich getriggerter Typ, wie zum Beispiel FlexRay, ist. Deshalb
arbeitet die periodische Aufgabe 602 alle 4 Millisekunden
und arbeitet die periodische Aufgabe 603 alle 8 Millisekunden.
-
Wie
es zuvor beschrieben worden ist, aktiviert das OS, wenn die Softwaretrigger 604 bis 606 durch
Hardware getriggert werden, entsprechende Aufgaben 601 bis 603.
Die Funktionstrigger 510 bis 513, um die REs 501 bis 509 laufen
zu lassen, sind den Aufgaben 601 bis 603 zugewiesen.
Der Funktionstrigger 510 ist der Ereignisaufgabe 601 zugewiesen.
Der Funktionstrigger 510 wird durch den Betrieb des Ereignistriggers 601 getriggert
und durch den Funktionstrigger 50 werden die REs 501 und 502 synchron
zu einer Steueranforderung von dem Fahrzeugbewegungskoordinator 102 laufen
gelassen.
-
Zum
Beispiel wird es angenommen, dass in dem Antriebsstrangkoordinator 103 der
Ausführungszyklus
von Funktionen durch die REs 503 und 504 in der
Phase eines Funktionsentwurfs als 7,5 Millisekunden bezeichnet ist.
Das heisst, der Funktionstrigger 511 ist als ein Trigger
bezeichnet, der in einem Zyklus von 7,5 Millisekunden aktiviert
wird. In diesem Fall kann, wenn die REs 503 und 504 in
einem Zyklus von 8 Millisekunden laufen gelassen werden, der kein Problem
bei einem Realisieren der Funktionen bewirkt, der Funktionstrigger
511, um die REs 503 und 504 laufen zu lassen,
der periodischen Aufgabe 602 zugewiesen sein, die alle
8 Millisekunden arbeitet.
-
Die
REs 501 und 502, welche Steuerlogiken des Antriebsstrangkoordinators 103 sind,
empfangen Daten 514 (siehe 5) als erforderlichen
Wert eines Steuerns, der durch den oberen Fahrzeugbewegungskoordinator 102 erzeugt
wird, wie zum Beispiel Daten, die ein erforderliches Achsendrehmoment darstellen,
und verarbeiten das empfangene erforderliche Achsendrehmoment in Übereinstimmung
mit einem Zustand des Antriebsstrangs in dem Fahrzeug.
-
Zum
Beispiel verarbeiten sie das erforderliche Achsendrehmoment zu einem
realisierbaren erforderlichen Wert von den Fahrzeugzuständen, wie zum
Beispiell einem derzeitigen Drehmoment und einer Fahrzeuggeschwindigkeit.
Der Funktionstrigger 511 ist der periodischen Aufgabe 602 zugewiesen, wobei
der Funktionstrigger 511 durch den Betrieb der periodischen
Aufgabe 602 getriggert wird, und die REs 506 bis 507 werden
von dem Funktionstrigger 511 alle 4 Millisekunden laufen
gelassen.
-
Die
REs 505 bis 507, welche Steuerlogiken der Motorsteuerkomponente 104 sind,
empfangen Daten 518 (siehe 5) als erforderliche
Werte eines Steuerns, die von dem oberen Antriebsstrangkoordinator 103 erzeugt
werden, wie zum Beispiel Daten, die ein erforderliches Motordrehmoment
darstellen, und berechnen tatsächliche
Steuergrößen von Aktoren.
Sie berechnen Steuergrößen, wie
zum Beispiel einen Drosselöffnungsgrad,
eine Einspritzmenge und einen Zündzeitpunkt,
auf der Grundlage dieser Steuergrößen, aktivieren Aktoren (nicht
gezeigt), die den Motor bilden, wie zum Beispiel eine elektronisch
gesteuerte Drossel, eine elektronisch gesteuerte Kraftstoffeinspritzdüse und eine
elektronisch gesteuerte Einspritzvorrichtung, und realisieren das
erforderliche Motordrehmoment, das von der oberen Komponente erzeugt
wird.
-
Die
Funktionstrigger 511 und 513 sind der periodischen
Aufgabe 603 zugewiesen, die Funktionstrigger 511 und 513 werden
durch den Betrieb der periodischen Aufgabe 603 getriggert,
und die REs 503 und 504 werden von dem Funktionstrigger 511 alle
8 Millisekunden laufen gelassen.
-
Die
REs 503 und 504, welche Steuerlogiken des Antriebsstrangkoordinators 103 ähnlich den
REs 501 und 502 sind, berechnen auf der Grundlage
des empfangenen Achsendrehmoments, um ein erforderliches Achsendrehmoment
zu realisieren, das in den REs 501 502 berechnet
wird (Verarbeiten eines erforderlichen Achsendrehmoments, das von
dem Fahrzeugbewegungskoordinator 102 erzeugt wird, in Übereinstimmung
mit den Fahrzeugzuständen),
ein erforderliches Motordrehmoment und einen erforderlichen Gang
als erforderliche Steuerwerte an der unteren Motorsteuerkomponente 104 und
der Getriebesteuerkomponente 105.
-
Obgleich
die Daten 518 des berechneten erforderlichen Motordrehmoments
zu der unteren Motorsteuerkomponente 104 weitergeleitet
werden, werden sie in der Motor-ECU 301 empfangen und weitergeleitet,
da sowohl der Antriebsstrangkoordinator 103 als auch die
Motorsteuerkomponente 104 in der Motor-ECU 301 realisiert
sind.
-
Andererseits
werden sie, obgleich die Daten des berechneten erforderlichen Gangs
zu der unteren Getriebesteuerkomponente 105 weitergeleitet werden, über die
Kommunikationsleitung 305 auf dem Netz weitergeleitet,
da die Getriebesteuerkomponente 105 in der AT-ECU 302 realisiert
ist. Die REs 508 und 509 werden von dem periodischen
Trigger 513 alle 8 Millisekunden laufen gelassen.
-
Die
REs 508 und 509, welche die Steuerlogiken der
Motorsteuerkomponente 104 ähnlich den REs 505 bis 507 sind,
berechnen Daten, die für
das Berechnen von Steuergrößen von
Aktoren durch die REs 505 bis 507 erforderlich
sind. Zum Beispiel berechnen sie auf der Grundlage von Sensorwerten, wie
zum Beispiel einem Motordrehzahlsensor, einem Motorwassertemperatursensor
und einem Luftflusssensor, die in dem nicht gezeigten Motor enthalten sind,
ein geschätztes
Motordrehmoment und dergleichen und führen die Daten 522,
die diese zeigen, der RE 507 zu.
-
In 6 sind
in der periodischen Aufgabe 603-b der Funktionstrigger 511,
der von der periodischen Aufgabe 603 erzeugt wird, wenn
die Ereignisaufgabe 601 den Funktionstrigger 510 erzeugt,
und die REs 503 und 504, die von dem Funktionstrigger laufen
gelassen werden, durch gestrichelte Linien gezeigt. Dies bedeutet,
dass in dem angezeigten Zeitpunkt der Funktionstrigger 511 nicht
getriggert wird und die REs 503 und 504 nicht
ausgeführt
werden.
-
Obgleich
beide der REs 503 und 504 Teil des Antriebsstrangkoordinators 103 sind,
ist, da der Antriebsstrangkoordinator 103 eine Komponente
ist, die auf das Erzeugen einer Steueranforderung von dem Fahrzeugbewegungskoordinator 102,
das heisst auf das Erzeugen des Funktionstriggers 510 aktiviert wird,
der Antriebsstrangkoordinator 103 während eines Betriebs der periodischen
Aufgabe 603-b nicht aktiv.
-
Da
jedoch die periodische Aufgabe 603 periodisch arbeitet,
würde ein
Triggern des Funktionstriggers 511 an jedem Betrieb der
periodischen Aufgabe 603 den Betrieb der REs 503 und 504 ohne
Aufweisen einer Funktion des Antriebsstrangkoordinators 103 bewirken.
Deshalb wird durch Anwenden eines Mechanismus zum Halten einer Betriebsinformation des
Antriebsstrangkoordinators 103, wie zum Beispiel eines
Belegt- und Stopp-Zustands, und durch Beziehen auf die Betriebsinformationen
zu der Zeit des Erzeugens des Funktionstriggers 511 eine
Konsistenz des Betriebs einer Funktion (das heisst des Antriebsstrangkoordinators 103)
mit der Funktion einer RE (das heisst der REs 503, 504)
sichergestellt.
-
Wie
es zuvor beschrieben worden ist, werden die Funktionstrigger 510 bis
513, um Funktionen (Komponenten) zu betreiben, von den Softwaretriggern 604 bis 606 getrennt,
um tatsächlich
Programme bezüglich
Software auszuführen,
und ist der Funktionstrigger 510 den Softwareaufgaben 601 bis 603 zugewiesen.
Die Funktionstrigger 510 bis 513 und die Softwaretrigger 604 bis 606 werden
während eines
Softwareentwurfs kombiniert.
-
Eine
derartige Softwarestruktur lässt
einen Funktionsentwurf ohne Berücksichtigung
bezüglich Hardware
zu. Anders ausgedrückt
wird, da ein Einfluss einer Hardwareänderung und einer Änderung eines
funktionalen Entwurfs vermieden werden kann, die Wiederverwendbarkeit
von Funktionen sichergestellt.
-
Zum
Beispiel wird, wie es in dem vorhergehenden Ausführungsbeispiel beschrieben
ist, in dem Fall, in dem ein zeitlich getriggerter Typ, wie zum
Beispiel FlexRay, für
die Kommunikationsleitung 305 angewendet wird, und Komponenten,
die mit einer hohen Genauigkeit verteilt werden, synchron aktiviert werden,
ein Aufgabenentwurf auf der Grundlage der Softwaretrigger 604 bis 604 durchgeführt, die
von einem internen Zeitgeber der Kommunikationssteuervorrichtung
getriggert werden, und werden die Funktionstrigger 510 bis 513 den
Aufgaben 601 bis 603 zugewiesen. Deshalb müssen die
Inhalte eines Funktionsentwurfs nicht geändert werden.
-
Weiterhin
ist, wenn der Fahrzeugbewegungskoordinator 102 in der gleichen
Motor-ECU 301 wie der Antriebsstrangkoordinator 103 verwendet
wird, eine einzige Änderung,
die für
den Fahrzeugbewegungskoordinator 102 erforderlich ist,
dass der Softwaretrigger 604, der auf das Empfangen von Netzdaten
getriggert worden ist, bezüglich
des Aktualisierens einer Steueranforderung (des Aktualisierens eines RAM)
getriggert werden sollte. Anders ausgedrückt müssen die Inhalte eines Funktionsentwurfs
nicht geändert
werden.
-
Obgleich
die vorliegende Erfindung vollständig
in Verbindung mit dem bevorzugten Ausführungsbeispiel von ihr unter
Bezugnahme auf die beiliegende Zeichnung beschrieben worden ist,
versteht es sich, dass verschiedene Änderungen und Ausgestaltungen
für Fachleute
ersichtlich werden.
-
Das
heisst, die vorliegende Erfindung beschreibt ein Anwenden einer
Funktionsstruktur an dem Fahrzeugsteuernetzsystem, das verschiedene Fahrzeugstabilitätssteuerfunktionen
für ein
sicheres Realisieren von bestimmten Fahrzeugbewegungssteuervorgängen auf
der Grundlage der Fahreranforderungen verwendet. Jedoch kann die
Funktionsstruktur der vorhergehenden Erfindung ebenso allgemein
an einem unterschiedlichen System anwendbar sein, das zu der vorhergehenden
Beschreibung unterschiedliche Steuerfunktionen beinhaltet.
-
Derartige Änderungen
und Ausgestaltungen verstehen sich als innerhalb des Umfangs der
vorliegenden Erfindung, wie er durch die beiliegenden Ansprüche definiert
ist.
-
Ein
zuvor beschriebenes Softwaresystem zur Verwendung in einer elektronischen
Steuereinheit ist dazu ausgelegt, seine Wiederverwendung ohne erneutes
Entwerfen von Triggern auch dann zu erleichtern, wenn eine Zielhardware
geändert
wird. Der Entwurf des Softwaresystems beinhaltet eine Klassifikation
von Triggertypen in zwei Kategorien, das heisst einen Funktionstrigger
und einen Softwaretrigger, und eine Kombination des Funktionstriggers
mit Softwareaufgaben zusätzlich
zu dem Zuweisen der Funktionstrigger zu den Softwaretriggern für einen
von einer Hardware unabhängigen
Entwurf des Softwaresystems.