-
TECHNISCHES
GEBIET
-
Die
vorliegende Erfindung betrifft Netzwerke, die in Fahrzeugen verwendet
werden, um eine verteilte Steuerung verschiedener Fahrzeugfunktionen
bereitzustellen, und insbesondere solche Netzwerke, die verschiedene
Gruppierungen von elektronischen Steuereinheiten (ECUs) verwenden,
um verschiedene Steueraufgaben auszuführen.
-
HINTERGRUND
DER ERFINDUNG
-
Bei
derzeitigen Fahrzeugen sind elektronische Steuereinheiten (ECUs)
in dem Fahrzeug verteilt, um eine Vielzahl von verschiedenen Fahrzeugfunktionen
auszuführen.
Diese Fahrzeugfunktionen können
bedienergesteuert oder automatisiert sein und werden hierin allgemein
als Steueraufgaben bezeichnet. Diese Steueraufgaben können z.B.
ein Steuern von Fahrzeugtürverriegelungen,
der Sitzposition, des Fahrtreglers, der Unterhaltungssystemeinrichtungen
(Tuner, CD-Spieler, etc.), von HLK, von Einbruchalarmen, der Innen-
und Außenbeleuchtung,
der elektrischen Scheibenposition, von Maschinen- und Fahrzeugsystemdiagnosen,
und seit kurzem Aufgaben, wie beispielsweise eine Sitzheizung und
eine Rückwärtserfassung,
umfassen.
-
Eine
häufige
falsche Vorstellung ist, dass jede der in dem Fahrzeug verwendeten
ECUs einer spezifischen Aufgabe gewidmet ist. Während einige ECUs, einschließlich Antriebsstrang-Steuermodulen
und Antiblockiersystem-Controllern, die Tendenz dazu haben, einer
einzelnen Steueraufgabe gewidmet zu sein, ist dies im Allgemeinen
für die
meisten anderen ECUs nicht der Fall. Viele Steueraufgaben werden
durch verschiedene ECUs ausgeführt,
die gemeinsam arbeiten und ihren Betrieb über einen Datenlink koordinieren.
Es kann sein, dass eine typische ECU einen Abschnitt der Steuerlogik
für verschiedene
nicht in Beziehung stehende Fahrzeugsteueraufgaben enthält und nicht
die vollständige
Steuerlogik für
jede einzelne Steueraufgabe enthält.
-
Die
ECUs sind typischerweise über
einen oder mehrere Fahrzeugbusse miteinander verbunden, die im Allgemeinen
als serielle Kommunikationsbusse in Form eines lokalen Netzwerks
verbunden sind. Zusätzlich
zu den Grundmechanismen zum Übertragen
von Signalen zwischen ECUs über
den Fahrzeugbus muss jede zuverlässige
Kommunikationsstrategie auch sicherstellen, dass eine Anzahl von
anderen ergänzenden Aufgaben
ausgeführt
wird. Eine dieser Aufgaben wird Netzwerkverwaltung genannt und wird
verwendet, um einen systemweiten allgemeinen Ansatz bereitzustellen,
um beispielsweise ein geordnetes Hochfahren (Aktivierung) von Kommunikationsfähigkeiten,
ein geordnetes Herunterfahren (Deaktivierung) von Kommunikationsfähigkeiten
und eine vorhersagbare Behebung von detektierbaren Kommunikationsfehlern
handzuhaben.
-
Mechanismen
zum Ausführen
eines geordneten Hochfahrens und Herunterfahrens sind wichtig, damit ECUs
ihre Signalempfangserwartungen mit der Signalübertragungsverfügbarkeit
anderer ECUs synchronisieren können.
Wenn diese Synchronisation nicht stattfindet, kann eine ECU das
Fehlen von Signalübertragungen
als das Versagen einer der anderen ECUs interpretieren und sichere
Standardsignalwerte annehmen, die durch den Insassen als ein inkorrekter
Fahrzeugbetrieb wahrgenommen werden können. Zum Beispiel können Scheinwerfer
standardmäßig "an" sein, wenn das Tag/Nacht-Sensorsignal
nicht rechtzeitig übertragen
wird.
-
Existierende
Fahrzeugnetzwerkverwaltungsstrategien sind relativ einfach. Die
Einfachheit rührt
von der Tatsache her, dass alle ECUs in einem Fahrzeug gleichzeitig
aktiviert und deaktiviert werden. Als ein Ergebnis ist der einzige
Verkomplizierungsfaktor, dass es sein kann, dass einige ECUs langsamer
ansprechen als andere. Es gibt Fahrzeugnetzwerkschemas, die einer
ECU ermöglichen,
andere ECUs zu aktivieren, jedoch nicht auf eine Weise, die von
einer Fahrzeugplattform unabhängig
ist und die mehreren ECUs ermöglicht, die
gleiche Ansammlung von ECUs zu aktivieren. Ferner sprechen sie auf
die Weise, auf die sie ihre Beginnoperationen auf "Anforderung" ausführen, nicht
so schnell an. Dies reduziert ihre Effektivität erheblich, da der Hochfahrprozess
schnell genug ausgeführt
werden muss, um zu verhindern, dass der Insasse Verzögerungen wahrnimmt,
die einem Knopfdruck folgen, welcher erfordert, dass die ECUs Steueroperationen
ausführen. Wenn
dies nicht möglich
ist, ist die einzige andere Möglichkeit,
die ECUs zu jedem Zeitpunkt wachzuhalten, zu dem es sein kann, dass
ein Insasse ihre Funktionalität
wünscht.
-
Der
Verbrauch der elektrischen Leistung bei derzeitigen Fahrzeugen erreicht
die Grenzen bezüglich dessen,
was durch die bestehende elektrische Fahrzeuginfrastruktur wirtschaftlich
bereitgestellt werden kann. Ein Verfahren zum Reduzieren des Verbrauchs
ist, die ECUs, die keine Fahrzeugfunktionalität aktiv steuern, in einen "Standby-" oder "Schlaf-"Zustand mit niedriger
Leistung zu bringen. Zum Beispiel werden Scheiben- und Sitzsteuer-ECUs
selten verwendet und können
für gewöhnlich in
einen Standby-Zustand gebracht werden. Aus der Perspektive einer
Netzwerkverwaltung führen
Fahrzeugsysteme mit sich im Standby-Zustand befindlichen ECUs eine
beträchtliche
Komplexität
ein. Bei diesen Systemen ist es gewünscht, ein Hochfahren und Herunterfahren
beliebiger Teilsätze
der ECU-Population des Fahrzeugs zu synchronisieren, während andere
ECUs "schlafen" gelassen werden.
Ferner sollte ein robuster Netz werkentwurf in der Lage sein, angeforderte
ECU-Sätze
hochzufahren, ohne die Steueroperationen zu stören, die durch die bereits
wachen ECUs ausgeführt
werden. Schließlich
sollte, damit eine ECU in mehreren Fahrzeugplattformen verwendet
werden kann, die ECU in der Lage sein, ihre Signalliefereinrichtungen
sogar hochzufahren, wenn es sein kann, dass die Signale an jeder
Plattform durch verschiedene ECUs geliefert werden.
-
EP 0 773 650 A2 offenbart
ein Fahrzeugnetzwerk einschließlich
mehrerer ECUs, ein Netzwerk-Power-Management-Verfahren und ein ECU-Steuerverfahren
gemäß den Oberbegriffen
der unabhängigen
Ansprüche.
-
Es
ist daher ein Hauptziel dieser Erfindung, ein fahrzeugeigenes Fahrzeugnetzwerk
bereitzustellen, das eine Netzwerkverwaltungsstrategie verwendet,
welche an dem Netzwerk verteilten ECUs ermöglicht, andere ECUs auf eine
plattformunabhängige
Weise unter Verwendung einer gemeinsamen Kommunikationsstrategie
zu aktivieren, die den ECUs ermöglicht,
in einem Ruhezustand mit niedriger Leistung gehalten zu werden,
bis sie benötigt
werden.
-
Dieses
Ziel wird durch das Fahrzeugnetzwerk, das Netzwerk-Power-Management-Verfahren
und das ECU-Steuerverfahren der unabhängigen Ansprüche erreicht.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
vorliegende Erfindung stellt ein fahrzeugeigenes Fahrzeugnetzwerk
und ein Verfahren zum Betreiben des Netzwerks bereit, das einer
ECU ermöglicht,
die anderen für
eine bestimmte Fahrzeugsteueraufgabe verwendeten ECUs zu aktivieren,
ohne vorab wissen zu müssen,
welche ECUs beim Ausführen
der Steueraufgabe verwendet werden. Das Netz werk umfasst eine Mehrzahl
von fahrzeugeigenen Fahrzeugelektronik-Steuereinheiten (ECUs), die über mindestens
einen Netzwerkbus miteinander verbunden sind, wobei das Netzwerk
in einer Mehrzahl von virtuellen Netzwerken angeordnet ist, die
jeweils eine Gruppe der ECUs umfassen, die zusammen eine Fahrzeugsteueraufgabe
ausführen.
Somit sind die ECUs, die zusammen ein erstes der virtuellen Netzwerke
umfassen, zusammen betreibbar, um eine erste Steueraufgabe auszuführen, und sind
jeweils unter Verwendung eines dem ersten virtuellen Netzwerk zugehörigen ersten
Codes identifiziert. Ähnlich
sind die ECUs, die das zweite virtuelle Netzwerk umfassen, zusammen
betreibbar, um eine zweite Steueraufgabe auszuführen, und sind jeweils unter
Verwendung eines dem zweiten virtuellen Netzwerk zugehörigen Codes
identifiziert. Die ersten und zweiten virtuellen Netzwerke können unter
Verwendung jeweiliger erster und zweiter Nachrichten aktiviert werden,
die sie über
den Fahrzeugbus empfangen. Sobald ein virtuelles Netzwerk aktiviert
ist, ist es dann betreibbar, um seine zugehörigen Steueraufgaben auszuführen. Vorzugsweise
umfassen die Nachrichten einen oder mehrere der Codes, die verwendet
werden, um die ECUs in einem bestimmten virtuellen Netzwerk zu identifizieren.
Auf diese Weise kann eine ECU andere ECUs aus ihrem Standby-Modus
aufwecken, ohne wissen zu müssen,
welche ECUs ein Teil des virtuellen Netzwerks sind, das verwendet
wird, um eine bestimmte Steueraufgabe zu realisieren.
-
Gemäß einem
anderen Aspekt der Erfindung ist ein Verfahren zum Verwalten eines
fahrzeugeigenen Fahrzeugnetzwerks bereitgestellt, das ECUs verwendet,
die zwischen einem aktiven Zustand und einem Ruhezustand mit niedriger
Leistung geschaltet werden können.
Das Netzwerk umfasst mindestens eine Gruppe oder einen Teilsatz
der ECUs an dem Netzwerk, wobei die Gruppe von ECUs zusammen betreibbar
ist, um eine bestimmte Fahrzeugsteueraufgabe auszuführen. Das
Verfahren umfasst die Schritte, dass eine Signalanfrage zum Aktivieren
einer Steueraufgabe empfangen wird; die ECUs aus dem Ruhezustand
mit niedriger Leistung aufgeweckt werden; und eine Nachricht an
die ECUs gesendet wird, die einen der Steueraufgabe zugehörigen Code
umfasst. Diese Nachricht wird von einigen oder allen der ECUs in
dem Netzwerk empfangen, und jede dieser ECUs geht, wenn der in der
Nachricht umfasste Code einer der ECU zugehörigen Steueraufgabe entspricht,
dann in einen aktiven Zustand über,
in dem die ECU betreibbar ist, um zusammen mit anderen der Steueraufgabe
zugehörigen
ECUs die Steueraufgabe auszuführen.
Wenn jedoch der in der Nachricht umfasste Code keiner der ECU zugehörigen Steueraufgabe
entspricht, dann geht sie in den Ruhezustand mit niedriger Leistung über.
-
Wenn
notwendig, kann den Nachrichten für die ECUs ein Aufwecksignal
vorangehen, das alle ruhenden ECUs in den aktiven Zustand schaltet.
Sobald die ECUs aufgeweckt sind, überwachen sie jeweils den Empfang
einer Nachricht, die einen einer der Steueraufgaben, für die sie
verwendet werden, zugehörigen Code
enthält.
Wenn innerhalb einer Zeitdauer dem Aufwecksignal folgend kein Code
empfangen wird, schalten sie zurück
in ihren Ruhezustand mit niedriger Leistung. Wenn ein Code empfangen
wird, dann prüft
jede ECU, ob sie zu dem empfangenen Code gehört; wenn dies der Fall ist,
geht sie in einen Programmmodus über,
in dem sie mit den anderen geeigneten ECUs arbeitet, um die zugehörige Steueraufgabe
auszuführen.
Wenn nicht, schaltet die ECU zurück
in den Ruhezustand. Auf diese Weise kann jede ECU an dem Netzwerk
verwendet werden, um andere einer bestimmten Steueraufgabe zugehörige ECUs
zu aktivieren, und dies kann stattfinden, ohne wissen zu müssen, welche
anderen oder wie viele andere ECUs involviert sind. Dies ermöglicht Systementwürfe, bei
denen eine bestimmte ECU an verschiedenen Fahrzeugplattformen ver wendet
werden kann, sogar, wenn die Funktion an jeder Plattform verschieden
ausgeführt
wird.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Hierin
nachfolgend werden bevorzugte beispielhafte Ausführungsformen der vorliegenden
Erfindung in Verbindung mit den beigefügten Zeichnungen beschrieben,
in denen gleiche Bezugszeichen gleiche Elemente bezeichnen, und:
-
1 ein
Blockdiagramm ist, das den physikalischen Entwurf eines ersten beispielhaften
fahrzeugeigenen Fahrzeugnetzwerks der vorliegenden Erfindung zeigt;
-
2 ein
Blockdiagramm des Netzwerks von 1 ist, das
es gemäß einer
bevorzugten Ausführungsform
der Erfindung in drei virtuelle Netzwerke organisiert zeigt;
-
3 ein
Flussdiagramm ist, das den Prozess zeigt, der durch eine ECU ausgeführt wird,
um eines der virtuellen Netzwerke zu aktivieren und es aktiv zu
halten, bis seine zugehörige
Steueraufgabe abgeschlossen ist;
-
4 ein
Flussdiagramm ist, das den Prozess zeigt, der durch jede der ECUs
an dem Fahrzeugbus ausgeführt
wird, wenn eines der virtuellen Netzwerke durch eine andere ECU
an dem Bus aktiviert wird;
-
5 den
Aufbau der Nachrichten zeigt, die verwendet werden, um die virtuellen
Netzwerke von 2 zu aktivieren;
-
6 ein
Blockdiagramm ist, das ein zweites beispielhaftes fahrzeugeigenes
Fahrzeugnetzwerk der vorliegenden Erfindung zeigt, das in drei virtuelle
Netzwerke organisiert ist;
-
7 ein
Blockdiagramm ist, das die Verwendung von Gateways zeigt, um einen
Kommunikationszugriff von dem Netzwerk von 2 auf andere
fahrzeugeigene und entfernte Netzwerke bereitzustellen;
-
8 ein
konzeptionelles Modell eines Kommunikations-Kernels ist, der durch eine ECU verwendet wird,
um über
das Netzwerk von 1 zu kommunizieren; und
-
9 ein Übersichtsblockdiagramm
ist, das zeigt, wie die Gateways von 6 verwendet
werden, um eine Kommunikation zwischen ECUs an verschiedenen Netzwerken
bereitzustellen.
-
BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
Zuerst
Bezug nehmend auf 1 ist ein fahrzeugeigenes Fahrzeugnetzwerk 10 der
vorliegenden Erfindung gezeigt. Wie bei einem herkömmlichen
Netzwerkentwurf umfasst das Netzwerk 10 eine Anzahl von elektronischen
Steuereinheiten (ECUs), die miteinander mittels eines fahrzeuginternen
Netzwerkbusses 12 verbunden sind, der ein serieller Kommunikationsbus oder
ein anderer geeigneter Datenlink sein kann. Insbesondere umfasst
das dargestellte Netzwerk 10 insgesamt sieben ECUs, die
die folgenden Steueraufgaben unterstützen:
- 1.
elektrische Scheibenheber – eine
gegebene Scheibe einer Fahrzeugtür
kann durch einen Schalter an der Tür elektrisch bedient werden,
und der Fahrer kann einen beliebigen der (vier) elektrischen Scheibenheber aus
einer Anordnung von Schaltern an der Fahrertür bedienen;
- 2. Fahrersitzheizung – die
Heizspule in dem Fahrersitz kann von einem Schalter an der Schalteranordnung des
Fahrers angeschaltet oder abgeschaltet werden;
- 3. elektrische Außenspiegel – beide
Fahrzeugseitenspiegel können
dadurch bewegt werden, dass der Fahrer Schalter in der Schalteranordnung
des Fahrers verwendet.
-
Weder
die einzelnen Fahrzeugsysteme noch ihre Sensoren und Aktuatoren
sind dargestellt; jedoch liegen der Entwurf solcher Systeme und
die Integration mit den verteilten ECUs innerhalb des Niveaus des Stands
der Technik. Es sei auch angemerkt, dass das erläuterte Netzwerk lediglich ein
Teil eines typischen fahrzeugeigenen Fahrzeugnetzwerks ist und für den Zweck
eines Erläuterns
des Aufbaus und Betriebs der vorliegenden Erfindung gezeigt ist.
In dem in 1 gezeigten Netzwerk könnten und
würden
normalerweise zahlreiche andere ECUs und Steueraufgaben umfasst
sein.
-
Wie
in 1 gezeigt, umfasst das Netzwerk 10 die
folgenden ECUs. Eine Fahrerbedienfeld-ECU (DCP-ECU von driver's control panel ECU) 14 wird verwendet,
um die Schaltergruppe des Fahrers zu verwalten, die Scheiben-, Spiegel-
und Sitzheizungsschalter umfasst. Eine ECU 15 des Bereichs
links vorne (LFZ-ECU von left front zone ECU) wird verwendet, um
die Scheiben- und Spiegelmotoren links vorne zu verwalten. Die verbleibenden
fünf Module
sind jeweils einer einzelnen Aufgabe gewidmet. Im Speziellen verwalten
die ECU 16 der Scheibe links hinten (LRW-ECU von left rear
window ECU), die ECU 17 der Scheibe rechts hinten (RRW-ECU
von right rear window ECU) und die ECU 18 der Scheibe rechts
vorne (RFW-ECU von right front window ECU) ihre entsprechenden Scheibenschalter
und -motoren. Die Fahrersitzheizungs-ECU (DHS-ECU von driver's heated seat ECU) 19 verwaltet
die Sitzheizungsspule, und die ECU 20 des Spiegels rechts
vorne (RFM-ECU von right front mirror ECU) verwaltet den entsprechenden
Spiegelmotor.
-
Die
folgende Tabelle listet die verschiedenen ECUs und ihre zugehörigen Fahrzeugfunktionen
(Steueraufgaben) auf. Wie oben erwähnt werden einige der ECUs
verwendet, um mehr als eine Steueraufgabe auszuführen, wohingegen andere einer
einzigen Aufgabe gewidmet sind. Somit wird z.B. die Fahrerbedienfeld-ECU
(DCP-ECU) zum Ausführen
aller drei Steueraufgaben verwendet, wohingegen die Fahrersitzheizungs-ECU
(DHS-ECU) einem Erwärmen
des Fahrersitzes gewidmet ist und bei allen anderen Fahrzeugfunktionen
keine Rolle spielt.
-
-
Gemäß einem
Aspekt der Erfindung sind die gezeigten ECUs 14-20 an
dem Netzwerk 10 in drei virtuelle Netzwerke bzw. VNs aufgeteilt – eines
für jede
der oben genannten drei Steueraufgaben. Somit können, wie in 2 gezeigt,
die sieben ECUs in ein virtuelles Netzwerk 22 für elektrische
Scheibenheber, ein virtuelles Sitzheizungs-Netzwerk 23 und
ein virtuelles Netzwerk 24 für elektrische Außenspiegel
aufgeteilt werden. Das virtuelle Scheiben-Netzwerk 22 umfasst
die Fahrerbedienfeld-ECU 14 sowie die vier ECUs 15-18,
die verwendet werden, um die Motoren für die vier Scheiben zu steuern.
Das virtuelle Fahrersitzheizungs-Netzwerk 23 umfasst die
Fahrerbedienfeld-ECU 15 und die Fahrersitzheizungs-ECU 19.
Das virtuelle Netzwerk 24 für elektrische Außenspiegel
umfasst die ECU 14 für
den Bereich links vorne, die Fahrerbedienfeld-ECU 15 und
die ECU 20 für
den Spiegel rechts vorne. Ein primärer Vorteil der Aufteilung
des Netzwerks in diese virtuellen Netzwerke gemäß den verschiedenen Steueraufgaben
ist, dass die ECUs an dem Fahrzeugbus 12 in einem Ruhezustand
mit niedriger Leistung gehalten werden können, wenn sie nicht in Verwendung
sind, und dann nur jene ECUs, die für eine bestimmte Steueraufgabe
nötig sind,
aufgeweckt und in einem aktiven Zustand gehalten werden müssen.
-
Zum
Beispiel erfordert ein Bewegen des linken Spiegels eine Kommunikation
zwischen der Fahrerbedienfeld-ECU und der ECU des Bereichs links
vorne, da der Spiegelsteuerschalter mit der Fahrerbedienfeld-ECU 14 verbunden
ist, während
der Motor des linken Spiegels durch die ECU 15 des Bereichs
links vorne gesteuert ist. Somit wird eine Schalteraktivierung von
dem Fahrer zum Bewegen des linken Spiegels durch die Fahrerbedienfeld-ECU 14 detektiert,
die das virtuelle Netzwerk 24 für elektrische Außenspiegel
aktiviert. Diese Aktivierung umfasst, dass die ECUs aus ihrem Standby-Zustand
aufgeweckt werden (unter der Annahme, dass einige oder alle von
ihnen nicht bereits wach sind und eine andere Funktion ausführen), und
dann die geeignete Steuerlogik ausgeführt wird, um die Funktion auszuführen. Diese
Steuerlogik kann derart in die verschiedenen ECUs programmiert sein,
dass sie auf geeignete Weise miteinander kommunizieren, um die bestimmte
Steueraufgabe zu realisieren – in
diesem Fall eine Bewegung des linken Spiegels.
-
Als
ein anderes Beispiel wird die Steuereingabe für die Fahrersitzheizung einer
ECU (der Fahrerbedienfeld-ECU 14) geliefert, die von der
ECU verschieden ist, die verwendet wird, um die Sitzheizung zu aktivieren
(die Fahrersitzheizungs-ECU 19). Somit wird das virtuelle
Sitzheizungs-Netzwerk 23 aktiviert,
wann immer der entsprechende Schalter an dem Fahrerbedienfeld ausgewählt wird.
Die Aktivierung eines virtuellen Netzwerks, um eine bestimmte Steueraufgabe
auszuführen,
muss nicht von einer der ECUs 14-20 stammen; vielmehr
kann sie von einer anderen Quelle stammen, wie beispielsweise einer
anderen ECU an dem Fahrzeugbus 12. Ein Beispiel hierfür ist die
Verwendung von noch einer anderen ECU (nicht gezeigt), die verbunden
ist, um Eingaben von dem Zündsystem
zu empfangen, so dass auf ein Detektieren eines personalisierten
Schlüssels
hin, der für
den Fahrer eindeutig ist, durch diese andere ECU ein Signal an die
ECUs 14, 15 und 20 gesendet wird, um
das virtuelle Spiegel-Netzwerk
zu aktivieren und die Spiegel auf eine voreingestellte Position zu
bewegen, die zuvor für
diesen bestimmten Fahrer in einem Speicher gespeichert wurde. Bei
diesem Beispiel wäre
die zusätzliche
ECU in dem virtuellen Spiegel-Netzwerk 24 umfasst. Ähnlich könnte die
Aktivierung dieses virtuellen Netzwerks, um die Seitenspiegel auf
eine voreingestellte Position zu bewegen, von noch einer anderen
ECU (nicht gezeigt) stammen, die Teil eines entfernten Kommunikationssystems
ist, das Signale von einem Schlüsselanhänger oder
einem anderen entfernten Sender empfängt.
-
In
dem in 2 gezeigten Netzwerk wird jedes der drei virtuellen
Netzwerke jedes Mal aktiviert, wenn eine seiner zugehörigen Schaltereingaben
ausgewählt
wird. Somit wird beispielsweise, wenn der Schalter für die Scheibe
rechts vorne niedergedrückt
wird, das virtuelle Scheiben-Netzwerk 22 über die
ECU 18 aktiviert, die den Tastendruck erfasst. Jedoch erfordern
nicht alle durch ein Element eines virtuellen Netzwerks ausgeführten Funktionen
ein Aktivieren des virtuellen Netzwerks. Zum Beispiel kann die ECU 18 der
Scheibe rechts vorne, obwohl sie ein Teil des virtuellen Scheiben-Netzwerks 22 ist,
das fünf
der ECUs umfasst, auf eine Weise realisiert sein, die keine Netzwerkkommunikation
erfordert, wenn der Schalter für
die Scheibe der Tür
rechts vorne aktiviert wird, da sowohl dieser Schalter als auch
der zugehörige
Motor der Scheibe rechts vorne durch dieselbe ECU gesteuert sind.
Umgekehrt werden, wenn der Fahrerbedienfeld-Schalter (DCP-Schalter)
für die Scheibe
der Tür
rechts vorne durch den Fahrer niedergedrückt wird, verschiedene ECUs
zum Detektieren des Schaltereignisses und Aktivieren des Scheibenmotors
verwendet. Demgemäß wird das
virtuelle Scheiben-Netzwerk aktiviert, einschließlich jener beider ECUs, die
verwendet werden, um die Steuerfunktion der Scheibe rechts vorne
zu erreichen, und jener ECUs in dem Netzwerk (wie beispielsweise
die ECUs für
die Scheiben links und rechts hinten), die bei der bestimmten Scheibenaktivierung
nicht involviert sind.
-
Ein
bedeutender Vorteil dieser Verwendung virtueller Netzwerke ist,
dass die Netzwerkverwaltungsstrategie die Aktivierung der notwendigen
ECUs zum Ausführen
einer Steueraufgabe ermöglicht,
ohne dass die verschiedenen involvierten ECUs wissen müssen, welche
oder wie viele andere ECUs für
die bestimmte Aufgabe erforderlich sind. Dies ermöglicht es,
die vielen Steueraufgaben unter Verwendung mehrerer ECUs auf eine
modulare verteilte Weise zu realisieren, während ein größerer Grad
an Unabhängigkeit
von der Steuerlogik für
eine bestimmte ECU zwischen verschiedenen Fahrzeugplattformen ermöglicht wird.
Dieser Aspekt der Erfindung wird nachstehend erläutert.
-
Die
Netzwerkverwaltung der virtuellen Netzwerke 22-24 verwendet
ein Nachrichtenprotokoll über
den Fahrzeugbus 12, das ermöglicht, alle ECUs in einem
bestimmten virtuellen Netzwerk zu aktivieren und in einem Betriebszustand
zu halten, bis die zugehörige
Steueraufgabe abgeschlossen ist. Die Aktivierung der ECUs in einem
virtuellen Netzwerk wird typischerweise durch eine der ECUs in dem
virtuellen Netzwerk eingeleitet, obwohl andere Auslöseeinrichtungen
und Quellen verwendet werden können.
-
Ein
bevorzugtes Verfahren zum Aktivieren eines der virtuellen Netzwerke
ist allgemein in 3 gezeigt, und die Verarbeitung
von Aufwecksignalen und Nachrichten, die die virtuellen Netzwerke
betreffen, ist in 4 gezeigt. Allgemein umfasst
eine Aktivierung eines virtuellen Netzwerks ein Aufwecken der ECUs
an dem Fahrzeugbus in Ansprechen auf eine Steueraufgabenanfrage
(wie beispielsweise eine Knopfaktivierung durch den Fahrer), ein
Senden einer Nachricht über
den Bus, um das dieser Steuer aufgabe zugehörige virtuelle Netzwerk zu
aktivieren, und dann ein Senden periodischer Nachrichten, um die
ECUs in dem virtuellen Netzwerk aktiv zu halten, bis die Steueraufgabe
abgeschlossen ist.
-
Genauer
gesagt beginnt der Prozess, wie bei Block 30 von 3 gezeigt,
beim Empfang einer Signalanfrage zum Aktivieren einer Steueraufgabe.
Diese Signalanfrage kann von einem durch den Fahrer oder einen anderen
Fahrzeuginsassen aktivierten Schalter stammen oder kann automatisch
entweder durch einen Sensor oder als das Ergebnis eines Fahrzeugsoftwareprozesses
erzeugt werden. Diese Anfrage wird durch eine der ECUs empfangen,
die bei Block 32 durch Senden eines Aufwecksignals über den
Fahrzeugbus an die anderen ECUs anspricht. Dieses Aufwecksignal
kann ein Hochspannungsaufwecksignal sein, wie in SAE J2411 "Single Wire CAN Network
for Vehicle Applications – Recommended
Practice" definiert.
Die ECU, die das Aufwecksignal überträgt, wird
für dieses
Steuerereignis als die Master-ECU betrachtet und ist für ein Aktivieren
des der erforderlichen Steueraufgabe zugehörigen virtuellen Netzwerks
verantwortlich. In dieser Hinsicht können verschiedene ECUs simultan
für verschiedene
gleichzeitige Steueraufgaben der Master sein und kann eine einzelne
ECU für
mehr als eine gleichzeitige Steueraufgabe ein Master sein. Wenn
beispielsweise der Sitzheizungsschalter an dem Fahrerbedienfeld
ausgewählt
wird, wird das virtuelle Sitzheizungs-Netzwerk 23 aktiviert,
wobei die ECU 14 der Master ist. Wenn der Fahrer, während der
Sitzheizungsprozess ausgeführt wird,
den Schalter für
die Scheibe der Tür
rechts vorne auswählt,
wird das virtuelle Scheiben-Netzwerk 22 aktiviert, wobei
die ECU 18 der Master ist und die anderen ECUs an diesem
virtuellen Netzwerk die Slaves sind. Somit wäre die ECU 14 simultan
zu Zwecken des virtuellen Sitzheizungs-Netzwerks 23 ein
Master und zu Zwecken des virtuellen Scheiben-Netzwerks 22 ein
Slave.
-
Es
wird nun wieder das bei Block 32 übertragene Aufwecksignal betrachtet,
wobei jene ECUs, die sich in dem Ruhezustand mit niedriger Leistung
befinden, auf dieses Aufwecksignal durch Schalten in einem aktiven
Zustand ansprechen, in dem sie beginnen, den Empfang von Nachrichten
an dem Fahrzeugbus zu überwachen,
wie es nachstehend in Verbindung mit 4 beschrieben
wird. Als Nächstes
sendet die Master-ECU über
den Fahrzeugbus 12 eine Nachricht eines virtuellen Netzwerks
bzw. eine VN-Nachricht
(VNM von virtual network message) aus, wie bei Block 34 angegeben.
Diese VNM wird verwendet, um das zu aktivierende virtuelle Netzwerk
und somit die ECUs, die zum Ausführen
der Steueraufgabe in dem aktivierten Zustand bleiben sollten, zu
identifizieren. Alle anderen ECUs, die keine anderen Steueraufgaben
ausführen,
kehren in ihren Schlafzustand zurück. Die Master-ECU startet
dann einen Ablauf-Timer, der z.B. auf drei Sekunden eingestellt sein
kann. Dies ist bei Block 36 gezeigt. Dann wird bei Block 38 eine Überprüfung durchgeführt, um
zu ermitteln, ob die Steueraufgabe abgeschlossen wurde. Wenn nicht,
bewegt sich der Prozess zu Block 40, bei dem der Timer überprüft wird.
Wenn er noch nicht abgelaufen ist, kehrt der Prozess zu Block 38 zurück, um nochmals
zu überprüfen, ob
die Steueraufgabe abgeschlossen ist. Wenn der Timer abgelaufen ist,
bewegt sich der Prozess zu Block 42, bei dem eine weitere
oder Folge-VNM über
den Fahrzeugbus gesendet wird, um den anderen ECUs in dem virtuellen
Netzwerk anzugeben, dass sie in dem aktiven Zustand fortfahren sollten,
um mit dem Ausführen
der Steueraufgabe fortzufahren. Der Prozessfluss kehrt dann zu Block 36 zurück, um den Timer
zurückzusetzen
und eine weitere Iteration dieses letzten Teils des Prozesses zu
beginnen. Sobald die Steueraufgabe abgeschlossen ist, wie bei Block 38 ermittelt,
werden keine weiteren VNMs zur Unterstützung dieses virtuellen Netzwerks
gesendet, und der Prozess für
diese Steueraufgabe endet.
-
Es
sei angemerkt, dass der Timer verwendet wird, um periodische Folge-VNMs zu senden, die
anderen ECUs in dem virtuellen Netzwerk mitteilen, dass die Steueraufgabe
noch nicht abgeschlossen ist, und dass sie daher in dem aktiven
Zustand bleiben sollten, um ihren Teil der Steueraufgabenlogik auszuführen, wenn
es einen gibt.
-
Der
Prozess von 3 ist der, der durch eine Master-ECU
ausgeführt
wird, um die Aktivierung eines der virtuellen Netzwerke zu steuern.
Bezug nehmend auf 4 ist der Prozess gezeigt, der
durch eine Slave-ECU verwendet wird, wenn Aufwecksignal und eine
VNM empfangen werden. Jede der ECUs ist entweder in ihrem Ruhezustand,
um Energie zu sparen, oder in ihrem aktiven Zustand zum Unterstützen einer
Steueraufgabe in Betrieb. Wie bei den Blöcken 50, 52 und 54 angegeben,
wird jede ECU an dem Fahrzeugbus auf einen Empfang eines Aufwecksignals über den
Fahrzeugbus von einer Master-ECU hin in ihren aktiven Zustand geschaltet,
wenn sie nicht bereits in diesem Zustand arbeitet. Dann wird ein
Ablauf-Timer gestartet, wie bei Block 56 angegeben. Der
Zweck dieses Timers ist, eine Zeitdauer von acht Sekunden bereitzustellen,
während
der die ECU den Empfang einer VNM an dem Bus überwacht, die angibt, welches
virtuelle Netzwerk initiiert werden sollte. Es sei angemerkt, dass
diese Zeitdauer so ausgewählt
ist, dass sie länger
als die Drei-Sekunden-Wiederholungsrate
des in 3 verwendeten Timers ist, so dass dieser Timer
nicht abläuft,
solange Folge-VNMs gesendet werden. Sobald der Timer startet, wird
bei Block 58 eine Überprüfung eines
Empfangs einer VNM ausgeführt.
Wenn keine solche Nachricht empfangen wurde, bewegt sich der Prozess
zu Block 60, bei dem eine Überprüfung des Timers ausgeführt wird,
um zu ermitteln, ob er abgelaufen ist. Wenn nicht, bewegt sich der
Prozessfluss zurück
zu Block 58, um wieder den Empfang einer VNM zu überprüfen. Der
Prozess der Blöcke 58 und 60 fährt entweder
fort, bis eine VNM empfangen wird oder bis der Timer ausläuft. Wenn der
Timer bei Block 60 nicht abläuft, wird eine Überprüfung ausgeführt, um
zu ermitteln, ob die ECU irgendeine andere Aufgabe ausführt, für die sie
wach bleiben sollte. Dies ist bei Block 62 gezeigt. Wenn
andere Operationen durch die ECU ausgeführt werden, dann fährt die
ECU in ihrem aktiven Zustand fort, um jene anderen Operationen auszuführen, wie
bei Block 64 angegeben. Wenn keine solchen Aufgaben ausgeführt werden,
bewegt sich der Prozessfluss statt dessen zu Block 66,
bei dem die ECU in ihren Ruhezustand mit niedriger Leistung zurückgebracht
wird.
-
Wenn
bei Block 58 eine VNM empfangen wird, dann wird bei Block 68 eine Überprüfung ausgeführt, um
zu ermitteln, ob das in der Nachricht identifizierte virtuelle Netzwerk
eines ist, von dem die ECU ein Teil ist. Wie es nachstehend in Verbindung
mit 5 erläutert
wird, kann diese Identifikation unter Verwendung eines Codes in
der Nachricht erreicht werden, der für das virtuelle Netzwerk eindeutig
ist. Wenn die ECU kein Teil des durch den Code identifizierten virtuellen
Netzwerks ist, dann bewegt sich der Prozess zurück zu Block 60, um
den Acht-Sekunden-Timer zu überprüfen und
entweder bei Block 58 mit einem Überwachen des Empfangs zusätzlicher
VNMs fortzufahren oder mittels Block 62 aus der Schleife
auszutreten, wenn erforderlich. Wenn sich die ECU in dem identifizierten
virtuellen Netzwerk befindet, bewegt sich der Prozess zu Block 70,
bei dem die ECU zusammen mit allen anderen in diesem virtuellen
Netzwerk in einen Betriebsmodus geschaltet wird, in dem sie zusammen
arbeiten, um die dem virtuellen Netzwerk zugehörige Steueraufgabe auszuführen. Es wird
auch ein Ablauf-Timer bei Block 72 gestartet. Dieser Timer
kann der gleiche sein wie der bei Block 60 verwendete.
Als Nächstes
wird bei Block 74 eine Überprüfung ausgeführt, um
zu ermitteln, ob eine Folge-VNM empfangen wurde. Wenn dies der Fall
ist, dann muss das virtuelle Netzwerk aktiv bleiben, und der Prozess kehrt
zu Block 72 zurück,
um den Timer zurückzusetzen
und neu zu starten. Wenn keine VNM empfangen wurde, wird der Timer
bei Block 76 überprüft, um zu
ermitteln, ob er abgelaufen ist. Wenn der Timer abgelaufen ist,
ist das virtuelle Netzwerk nicht mehr aktiv, und der Prozess bewegt
sich zu Block 62, um den geeigneten ECU-Betriebszustand
zu ermitteln. Wenn der Timer noch nicht abgelaufen ist, kehrt der
Prozess zu Block 74 zurück,
um mit einem Überwachen
eines Empfangs einer geeigneten VNM fortzufahren. Es sei angemerkt, dass
dieser Timer natürlich,
sowie alle anderen hierin erwähnten,
durch die ECU selbst als Software realisiert sein kann.
-
Um
einen vollständig
konsistenten Ansatz für
die verwendete Nachrichtenübertragung
des virtuellen Netzwerks über
den Fahrzeugbus vorzusehen, spricht jede ECU auf exakt die gleiche
Weise auf Aufweckanfragen und VNMs an, unabhängig davon, ob es sich um eine
Master-ECU oder eine Slave-ECU oder beides handelt. Somit spricht
jede Master-ECU entsprechend dem Prozess von 4 als ein
Slave auf ihre eigene ausgesendete VNM an, obwohl sie der Initiator
dieser Nachricht war. Ferner muss ein einzelnes virtuelles Netzwerk
zu einem Zeitpunkt nicht nur einen Master haben. Vielmehr kann jedes
Auslöseereignis
(wie beispielsweise eine Schalteraktivierung durch einen Insassen)
ein virtuelles Netzwerk hochfahren und dieses aktiv halten, bis
die Funktion bis zu einem Abschluss ausgeführt wurde. Somit wird z.B.,
wenn der Schalter für
die Scheibe rechts hinten durch einen Insassen aktiviert wird, das
virtuelle Scheiben-Netzwerk 22 aktiviert, wobei die ECU 17 der
Master ist und daher eine Initialisierungs-VNM sowie Folge-VNMs
(weitere VNMs) sendet. Wenn der Fahrer, während dieses virtuelle Netzwerk
aktiv ist, den Schalter für
die Scheibe links vorne an dem Fahrerbedienfeld auswählt, dann
sendet auch die ECU 14 eine Initialisierungs-VNM sowie
Folge-VNMs. Jeder Master fährt
mit einem Senden dieser VNMs fort, bis seine zugehörige Aufgabe
abgeschlossen ist. Auf diese Weise hält jede Master-ECU das virtuelle
Netzwerk solange aktiv, wie es benötigt wird. Somit hat aus der Sicht der
Netzwerkverwaltung der Abschluss einer Aufgabe keine Auswirkung
auf die Ausführung
einer anderen, da jede Master-ECU das virtuelle Netzwerk unabhängig von
der anderen aktiv hält.
-
Bezug
nehmend auf 5 wird nun das Format der VN-Nachricht
(VNM) beschrieben. Diese Nachrichten werden als ein Frame 80 übertragen,
der einen Header 82, ein Anfangs-Byte 84, das
den Nachrichtentyp identifiziert, und sieben Netzwerkidentifikator-Byte 86 umfasst,
die verwendet werden, um das durch die Nachricht aktivierte virtuelle
Netzwerk zu identifizieren. Der Header 80 stellt eine Frame-ID
bereit, die in zwei Teile aufgeteilt ist: der erste Teil ist ein
festes Bit-Muster (in der gezeigten Ausführungsform '11000'), das die Nachricht als eine VNM identifiziert,
und der zweite Teil ist eine ECU-ID, die für jede ECU eindeutig ist und
verwendet wird, um zu identifizieren, welche ECU die Nachricht überträgt. Das
feste Bit-Muster umfasst die fünf Bit
hoher Wertigkeit (b6-b10) der Frame-ID 82 und kann verwendet werden,
um ein Filtern der Nachrichten durch die ECUs zu vereinfachen. Die
ECU-ID umfasst die sechs Bit niedriger Wertigkeit (b0-b5) der Frame-ID und
ermöglicht
die eindeutige Identifikation von bis zu vierundsechzig verschiedenen
ECUs. Das Nachrichtentyp-Byte 84 umfasst
byte0 der Nachrichtendaten. Es umfasst ein Bit niedriger Wertigkeit
(b0), das als ein Flag verwendet wird, um anzugeben, ob die VNM
eine anfängliche
VNM (die verwendet wird, um das virtuelle Netzwerk zu initiieren)
oder eine Folge-VNM ist (die verwendet wird, um das virtuelle Netzwerk
aktiv zu halten). Die Bits höherer
Wertigkeit von byte0 können
für zusätzliche
Flags oder Daten verwendet werden, wie es gewünscht ist. Die verbleibenden
sieben Byte (byte1-byte7) sind VN-ID-Bits, die ein oder mehrere
virtuelle Netzwerke eindeutig identifizieren. Jede VN-ID weist die
Form eines Codes auf, der für
dieses virtuelle Netzwerk eindeutig ist, und der daher eindeutig
zu der Steueraufgabe gehört,
für dieses
virtuelle Netzwerk existiert. Da die sieben Byte bis zu 56 Bit liefern,
kann jede Bit- Position
einem anderen der virtuellen Netzwerke entsprechen, wobei eine Null
(gelöschtes
Bit) angibt, dass das dieser Bit-Position zugehörige virtuelle Netzwerk nicht durch
die Nachricht aktiviert wird, und eine Eins (gesetztes Bit) angibt,
dass es dies wird. Somit kann der Code für ein bestimmtes virtuelles
Netzwerk ein einzelnes Bit umfassen, das an einer ausgewählten Position
in der VNM angeordnet ist. Die Verwendung von Bit-Positionen anstatt
sequentieller binärer
Zahlen zum Identifizieren der verschiedenen virtuellen Netzwerke
ermöglicht
einer ECU, die gleichzeitig der Master mehrerer virtueller Netzwerke
ist, eine einzelne VNM zu senden, die dazu dient, all jene virtuellen
Netzwerke aktiv zu halten. Die zugeordneten Bit-Positionen können auch
verwendet werden, um die durch jede ECU erforderliche Verarbeitung
zum Ermitteln, ob sie ein Teil des aktivierten virtuellen Netzwerks
ist, zu vereinfachen. Ein oder mehrere der Bits in diesen sieben
Byte können
zum Bezeichnen eines gemeinsamen virtuellen Netzwerks reserviert
sein, das an verschiedenen Fahrzeugplattformen verwendet wird, wie
beispielsweise ein virtuelles Diagnose-Netzwerk.
-
Es
sei angemerkt, dass jede Nachricht durch Verwenden des oben für die VNMs
erläuterten
Frame-Formats die Informationen umfasst, die notwendig sind, um:
sie von anderen Nachrichten zu unterscheiden; die ECU zu identifizieren,
von der die Nachricht stammt; den Typ von Nachricht zu identifizieren;
und das virtuelle Netzwerk/die virtuellen Netzwerke zu identifizieren,
für das/die
eine anfängliche
oder fortdauernde Aktivierung angefragt wird.
-
Da
nun der Grundoperationsprozess für
sowohl die Master- als auch die Slave-ECUs zusammen mit dem Format
der VNMs definiert wurde, zeigt das folgende Beispiel den gesamten
Prozess, um eines der virtuellen Netzwerke von 2 zu
aktivieren, es aktiv zu halten, bis seine zugehörige Steueraufgabe abgeschlossen
ist, und das Netzwerk dann zu deaktivieren. Bei diesem Beispiel
wird der Betrieb des virtuellen Sitzheizungs-Netzwerks beschrieben,
wie er in Ansprechen auf eine Aktivierung des Sitzheizungsschalters
durch den Fahrer an dem Fahrerbedienfeld stattfinden würde, wobei
die Startannahme ist, dass alle ECUs schlafen, wenn der Fahrer die
Sitzheizung anschaltet. Es ist natürlich zu verstehen, dass die
Aktivierung des virtuellen Netzwerks auch das Ergebnis eines automatischen
Systems sein könnte,
anstatt durch den Fahrer stattzufinden, wie beispielsweise mittels
einer anderen ECU, die die Sitzheizung automatisch anschaltet, wenn
die Fahrzeugzündung
bei kalten Umgebungstemperaturen angeschaltet wird.
- 1. Die Fahrerbedienfeld-ECU (DCP-ECU) 14 erfasst, dass
der Sitzheizungsschalter in die "An"-Position geschaltet
wurde. Sie überträgt sofort
eine Aufwecknachricht.
- 2. Alle sieben ECUs wachen in Ansprechen auf die Aufwecknachricht
auf und bringen sich selber in einen Zustand, der ihnen erlaubt,
während
den nächsten
acht Sekunden übertragene
VNMs zu empfangen. Es können
weitere Aufwecksignale für
eine Zeitdauer (z.B. fünf
Sekunden) blockiert werden, da nun alle ECUs für acht Sekunden wach sind.
- 3. Nach einer kurzen Verzögerung,
um den anderen ECUs zu ermöglichen,
aufzuwachen, sendet die DCP-ECU 14 eine VNM aus, die den
geeigneten Code enthält,
um anzugeben, dass das virtuelle Sitzheizungs-Netzwerk 23 initialisiert
werden soll.
- 4. Die Fahrersitzheizungs-ECU (DHS-ECU) 19 empfängt die
VNM und:
a. ermittelt, dass das initialisierte virtuelle Sitzheizungs-Netzwerk
ein virtuelles Netzwerk ist, bei welchem die DHS-ECU 19 ein
Mitglied ist;
b. ermöglicht
die Kommunikationsfähigkeiten,
die notwendig sind, um das virtuelle Netzwerk zu unterstützen; und
c.
startet den Acht-Sekunden-Timer, um eine Deaktivierung dieser Fähigkeiten
zu verhindern, bis die DCP-ECU 14 ein Übertragen von VNMs stoppt und
der Timer abläuft.
- 5. Gleichzeitig reagiert die DCP-ECU 19 auf ihre eigene
VNM-Übertragung
genau wie die DHS-ECU 19 – durch Ausführen der
Schritte 4(a)-(c).
- 6. Die anderen fünf
ECUs empfangen die VNM ebenfalls und:
a. ermitteln, dass das
initialisierte virtuelle Netzwerk ein virtuelles Netzwerk ist, bei
welchem sie kein Mitglied sind; und
b. fahren, bis der oben
in Schritt 2 verwendete Timer abläuft, damit fort, zu warten
und zu überprüfen, ob eine
VNM ausgestrahlt wird, die ein virtuelles Netzwerk aktiviert, bei
welchem sie ein Mitglied sind.
c. kehren nach Ablauf des Timers
in den Ruhezustand mit niedriger Leistung zurück, wenn sie keine anderen
Aufgaben verarbeiten.
- 7. Mit der Freigabe der Kommunikationsfähigkeiten der DCP- und DHS-ECUs
fährt die
zum Ausführen
der Steueraufgabe (Erwärmen
des Sitzes) notwendige Kommunikation fort.
- 8. Während
die Steueraufgabe fortfährt,
sendet die DCP-ECU 14 alle drei Sekunden eine VNM aus,
um den Mitgliedern des virtuellen Netzwerks mitzuteilen, dass die
Kommunikationsfähigkeiten
des virtuellen Netzwerks andauern müssen. Mit jeder VNM-Übertragung
durch die DCP-ECU 14:
a. setzt die DHS-ECU 19 den
Timer zurück,
was eine Deaktivierung der unterstützenden Kommunikationsfähigkeiten
für weitere
acht Sekunden verhindert; und
b. reagiert die DCP-ECU 14 auf
ihre eigene VNM-Übertragung
genau wie die DHS-ECU – durch
Zurücksetzen
ihres Acht-Sekunden-Timers.
- 9. Wenn die DCP-ECU 14 das Steuern der Sitzheizung
ausgeführt
hat, stoppt sie die Übertragung
der VNM, die die Daten enthält,
welche das virtuelle Sitzheizungs-Netzwerk aktiv halten. Dann:
a.
läuft nach
acht Sekunden die Verhinderung der Deaktivierung der Kommunikationsfähigkeiten
durch den Timer an der DHS-ECU 19 ab. Die DHS-ECU kehrt
in den Schlafzustand zurück.
b.
läuft nach
denselben acht Sekunden die Verhinderung der Deaktivierung der Kommunikationsfähigkeiten durch
den Timer an der DCP-ECU 14 ab. Die DCP-ECU kehrt in den
Schlafzustand zurück.
-
Die
Fähigkeit,
nur einen Teilsatz der ECUs aufzuwecken und in einem aktiven Zustand
zu halten, um eine Steueraufgabe auszuführen, ist vorteilhaft, da sie
dabei hilft, die Zeitdauer, während
der die ECUs in dem aktiven Zustand mit hoher Leistung arbeiten,
zu beschränken.
Dies gilt insbesondere für
ECUs, wie beispielsweise die DHS-ECU 19, die nur bei dem
seltenen Auftreten einer Anfrage zum Erwärmen des Fahrersitzes aktiviert
werden muss. Diese Leistungsersparnisse können erheblich sein, insbesondere
im Hinblick auf die steigenden Belastungen, die Fahrzeugbatterien
und der elektrischen Systeminfrastruktur auferlegt werden. Bei einem
Fahrzeug mit vierzig solcher ECUs, die jeweils mit 100 mA arbeiten,
und unter der Annahme, dass zu jedem Zeitpunkt 25 % von ihnen in
ihrem Ruhezustand gehalten werden können, liefert dies eine Stromreduktion
von 40 × 0,25 × 100 mA
= 1A. Dies ist auch aus wirtschaftlicher Sicht erheblich, da geschätzt wird, dass
die durch ein typisches Fahrzeug heutzutage benötigte Leistung zwischen 5 und
7 Euro pro Ampere (sieben und neun Dollar pro Ampere) kostet.
-
Es
gibt eine Anzahl von anderen Vorteilen der Erfindung, die nun ersichtlich
sein sollten. Zum Beispiel ermöglicht
der bei diesen virtuellen Netzwerken verwendete Netzwerkverwaltungsansatz,
ECUs für
bestimmte Steueraufgaben auf eine Weise zu entwickeln, die von der
Fahrzeugplattform unabhängig
sein kann. Er ermöglicht
auch einen unabhängigen
Entwurf vieler der ECUs, da sie nicht wissen müssen, welche anderen ECUs an
dem Fahrzeugbus umfasst sind, um ihre zugeordneten Aufgaben auszuführen; vielmehr
müssen
sie einfach mit ihrem Anteil der Steuerlogik für jede Aufgabe programmiert
sein und müssen
wissen, welche Eingänge
sie empfangen sollen und welche Ausgänge sie liefern sollen. Dies
hilft dabei, die Entwicklungszeit der ECUs zu reduzieren, da sie
unabhängiger
voneinander entwickelt werden können.
Der oben erläuterte
Netzwerkverwaltungsansatz stellt auch ein geordneteres Hochfahren
und Herunterfahren der ECUs bereit, als es bei vielen der herkömmlichen
Netzwerkentwürfe
der Fall ist.
-
Bezug
nehmend auf 6 ist ein Teil eines zweiten
physikalischen Netzwerks für
ein Unterhaltungsteilsystem für
ein Fahrzeug gezeigt. Das Unterhaltungssystem ist entworfen, um
einen Tuner-AM/FM-Empfang, einen Kassettenspieler und einen CD-Spieler
zu unterstützen,
wie durch deren jeweilige ECUs 90, 92 und 94 dargestellt.
Jede dieser ECUs ist zusammen mit einer ECU 96 für einen
Audioverstärker
und einer ECU 98 für
eine Motorantenne mit dem Fahrzeugbus 12 verbunden. Es
sei angemerkt, dass der Fahrzeugbus 12 zusätzliche
ECUs für
andere Fahrzeugsysteme und -funktionen, die beispielsweise ein Karosserie-Steuermodul
(BCM von body control module) 100 umfassen, sowie die ECUs
von 1 und 2 umfasst. Das Unterhaltungsteilsystem
ist in drei virtuelle Netzwerke aufgeteilt – eines für Radio, eines für den Kassettenspieler und
eines für
den CD-Spieler. Das virtuelle Radio-Netzwerk umfasst die Tuner-,
die Verstärker-
und die Antennen-ECU (d.h. die ECUs 90, 96 und 98).
Das virtuelle Kassetten-Netzwerk umfasst die Kassetten-ECU 92 und die
Verstärker-ECU 96.
Das virtuelle CD-Spieler-Netzwerk umfasst die CD-Spieler-ECU 94 und die Verstärker-ECU 96.
-
Durch
Organisieren der ECUs des Unterhaltungsteilsystems in die virtuellen
Netzwerke auf diese Weise können
die Entwicklung, die Integration und der Betrieb der ECUs, die einem
Audio-Medium gewidmet sind, von jenen entkoppelt werden, die anderen
Audio-Medien gewidmet sind. Zum Beispiel ermöglicht, während eine herkömmliche
Netzwerkverwaltungstechnik für
diese Unterhaltungs-ECUs durch Hochfahren und Herunterfahren aller
ECUs zusammenarbeiten würde,
die Verwendung virtueller Netzwerke, wie in 6 gezeigt, dass
das virtuelle CD-Spieler-Netzwerk nur die ECUs 94 und 96 aktiviert.
Somit kann den ECUs 90, 92 und 98 ermöglicht werden,
zu schlafen, während
der Fahrzeug-CD-Spieler verwendet wird, wodurch der Gesamtleistungsverbrauch
reduziert wird. Ferner kann durch Umfassen einer Unterstützung in
der Logik der ECU 96 für alle
verschiedenen potentiellen Audioquellen jede der Quellen einfach
umfasst oder ausgeschlossen werden, ohne die anderen ECUs in dem
Unterhaltungsteilsystem zu beeinflussen. Somit können z.B. durch Entwerfen einer
Unterstützung
für ein
virtuelles CD-Spieler-Netzwerk in der Verstärker-ECU 96 ein CD-Spieler
und seine ECU 94 zu einem bestimmten Fahrzeug hinzugefügt werden,
wenn dies gewünscht
ist, ohne dass eine Änderung
einer der anderen ECUs erforderlich ist. Diesbezüglich sind auch andere unabhängige Integrationen
möglich.
Zum Beispiel könnte
die Tuner-ECU 90 mit der Verstärker-ECU 96 zu einer
einzigen ECU integriert sein, die beide Funktionen ausführt, und
diese Integration kann erreicht werden, ohne die Kassetten- oder
CD-Spieler-ECU 92, 94 oder ihre zugehörigen virtuellen
Netzwerke zu beeinflussen.
-
Obwohl
das Unterhaltungsteilsystem von 6 in drei
virtuellen Netzwerken angeordnet ist, sei angemerkt, dass es als
ein einzelnes virtuelles Netzwerk realisiert sein könnte, wenn
dies gewünscht
ist. Diesbezüglich
ist zu verstehen, dass der Begriff "Steueraufgabe", wie hierin verwendet, verschiedene
Fahrzeugfunktionen auf vielen verschiedenen allgemeinen und spezifischen
Ebenen umfasst. Somit könnte
eine Steueraufgabe für
das Unterhaltungsteilsystem allgemein als Steuern des Fahrzeug-Audiounterhaltungssystems
definiert sein (unter Verwendung eines einzelnen virtuellen Netzwerks)
oder könnte
in mehrere spezifische Aufgaben aufgeteilt sein, wie beispielsweise
Steuern des Tuners, des Kassettenspielers oder des CD-Spielers (unter Verwendung
von drei separaten virtuellen Netzwerken).
-
Die
Erläuterung
richtete sich bisher auf die Verwendung der Erfindung in Verbindung
mit einem einzigen physikalischen Bus. Die Erfindung kann jedoch
auch in Verbindung mit mehreren fahrzeugeigenen Fahrzeugbussen verwendet
werden. Durch einen Bediener gesteuerte Funktionen des oben in Verbindung
mit 1, 2 und 6 erläuterten
Typs sind typischerweise an einem Bus für niedrige Geschwindigkeiten realisiert,
bei dem die Systemansprechzeitanforderungen in der Größenordnung
von 100-200 ms liegen. Das Fahrzeug könnte auch einen Bus für hohe Geschwindigkeiten
zur Verwendung beim gemeinsamen Nutzen von Echtzeitdaten umfassen,
wie beispielsweise eines durch einen Fahrer befohlenen Drehmoments,
des tatsächlichen
Maschinendrehmoments, des Lenkwinkels usw. Es könnte auch ein Bus für mittlere
Geschwindigkeiten für
erweiterte Informations- und Unterhaltungszwecke umfasst sein, wie
beispielsweise, wenn große Datenmengen
in einer relativ kurzen Zeit übertragen
werden müssen,
z.B. bei erweiterten Anzeige- oder Navigationssystemen. Es können in
dem Fahrzeug auch dritte Netzwerke sowie Drahtlosverbindungen und
entfernte Netzwerke, wie beispielsweise das OnStarTM-System,
das bei vielen der von General Motors Corporation verkauften Systemen
verfügbar
ist, umfasst sein.
-
In
einigen Fällen
können
verschiedene ECUs, die beim Ausführen
einer bestimmten Steueraufgabe beteiligt sind, physikalisch an verschiedenen
Bussen oder Netzwerken angeordnet sein. Somit werden, wie in 7 gezeigt,
Gateways verwendet, um eine Schnittstelle zwischen diesen verschiedenen
Bussen zu bilden, so dass die Aufwecksignale und VN-Nachrichten (VNMs)
von einem Bus zu einem anderen übertragen
werden können.
In dem gezeigten Beispiel sind drei physikalische fahrzeugeigene
Busse gezeigt: ein Bus 110 für hohe Geschwindigkeiten, ein
Bus 112 für
niedrige Geschwindigkeiten (wie beispielsweise der in 1, 2 und 6 gezeigte
Fahrzeugbus 12) und ein dritter Bus 114, wie er
beispielsweise in einem industriell entwickelten Unterhaltungssystem
verwendet werden könnte.
Es sind auch ein Dienst-Tool 116, wie beispielsweise ein
Diagnose-Code-Scanner, und ein entferntes Netzwerk 118 gezeigt,
auf das über
Satellitenverbindungen oder auf eine andere Weise zugegriffen wird.
Bei dem gezeigten Beispiel werden vier Gateways verwendet: Gateway G1,
das eine Schnittstelle zwischen dem Bus 110 für hohe Geschwindigkeiten
und dem Bus 112 für
niedrige Geschwindigkeiten bildet; Gateway G2, das eine Schnittstelle
zwischen dem Bus 110 für
hohe Geschwindigkeiten und dem Dienst-Tool 116 bildet;
Gateway G3, das eine Schnittstelle zwischen dem Bus 112 für niedrige Geschwindigkeiten
und dem dritten Bus 114 bildet; und Gateway G4, das eine
Schnittstelle zwischen dem Bus 112 für niedrige Geschwindigkeiten
und dem entfernten Netzwerk 118 bildet.
-
8 zeigt
einen Konzeptentwurf eines Kommunikations-Kernels 120,
der von jeder ECUs beim Kommunizieren mit ihrem jeweiligen Bus verwendet
werden kann. Dieser Kommunikations-Kernel stellt eine standardisierte
Schnittstelle zwischen dem Bus und dem Anwendungsprozess 122 bereit,
der durch die ECU ausgeführt
wird. Er umfasst sowohl Software- als auch physikalische Schichten.
Genauer gesagt umfasst der Kommunikations-Kernel 120 eine physikalische
Schicht 124, die eine Umwandlung der durch die Datenlink-Schicht 126 erzeugten
Digitaldatensymbole (1 en und 0 en) in an dem Bus übertragene
elektrische Signale bereitstellt. Die physikalische Schicht 124 umfasst
beispielsweise Bus-Transceiver, eine Filterung und die physikalische
Verdrahtung, um die ECU mit dem Bus zu verbinden. Die Datenlink-Schicht 126 stellt
Dienste für
die Übertragung
einzelner Frames zwischen Knoten (ECUs) bereit. Sie handhabt das
Protokoll des Bussystems (z.B. Bit-Timing, Arbitration und Fehlerdetektion).
Der Kernel umfasst eine Netzwerkverwaltungsschicht 128, die
verwendet wird, um das Hochfahren, Herunterfahren und die Fehlerhandhabung
für die
ECUs zu steuern, wenn diese Funktionen eine Interaktion zwischen
den ECUs umfassen und daher global verwaltet werden müssen, und
umfasst auch eine Knotenverwaltungsschicht 130, die verwendet
wird, um das Hochfahren, Herunterfahren und die Fehlerhandhabung
zu steuern, wenn diese Funktionen keine Interaktion mit den anderen ECUs
umfassen und daher lokal verwaltet werden können. Der Kernel 120 umfasst
ferner eine Transportschicht 132, die Datenpakete unter
Verwendung von Diensten der Datenlink-Schicht 126 überträgt. Sie
stellt einen Transportdienst ohne Rückmeldung (1:N-Kommunikation,
1:1-Kommunikation)
bereit. Wenn lange Nachrichten über
das Netzwerk übertragen
werden müssen,
stellt die Transportschicht Dienste für eine segmentierte Datenübertragung
bereit. Auf der Sendeseite wird die Nachricht in Segmente geteilt,
wobei jedes Segment kurz genug ist, um in einen einzigen Netzwerk-Frame
zu passen. Auf der Empfangsseite werden ein zelne Segmente zu einer
Nachricht zusammengesetzt. Die Transportschicht 132 stellt
auch einen Verbindungs-Setup und eine Flusssteuerung bereit. Schließlich umfasst
der Kernel 120 auch eine Interaktionsschicht 134,
die als die Anwendungsprogrammschnittstelle dient. Sie stellt der
Anwendung 122 unabhängig
von dem Busprotokoll Kommunikationsdienste bereit und verwendet
Dienste der Transportschicht 132 für eine Kommunikation an dem
Bus.
-
Trotz
der Tatsache, dass die Netzwerke, die die Busse 110 und 112 verwenden,
jeweils derart entworfen sein könnten,
dass der Großteil
der Signale in deren lokalen Netzwerk bleibt, müssen einige Signale aus dem
lokalen Netzwerk heraus übertragen
werden. Dies ist z.B. der Fall, wenn ein virtuelles Netzwerk mehr
als einen physikalischen Bus überspannt.
Diese Nachrichten werden unter Verwendung eines der Gateways zwischen
den Bussen übertragen.
Wie in 9 gezeigt, ist jeder Gateway-Knoten mit mindestens zwei Bussen verbunden
und interagiert mit jedem Netzwerk gemäß seiner Nachrichtenstrategie
und seinen Übertragungsmodellen.
Somit umfasst das Gateway für
jedes der beiden Netzwerke einen separaten Kommunikations-Kernel 140, 142.
Dieser Gateway-Knoten
führt normalerweise
verschiedene Anwendungsaufgaben aus, wobei die Gateway-Funktion
lediglich eine von ihnen ist. Das Gateway interagiert mit den Interaktionsschichten 134 des Bus-Kernels
und führt
einige oder alle der folgenden Dienste aus: Übertragung von Aufweckanfragen
an andere Netzwerke; Übertragung
von VN-Informationen, wie beispielsweise VNMs, an andere Netzwerke; Übertragung
von Signalen zwischen Netzwerken; Unterstützung einer Signalparameterverarbeitung
(Ereigniserzeugung, Datenumwandlung, Datenfilterung etc.); und Übertragung
von Blockinformationen mit USDT-Protokoll.
-
An
dem Teilnetz 112 für
niedrige Geschwindigkeiten sind die Übertragungsgeschwindigkeiten
niedrig genug, dass VNM-Übertragungen
im Wesentlichen verarbeitet werden können, wenn sie empfangen werden, d.h.
auf einer "Interrupt-Basis". Als ein Ergebnis
sind die Timing-Anforderungen relativ einfach. Weitere VNMs (Folge-VNMs)
werden alle drei Sekunden übertragen
(falls erforderlich), und initialisierende VNM-Übertragungen
können
im Wesentlichen unbeschränkt
sein. An dem Teilnetz 110 für hohe Geschwindigkeiten ist
die Übertragungsgeschwindigkeit
hoch genug, dass es sein kann, dass eine mit ungesteuerten Bursts
von VNMs in Verbindung stehende Prozessoranforderung nicht akzeptiert
werden kann. Um diese Bursts zu steuern, können die ECUs mit einem Burst-Algorithmus
programmiert sein, der jeder ECU periodisch einen Zeitschlitz bereitstellt,
um eine einzelne VNM zu übertragen.
Der Burst-Algorithmus ist parametrisiert, so dass er abgestimmt werden
kann, um den richtigen Kompromiss zwischen Leistung und VNM-Übertragungs-Timing bereitzustellen.
Die Burst-Vermeidung kann wie folgt realisiert sein. In den sechs
niedrigstwertigen Bits der VNM-Frame-ID von 5 ist eine
ECU-ID enthalten, die den Übertragungsknoten
dieser VNM eindeutig identifiziert. Die beiden höchstwertigen Bits dieses ECU-Identifikators
werden verwendet, um das Teilnetz zu identifizieren, an dem sich
die ECU befindet (z.B. das Teilnetz 110 für hohe Geschwindigkeiten
gegenüber
dem Teilnetz 112 für niedrige
Geschwindigkeiten). Die vier niedrigstwertigen Bits werden als eine
VNM-Übertragungssequenzzahl (0
bis 15) verwendet. Unter Verwendung dieser Sequenzzahl können Einrichtungen
ihre VNM-Übertragungsintervalle
auf eine Weise berechnen, die Bursts vermeidet. Somit identifiziert
die ECU-ID nicht nur die ECU eindeutig für den Bus 110 für hohe Geschwindigkeiten,
sondern wird auch verwendet, um den ECU-Zeitschlitz zum Senden von
VNMs zu ermitteln.
-
Die
folgenden Konstanten werden in dem Burst-Vermeidungsalgorithmus
verwendet:
-
Die
VNM-Übertragungsschlitzbreite
s wird so gewählt,
dass die Übertragungen
von sechzehn separaten Knoten in dem VNM-Übertragungsintervall i gleichmäßig beabstandet
sind. Die VNM-Initialisierungsschlitzbreite si muss
größer sein
als w und muss Übertragungsverzögerungen
(Warteschlangenbildung bzw. Queuing) und Empfangsverzögerungen
(zyklisches Abfragen bzw. Polling) berücksichtigen. Diese Beschränkungen können wie
folgt ausgedrückt
werden:
si > w + q + p,
wobei q die Queuing-Verzögerungstoleranz
ist und p die maximale Polling-Zeit
ist.
-
Die
folgenden Variablen werden verwendet:
-
Der
folgende Algorithmus kann an jedem Knoten an dem Teilnetz für hohe Geschwindigkeiten
realisiert sein, das erforderlich ist, um eine VNM zu übertragen.
Beim Detektieren eines Aufweckanfragesignals schaltet die ECU, wenn
sie sich in dem Ruhemodus befindet, innerhalb der Zeit w in ihren
aktivierten Zustand, initialisiert den Kommunikations-Kernel und
setzt den VNM-Übertragungs-Timer
auf V = w + n·si. Wenn die ECU bereits wach ist, dann wird
der VNM-Übertragungs-Timer
mit V = w + n·si neu initialisiert. Beim Empfang jeder VNM
berechnet jede ECU die Wartezeit V zum Übertragen ihrer VNM auf der
Grundlage der empfangenen ECU-ID nr und
ihrer eigenen ECU-ID n neu. Falls n < nr wird die Übertragungswartezeit
mit V = i – (nr – n)·s berechnet.
Falls n > nr wird die Übertragungswartezeit mit V
= (nr – n)·s berechnet.
-
Wenn
eine ECU ein virtuelles Netzwerk hochfahren muss und Aufwecksignale
blockiert sind, dann ist die Ansprechbarkeit des Aktivierungsprozesses
durch die Zeit beschränkt,
die die ECU benötigt,
um einen offenen Übertragungsschlitz
zu erhalten. Im ungünstigsten
Fall ist dies (i – s).
Wenn Aufwecksignale nicht blockiert sind, dann ist die Ansprechbarkeit
dadurch beschränkt,
wie schnell die ECU das Aufwecksignal übertragen kann und wie lange
die ECU darauf warten muss, dass sich ihr Schlitz öffnet. Dies
hängt davon
ab, welche ECU die erste ist, die eine VNM überträgt, wenn jedoch die ECU mit
Schlitz 1 der erste Sender ist, dann beträgt die Verzögerung w + si +
(n – 1)·s oder
ungefähr
2·w +
n·s,
wobei n die Sequenzzahl der ECU ist. In dem Fall, dass Aufwecksignale
blockiert sind, kann die Leistung des ungünstigsten Falls durch Auswählen eines
kleineren Werts für
i verbessert werden. Da sechzehn ECUs möglich sind, ist der kleinste
Wert, der verwendet werden kann, i = 16·s. Dies entspricht einem
dauernden konstanten Rotieren durch die Schlitze, wobei zu jedem Zeitpunkt
ein ECU-Schlitz offen ist. Die Verzögerung des ungünstigsten
Falls, um in diesem Fall (Aufwecksignale sind blockiert) eine Initialisierungs-VNM zu übertragen,
beträgt
dann 15·s.
In dem Fall, dass die Aufwecksignale nicht blockiert sind, kann
die Verzögerung
minimiert werden, wenn die ECU mit Sequenzzahl 1 immer eine VNM überträgt, so dass
die ECU mit Sequenzzahl 1 sorgfältig
ausgewählt
werden sollte. Unter der Annahme, dass immer die ECU mit Sequenzzahl
1 sendet, ist die einzige andere Optimierung, die ausgeführt werden
kann, um w zu reduzieren, die Initialisierungszeit des ungünstigsten
Falls.
-
Es
gibt verschiedene Umstände,
unter denen die ECUs zurückgesetzt
werden. Zum Beispiel findet bei jedem Anschalten ein Zurücksetzen
statt, wobei die ECUs dann ihre Kommunikations-Kernels initialisieren.
In ihrem Ruhezustand mit niedriger Leistung kann jede ECU zumindest Änderungen
an ihren Eingängen
detektieren und insbesondere Aufweckanfragen und VNMs detektieren.
Beim Empfang von einer dieser initiieren die ECUs ihre Kommunikations-Kernel,
wenn sie nicht bereits aktiv sind. Dies wird durch die ECU als ein
Teil ihres Schaltens von einem Ruhezustand in einen aktivierten
Zustand durchgeführt.
Jedes Mal, wenn der Kommunikations-Kernel initialisiert wird, bleibt
er für
ein Minimum von acht Sekunden aktiv, um den Empfang von Nachrichten
zu überwachen, und
wie oben erläutert
werden, wenn eine für
ein virtuelles Netzwerk, bei welchem die ECU ein Mitglied ist, empfangen
wird, die acht Sekunden neu gestartet, wobei dieser Prozess fortfährt, bis
keine VNMs mehr empfangen werden.
-
Durch
Aktivieren des Kommunikations-Kernels für acht Sekunden jedem Zurücksetzen
folgend stellt das System eine vorhersagbare Behebung von Fehlerzuständen bereit,
wie beispielsweise ein Zurücksetzen einer "laufenden" ECU. Wenn eine ECU
ein Leistungsversagen erfährt
(z.B. eine unterbrochene Leistungsversorgungsleistung) oder ein
Zurücksetzen
einer laufenden ECU erfährt,
kann sie sich jedem aktiven virtuellen Netzwerk wieder anschließen, sobald
die ECU mit Leistung versorgt wird. Dies wird durch Programmieren
der ECUs derart erreicht, dass sie, wenn sie angeschaltet werden
und detektieren (mittels eines Empfangs einer weiteren VNM (Folge-VNM)),
dass ein virtuelles Netzwerk, bei welchem sie ein Teil sind, momentan
arbeitet, anfragen, das virtuelle Netzwerk neu zu initialisieren.
Somit fährt
die ECU einem Anschalten oder Zurücksetzen folgend ihren Kommunikations-Kernel
hoch und hält
ihn für
acht Sekunden aktiv. Während
dieses Zeitintervalls überwacht
die ECU empfangene VNMs, um zu ermitteln, ob irgendein virtuelles
Netzwerk, das sie unterstützt,
aktiv ist. Wenn sie ein aktives virtuelles Netzwerk detektiert,
das sie unterstützt,
dann fragt sie an, um das virtuelle Netzwerk neu zu initialisieren.
Die ECU nimmt auch ihre Unterstützung
des virtuellen Netzwerks wieder auf. An dieser Stelle wird die ECU
neu in das virtuelle Netzwerk integriert. Auf eine ähnliche
Weise kann sich eine ECU erholen, wenn ein beliebiges transientes
Kommunikationsversagen dazu führt,
dass ein einzelnes virtuelles Netzwerk an der ECU inaktiv ist, während es
für andere
ECUs aktiv ist. Zu jedem Zeitpunkt, zu dem die Anwendung den Verdacht
hat, dass eine Kommunikation versagt haben kann, kann sie entweder
den Kommunikations-Kernel hochfahren oder das Herunterfahren des
Kom munikations-Kernels verhindern. Wenn der Kommunikations-Kernel
aktiv ist, kann sich die ECU unter Verwendung des gleichen Prozesses
wie der, der oben für
ein ECU-Zurücksetzen
beschrieben ist, allen beliebigen aktiven virtuellen Netzwerken
neu anschließen.
-
Wenn
ein virtuelles Netzwerk hochgefahren wird, beginnen die teilnehmenden
ECUs jeweils, die Quellen der Signale, die sie empfangen, zu beaufsichtigen.
Jede ECU in dem virtuellen Netzwerk kann ausgestaltet sein, um periodisch
ein oder mehrere Signale auszusenden, die als ihr "Herzschlag" dienen. Die ECUs überwachen
dann die Herzschläge
der anderen ECUs in dem virtuellen Netzwerk, so dass sie die Anwendung
benachrichtigen können,
wenn eine der Informationsquellen versagt. Wenn eine Informationsquelle
versagt, kann die zugehörige
Anwendung benachrichtigt werden und ein Diagnose-Problem-Code wird
gesetzt. Die Anwendung kann dann anwendungsspezifische Maßnahmen
ergreifen, wie es notwendig ist.
-
Wie
oben beschrieben wird ein virtuelles Netzwerk durch eine Übertragung
einer anfänglichen
VNM aktiviert, die einen Code enthält, welcher das virtuelle Netzwerk
identifiziert. Wenn die mit dem Hochfahren des virtuellen Netzwerks
in Verbindung stehenden Zeitverzögerungen
minimiert werden müssen,
kann das virtuelle Netzwerk konfiguriert werden (an allen ECUs in
diesem virtuellen Netzwerk), um "anfänglich aktiv" zu sein. Bei diesen
virtuellen Netzwerken behandeln die ECUs eine Busaufweckaussendung
sowohl als ein Aufwecksignal, das den Kommunikations-Kernel hochfährt, als
auch als eine VNM, die das virtuelle Netzwerk initialisiert. Die
Zeit des Hochfahrens wird dadurch reduziert, dass nicht auf die
VNM-Übertragung
gewartet werden muss, die das virtuelle Netzwerk initialisiert.
Der Prozess des Aktivhaltens des virtuellen Netzwerks und der Prozess des Herunterfahrens
dessen basiert immer noch auf VNM-Übertragungen, wie oben in Verbindung
mit 1, 2 und 6 erläutert.
-
In
jenen Fällen,
in denen alle ECUs an einem bestimmten virtuellen Netzwerk die gleiche
Eingabe gemeinsam nutzen, die verwendet wird, um die Steueroperation
für das
virtuelle Netzwerk zu initiieren, können die ECUs in diesem virtuellen
Netzwerk ausgestaltet sein, um jeweils ihre Kommunikations-Kernel
in Ansprechen auf ein Auslösesignal
(Zustandsänderung)
an dieser gemeinsam genutzten Eingabe zu aktivieren. Dies ist somit
eine andere Art, auf die ein virtuelles Netzwerk ohne die Verwendung
von VNMs oder Aufwecksignalen aktiviert werden kann. Ferner muss
bei dieser Anordnung eine Deaktivierung des virtuellen Netzwerks
nicht auf einem Timeout durch einen Timer basieren, sondern kann
sofort stattfinden, wenn dies durch die Anwendung angefragt wird,
oftmals als ein Ergebnis dessen, dass eine gemeinsam benutzte Eingabe
wieder ihre Zustände ändert. Die
Aktivierung eines virtuellen Netzwerks unter Verwendung gemeinsam
genutzter Eingaben ist einfacher als die eines, das unter Verwendung
von VNMs aktiviert wird, da der Bus bei dem Aktivierungsprozess
nicht verwendet wird. Der Preis dieser Vereinfachung ist, dass alle
ECUs die Eingaben, die notwendig sind, um zu detektieren, wann das
virtuelle Netzwerk aktiviert werden soll, gemeinsam nutzen müssen. Wenn dies
ein natürliches
Nebenprodukt der Fahrzeugarchitektur ist, kann es einfach ausgenutzt
werden, andernfalls ist es jedoch wirtschaftlich im Allgemeinen
nicht gewünscht,
eine Verdrahtung einzuführen,
um zusätzliche Kosten
für die
Aktivierung eines virtuellen Netzwerks zu reduzieren.
-
Wenn
das Spannungsniveau einer ECU ausreichend abfällt, kann es sein, dass sie
nicht zuverlässig senden
oder empfangen kann. Während
ohne eine zusätzliche
Hardware-Unterstützung
wenig getan werden kann, um dies zu vermeiden, kann unter bestimmten
Umständen
eine relativ transparente Erholung von dem Ereignis durchgeführt werden.
Im Allgemeinen können
Niederspannungszustände
nicht vorhergesagt werden. Es ist jedoch bekannt, dass es wahrscheinlicher
ist, dass Spannungsabfälle
während
bestimmten vordefinierten Fahrzeugsituationen auftreten. Wenn ECUs
vor der Mitteilung dieses Ereignisses bereitgestellt werden, können sie
Verhinderungsmaßnahmen
ergreifen, die, während
keine fehlerhaften Nachrichtenübertragungen verhindert
werden, verwendet werden können,
um eine schnelle transparente Erholung zu vereinfachen. Auf eine
Mitteilung hin können
sich diese ECUs selbst in einen Niederspannungstoleranzmodus bringen,
der sie davon abhält,
aufgrund der Unfähigkeit,
VNMs zu übertragen,
deaktiviert zu werden. Diesem Ereignis folgend werden virtuelle
Netzwerke, die als niederspannungsanfällig betrachtet werden, neu
initialisiert, so dass ECUs in dem virtuellen Netzwerk eine gemeinsame
Sicht der Werte der gemeinsam genutzten Signale neu herstellen.
Dieser niederspannungstolerante Modus kann über den Kommunikations-Kernel
aufgerufen und abgeschlossen werden, und wenn an einer beliebigen
ECU in einem virtuellen Netzwerk eine Unterstützung für diesen Modus umfasst ist,
dann sollte sie an allen anderen ECUs in diesem virtuellen Netzwerk
umfasst sein.
-
Wenn
allen ECUs in einem virtuellen Netzwerk ein Vorwissen über einen
Niederspannungszustand verfügbar
ist, können
Verhinderungsmaßnahmen
ergriffen werden. Auf einen Empfang spezifischer Signalwerte hin,
die angeben, dass der Niederspannungszustand bevorsteht, können Anwendungen
an ECUs, die ausgestaltet sind, um den Niederspannungstoleranzmodus
zu unterstützen,
diese Prozedur aufrufen. Da es sein kann, dass ECUs schlafen, wenn
das Eintrittssignal übertragen
wird, ist es möglich,
dass sie aufwachen können,
während
der Niederspannungszustand vorherrscht. Folglich müssen diese
ECUs annehmen, dass jedes Mal, wenn sie ihren Kommunikations-Kernel
initialisieren, ein Niederspannungszustand vorliegt. Mit anderen Worten
können
ECUs, die während
des Zustands aufwachen, nicht auf Signalübertragungen warten, um zu ermitteln,
ob eine niederspannungstolerante Operation stattfindet, da die Kommunikation
während
des Niederspannungszustands nicht zuverlässig ist. Sie sind daher programmiert,
um standardmäßig in den
Niederspannungstoleranzmodus überzugehen.
-
Die
ECU, die das Niederspannungstoleranzmodus-Signal aussendet, sendet
das Moduseintrittssignal (oder Modusstartsignal) aus, wenn sie detektiert,
dass der Niederspannungszustand gleich stattfinden wird. Um einen
Eintritt in den Niederspannungstoleranzmodus zu synchronisieren,
muss die Master-ECU auf ihren eigenen Eintritt reagieren und Signalübertragungen
auf die gleiche Weise (und zum gleichen Zeitpunkt) auszugeben, wie
die ECUs diese Signale empfangen. ECUs, die zum Zeitpunkt der Eintrittssignalaussendung wach
sind, reagieren auf diesen Signalwert durch Anhalten verschiedener
Timer, die nicht zuverlässig
aufrechterhalten werden können,
während
der Niederspannungszustand vorliegt. Wenn diese ECUs nachfolgend während des
Niederspannungszustands andere virtuelle Netzwerke hochfahren, werden
die entsprechenden Timer auf ihre normalen Startwerte initialisiert
und dann gehalten. ECUs, die den Niederspannungstoleranzmodus unterstützen und
die während
des Niederspannungszustands aufwachen, gehen standardmäßig in den Niederspannungstoleranzmodus über und
verhalten sich, als ob sie das Eintrittssignal empfangen hätten. Wenn
die Niederspannungstoleranzmodus-Master-ECU
detektiert, dass der Niederspannungszustand nicht mehr vorliegt,
sendet sie das Austrittssignal aus, das einfach ein anderer Wert
des gleichen Signals sein kann, das verwendet wird, um den Niederspannungstoleranzmodus
zu initiieren. Beim Empfang des Austrittssignals nehmen die ECUs
die normale Verarbeitung wieder auf. Zusätzlich behält jede ECU eine Liste virtueller
Netzwerke, die sie als niederspannungsanfällig betrachtet. Wenn das Austrittssignal
empfangen wird, fordert jede ECU, die momentan der Master eines
virtuellen Netzwerks in ihrer Niederspannungsanfälligkeitsliste ist, an, um
das virtuelle Netzwerk zu initialisieren (durch Übertragen einer Initialisierungs-VNM).
Dies findet statt, um eine gemeinsame Sicht der VN-Signalwerte neu
herzustellen, da es sein kann, dass einige Übertragungen während des
Niederspannungszustands verpasst wurden.
-
Alle
ECUs, die den Niederspannungstoleranzmodus unterstützen, umfassen
die Eintritts- und Austrittssignale in allen virtuellen Netzwerken,
die sie unterstützen.
Dies garantiert, dass sie ungeachtet dessen, welche virtuellen Netzwerke
sie aktiv unterstützen,
das Austrittssignal empfangen, wenn sie zu dem Zeitpunkt, zu dem
es ausgesendet wird, wach sind. Der ECUs willen, die während des
Niederspannungszustands in einen Schlafzustand übergegangen sein könnten, muss
der Master auch sicherstellen, dass alle ECUs im Ruhezustand geweckt
werden und das Austrittssignal neu ausgesendet wird. Um dies zu
erreichen, aktiviert die Anwendung des Masters ein separates virtuelles
Netzwerk, das eine Aussendung des Austrittssignals als ein Teil
seiner Initialisierung umfasst, und das dafür bekannt ist, allen ECUs gemein
zu sein, die eine Niederspannungstoleranzoperation unterstützen. Es
kann ein virtuelles Netzwerk, das dieser Funktion gewidmet ist,
vorgesehen sein, wenn dies notwendig ist. Um die Möglichkeit
abzudecken, dass dieses virtuelle Niederspannungstoleranzmodus-Netzwerk
bereits aktiv sein kann, sind alle ECUs, die den Niederspannungstoleranzmodus
ausführen,
programmiert, um das virtuelle Niederspannungstoleranzmodus-Netzwerk
in ihrer Niederspannungsanfälligkeitsliste
zu umfassen. Dies stellt sicher, dass eine Initialisierung des virtuellen
Niederspannungstoleranzmodus-Netzwerks und die nachfolgende Neuaussendung
des Austrittssignals ungeachtet dessen stattfinden, ob das virtuelle
Niederspannungstoleranzmodus-Netzwerk
aktiv ist, wenn der Niederspannungszustand endet, oder nicht.
-
Es
sollte somit zu verstehen sein, dass gemäß der vorliegenden Erfindung
ein Verfahren und eine Vorrichtung für eine fahrzeuginterne Netzwerkverwaltung
unter Verwendung von virtuellen Netzwerken bereitgestellt wurden,
die die hierin spezifizierten Ziele und Vorteile erreichen. Es ist
natürlich
zu verstehen, dass die vorangehende Beschreibung bevorzugte beispielhafte
Ausführungsformen
umfasst, und dass die Erfindung nicht auf die gezeigten spezifischen
Ausführungsformen
beschränkt
ist. Verschiedene Änderungen
und Abwandlungen werden für
den Fachmann ersichtlich. Zum Beispiel ist zu verstehen, dass, obwohl
die Verwendung eines Hochspannungsaufwecksignals in Verbindung mit
der erläuterten
Ausführungsform
beschrieben wurde, jede einer Anzahl von anderen Aufwecktechniken
eingesetzt werden könnte,
wie beispielsweise die Verwendung eines separaten Signals, das an
jede ECU über
eine zugeordnete Leitung gesendet wird. Optional könnte, wenn
die ECUs auf der Grundlage eines Codes, der in dem Header einer
Netzwerknachricht enthalten ist, aufwachen können, das Aufwecken ohne die
Verwendung eines Hochspannungssignals oder einer zugeordneten Leitung
erreicht werden, und könnte
sogar mit der VNM selbst kombiniert sein, so dass nur eine einzige
Nachricht gesendet werden muss, um die ECUs sowohl aufzuwecken als
ihnen auch die Initialisierungs-VNM zu liefern. Alle diese Änderungen
und Abwandlungen sollen innerhalb des Schutzumfangs der beigefügten Ansprüche liegen.
