DE102018107744A1

DE102018107744A1 - Architekturen und Verfahren zur Verwaltung von Fahrzeuginternen vernetzten Steuerungen und Vorrichtungen

Info

Publication number: DE102018107744A1
Application number: DE102018107744.0A
Authority: DE
Inventors: Shige Wang; Chang Liu
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2017-04-05
Filing date: 2018-04-02
Publication date: 2018-10-11
Also published as: US20180295011A1; CN108733023A

Abstract

Offenbart werden Steuerungsalgorithmen und Systemarchitekturen zur Verwaltung des Betriebs vernetzter Steuerungen und Vorrichtungen, einschließlich Fahrzeuge mit einem Bordnetz von elektronischen Steuergeräten (ECU) und Steuerlogik zum Regeln des Ruhens und Aktivierens dieser ECUs. Ein Verfahren zur Verwaltung des fahrzeuginternen Netzwerks von ECUs in einem Kraftfahrzeug beinhaltet: das Ermitteln von Statusvektoren für eine Gruppe von ECUs, wobei jeder Statusvektor angibt, ob das entsprechende ECU aktiv oder nicht aktiv ist; das Ermitteln der Vorrichtungsrollen für diese ECUs - Slave oder Master; das Ermitteln einer zugewiesenen Hierarchie zum Auswählen der ECUs als Master-Vorrichtung; das Empfangen eines Modusänderungssignals, das anzeigt, dass ein ECU beabsichtigt, in den Ruhezustand oder in den aktivierten Zustand überzugehen; und in Reaktion darauf, das Modifizieren der jeweiligen Vorrichtungsrolle für ein ECU vom Master zum Slave und der jeweiligen Vorrichtungsrolle für ein anderes ECU vom Slave zum Master basierend auf der zugewiesenen Hierarchie und den Statusvektoren für die ECUs.

Description

EINLEITUNG
Die vorliegende Offenbarung betrifft im Allgemeinen Netzwerke von elektronischen Steuerungen und Datenverarbeitungsvorrichtungen. Genauer gesagt, beziehen sich die Aspekte dieser Offenbarung auf Systemarchitekturen und Steuerlogik für das Sleep/Wakeup-Management von vernetzten Steuerungen und Vorrichtungen, die eine verteilte Steuerung von Fahrzeugfunktionen ermöglichen.
Aktuelle Serienfahrzeuge, wie das moderne Automobil, sind ursprünglich mit einem Netzwerk von elektronischen Steuervorrichtungen und Rechenvorrichtungen ausgestattet, die über das gesamte Fahrzeug verteilt sind, um verschiedene Fahrzeugfunktionen ausführen zu können. Diese Fahrzeugfunktionen, ob bedienergesteuert oder automatisiert, können die Steuerung von Fahrzeugtürschlössern, Sitzposition, Tempomat, Komponenten des Unterhaltungssystems, Heizungslüftung und Klimaanlage (HVAC), Scharfschaltung und Entschärfung von Diebstahlschutzalarmen, Innen- und Außenbeleuchtung, Antriebsstrangbetrieb und Systemdiagnose, elektrische Fensterheberposition sowie weitere Funktionen beinhalten. Obwohl einige elektronische Onboard-Steuergeräte (ECU), wie beispielsweise Motorsteuerungsmodule (ECM) und Bremssystem-Steuerungsmodule (BCM), für die Steuerung eines einzelnen Subsystems vorgesehen sind, arbeiten die meisten anderen Steuergeräte in interoperablen Gruppen zur Steuerung des Fahrzeugbetriebs. Viele Aufgaben der Fahrzeugsteuerung werden von mehreren ECUs übernommen, die gemeinsam arbeiten und ihren Betrieb über eine Datenverbindung koordinieren. Ein herkömmliches ECU kann beispielsweise einen Teil der Steuerlogik für mehrere unabhängige Fahrzeugsteuerungsaufgaben enthalten, jedoch nicht die komplette Steuerlogik für eine einzelne Steueraufgabe.
Fahrzeuginterne ECUs sind typischerweise über einen Netzwerkkommunikationsbus miteinander verbunden, der einzeln oder als serielle Kommunikationsschnittstelle in Form eines Local Area Network (LAN) realisiert werden kann. Die Kommunikationstopologie kann durch Gateway-/Brückenvorrichtungen, wie beispielsweise Ethernet-Switches, unterstützt werden. Neben der notwendigen Hardware für die Signalübertragung zwischen vernetzten ECUs wird ein zuverlässiges Kommunikationsprotokoll implementiert, um sicherzustellen, dass Primär- und Nebenaufgaben synchron ausgeführt werden können. Eine dieser Aufgaben ist das Netzwerkmanagement zur Bereitstellung einer systemweiten gemeinsamen Methodik für die Behandlung von Ereignissen wie: geordnete Inbetriebnahme (Aktivierung) der Kommunikationsfähigkeiten; geordnete Abschaltung (Deaktivierung) der Kommunikationsfähigkeiten und vorhersagbare Wiederherstellung von erkennbaren Kommunikationsfehlern. Ein geordnetes Hoch- und Herunterfahren trägt dazu bei, dass ECUs ihre Signalempfangserwartungen mit der Verfügbarkeit von Signalübertragungen anderer ECUs synchronisieren können. Wenn keine Synchronisation stattfindet, kann ein ECU die fehlende Signalübertragung als falsch-positiven Ausfall eines der anderen ECUs interpretieren und kann sichere Standardsignalwerte übernehmen.
Um den Stromverbrauch in bestehenden elektrischen Infrastrukturen von Fahrzeugen zu reduzieren, können ECUs, die die Fahrzeugfunktionalität nicht aktiv steuern, vorübergehend in einen stromsparenden „Standby“- oder „Sleep“-Zustand versetzt werden. So können beispielsweise elektrische Fensterheber- und Sitzsteuer-ECUs, die im Vergleich zu anderen Steuerungen nur selten eingesetzt werden, in der Regel im Standby-Modus gewartet werden. Bestehende Fahrzeugnetzwerk-Management-Strategien erfordern oft, dass alle ECUs einer bestimmten Gruppe gleichzeitig aktiviert („wach“) und deaktiviert („schlafend“) werden. In einem „Master-Slave“-Fahrzeugnetzwerk werden zum Beispiel fahrzeuginterne Vorrichtungen zu virtuellen Gruppen zusammengefasst, wobei für jede Gruppe von berechtigten Vorrichtungen ein einzelnes ECU als „Master“ zugeordnet wird. Das Master-ECU kann eine unidirektionale Steuerung über die verbleibenden „Slave“-ECUs in der Gruppe aufweisen, einschließlich der Fähigkeit, jedes Slave-ECU zu aktivieren oder zu deaktivieren. Bei derartigen Systemen synchronisiert das Master-ECU das An- und Abschalten aller Assets, die der jeweiligen Gruppe zugeordnet sind. Robuste Netzwerk-Designs sind in der Regel in der Lage, ECU-Einstellungen auf Abruf zu starten, ohne dass die Steuerungsvorgänge der bereits aktivierten ECUs unterbrochen werden.
KURZDARSTELLUNG
Hierin offenbart sind Steuerungsalgorithmen und Systemarchitekturen zur Verwaltung des Deaktivierens und Aktivierens von fahrzeuginternen vernetzten Steuerungen und Vorrichtungen, Verfahren zur Implementierung und Verfahren zur Konstruktion solcher Algorithmen/Architekturen und Kraftfahrzeuge, die mit einem Bordnetz aus elektronischen Steuergeräten (ECU) und Steuerlogik zur Steuerung des Zu- und Abschaltens dieser vernetzten ECUs ausgestattet sind. Als Beispiel und nicht als Einschränkung wird eine Architektur mit Diensten und Protokollen vorgestellt, um die einzelnen, vernetzten Steuerungen und Vorrichtungen dynamisch zu verwalten, die in den Ruhezustand eintreten und in den Normalbetriebsmodus übergehen. Die Architektur nimmt eine Master-Slave-Beziehung für die Vorrichtungen an, wobei eine primäre Master-Vorrichtung periodisch Netzwerk-Management-Frame-Prompts über Multicast-Verteilung sendet. In diesem Fall ist der Master auch dafür verantwortlich, zu genehmigen, welche Vorrichtung(n) in den Ruhezustand versetzt werden können, und kann auch so betrieben werden, dass Slave-Vorrichtungen im Ruhezustand zum Aktivieren aufgefordert werden. Der Ruhezustand und Variationen desselben, wie beispielsweise Sleeping, Snoozing, asleep usw., können als reduzierter „niedriger“-Leistungsmodus im Vergleich zum normalen Betriebsmodus bezeichnet werden; der Ruhezustand ist kein Aus-Zustand, der einen Neustart der Vorrichtung bevor sie voll funktionsfähig wird. Eine Vorrichtung verbraucht während des Ruhezustands etwas Energie, z. B. um den lokalen Speicher zu versorgen und auf ein Aufweckereignis reagieren zu können.
Alle Vorrichtungen, einschließlich des Masters und aller Slave-Vorrichtungen, können basierend auf den einzelnen Betriebszuständen in den Ruhezustand versetzt oder aktiviert werden. Im Allgemeinen fragt eine Slave-Vorrichtung den Master nach der Genehmigung einer Änderungsanforderung für den Ruhe-zu-Aktiv- oder für den Aktiv-zu-Ruhe-Modus. Wenn eine Master-Vorrichtung in den Ruhezustand versetzt wird oder wenn eine ruhende Vorrichtung aktiviert wird, kann über ein Master-Auswahlprotokoll ein neuer Master ausgewählt werden. Die Architektur verweist auf eine Master-Auswahltabelle, die als Kalibrierungswerte auf einer oder mehreren Vorrichtungen gespeichert wird und definiert eine Rangfolge (Hierarchie) der als Master zu bezeichnenden Vorrichtungen. Eine Status-Tabelle dient gleichzeitig dazu, den Sleep/Wake-Status jeder einzelnen Vorrichtung und deren aktuelle Rolle (Master oder Slave) zu verfolgen.
Neben den normalen Kommunikations- und Verwaltungsrahmen können zwei Arten von Netzwerkrahmen verwendet werden, um Informationen für die Aktualisierung der jeweiligen Zustände jeder Vorrichtung zu übertragen, um eine konsistente Sicht auf die Vorrichtungen im Netzwerk aufrechtzuerhalten und um den Ruhezustand und die Aktivierungsfunktion zu verwalten. Ein Netzwerk-Management-Frame (NMF) wird von einer Master-Vorrichtung gesendet und enthält Master-Informationen mit einem Source-Identifier und einem Datenfeld, das anzeigt, welche Vorrichtungen sich im Ruhezustand befinden und welche unter Verwendung eines Bit-Vektors aktiviert werden, z. B. mit Bit = 0 ruhend und Bit = 1 für das Aktivieren. Ein NMF wird an alle aktiven Geräte gesendet, und alle Slave-Vorrichtungen aktualisieren ihre Status-Tabelle entsprechend. Ein Request-Frame (REQ) wird von einer Slave-Vorrichtung oder einer aktiven Vorrichtung verwendet, um eine Anfrage zu senden. Ein REQ wird beispielsweise verwendet, wenn das Netzwerk mit der Auswahl eines Masters beginnt und eine Slave-Vorrichtung sich entschließt in den Ruhezustand überzugehen. Für die Zwecke dieser Offenbarung können die Begriffe „Steuerung“ und „ECU“ und „Vorrichtung“ austauschbar verwendet werden, sofern nicht ausdrücklich darauf verzichtet wird.
Das Protokoll für die Masterauswahl wird zum Beispiel aufgerufen, wenn eine Vorrichtung in einer Gruppe aktiviert wird - die Aufwachvorrichtung wartet auf NMF, um anzuzeigen, ob das Netzwerk läuft und ein Master vorhanden ist. Wenn die Vorrichtung den NMF empfängt, führt er Wakeup-Management-Protokoll aus, um sich dem Netzwerk zu verbinden. Wenn der NMF nicht vor der Zeitüberschreitung ankommt, geht die Vorrichtung davon aus, dass das Netzwerk nicht läuft und befördert sich selbst zum Master. Das Master-Auswahlprotokoll wird dann aufgerufen, um eine Vorrichtung mit der höchsten Priorität als Master auszuwählen. Wenn eine Slave-Vorrichtung keine Aktivität aufweist und in den Ruhestand möchte, ruft es ein Sleep-Management-Protokoll auf und sendet einen REQ zur Genehmigung an die Master-Vorrichtung. Wenn die Master-Vorrichtung im nächsten NMF mit einem entsprechenden Statusvektorbit im Ruhezustand bestätigt, kann die Vorrichtung in den Ruhezustand übergehen; andernfalls bleibt die Vorrichtung bis zum Empfang des NMF mit dem Statusvektorbit im Ruhezustand aktiv. Entscheidet sich der Master dafür, zu schlafen, sendet der Master ein NMF mit eingeschaltetem Bit und aktiviert eine oder mehrere Vorrichtungen und/oder aktive Slaves durchlaufen den Master-Auswahlprozess. Wenn eine Vorrichtung aktiviert wird und den NMF empfängt, ruft sie das Wakeup-Management-Protokoll auf, um zu ermitteln, ob es eine höhere Priorität als der aktuelle Master aufweist. Wenn ja, übernimmt er die Rolle des Masters und sendet mit dieser Information ein NMF aus; der alte Master wird dann zum Slave, wenn er das neu gesendete NMF empfängt.
Zu den Vorteilen für zumindest einige der offenbarten Konzepte gehört ein flexibles, nicht festes Master-Slave-Architekturdesign von vernetzten Steuerungen, das es jeder vernetzten Vorrichtung ermöglicht, bei Bedarf zu aktivieren (oder abzuschalten), ohne alle anderen Vorrichtungen aufwecken (oder auszuschalten) zu müssen. Offenbarte Systeme, Verfahren und Vorrichtungen ermöglichen es, die Bezeichnung und die damit verbundene Funktionalität einer Master-Vorrichtung auf andere Vorrichtungen innerhalb einer bestimmten Gruppe zu übertragen, wodurch die Netzwerkkonfiguration flexibler und energieeffizienter wird. Andere damit verbundene Vorteile können die Abschwächung oder anderweitige Verhinderung eines Netzwerkausfalls bei Ausfall einer Master-Vorrichtung sein, wodurch die Verfügbarkeit und Zuverlässigkeit des Systems verbessert wird. Alle Vorrichtungen einer Gruppe können so ausgelegt sein, dass sie dieselben Kalibrierungstabellen verwenden, um die Prioritäten der Hauptvorrichtungen zu ermitteln und dieselben Algorithmen auszuführen, so dass das gesamte Systemdesign vereinfacht und die Kommunikationsprotokolle auf Geschwindigkeit optimiert werden. Offenbarte Konzepte können in Anwendungen außerhalb von Fahrzeugsystemen, wie Massendatenspeicherung, Cloud Computing, Internet of Things (IoT) und andere Computernetzwerkarchitekturen, integriert werden.
Aspekte der vorliegenden Offenbarung richten sich auf Steuerlogik und computerausführbare Algorithmen zur Verwaltung des Betriebs von vernetzten Steuerungen und Vorrichtungen. Offenbart wird zum Beispiel ein Verfahren zur Verwaltung eines Bordnetzes von ECUs eines Kraftfahrzeugs. Eine Gruppe der fahrzeugseitigen ECUs ist über eine Kommunikationsschnittstelle, wie beispielsweise einen Ethernet-Switch, miteinander verbunden und kann jeweils zum Übergang zwischen Ruhe- und Aktivzustand betrieben werden. Dieses Verfahren beinhaltet in beliebiger Reihenfolge und in beliebiger Kombination mit den offenbarten Merkmalen und Optionen: das Ermitteln der jeweiligen Statusvektoren für die ECUs in der Gruppe, wobei jeder Statusvektor angibt, ob sich das entsprechende ECU im Wach- oder im Ruhezustand befindet; das Ermitteln der jeweiligen Vorrichtungsrollen für das jeweilige ECU in der Gruppe, wobei jede Vorrichtungsrolle das entsprechende ECU als Slave-Vorrichtung oder Master-Vorrichtung bezeichnet; das Ermitteln einer zugewiesenen Hierarchie für die Gruppe von ECUs, wobei die zugewiesene Hierarchie Prioritätskennzeichnungen (z. B. 1, 2, 3 usw.) für die Auswahl jedes ECU als Master-Vorrichtung beinhaltet; Senden oder Empfangen eines Modusänderungssignals, z. B. eingebettet in ein REQ- oder NMF-Paket, das anzeigt, dass ein Steuergerät in der Gruppe beabsichtigt, vom Aufwach- in den Ruhezustand oder vom Ruhezustand in den Wachzustand zu wechseln; und, in Reaktion auf dieses Modusänderungssignal, Modifizieren der jeweiligen Vorrichtungsrolle für ein erstes ECU in der Gruppe von der Master-Vorrichtung zur Slave-Vorrichtung und Modifizieren der jeweiligen Vorrichtungsrolle für ein zweites ECU in der Gruppe von der Slave-Vorrichtung zur Master-Vorrichtung, wobei beide Modifikationen auf der zugeordneten Hierarchie und den Statusvektoren für die Steuergeräte basieren.
Weitere Aspekte der vorliegenden Offenbarung beziehen sich auf Kraftfahrzeuge, die mit einem Bordnetz von Steuerungen und Vorrichtungen sowie einer Steuerlogik zur Steuerung des Betriebs dieser Steuerungen/Vorrichtungen ausgestattet sind. Ein „Kraftfahrzeug“, wie hierin verwendet, kann sich auf jede relevante Fahrzeugplattform, wie z. B. Personenkraftwagen (Verbrennungsmotoren, Hybrid-, Elektro-, Brennstoffzellenantrieben, vollständig oder teilweise autonom, usw.), Transportfahrzeuge, Industriefahrzeuge, Raupenfahrzeuge, Geländefahrzeuge (ATV), landwirtschaftliche Geräte, Boote, Flugzeuge, Züge usw. In einem Beispiel wird ein Kraftfahrzeug vorgestellt, das eine Fahrzeugkarosserie, eine Kommunikationsschnittstelle und mehrere ECUs, die an die Fahrzeugkarosserie angeschlossen sind, beinhaltet, wobei eine Gruppe der ECUs über die Kommunikationsschnittstelle kommunikativ verbunden ist. Jedes ECU in der Gruppe ist auf Folgendes programmiert: das Ermitteln, über eine lokal gespeicherte Statustabelle die jeweiligen Statusvektoren für die ECUs in der Gruppe, wobei jeder Statusvektor angibt, ob das entsprechende ECU im Wachzustand oder im Ruhezustand ist; das Ermitteln, über die lokal gespeicherte Statustabelle, die jeweiligen Vorrichtungsrollen für die ECUs, wobei jede Vorrichtungsrolle das entsprechende ECU als Slave oder Master bezeichnet; das Ermitteln, über eine lokal gespeicherte Master-Auswahltabelle, einer zugewiesenen Hierarchie für die ECUs in der Gruppe, wobei die zugewiesene Hierarchie die entsprechenden Prioritätsbezeichnungen zur Auswahl der ECUs als Master-Vorrichtung beinhaltet; und Empfangen oder Senden eines Modusänderungssignals, das anzeigt, dass das ECU oder eines der anderen ECUs in der Gruppe beabsichtigt, vom Aktivzustand in den Ruhezustand oder vom Ruhezustand in den Aktivzustand überzugehen. Als Reaktion auf das Empfangen/Senden eines Modusänderungssignals wechselt die entsprechende Vorrichtungsrolle für ein erstes ECU in der Gruppe von Master zu Slave, während gleichzeitig die jeweilige Vorrichtungsrolle für ein zweites ECU von Slave zu Master basierend auf der zugeordneten Hierarchie und den Statusvektoren geändert wird.
Zusätzliche Aspekte der vorliegenden Offenbarung beziehen sich auf nicht-flüchtige, computerlesbare Medien, in denen Anweisungen zur Ausführung durch mindestens einen oder mehrere Prozessoren eines fahrzeuginternen Netzwerks von ECUs gespeichert sind. Diese Anweisungen bewirken, wenn sie ausgeführt werden, dass das Netzwerk von ECUs verschiedene Schritte durchführt, einschließlich: dem Abrufen aus einer Nachschlagetabelle oder dem anderweitigen Ermitteln von Statusvektoren für die ECUs in einer virtuellen Gruppe, wobei jeder Statusvektor angibt, ob ein ECU aktiv oder im Ruhezustand ist; dem Abrufen aus einer Nachschlagetabelle oder dem anderweitigen Ermitteln von entsprechenden Vorrichtungsrollen für die ECUs in der Gruppe, wobei jede Vorrichtungsrolle ein ECU als Slave-Vorrichtung oder Master-Vorrichtung bezeichnet; dem Abrufen aus einer Nachschlagetabelle oder dem anderweitigen Ermitteln einer zugeordneten Hierarchie für die Gruppe von ECUs, wobei die zugewiesene Hierarchie die ECUs zur Auswahl als Mastervorrichtung priorisiert; dem Empfangen/Senden eines Modusänderungssignals, das anzeigt, dass ein ECU in der Gruppe beabsichtigt, in den Ruhezustand oder in den Wachzustand überzugehen; und, in Reaktion auf das Modusänderungssignal, dem Modifizieren der jeweiligen Vorrichtungsrolle für ein erstes ECU in der Gruppe zu einer Slave-Vorrichtung bei gleichzeitiger Modifizierung der jeweiligen Vorrichtungsrolle für ein zweites ECU zu einer Master-Vorrichtung basierend auf der zugewiesenen Hierarchie und den Statusvektoren für die ECUs in der Gruppe.
Die vorstehende Kurzdarstellung soll nicht jede Ausführungsform oder jeden Aspekt der vorliegenden Offenbarung repräsentieren. Vielmehr veranschaulicht die vorstehende Kurzdarstellung lediglich einige der neuartigen Aspekte und Merkmale, wie hierin dargelegt. Die vorstehend aufgeführten Merkmale und Vorteile sowie andere Merkmale und Vorteile der vorliegenden Offenbarung werden aus der folgenden ausführlichen Beschreibung der dargestellten Ausführungsformen und der repräsentativen Arten zum Ausführen der vorliegenden Offenbarung in Verbindung mit den begleitenden Zeichnungen und den beigefügten Ansprüchen leicht ersichtlich. Darüber hinaus beinhaltet die vorliegende Offenbarung ausdrücklich alle Kombinationen und Teilkombinationen der vorangehenden Elemente und Merkmale, die oben und im Folgenden dargestellt sind.
Figurenliste

1 ist eine schematische Darstellung eines repräsentativen Kraftfahrzeugs mit einem Netzwerk von Fahrzeugsteuerungen und -vorrichtungen gemäß den Aspekten der vorliegenden Offenbarung.
2 ist ein schematisches Diagramm einer repräsentativen Master-Slave-Systemarchitektur zum Verwalten von Ruhe- und Aktivierungsfunktionen von vernetzten Steuerungen und Vorrichtungen im Fahrzeug entsprechend den Aspekten der offenbarten Konzepte.
3 ist ein Flussdiagramm für ein Master-Auswahlprotokoll, das den Anweisungen entsprechen kann, die von einer integrierten Steuerlogikschaltung, einer programmierbaren elektronischen Steuerungseinheit oder einer anderen computergestützten Vorrichtung eines Kraftfahrzeugs gemäß den Aspekten der offenbarten Konzepte ausgeführt werden.
4 ist ein Flussdiagramm für ein Ruhezustand-Managementprotokoll, das den Anweisungen entsprechen kann, die von einer integrierten Steuerlogikschaltung, einer programmierbaren elektronischen Steuerungseinheit oder einer anderen computergestützten Vorrichtung eines Kraftfahrzeugs gemäß den Aspekten der offenbarten Konzepte ausgeführt werden.
5 ist ein Flussdiagramm für ein Aktivierungs-Managementprotokoll, das den Anweisungen entsprechen kann, die von einer integrierten Steuerlogikschaltung, einer programmierbaren elektronischen Steuerungseinheit oder einer anderen computergestützten Vorrichtung eines Kraftfahrzeugs gemäß den Aspekten der offenbarten Konzepte ausgeführt werden.

Für die vorliegende Offenbarung können verschiedene Modifikationen und alternative Formen zur Anwendung kommen und einige exemplarische Ausführungsformen werden hierin anhand der Zeichnungen in Form von Detailbeispielen dargestellt. Es versteht sich allerdings, dass die neuartigen Aspekte dieser Offenbarung nicht auf die in den hinzugefügten Zeichnungen dargestellten besonderen Formen beschränkt sind. Vielmehr umfasst diese Offenbarung alle Modifikationen, Entsprechungen, Kombinationen, Teilkombinationen Permutationen, Gruppierungen und Alternativen, die dem Erfindungsgedanken und dem Umfang der Offenbarung entsprechen, wie sie durch die beigefügten Ansprüche definiert sind.
AUSFÜHRLICHE BESCHREIBUNG
Diese Offenbarung eignet sich für eine Vielzahl von Ausführungsformen. Diese sind in den Zeichnungen dargestellt und hierin in detaillierten exemplarischen Ausführungsformen der Offenbarung beschrieben, mit der Erkenntnis, dass die vorliegende Offenbarung als eine Veranschaulichung der Prinzipien der Offenbarung zu betrachten ist, und nicht als eine Einschränkung der breiten Aspekte der Offenbarung bezüglich der dargestellten Ausführungsformen. Entsprechend sollten Elemente und Einschränkungen, die beispielsweise in den Abschnitten der Kurzdarstellung, der Zusammenfassung und der ausführlichen Beschreibung offenbart, aber nicht explizit in den Patentansprüchen aufgeführt sind, nicht per Schlussfolgerung, Rückschluss oder anderweitig einzeln oder insgesamt in die Patentansprüche integriert werden. Zu Zwecken der vorliegenden ausführlichen Beschreibung, soweit nicht ausdrücklich dementiert: beinhaltet die Singularform die Pluralform und umgekehrt; die Wörter „und“ und „oder“ sind beide verbindend und trennend; das Wort „alle“ bedeutet „alle und jegliche“; das Wort „jegliche“ bedeutet „alle und jegliche“; und die Wörter „einschließlich“ und „umfassend“ und „mit“ bedeuten „einschließlich ohne Einschränkung“. Darüber hinaus können beispielsweise Wörter für Annäherungen, wie „etwa“, „fast“, „wesentlich“, „ungefähr“ und dergleichen, hierin im Sinne von „bei, nahe oder nahezu“, oder „innerhalb 3-5 % von“ oder „innerhalb akzeptabler Herstellungstoleranzen“ oder jegliche logische Kombination davon verwendet werden.
Mit Bezug auf die Zeichnungen, worin sich gleiche Bezugszeichen auf gleiche Merkmale in den verschiedenen Ansichten beziehen, wird in 1 eine schematische Darstellung eines repräsentativen Fahrzeugs, das im Allgemeinen mit 10 bezeichnet wird und hierin zu Zwecken der Erörterung als eine Vier-Personen-Limousine dargestellt. Verpackt in einer Fahrzeugkarosserie 12 des Automobils 10, z. B. verteilt auf die verschiedenen Fahrzeugabteile, ist ein Bordnetz von Datenverarbeitungsvorrichtungen, wie beispielsweise die nachfolgend beschriebenen verschiedenartigen Vorrichtungen und Steuerungen. Das dargestellte Automobil 10 - hier auch kurz als „Kraftfahrzeug“ oder „Fahrzeug“ bezeichnet - ist lediglich eine exemplarische Anwendung, mit der die neuartigen Aspekte und Merkmale dieser Offenbarung praktiziert werden können. Ebenso sollte die Implementierung der vorliegenden Konzepte für die in 1 dargestellte spezifische Anzahl und Art der Datenverarbeitungsvorrichtungen als exemplarische Anwendung der hierin offenbarten Konzepte und Merkmale verstanden werden. Insofern wird davon ausgegangen, dass Aspekte und Merkmale dieser Offenbarung auf jede beliebige Anzahl und Art und Anordnung von vernetzten Steuerungen und Vorrichtungen angewendet werden können, die für nichtautomotive Anwendungen verwendet und von jedem logisch relevanten Kraftfahrzeugtyp implementiert werden. Darüber hinaus wurden nur ausgewählte Komponenten des Fahrzeugs 10 dargestellt und werden hierin ausführlich beschrieben. Dennoch können die hierin erörterten Kraftfahrzeuge und Netzwerkarchitekturen zahlreiche zusätzliche und alternative Merkmale und andere allgemein bekannte periphere Komponenten beinhalten, zum Beispiel zum Ausführen der verschiedenen Verfahren und Funktionen dieser Offenbarung. Letztendlich sind die hierin abgebildeten Zeichnungen nicht unbedingt maßstabsgetreu und dienen lediglich Anleitungszwecken. Somit gelten die spezifischen und relativen Maße der Zeichnungen nicht als einschränkend.
Das repräsentative Fahrzeug 10 von 1 ist ursprünglich mit einer Fahrzeug-Telekommunikations- und Informationseinheit 14 (umgangssprachlich als „Telematik“ bezeichnet) ausgestattet, die mit einem drahtlosen Kommunikationssystem (z. B. Mobilfunkmasten, Basisstationen und/oder mobile Vermittlungsstellen (MSCs) usw.; nicht dargestellt) kommuniziert. Einige der anderen Fahrzeug-Hardware 16, die allgemein in 1 dargestellt sind, beinhalten als nicht einschränkende Beispiele eine Anzeigevorrichtung 18, ein Mikrofon 28, einen Lautsprecher 30 und Eingangssteuerungen 32 (z. B. Tasten, Knöpfe, Schalter, Tastaturen, Touchscreens usw.). Im Allgemeinen ermöglichen diese Hardware-16-Komponenten dem Benutzer die Kommunikation mit der Telematikeinheit 14 und anderen Systemen und Systemkomponenten innerhalb des Fahrzeugs 10. Das Mikrofon 28 ermöglicht dem Fahrzeuginsassen die Eingabe von verbalen oder anderen auditiven Befehlen und kann mit einer integrierten Sprachverarbeitungseinheit mit einer Mensch/Maschine-Schnittstellen-(HMI)-Technologie ausgestattet werden. Umgekehrt stellt der Lautsprecher 30 eine verbale Ausgabe für die Fahrzeuginsassen bereit und kann entweder ein eigenständiger Lautsprecher speziell zur Verwendung mit der Telematikeinheit 14 oder Teil der Fahrzeug-Audiokomponente 22 sein. Das Audiosystem 22 ist funktionsfähig mit einer Netzwerkverbindungsschnittstelle 34 und einem Audiobus 20 verbunden, um analoge Informationen über eine oder mehrere Lautsprecherkomponenten zu empfangen und als Ton wiederzugeben.
Kommunikativ an die Telematikeinheit 14 angekoppelt ist eine Netzwerkverbindungsschnittstelle 34, zu deren geeigneten Beispielen Twisted Pair/Fiber Optic Ethernet Switch, interner/externer paralleler/serieller Kommunikationsbus, LAN, Controller Area Network (CAN), Media Oriented System Transfer (MOST), Local Interconnection Network (LIN) u. ä. gehören. Andere geeignete Kommunikationsschnittstellen können diejenigen sein, die den bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen. Die Netzwerkverbindungsschnittstelle 34 ermöglicht es der Fahrzeug-Hardware 16, einschließlich der Telematikeinheit 14, untereinander und mit verschiedenen Systemen und Subsystemen sowohl außerhalb der Fahrzeugkarosserie 12 als auch innerhalb des Fahrzeugs 10 Signale zu senden und zu empfangen, um verschiedene Fahrzeugfunktionen auszuführen, wie zum Beispiel das Entriegeln einer Fahrzeugtür, das Positionieren und Ausrichten eines Fahrzeugsitzes, das Steuern der Motordrosselklappe, das Aktivieren/Deaktivieren des Bremssystems und dergleichen. So empfängt und/oder überträgt die Telematikeinheit 14 beispielsweise Daten zu/von einem Sicherheitssystem ECU 52, einem Motorsteuergerät (ECM) 54, einem Infotainment-Anwendungsmodul 56, Sensorschnittstellenmodul(en) 58 und verschiedenen anderen Fahrzeugsteuervorrichtungen 60, wie beispielsweise einem Getriebesteuermodul (TCM), einem Klimasteuermodul (CCM), einem Bremssystemmodul (BCM) usw.
Mit weiterem Bezug auf 1 ist die Telematikeinheit 14 eine bordeigene Datenverarbeitungsvorrichtung, die sowohl einzeln als auch durch ihre Verbindung mit anderen vernetzten Vorrichtungen eine Mischung von Dienstleistungen bereitstellt. Diese Telematikeinheit 14 besteht im Allgemeinen aus einem oder mehreren Prozessoren, die als diskreter Mikroprozessor, anwendungsspezifische integrierte Schaltung (ASIC), Zentraleinheit (CPU) 36 usw. ausgeführt werden können, die funktionsfähig an eine oder mehrere elektronische Speichervorrichtungen 38 gekoppelt sind, von denen jede die Form einer CD-ROM, einer Magnetplatte, einer IC-Vorrichtung, eines Halbleiterspeichers (z. B. verschiedene Arten von RAM oder ROM) usw. und einer Echtzeituhr (RTC) 46 annehmen kann. Die Kommunikationsfähigkeiten mit entfernten, off-board vernetzten Vorrichtungen werden über einen oder mehrere oder alle von einem/einer zellularen Chipsatz/Komponente 40, ein drahtloses Modem 42, einen Navigations- und Ortungs-Chipsatz/Komponente 44 (z. B. Global Positioning System (GPS)), eine drahtlose Nahbereichs-Kommunikationsvorrichtung 48 (z. B. eine Bluetooth®-Einheit) und/oder eine Dualantenne 50 bereitgestellt. Es ist davon auszugehen, dass die Telematikeinheit 14 ohne eine oder mehrere der vorstehend aufgeführten Komponenten implementiert werden kann, oder dass sie je nach Bedarf zusätzliche Komponenten und Funktionen für eine bestimmte Endanwendung beinhalten kann.
Zuwendend auf 2 ist eine repräsentative Master-Slave-Systemarchitektur dargestellt, die allgemein als 100 bezeichnet wird, um den Betrieb verschiedener vernetzter ECUs, elektronischer Hardware und anderer Datenverarbeitungsvorrichtungen zu verwalten. Die in 2 dargestellte exemplarische Architektur beinhaltet beispielsweise eine Auswahl von ECUs 112A, 112B, 112C ... 112N, die über eine Kommunikationsschnittstelle 114 kommunikativ miteinander verbunden sind. Wie dargestellt, wird dem ersten ECU 112A derzeit die Rolle einer Master-Vorrichtung (M) zugewiesen, während die übrigen ECUs 112B, 112C...112N in der Rolle der Slave-Vorrichtungen (S) agieren. Obwohl sich das Erscheinungsbild unterscheidet, ist vorgesehen, dass alle vorstehend genannten Merkmale in Bezug auf die fahrzeuginterne Netzwerkarchitektur von 1 einzeln, gemeinsam oder in beliebiger Kombination in die vernetzte ECU-Architektur von 2 integriert werden können und umgekehrt. Als nicht einschränkendes Beispiel können die ECUs 112A-112N von 2 jede der zuvor in Bezug auf 1 beschriebenen Konfigurationen der entsprechenden fahrzeuginternen Vorrichtungen übernehmen, wie Telematikeinheit 14, Anzeigevorrichtung 18, Audiosystem 22, Sicherheitssystem ECU 52, ECM 54, Infotainment-Anwendungsmodul 56, Sensor-Interface-Modul(e) 58, andere Fahrzeugsteuervorrichtungen 60, usw. In gleicher Weise kann die Kommunikationsschnittstelle 114 von 2 jede der vorstehend beschriebenen Formen hinsichtlich der Netzwerkverbindungsschnittstelle 34 von 1 annehmen.
Die Systemarchitektur 100 ist so konzipiert, dass die einzelnen Steuerungen 112A-112N dynamisch und kooperativ zwischen einem energiesparenden Ruhemodus (dargestellt mit Kreuzschraffur im ECU 112B von 2) und einem regulären Wachmodus (dargestellt ohne Kreuzschraffur in den ECUs 112A, 112B und 112N von 2) basierend auf ihren jeweiligen Betriebsanforderungen wechseln können, ohne dass jede Vorrichtung in einer bestimmten Gruppe ruhen/aktiviert werden muss. Eine Master-Vorrichtung kann zum Beispiel im Ruhezustand sein oder sich selbst aktivieren und andere Vorrichtungen in den Ruhezustand versetzen oder aktivieren, je nach ihren eigenen betrieblichen Bedürfnissen oder den Bedürfnissen anderer Knoten in der Gruppe. Eine Slave-Vorrichtung hingegen kann die Anforderung stellen, in den Ruhezustand zu gehen oder aktiviert zu werden, oder sie kann vorübergehend die Rolle der Master-Vorrichtung übernehmen, basierend auf ihren eigenen betrieblichen Bedürfnissen oder den Bedürfnissen anderer Knoten in der Gruppe. Durch die Implementierung der hierin beschriebenen Protokolle kann dieses System das Schlummern und Aufwecken von Vorrichtungen zuverlässig steuern, was wiederum dazu beiträgt, den Energieverbrauch zu senken, ohne die Gesamtfunktionalität zu beeinträchtigen. So wird beispielsweise ein einzelnes ECU dynamisch als alleinige Master-Vorrichtung zur Aufrechterhaltung des Gruppenbetriebs durch Netzwerkmanagement-Frame-Pakete bezeichnet, die z. B. durch Multicast-Verteilung mit begrenzten Taktdriften übertragen werden. Mit dieser Funktion ist es weder erforderlich, dass eine Master-Vorrichtung ständig aktiviert bleibt, noch dass alle Slave-Vorrichtungen im Ruhezustand sind, wenn sich eine Master-Vorrichtung im Ruhezustand befindet. Darüber hinaus können alle Vorrichtungen einer bestimmten Gruppe so programmiert werden, dass sie dieselben oder ähnliche Master-Regelalgorithmen ausführen, wodurch das Design der Gesamtarchitektur vereinfacht und robuster wird.
Für die Verwaltung des Betriebs der vernetzten ECUs von 2 kann es erforderlich sein, Systeminformationen zu sammeln, zu speichern, abzurufen und/oder zu aktualisieren, die in einer leicht zugänglichen Datenstruktur gehalten werden. Diese Systeminformationen können Folgendes beinhalten: (1) Statusvektoren für alle ECUs einer bestimmten Gruppe, wobei jeder jeweilige Statusvektor angibt, ob sich das entsprechende ECU im aktivierten Zustand oder im Ruhezustand befindet; (2) Vorrichtungsrollen für alle ECUs in einer bestimmten Gruppe, wobei die jeweilige Vorrichtungsrolle das entsprechende ECU als Slave-Vorrichtung oder Master-Vorrichtung bezeichnet; und (3) eine Rangfolge (im Folgenden auch „zugewiesene Hierarchie“ genannt), die bei der Auswahl aller ECUs in einer bestimmten Gruppe priorisiert, welche ECU temporär als Master-Vorrichtung zugewiesen wird. Entsprechend der repräsentativen Architektur von 2 verwaltet die Master-Vorrichtung (M) ECU 112A Systeminformationen in einer Master-Auswahltabelle (MST) und einer Statustabelle (ST). Die MST hält die zugewiesene Hierarchie aufrecht, die die priorisierte Reihenfolge der Vorrichtungen bei der Auswahl einer Master-Vorrichtung festlegt, wobei die zugewiesenen Prioritätskennzeichnungen (z. B. 1, 2, 3, usw.) für die Vorrichtungen im Voraus bestimmt und als Kalibrierungswerte gespeichert werden können. Umgekehrt verfolgt und pflegt der ST die Statusvektoren (Bit = 0 für den Ruhezustand); Bit = 1 für den aktivierten Zustand) und die Vorrichtungsrollen (M = Master; S = Slave) und kann periodisch und/oder in Echtzeit entsprechend den Informationen im NMF für eine konsistente Darstellung aktualisiert werden. Für mindestens einige Konfigurationen ist es wünschenswert, dass jedes ECU 112A-112N in der dafür vorgesehenen Gruppe in einer entsprechenden lokalen Speichervorrichtung individuelle Kopien von ST und MST speichert. Dabei kann jede Vorrichtung die Statusvektoren, die Vorrichtungsrollen und/oder die zugeordnete Hierarchie mit Verweis auf ST oder MST abrufen, aufrufen oder anderweitig ermitteln.
Alle Vorrichtungen in der repräsentativen Architektur 100 von 2, ob Master oder Slave, können je nach Gruppen- oder individuellen Betriebsbedürfnissen sowohl im Ruhezustand als auch im aktivierten Zustand arbeiten. Im Allgemeinen sendet eine Vorrichtung, wenn sie in den Ruhezustand oder in den aktiven Zustand versetzt werden soll, ein Signal zur Änderung der Betriebsart, das die Absicht anzeigt, vom aktiven Zustand in den Ruhezustand oder vom Ruhezustand in den aktiven Zustand überzugehen. Zwei Arten von Netzwerk-Frames können zum Beispiel eingesetzt werden, um Informationen zwischen Geräten zu übertragen, um den Ruhezustand und das Aktivieren von Vorrichtungen zu verwalten, den Status und die Rolle der einzelnen Vorrichtungen zu aktualisieren und eine konsistente Ansicht der Vorrichtungen im Netzwerk aufrechtzuerhalten. Als nicht einschränkendes Beispiel, wenn eine Master-Vorrichtung beabsichtigt, in den Ruhezustand zu wechseln und/oder eine Slave-Vorrichtung in den Ruhezustand zu versetzen oder zu aktivieren, ist ein Signal zur Anzeige einer solchen Änderung in einem Netzwerk-Management-Frame (NMF)-Paket beinhaltet, das vom Master an einige oder alle Slave-Vorrichtungen gesendet wird, z. B. über Multicast-Verteilung (Eine-an-Viele in der Computernetzwerk-Gruppenkommunikation). Wenn die Master-Vorrichtung eine Slave-Vorrichtung aktivieren (oder in den Ruhezustand versetzen) möchte, kann das vom Master gesendete NMF-Paket einen Befehl beinhalten, dass die Slave-Vorrichtung in den aktiven Zustand (oder in den Ruhezustand) übergeht. Dieser Befehl kann in Form einer entsprechenden Änderung des jeweiligen Statusvektors der Slave-Vorrichtung im ST erfolgen und kann vor der Rolle des Masters gesendet werden, der zu einer neuen Vorrichtung migriert und die zuvor benannte Master-Vorrichtung wird gleichzeitig in den Ruhezustand versetzt. In diesem Zusammenhang, wenn die Master-Vorrichtung in den Ruhezustand versetzt werden möchte, kann das vom Master gesendete NMF-Paket Folgendes beinhalten: ein Modusänderungssignal (Statusvektoränderung), das auf dasselbe hinweist; und eine Master-Auswahlabfrage zur Auswahl eines neuen Masters. Als Reaktion darauf können eine oder mehrere oder alle Slave-Vorrichtungen einzeln mit einem Request-Frame-Paket (REQ-Paket) antworten, das eine Master-Bezeichnungsanforderung beinhaltet, die vor Beginn des Ruhezustands der Master-Vorrichtung als Master-Vorrichtung ausgewählt wird.
In Fortsetzung der Beispiele für Netzwerk-Frame-Optionen, wenn eine Vorrichtung im Ruhezustand aktiviert werden soll, ist in einem REQ-Paket, das von der ruhenden ECU an ein Master-ECU (wenn eines davon aktiv ist) und/oder andere zugängliche ECUs in der Gruppe gesendet wird, ein Modusänderungssignal, das diese Absicht anzeigt, beinhaltet. Dieses REQ-Paket kann zudem eine Master-Bezeichnungsanforderung beinhalten, und kann vor der Änderung der jeweiligen Vorrichtungsrollen für beliebige Vorrichtungen an/von Slave oder Master gesendet werden. Im Gegenzug kann das REQ-übertragende ECU von einer aktivierten Master-Vorrichtung ein NMF-Paket empfangen, das die Anforderung bestätigt - z. B. den jeweiligen Statusvektor und die Rolle der Vorrichtung des REQübertragenden ECU, die im ST aktualisiert wurden, um sowohl die aktivierte als auch die Master-Vorrichtung anzuzeigen. Umgekehrt, wenn die REQ-übertragende ECU kein NMF-Paket von einer Master-Vorrichtung empfängt, z. B. vor Ablauf einer bestimmten Zeitspanne (Zeitüberschreitungsbedingung), kann es erforderlich sein, dass die REQ-übertragende ECU im Ruhezustand weiterläuft. Alternativ kann sich das REQ-übertragende ECU vorübergehend selbst als Master-Vorrichtung auswählen, z. B. bis der Master-Auswahlprozess eingeleitet werden kann, um ein höher priorisiertes ECU als Master-Vorrichtung auszuwählen. Wenn nun eine aktivierte Slave-Vorrichtung in den Ruhezustand übergehen möchte, sendet die Slave-Vorrichtung ein REQ-Paket mit einer entsprechenden Modus-Änderungsanforderung an die aktuell benannte Master-Vorrichtung. Das Master-ECU antwortet auf dieses REQ-Paket mit einem NMF-Paket, das die Modus-Änderungsanforderung entweder genehmigt oder ablehnt, wie im Folgenden näher beschrieben wird.
Zur Unterstützung eines kollaborativen Sleep/Wake-Prozesses kann die Rolle der Master-Vorrichtung zwischen den Assets migrieren, die einer entsprechenden Gruppe zugeordnet sind, wobei die jeweilige Rolle der Vorrichtung für ein Master-ECU in der Gruppe von Master zu Slave geändert wird, während die jeweilige Rolle der Vorrichtung für ein Slave-ECU in der Gruppe von Slave zu Master geändert wird. Der Master-Auswahlprozess, der im Folgenden näher beschrieben wird, basiert auf der zugeordneten Hierarchie der ECUs in der Gruppe und den aktuellen Betriebsarten für diese ECUs. Nach der Modifikation der jeweiligen Rolle für eine Slave-Vorrichtung zum Master wird das neu benannte Master-ECU ein Netzwerkmanagement-Frame-Paket mit einer aktualisierten Statustabelle mit allen geänderte Vorrichtungsrollen und alle geänderten Statusvektoren an die verbleibenden ECUs übertragen. Nach dem Senden des NMF-Pakets aktualisiert jedes der empfangenden ECUs in der Gruppe seinen individuellen ST, der in seinem jeweiligen lokalen Speicher abgelegt ist, um die geänderten Vorrichtungsrollen und geänderten Statusvektoren aufzunehmen. Zumindest bei einigen Ausführungsformen sind die NMF- und REQ-Pakete kurz, um den Übertragungsaufwand zu minimieren und den Verarbeitungsaufwand zu reduzieren. Als weitere Option beinhalten beide Pakete einen Quellidentifikator, der angibt, welche Vorrichtung das Paket gesendet hat, und eine Statusbit-Vektoränderung mit der beabsichtigten Geräte-ID (für ein NMF) oder eine Modus-Änderungsanforderung mit/ohne Master-Bezeichnungsanforderung (für einen REQ).
3 veranschaulicht eine Reihe repräsentativer Operationen zum Ausführen eines Master-Auswahlprotokolls, beispielsweise über ein vernetztes ECU, das derzeit als Master-Vorrichtung bezeichnet wird. In diesem Zusammenhang veranschaulicht 4 eine Reihe repräsentativer Operationen zum Ausführen eines Ruhezustands-Managementprotokolls, zum Beispiel über ein beliebiges vernetztes ECU in einer bestimmten Gruppe, unabhängig davon, ob es sich um einen Master oder Slave handelt, der beabsichtigt, in den Ruhezustand überzugehen. Umgekehrt veranschaulicht 5 eine Reihe repräsentativer Operationen zum Ausführen eines Aktivierungszustands-Managementprotokolls, zum Beispiel über ein beliebiges vernetztes ECU in einer bestimmten Gruppe, unabhängig davon, ob es sich um einen Master oder Slave handelt, der beabsichtigt, in den aktiven Zustand überzugehen. Einige oder alle der in den 3-5 dargestellten und hierin beschriebenen Vorgänge können repräsentativ für einen Algorithmus oder ein Verfahren 200, 300 und 400 sein, das prozessorausführbaren Anweisungen entspricht, die beispielsweise im Haupt- oder Hilfsspeicher gespeichert werden können und beispielsweise durch eine ECU, eine CPU, einer im Fahrzeug oder entfernt befindlichen Fahrzeugsteuerlogikschaltung oder einer anderen Vorrichtung ausgeführt werden können, um beliebige oder alle der oben und/oder unten beschriebenen Funktionen auszuführen, die den offenbarten Konzepten zugeordnet sind.
Im Hinblick auf 3 wird das Master-Auswahlprotokoll 200 im Allgemeinen verwendet, wenn: eine Master-Vorrichtung in den Ruhezustand versetzt werden soll und dann ein neuer Master ausgewählt werden soll, um den Systembetrieb aufrechtzuerhalten; eine Master-Vorrichtung derzeit nicht existiert (z. B. wenn das System erstmalig initialisiert wird); oder wenn eine neue Vorrichtung sich einer Gruppe anschließt oder eine Vorrichtung aktiviert wird und festgestellt wird, dass diese neue/aktive Vorrichtung eine höhere Priorität aufweist als der vorhandene Master. In zumindest einigen Ausführungsformen trifft die jeweilige Vorrichtung eine lokale Entscheidung mit Statusinformationen, die von allen anderen Vorrichtungen abrufbar sind. Das Verfahren 200 beginnt bei Block 201 mit dem Warten auf den Empfang eines NMF-Pakets, z. B. von einer aktuell benannten Master-Vorrichtung. Wenn bei Block 203 bestimmt wird, dass ein NMF-Paket empfangen wird (Block 203 = J), fährt das Verfahren 200 mit Block 205 fort, um einen Wakeup-Prozess einzuleiten, wie beispielsweise das Wakeup-Management-Protokoll 400 von 5. Wird jedoch bei Block 203 bestimmt, dass ein NMF-Paket nicht empfangen wird (Block 203 = N), fährt das Verfahren 200 mit Block 207 fort, um zu bewerten, ob eine Zeitüberschreitungsbedingung aufgetreten ist, nämlich wenn eine bestimmte Zeitspanne für das Warten auf NMF verstrichen ist. Als Reaktion auf das Ermitteln, dass die Zeitüberschreitungsbedingung nicht aufgetreten ist (Block 207 = N), führt das Verfahren 200 Schleifen zurück zu Block 201, um auf ein NMF-Paket zu warten.
Mit fortlaufendem Verweis auf 3, wenn ein NMF-Paket nicht empfangen wird, wie bei Block 203 ermittelt, und tatsächlich eine Zeitüberschreitungsbedingung aufgetreten ist, wie bei Block 207 bestimmt, wird die Vorrichtung, die das Master-Auswahlprotokoll 200 ausführt, ein REQ-Paket an andere vernetzte Vorrichtungen mit einer Master-Bezeichnungsanforderung, die als Master-Vorrichtung ausgewählt werden soll, bei Block 209 angezeigt. Bei Block 211 bestimmt das Verfahren 200, ob ein NMF-Paket mit einer entsprechenden ST-Rollenänderung der Vorrichtung empfangen wird, die die Anforderung der anfordernden Vorrichtung zum Master bestätigt/ablehnt. Wenn bei Block 211 bestimmt wird, dass ein NMF-Paket, das die Anfrage genehmigt, nicht empfangen wird (Block 211 = N), bezeichnet sich die anfordernde Vorrichtung vorübergehend als Master-Vorrichtung und sendet ein NMF-Paket an die anderen vernetzten Vorrichtungen, die diese Änderung anzeigen, wie bei Block 213 angegeben. Wird jedoch bei Block 211 ermittelt, dass ein NMF-Paket empfangen wird, aber die Rollenänderungsanforderung an den Master abgelehnt wird (Block 211 = J), so fährt das Verfahren 200 mit Block 215 fort, wobei die anfordernde Vorrichtung als Slave-Vorrichtung bezeichnet wird. Das Verfahren 200 geht von den beiden Blöcken 213 und 215 zu Block 217 über, wobei der ST aktualisiert wird, um Änderungen der Vorrichtungsrollen zu berücksichtigen.
Mit anschließendem Bezug auf 4 wird das Ruhemodus-Managementprotokoll 300 im Allgemeinen durch eine Netzwerkvorrichtung eingesetzt, die beabsichtigt, in den Ruhemodus zu wechseln, z. B. wenn es keine korrelierte Aktivität für diese Vorrichtung gibt und/oder eine andere Vorrichtung im Netzwerk nicht mit dieser Vorrichtung interagieren muss. Als Beispiel, und nicht als Einschränkung, kann eine Slave-Vorrichtung zum Wechseln in den Ruhezustand auffordern, benötigt aber im Allgemeinen eine Master-Vorrichtung, um die Anforderung zu genehmigen. Obwohl die Entscheidung für den Ruhezustand und der Übergang in den Ruhezustand lokal getroffen wird, bedarf es der „globalen“ Zustimmung eines Masters. Erhält die Master-Vorrichtung eine Genehmigung, aktualisiert sie NMF mit dem entsprechenden Slave-Bit auf S; sobald die anfordernde Slave-Vorrichtung ein NMF-Paket empfängt, dessen Bit auf S gesetzt ist, kann sie in den Ruhezustand übergehen. Als weiteres Beispiel, wenn die Master-Vorrichtung in den Sleep-Modus wechseln möchte, wird die Bezeichnung „Master“ auf eine Slave-Vorrichtung übertragen. Slave-Vorrichtungen können diese Änderung durch das Auftreten einer Zeitüberschreitungsbedingung von NMF erkennen; diese Slave-Vorrichtungen treten in die Master-Auswahlphase ein, wie beispielsweise das Master-Auswahlprotokoll 200 von 3. Lokal gespeicherte ST werden beim Empfangen von NMF entsprechend den Statusvektoränderungen aktualisiert.
Das Verfahren 300 von 4 beginnt bei Block 301 mit der Vorrichtung, die das Sleep-Management-Protokoll ausführt und ermittelt, ob es sich um einen Master handelt. Wenn bei Block 301 ermittelt wird, dass es sich bei der Vorrichtung tatsächlich um den agierenden Master handelt (Block 301 = J), fährt das Verfahren 300 mit dem Block 303 fort, wobei die Master-Vorrichtung ein NMF-Paket mit dem Statusvektor in den Ruhezustand versetzt (Bit = 0) sendet. Wird hingegen ermittelt, dass es sich bei der Vorrichtung nicht um die aktive Master-Vorrichtung handelt (Block 301 = N), so wird die Vorrichtung ein REQ-Paket an den vorhandenen Master mit einer Modusänderungsanforderung senden, die anzeigt, dass sie beabsichtigt, in den Ruhezustand überzugehen, wie bei Block 305 angegeben. Bei Block 307 ermittelt das Verfahren 300, ob ein NMF-Paket empfangen wird, wenn eine Genehmigung der Modenänderungsanforderung der Slave-Vorrichtung vorliegt (z. B. jeweiliges Statusvektor-Bit = 0 in ST). Wird bei Block 307 ermittelt, dass die NMF-Genehmigung nicht vorliegt (Block 307 = N), so schleift das Verfahren 300 zu Block 309 und hält die anfordernde Vorrichtung aktiv, bis das erforderliche NMF-Paket empfangen wird. Wenn jedoch die NMF-Genehmigung vorliegt (Block 307 = J), fährt das Verfahren mit Block 311 fort, versetzt die anfordernde Vorrichtung in den Ruhezustand und aktualisiert optional ST.
Alle vernetzten Vorrichtungen in einer bestimmten Gruppe können das Wakeup-Management-Protokoll 400 von 5 auslösen und mit dem Aktivieren beginnen, z. B. wenn sie durch ein Input/Output (I/O)-Signal von einer anderen Fahrzeugvorrichtung und/oder durch eine andere Vorrichtung im Netzwerk aktiviert werden. Nach dem Aufwachen durchläuft eine Vorrichtung einen ähnlichen Prozess wie die Masterauswahl und: prüft durch „Abhören“ eines NMF-Pakets, ob ein Master vorhanden ist; wenn ein Master vorhanden ist, jedoch mit geringerer Priorität, wird die Master-Bezeichnung übertragen; ansonsten senden eines REQ-Pakets mit einer Master-Bezeichnungsanforderung und Update ST gemäß NMF. Alle anderen Vorrichtungen im Netzwerk müssen dann möglicherweise ihren ST gemäß NMF aktualisieren, um eine konsistente Ansicht über alle Vorrichtungen hinweg zu gewährleisten. Das Verfahren 400 von 5 beginnt bei Block 401 mit dem Aktivieren einer Vorrichtung und fährt gleichzeitig mit dem Empfangen eines NMF-Pakets, z. B. von einer aktuell bezeichneten Master-Vorrichtung, zu Block 403 fort. Bei Block 405 ermittelt das Verfahren 400 z. B. aus dem MST im NMF-Paket, ob die NMF-übertragende Master-Vorrichtung eine niedrigere oder niedrigste Priorität aufweist. Wenn bei Block 405 ermittelt wird, dass die Master-Vorrichtung eine niedrige/niedrigste Priorität aufweist (Block 405 = J), fährt das Verfahren 400 mit Block 407 fort, um den ST mit der jeweiligen Vorrichtungsrolle der empfangenden Vorrichtung, die auf eine Master-Vorrichtung geändert wurde, zu aktualisieren, und dann, bei Block 409, ein NMF-Paket über die neu benannte Master-Vorrichtung mit dem aktualisierten ST zu senden. Andererseits, wenn diese Master-Vorrichtung keine niedrige/niedrigste Priorität aufweist (Block 405 = N), fährt das Verfahren 400 mit Block 411 fort, wobei die NMF-Empfangsvorrichtung ein REQ-Paket mit einem Modusänderungssignal sendet, das die Absicht anzeigt, vom Ruhezustand in den aktiven Zustand überzugehen und bei Block 413 den ST mit einer entsprechenden Modusänderung zu aktualisieren.
Aspekte dieser Offenbarung können in einigen Ausführungsformen durch ein computerausführbares Programm von Anweisungen implementiert werden, wie zum Beispiel Programmmodulen, die allgemein als Softwareanwendungen oder Anwendungsprogramme bezeichnet werden, die von einem Onboard-Computer ausgeführt werden. Die Software kann in nicht einschränkenden Beispielen Routinen, Programme, Objekte, Komponenten und Datenstrukturen beinhalten, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Software kann eine Schnittstelle bilden, damit ein Computer entsprechend einer Eingabequelle reagieren kann. Die Software kann auch mit anderen Codesegmenten zusammenarbeiten, um eine Vielzahl von Aufgaben in Reaktion auf Daten zu initiieren, die in Verbindung mit der Quelle der empfangenen Daten empfangen werden. Die Software kann auf einem beliebigen einer Vielzahl von Speichermedien, wie CD-ROM, Magnetplatte, Blasenspeicher und Halbleiterspeicher (z. B. verschiedene Arten von RAM oder ROM), gespeichert sein.
Darüber hinaus können Aspekte der vorliegenden Offenbarung mit einer Vielzahl von Computersystem- und Computernetzkonfigurationen einschließlich Mehrprozessorsystemen, Mikroprozessor-basierter oder programmierbarer Unterhaltungselektronik, Minicomputern, Mainframe-Computern und dergleichen durchgeführt werden. Zusätzlich können Aspekte der vorliegenden Offenbarung in Umgebungen mit verteilter Datenverarbeitung ausgeführt werden, bei denen Aufgaben durch Femverarbeitungsvorrichtungen ausgeführt werden, die durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Computerumgebung können Programmmodule sowohl auf lokalen als auch entfernten Computerspeichermedien einschließlich Speichergeräten angeordnet sein. Aspekte der vorliegenden Offenbarung können daher in Verbindung mit verschiedener Hardware, Software oder einer Kombination davon in einem Computersystem oder einem anderen Verarbeitungssystem implementiert werden.
Jedes der hierin beschriebenen Verfahren kann maschinenlesbare Anweisungen zur Ausführung beinhalten durch: (a) einen Prozessor, (b) eine Steuerung, und/oder (c) jede andere geeignete Verarbeitungsvorrichtung. Jeder hierin offenbarte Algorithmus, jede Software oder jedes Verfahren kann in einer Software enthalten sein, die auf einem greifbaren Medium, wie beispielsweise einem Flash-Speicher, einer CD-ROM, einer Diskette, einer Festplatte, einer Digital Versatile Disk (DVD) oder andere Speichervorrichtungen, gespeichert ist, jedoch werden Fachleute leicht erkennen, dass der gesamte Algorithmus und/oder Teile davon alternativ durch eine andere Vorrichtung als eine Steuerung ausgeführt werden können und/oder in Firmware oder dedizierter Hardware in einer gut bekannten Weise implementiert werden können (z. B. kann er durch einen anwendungsspezifischen integrierter Schaltkreis (Application Specific Integrated Circuit), eine programmierbare Logikvorrichtung (PLD), eine feldprogrammierbare Logikvorrichtung (FPLD), eine diskrete Logik usw. implementiert werden). Obwohl spezielle Algorithmen unter Bezugnahme auf die hier dargestellten Flussdiagramme beschrieben werden, wird der Durchschnittsfachmann leicht erkennen, dass viele andere Verfahren zum Implementieren der exemplarischen maschinenlesbaren Anweisungen alternativ verwendet werden können.
Obwohl einige Aspekte der vorliegenden Offenbarung im Detail unter Bezugnahme auf die dargestellten Ausführungsformen beschrieben worden sind, werden Fachleute auf dem Gebiet erkennen, dass viele Änderungen an denselben vorgenommen werden können, ohne vom Schutzumfang der vorliegenden Offenbarung abzuweichen. Die vorliegende Offenbarung ist nicht beschränkt auf die hierin offenbarte genaue Konstruktion und Zusammensetzung; jegliche und alle Modifikationen, Änderungen und Variationen, ersichtlich aus den vorangehenden Beschreibungen, liegen innerhalb des Umfangs der Offenbarung, wie in den hinzugefügten Ansprüchen definiert. Darüber hinaus beinhalten die vorliegenden Konzepte ausdrücklich alle Kombinationen und Teilkombinationen der vorangehenden Elemente und Merkmale.

Claims

Verfahren zum Verwalten eines Bordnetzes von elektronischen Steuereinheiten (ECU) eines Kraftfahrzeugs, wobei eine Gruppe der ECUs über eine Kommunikationsschnittstelle miteinander verbunden ist und jedes für den Übergang zwischen einem aktivierten Zustand und einem Ruhezustand betreibbar ist, das Verfahren umfassend: das Ermitteln der jeweiligen Statusvektoren für die ECUs in der Gruppe, wobei jeder der Statusvektoren angibt, ob sich das entsprechende ECU im aktivierten Zustand oder im Ruhezustand befindet; das Ermitteln der jeweiligen Vorrichtungsrollen für die ECUs in der Gruppe, wobei jede der Vorrichtungsrollen das entsprechende ECU als Slave-Vorrichtung oder Master-Vorrichtung bezeichnet; das Ermitteln einer zugewiesenen Hierarchie für die ECUs in der Gruppe, wobei die zugewiesene Hierarchie einschließlich der entsprechenden Prioritätsbezeichnungen zur Auswahl der ECUs als Master-Vorrichtung dient; das Übertragen eines Modusänderungssignals, das anzeigt, dass eines der ECUs beabsichtigt, vom aktivierten Zustand in den Ruhezustand oder vom Ruhezustand in den aktivierten Zustand überzugehen; und in Reaktion auf das Übertragen des Modusänderungssignals, Modifizieren der jeweiligen Vorrichtungsrolle für ein erstes der ECUs in der Gruppe von der Master-Vorrichtung zu der Slave-Vorrichtung und Modifizieren der jeweiligen Vorrichtungsrolle für ein zweites der ECUs in der Gruppe von der Slave-Vorrichtung zu der Master-Vorrichtung basierend auf der zugewiesenen Hierarchie und den Statusvektoren für die ECUs in der Gruppe.
Verfahren nach Anspruch 1, worin das Modusänderungssignal die Absicht anzeigt, vom aktivierten Zustand in den Ruhezustand überzugehen, das in einem Netzwerkmanagement-Frame (NMF)-Paket beinhaltet ist, das durch das erste ECU gesendet und von dem zweiten ECU empfangen wird, und das vor dem Modifizieren der jeweiligen Vorrichtungsrolle für das erste ECU von der Master-Vorrichtung zur Slave-Vorrichtung gesendet wird.
Verfahren nach Anspruch 2, worin das NMF-Paket von dem ersten ECU an andere ECUs in der Gruppe über Multicast-Verteilung gesendet wird, wobei das Verfahren weiterhin das Empfangen einer Master-Bezeichnungsanforderung, die als die Master-Vorrichtung ausgewählt werden soll, durch das erste ECU von einem oder mehreren der anderen ECUs vor dem Modifizieren der jeweiligen Vorrichtungsrolle für das zweite ECU an die Master-Vorrichtung umfasst.
Verfahren nach Anspruch 2, worin das NMF-Paket, das vom ersten ECU an das zweite ECU gesendet wird, einen Befehl für das zweite ECU beinhaltet, um vom Ruhezustand in den aktivierten Zustand überzugehen, bevor die jeweilige Vorrichtungsrolle für das zweite ECU zur Master-Vorrichtung geändert wird.
Verfahren nach Anspruch 1, ferner umfassend das Übertragen, vom zweiten ECU an andere ECUs in der Gruppe nach Modifizierung der jeweiligen Vorrichtungsrolle für das zweite ECU an die Master-Vorrichtung, eines Netzwerkmanagement-Frame (NMF)-Pakets, wobei das NMF-Paket eine Statustabelle (ST) mit den modifizierten Vorrichtungsrollen der ersten und zweiten ECUs und einen modifizierten Statusvektor für das erste ECU beinhaltet, der anzeigt, dass das erste ECU im Ruhezustand ist.
Verfahren nach Anspruch 5, ferner umfassend das Aktualisieren, über jedes der anderen ECUs in der Gruppe, einer individuellen Statustabelle (ST), die von einer jeweiligen lokalen Speichervorrichtung des ECU gespeichert wird, um die geänderten Vorrichtungsrollen der ersten und zweiten ECUs und den geänderten Statusvektor für das erste ECU, der anzeigt, dass das erste ECU im Ruhezustand ist, einzubeziehen.
Verfahren nach Anspruch 1, worin das Modusänderungssignal die Absicht anzeigt, vom Ruhezustand in den aktivierten Zustand überzugehen, das in einem Anforderungsframe (NMF)-Paket beinhaltet ist, das durch das zweite ECU gesendet und von dem ersten ECU empfangen wird, und das vor dem Modifizieren der jeweiligen Vorrichtungsrolle für das zweite ECU von der Slave-Vorrichtung zur Master-Vorrichtung gesendet wird.
Verfahren nach Anspruch 7, ferner umfassend das Empfangen durch das zweite ECU vom ersten ECU als Antwort auf das REQ-Paket eines Netzwerkmanagement-Frame (NMF)-Pakets mit dem Statusvektor und der Vorrichtungsrolle des ersten ECU, welches die aktivierte und die Master-Vorrichtung anzeigt.
Verfahren nach Anspruch 7, ferner umfassend, in Reaktion auf das zweite ECU, das kein Netzwerkmanagement-Frame (NMF)-Paket von einem der anderen ECUs in der Gruppe vor Ablauf einer voreingestellten Zeitüberschreitungsperiode empfängt, Selbstauswahl durch das zweite ECU als Master-Vorrichtung.
Verfahren nach Anspruch 1, ferner umfassend das Empfangen, durch das zweite ECU von einem dritten der ECUs in der Gruppe, nachdem die jeweilige Vorrichtungsrolle für das zweite ECU von der Slave-Vorrichtung zur Master-Vorrichtung geändert wurde, eines Anforderungsframe-(REQ)-Pakets, das eine Modusänderungsanforderung zum Übergang vom aktivierten Zustand in den Ruhezustand beinhaltet.