DE102012102173A1

DE102012102173A1 - Re-konfigurierbare Schnittstellen-basierende elektrische Architektur

Info

Publication number: DE102012102173A1
Application number: DE102012102173A
Authority: DE
Inventors: Dipankar Das; Vinod Kumar AGRAWAL; Seetharaman RAJAPPAN
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2011-04-13
Filing date: 2012-03-15
Publication date: 2012-10-18
Anticipated expiration: 2032-03-16
Also published as: US20120265359A1; CN102736538A; US8930036B2; CN102736538B; DE102012102173B4

Abstract

Eine elektrische Netzwerkarchitektur mit einem re-konfigurierbaren Interface-Layer, zusammen mit einer dazu gehörigen Re-Konfigurationsmethodik. Der Interface-Layer umfasst rekonfigurierbare Interface-Geräte, die einer Vielzahl von Sensoren und Aktuatoren gestatten, mit einer Vielzahl von Kontrolleinheiten zu kommunizieren. Jeder Sensor oder Aktuator ist mit einer Vielzahl von Interface-Geräten verbunden, welche wiederum mit einem Bus verbunden sind. Die Kontrolleinheiten sind darüber hinaus mit dem Bus verbunden. Im Fall eines Interface-Geräteausfalls können andere Interface-Geräte re-konfiguriert werden, um die Kommunikation zwischen Sensoren, Aktuatoren und Kontrolleinheiten aufrecht zu halten. Im Fall eines Ausfalls einer Kontrolleinheit können die Interfacegeräte re-konfiguriert werden, um Sensor- und Aktuator-Nachrichtenverkehr an eine andere Kontrolleinheit zu leiten, die die Funktionen der ausgefallenen Kontrolleinheit handhaben kann. Die Gesamtzahl von Kontrolleinheiten kann darüber hinaus reduziert werden, da jede Kontrolleinheit flexiblen Zugang zu vielen Sensoren und Aktuatoren hat.

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich allgemein auf eine Architektur für elektrische Netzwerke und insbesondere auf ein Bordnetz für Fahrzeuge und andere Systeme, die einen rekonfigurierbaren Interface-Layer zwischen Sensoren/Aktuatoren und Controllern verwenden und es gestatten, dass Nachrichten von Sensoren dynamisch zu verschiedenen Controllern geleitet werden, so dass eine Gelegenheit zur Konsolidierung von Controllern angeboten und eine bessere Fehlertoleranz im Falle eines Geräteausfalls gewährleistet wird.
2. Diskussion des Standes der Technik
Moderne Fahrzeuge beinhalten eine signifikante Anzahl von elektrischen und elektronischen (E/E)-Systemen. Diese Systeme beinhalten zahlreiche Sensoren, Aktuatoren und Controller, die alles, ausgehend vom Entriegeln der Türen bis zum Regeln der Leistung von der Maschine oder der Federung, erlauben. Die verlässliche Operation von den E/E-Systemen ist sehr wichtig, da es oft keine andere Möglichkeit gibt, um eine Funktion eines Fahrzeugs auszuführen, falls ein bestimmtes E/E-System in-operativ wird.
Die Verbreitung von Sensoren, Aktuatoren und Controllern fügen einem Fahrzeug ein hohes Maß an Kosten und Komplexität zu. Herkömmliche E/E-Netzwerkarchitekturen haben nicht die Flexibilität, um Geräteausfälle ordnungsgemäß zu handhaben oder sich für die Maximierung der Leistungsfähigkeit oder zur Minimierung der Kosten anzupassen. Das liegt daran, dass in herkömmlichen Bordnetzen, Sensoren und Aktuatoren für ein bestimmtes Sub-System direkt mit einem Controller kommunizieren, der das Sub-System steuert. Im Fall eines Ausfalls eines solchen Controllers können die Steuerfunktionen des betroffenen Sub-Systems nicht von einem anderen Controller im Fahrzeug übernommen werden, da die Kommunikation mit den betroffenen Sensoren und Aktuatoren verloren gegangen ist. Darüber hinaus ist die Konsolidierung von Controllern in herkömmlichen Bordnetzen unmöglich, da individuelle Controller typischerweise keinen Zugang zu den Sensordaten von anderen Sub-Systemen haben.
Demzufolge besteht ein Bedarf für eine E/E-Netzwerkarchitektur, die eine größere Fehlertoleranz durch eine dynamische Re-Konfiguration gestattet und eine Gelegenheit für die Integration von Controllern erlaubt.
ZUSAMMENFASSUNG DER ERFINDUNG
Im Einklang mit den Lehren der vorliegenden Erfindung wird eine elektrische Netzwerkarchitektur mit einem rekonfigurierbaren Interface-Layer zusammen mit einer dazugehörigen Re-Konfigurationsmethodik offenbart. Der Interface-Layer umfasst eine Vielzahl von re-konfigurierbaren Interface-Geräten, welche einer Vielzahl von Sensoren und Aktuatoren es erlaubt, mit einer Vielzahl von Kontrolleinheiten zu kommunizieren. Jeder Sensor oder Aktuator ist mit einer Vielzahl von Schnittstellengeräten verbunden, welche wiederum mit einem Bus verbunden sind. Die Kontrolleinheiten sind darüber hinaus mit dem Bus verbunden. Im Fall von einem Ausfall eines Schnittstellengerätes können andere Schnittstellengeräte rekonfiguriert werden, um all die notwendige Kommunikation zwischen Sensoren, Aktuatoren und Kontrolleinheiten aufrecht zu halten. Im Fall von einem Kontrollgerätausfall können die Schnittstellengeräte re-konfiguriert werden, um den Sensor- und Aktuator-Nachrichtenverkehr zu einer anderen Kontrolleinheit zu leiten, die die Funktionen der ausgefallenen Kontrolleinheit behandeln kann. Die Gesamtzahl von Kontrolleinheiten kann darüber hinaus reduziert werden, da jede Kontrolleinheit flexiblen Zugang zu vielen Sensoren und Aktuatoren hat.
Weitere Merkmale der vorliegenden Erfindung werden aus der folgenden Beschreibung und den beigefügten Patentansprüchen in Verbindung mit den beigefügten Figuren offensichtlich.
KURZE BESCHREIBUNG DER FIGUREN
1 ist ein schematisches Diagram eines Bordnetzes, wie es typischerweise in den gegenwärtigen Fahrzeugen verwendet wird;
2 ist ein schematisches Diagramm eines vorgeschlagenen Bordnetzes, welches eine höhere Flexibilität und Fehlertoleranz aufweist, als die gegenwärtigen verfügbaren Bordnetze;
3 ist ein schematisches Diagram eines Bordnetzes aus der 2, das zeigt, wie eine Menge von universellen Schnittstellengeräten verwendet werden, um die Flexibilität und Fehlertoleranz bereitzustellen;
4 ist ein schematisches Diagram von einem der universellen Schnittstellengeräte aus der 3, welches zeigt, wie das Gerät interne und externe Kommunikation und Re-Konfiguration handhabt;
5 ist ein Flussdiagramm für ein Verfahren, das verwendet werden kann, um die Schnittstellengeräte in dem Bordnetz aus der 3 zu re-konfigurieren;
6 ist ein schematisches Diagramm einer anderen Ausführungsform für ein flexibles und fehlertolerantes Bordnetz aus der 2, wobei die Schnittstellengeräte drahtlos mit den ECUs kommunizieren; und
7 ist ein schematisches Diagramm einer anderen Ausführungsform eines flexiblen und fehlertoleranten Bordnetzes aus der 2, wobei die Schnittstellengeräte in den ECUs integriert sind.
DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Die folgende Diskussion der Ausführungsformen der Erfindung, die auf eine re-konfigurierbare Schnittstellen-basierende elektrische Architektur gerichtet ist, ist rein beispielhafter Natur und in keiner Weise dazu gedacht, die Erfindung oder ihre Anwendungen oder Verwendungen zu begrenzen. Beispielsweise wird die offenbarte Architektur für Fahrzeuganwendungen beschrieben, die Architektur ist jedoch gleichermaßen für Nicht-Fahrzeugsysteme anwendbar.
1 ist ein schematisches Diagramm eines Bordnetzes 10, welches typischerweise gegenwärtig in Fahrzeugen oder anderen Anwendungen verwendet wird. Das Bordnetz 10 beinhaltet Sensoren 12 und 14, einen Aktuator 16, elektronische Kontrolleinheiten (ECUs) 20 und 30 und einen Kommunikations-Bus 40. In diesem Beispiel ist der Sensor 12 direkt mit der ECU 20 verbunden, wobei die ECU 20 für die Ausführung einer Funktion, welche als Aufgabe 22 bezeichnet ist, verantwortlich ist, welche Daten von dem Sensor 12 erfordert. Ähnlich dazu sind der Sensor 14 und der Aktuator 16 direkt mit der ECU 30 verbunden, welche eine Aufgabe 32 behandelt, welche Daten von dem Sensor 14 erfordert und Befehle an den Aktuator 16 bereitstellt. Wie von einem Fachmann verstanden wird, stellen die Sensoren 12 und 14 Daten über den Zustand einer Komponente oder eines Systems bereit, beispielsweise eine Temperatur oder einen Druck, wohingegen der Aktuator 16 eine Aktion ausführt, beispielsweise das Entriegeln einer Tür oder das Anschalten einer Beleuchtung.
Es gibt zwei Hauptnachteile für das Bordnetz 10. Erstens gibt es keine Möglichkeit, beim Ausfall einer ECU die Funktion, die von der ausgefallenen ECU ausgeführt wurde, an eine andere ECU zu transferieren. Dies liegt daran, dass gerade, falls eine Ersatz-ECU dazu programmiert wurde, die Aufgabe einer ausgefallenen ECU auszuführen, die Ersatz-ECU keinen Zugang zu den Daten haben würde, die sie benötigen würde, um die Aufgabe auszuführen, da die Sensoren und/oder Aktuatoren an die ausgefallene ECU gebunden sind. Beispielsweise würde im Falle eines Ausfalls der ECU 30 die ECU 20 nicht in der Lage sein, die Aufgabe 32 auszuführen, da die ECU 20 keinen Zugang zu den Daten von dem Sensor 14 haben würde und deswegen nicht in der Lage wäre, Befehle an den Aktuator 16 abzugeben.
Der zweite Nachteil des Bordnetzes 10 ist der, dass sie keinen Anreiz dafür geben würde, ECUs wegen der gerade erwähnten fehlenden Ersatzkapazität zu kombinieren. Mit anderen Worten, Systemdesigner zögern, zu viele Funktionen auf eine individuelle ECU zu kombinieren, da all diese Funktionen im Fall eines Ausfalls dieser ECU verloren gehen würden. Diese Nachteile können mit einer flexibleren Architektur überwunden werden.
2 ist ein schematisches Diagramm für ein vorgeschlagenes Bordnetz 50, das eine höhere Flexibilität und Fehlertoleranz als die gegenwärtig verfügbaren Bordnetze bietet. In der 2 und den darauf folgenden Figuren werden ähnliche Elemente aus den vorher gegangenen Figuren mit den selben Bezugszeichen gezeigt.
Die Architektur 50 addiert einen flexiblen Interface-Layer 60 zwischen den Sensor/Aktuator-Layer und den Bus 40 hinzu. Das heißt, die Sensoren 12 und 14 und der Aktuator 16 sind mit dem flexiblen Interface-Layer 60 verbunden, welcher Daten von den Sensoren 12 und 14 an den Bus 40 und Daten von dem Bus 40 an den Aktuator 16 liefert. In dem Bordnetz 50 kommuniziert der ECU-Layer mit dem Bus 40; demzufolge können die ECUs 20 und 30 jedwede Sensordaten bekommen, die sie so lange benötigen, so lang sie auf dem Bus 40 über den Interface-Layer 60 gelegt sind. Ähnlicherweise können die ECUs 20 und 30 Befehle für jeden Aktuator auf den Bus 40 legen und der Interface-Layer 60 wird Sorge tragen, dass die Befehle an den richtigen Aktuator geliefert werden.
Das Bordnetz 50 bietet die Flexibilität, um Daten und Aufgaben an verschiedene ECUs im Falle eines ECU-Ausfalls zu leiten, so dass eine bessere Fehlertoleranz bereitgestellt wird und die Tür für eine ECU-Integration und Konsolidierung geöffnet wird. Beispielsweise können die ECUs 20 und 30 beide mit der Software programmiert werden, die notwendig ist, um die Aufgaben 22 und 32 auszuführen. Wir betrachten nun den Fall, der für das oben beschriebene Bordnetz 10 beschrieben wurde, wobei unter Normalbedingungen die ECU 20 die Aufgabe 22 mit Hilfe der Daten von dem Sensor 12 ausführt und die ECU 30 die Aufgabe 32 mit den Daten von dem Sensor 14 ausführt und Befehle an den Aktuator 16 abgibt. Wie oben im Rahmen der Diskussion des Bordnetzes 10 diskutiert wurde, gibt es bei Ausfall der ECU 30 keine Möglichkeit für die ECU 20, die Aufgabe 32 auszuführen. Im Fall des Bordnetzes 50 jedoch kann der Interface-Layer 60 bei Ausfall der ECU 30 immer noch Daten von dem Sensor 14 auf den Bus 40 legen und diese Daten an die ECU 20 leiten. Die ECU 20 kann dann die Aufgabe 32 ausführen und einen Befehlsausgang für den Aktuator 16 bereitstellen, welcher dann auf den Bus 40 gelegt wird und an den Aktuator 16 über den Interface-Layer 60 geleitet wird. In diesem Szenario führt die ECU 20 auch ihre eigene ursprüngliche Aufgabe, das heißt die Aufgabe 22, aus.
Demzufolge gewährleistet das Bordnetz 50 eine Fehlertoleranz, die mit dem Bordnetz 10 unmöglich war. Darüber hinaus stellt das Bordnetz 50 eine Gelegenheit für eine signifikante Konsolidierung in der Anzahl von ECUs dar. Beispielsweise beinhalten die meisten modernen Fahrzeuge viele Micro-Controller, die über das Fahrzeug verstreut sind, wobei jeder Micro-Controller eine Kontrollfunktion für ein gewisses Sub-System ausführt. Diese Micro-Controller können typischerweise nicht konsolidiert werden oder integriert werden, da jeder Micro-Controller nur mit den Sensoren und Aktuatoren für das spezifische Sub-System verbunden ist. Unter Verwendung des Bordnetzes 50 kann jeglicher Controller mit jeglichem Sensor oder Aktuator innerhalb des Fahrzeuges kommunizieren und jeder Controller kann in allgemeiner Weise als ein Ersatz-Backup für jeden anderen Controller dienen. Demzufolge besteht eine Gelegenheit, um etliche Sub-System-Kontrollfunktionen in eine einzelne, hoch integrierte ECU zu kombinieren, welche sowohl die Hardware-Kosten erniedrigt, als auch eine Redundanz im Ausfallfall gewährleistet.
Das Bordnetz 50 in 2 zeigt einen flexiblen Interface-Layer 60 in einer generischen Form, der als eine Art von ”Virtual-cross-bar-Schalter” dient, um den Sensor/Aktuator-Layer mit dem ECU-Layer bei Bedarf zu verbinden. Die folgende Diskussion wird verschiedene Ausführungsformen des Bordnetzes 50 beschreiben und wie die Kommunikationspfade rekonfiguriert werden, um die gewünschte Flexibilität und Fehlertoleranz bereitzustellen.
3 ist ein schematisches Diagramm eines Bordnetzes 70, das ein Ausführungsbeispiel eines flexiblen und fehlertoleranten Bordnetzes aus der 2 zeigt. In dem Bordnetz 70 besteht der flexible Interface-Layer 60 aus einer Menge von universellen Interface-Geräten, insbesondere den Interface-Geräten 72 und 74. Die Interface-Geräte 72 und 74 können jeweils konfiguriert werden, um Datennachrichten von einem oder beiden der Sensoren 12 und 14 entweder an die ECU 20 oder 30 zu leiten und Befehlsnachrichten entweder von der ECU 20 oder der ECU 30 an den Aktuator 16 zu leiten. Beispielsweise würde das Interface-Gerät 72 in einer normalen Betriebsart, das heißt wenn alle Geräte sauber arbeiten, Daten auf der Leitung 76 von dem Sensor 12 empfangen und die Daten über eine Nachricht auf den Bus 40, die bestimmt sind für die ECU 20, senden. Gleichzeitig würde das Interface-Gerät 74 Daten auf der Leitung 78 von dem Sensor 14 empfangen und die Daten über eine Nachricht auf den Bus 40, welche bestimmt ist für die ECU 30, senden. Und die ECU 30 würde die Aktuator-Befehle auf den Bus 40 legen, welche von dem Interface-Gerät 74 aufgenommen werden würden und auf der Leitung 80 an den Aktuator 16 geleitet würden.
Die Fehlertoleranz oder Ersatzkapazität kann mit Hilfe einiger Beispiele erklärt werden. Falls beispielsweise die ECU 30 ausfällt, antwortet die ECU 20 durch Senden einer Nachricht an das Interface-Gerät 74, wobei es dieses instruiert, alle Nachrichten an die ECU 20 anstelle an die ECU 30 zu leiten. Gleichzeitig wird die ECU 20 anfangen, jegliche Aufgaben, beispielsweise die Aufgabe 32, die vorher auf der ECU 30 ausgeführt wurde, auszuführen. Demzufolge werden Daten von dem Sensor 14 auf den Bus 40 über das Interface-Gerät 74 mittels einer Nachricht, die für die ECU 20 bestimmt ist, gelegt. Die ECU 20 wird die Daten von dem Sensor 14 verwenden, um die Aufgabe 32 auszuführen, und wird einen Befehl für den Aktuator 16 in einer Nachricht auf dem Bus 40 abgeben. Die Nachricht, die den Befehl für den Aktuator 16 beinhaltet, wird von dem Interface-Gerät 74 aufgenommen und an den Aktuator 16 abgeliefert. Die ECU 20 wird die Operationen, die mit der Aufgabe 32 verbunden sind, in Verbindung mit der normalen Ausführung der Aufgabe 22 ausführen.
Die Architektur 70 kann des weiteren einen Ausfall eines Interface-Geräts, wie hier veranschaulicht, behandeln. Falls beispielsweise das Interface-Gerät 72 ausfällt, wird die ECU 20 eine Nachricht an das Interface-Gerät 74 senden, um es zu instruieren, seinen Datenkanal für den Sensor 20 zu aktivieren und Daten von dem Sensor 12 an die ECU 20 zu senden. Demzufolge wird das Interface-Gerät 74 damit anfangen, Daten von dem Sensor 12 auf der Leitung 82 zu empfangen und wird diese Daten in Nachrichten, die für die ECU 20 bestimmt sind, über den Bus 40 senden. Analog dazu wird das Interface-Gerät 72, wenn das Interface-Gerät 74 ausfällt, instruiert werden, mit dem Sensor 14 und dem Aktuator 16 auf den Leitungen 84 und 86 zu kommunizieren. Im Fall eines Interface-Geräteausfalls ändert sich der Sensor/Aktuator-Kanalgebrauch und die Nachrichtenweiterleitung, aber die Aufgaben, die von den ECUs ausgeführt werden, bleiben die gleichen wie in einer normalen Betriebsbedingung.
Ein Heartbeat-Type-Ansatz kann verwendet werden, um die Detektion eines Ausfalls eines Interface-Geräts oder einer ECU zu detektieren. Der gesamte Nachrichtenverkehr zwischen dem Interface-Gerät 72 und dem Bus 40 wird auf der Leitung 90 ausgeführt und der gesamte Nachrichtenverkehr zwischen dem Interface-Gerät 74 und dem Bus 40 wird auf der Leitung 92 ausgeführt. Alle Nachrichten auf dem Bus beinhalten ein Quellgerät und ein Bestimmungsgerät in der Nachricht als solcher in einer gewöhnlichen Bus-Kummunikationsweise. Die flexible Weiterleitung von Nachrichten durch die Interface-Geräte 72 und 74 wird auf Grund von re-konfigurierbaren Nachrichtentabellen und re-konfigurierbaren Kanalverwendungstabellen bewerkstelligt, wie weiter unten diskutiert werden wird.
Es versteht sich, dass in einem vollständigen Fahrzeug oder System viel mehr Interface-Geräte, Sensoren, Aktuatoren und ECUs existieren können, als in der 3 und den anderen Bordnetzfiguren dargestellt ist. Die Geräte und Verbindungen können im Einklang zu den vorgestellten Beispielen repliziert werden. Es versteht sich des weiteren, dass ein Aktuatorgerät interne Sensoren beinhalten kann, bei welchen die Daten nicht von einem zu einem anderen Gerät fließen müssten. Darüber hinaus bezeichnet die Verwendung des Begriffs ”Leitung” in dieser Diskussion eine logische Verknüpfung zwischen zwei Geräten und ist nicht dazu gedacht, einen einzelnen physikalischen ”Draht” zu bedeuten. Diese Ausführungen werden von Fachleuten bei Bordnetzen gut verstanden.
4 ist ein schematisches Diagramm für das Interface-Gerät 72 aus der 3, das zeigt, wie das Gerät 72 interne und externe Kommunikation und Re-Konfiguration handhabt. Das Interface-Gerät 72 beinhaltet einen Kommunikations-Controller 100, welcher die Drehscheibe für die internen und externen Kommunikationen ist. Das Interface-Gerät 72 beinhaltet darüber hinaus Eingangskanäle 102 und 104, welche Analog/Digital-Wandler oder andere Arten von Eingangskanälen sein können. Der Eingangskanal 102 empfängt Daten von dem Sensor 12 auf der Leitung 76, wie in der 3 gezeigt. Der Eingangskanal 104, falls er verwendet wird, empfängt Daten von dem Sensor 14 auf der Leitung 84, was in der 3 und in der vorhergehenden Diskussion aufgezeigt wurde. Das Interface-Gerät 72 beinhaltet einen Ausgangskanal 106, welcher ein Pulsweiten-modulierter Treiber (PWM) oder eine Art von anderem Ausgangskanal sein kann. Der Ausgangskanal 106 stellt Befehle an den Aktuator 16 auf der Leitung 86, sofern er verwendet wird, bereit, was in der 3 und in der vorhergehenden Diskussion aufgezeigt wurde.
Die Eingangskanäle 102 und 104 und der Ausgangskanal 106 kommunizieren mit dem Kommunikations-Controller 100, welcher wiederum mit dem Bus 40 über die Leitung 90 kommuniziert, was in der 3 gezeigt ist. Der Kommunikations-Controller 100 kann programmiert sein, um mit dem Bus 40 über irgendein gewünschtes Protokoll, beispielsweise das Controller Area Network(CAN)-Protokoll. Das Interface-Gerät 72 beinhaltet eine re-konfigurierbare Nachrichtentabelle 108 und eine rekonfigurierbare Kanalverwendungstabelle 110. Die Nachrichtentabelle 108 weist eine Liste auf, welche Nachrichten von dem Sensor/Aktuator-Layer zu dem ECU-Layer abbildet und umgekehrt. Beispielsweise würde die Nachrichtentabelle 108 unter Normalbedingungen einen Eintritt aufweisen, der indiziert, dass Daten von dem Sensor 12 an die ECU 20 gesendet werden müssen. Demzufolge würde der Kommunikations-Controller 100 Daten vom Sensor 12 nehmen, welche auf dem Eingangskanal 102 empfangen werden, würde diese Daten in eine Nachricht, die für die ECU 20 bestimmt ist, eng codieren und die Nachricht auf den Bus 40 über die Leitung 90 legen. Falls die ECU 20 ausfällt, würde die ECU 30 eine Nachricht an das Interface-Gerät 72 senden, die indiziert, dass die Nachrichtentabelle 108 re-konfiguriert werden sollte, um Daten von dem Sensor 12 zu der ECU 30 abzubilden.
Die Kanalverwendungstabelle 110 zeigt eine Liste, welche Eingangs- und Ausgangskanäle von dem Interface-Gerät 72 verwendet werden müssen, welche Sensor- oder Aktuator-Geräte dem jeweiligen Kanal zugeordnet sind und die Refresh- oder Abtastrate für jeden Sensor oder Aktuator. Beispielsweise würde unter Normalbedingungen die Kanalverwendungstabelle 110 in dem Interface-Gerät 72 anzeigen, dass der Eingangskanal 102 aktiv ist und mit dem Sensor 12 verbunden ist. Der Eingangskanal 104 und der Ausgangskanal 106 wären inaktiv unter Normalbedingungen und diese Information würde auch in der Kanalverwendungstabelle 110 enthalten sein. Im oben diskutierten Beispiel würde das Interface-Gerät 72 eine Nachricht erhalten, welche es instruiert, den Eingangskanal 104 an den Sensor 14 zu aktivieren und den Ausgangskanal 106 an den Aktuator 16, falls das Interface-Gerät 74 ausfällt. Die Abtast- und Refresh-Raten würden darüber hinaus respektive ebenfalls bereitgestellt. Diese Information würde in der Kanalverwendungstabelle 110 abgespeichert werden. Die Kanalverwendungstabelle 110 erlaubt es in Verbindung mit der Nachrichtentabelle 108 dem Kommunikations-Controller 100, in dem Interface-Gerät 72 die Verwendung von Eingangs- und Ausgangskanalverwendung zu managen und sauber Nachrichten zu und von dem Bus 40 zu leiten. Die Re-Konfigurabilität des Interface-Geräts 72 stellt demnach die Flexibilität und Fehlertoleranz, die in dem Interface-Gerät 60 benötigt wird, wie oben diskutiert, bereit.
Die ECUs 20 und 30 müssen in der Lage sein, Nachrichten an das Interface-Gerät 72 zu senden, um die Nachrichtentabelle 108 und die Kanalverwendungstabelle 110 je nach Anforderung zu re-konfigurieren. Die Logik für die Re-Konfigurationsnachrichten kann in einer Re-Konfigurationsstrategietabelle (nicht gezeigt) abgelegt sein, welche anzeigt, welche Aktion bei Ausfall eines bestimmten Gerätes unternommen werden soll. Beispielsweise würde die ECU 30, falls das Interface-Gerät 74 ausfällt, wie oben erörtert, Nachrichten an das Interface-Gerät 72 senden, um das Interface-Gerät 72 zu instruieren, den Eingangskanal 104 zu aktivieren, den Ausgangskanal 106 zu aktivieren, Daten von dem Sensor 14 an die ECU 30 zu leiten und Daten von der ECU 30 an den Aktuator 16 zu leiten. Die ersten zwei dieser Nachrichten würden auf die Kanalverwendungstabelle 110 angewendet werden, wohingegen die letzten zwei Nachrichten auf die Nachrichtentabelle 108 angewendet werden würden. Die Re-Konfigurationsstrategietabelle in den ECUs 20 und 30 würde auch die Re-Konfigurationsantworten aufweisen, die für jedwede Art von Ausfallsituation notwendig wären. Darüber hinaus ist auch die Verwendung einer Ausfallwicht-Antwort-Interface-Gerätekonfigurationsstrategie zu verwenden. Beispielsweise kann das Interface-Gerät 24 instruiert sein, die Kommunikation einzustellen, falls das Interface-Gerät 74 ausfällt, um falsche Nachrichten auf dem Bus 40 zu vermeiden.
Es ist anmerkenswert, dass die oben erwähnte Re-Konfigurationsstrategie effizienter ist als ein Redundanz-basierender Ansatz, bei dem die Interface-Geräte 72 und 74 immer alle Daten von allen verbundenen Sensoren und Aktuatoren senden und empfangen. Zum einen können unter Verwendung der Re-Konfigurationsstrategie beide Interface-Geräte 72 und 74 nicht benötigte Eingangs- und Ausgangskanäle inaktiv halten, was Leistung spart. Zweitens minimiert die Verwendung der Re-Konfigurationsstrategie den Nachrichtenverkehr auf dem Bus 40. Beispielsweise gäbe es vier Nachrichten auf dem Bus 40 für jedes Bus-Zeitsegment, falls beide Interface-Geräte 72 und 74 Daten von beiden Sensoren 12 und 14 empfangen würden und diese auf Daten auf dem Bus 40 legen würden. Andererseits gibt es bei Verwendung der Re-Konfigurationsstrategie nur zwei Sensordatennachrichten auf dem Bus 40 und dies ist unter normalen Betriebsbedingungen wahr, wo beide Interface-Geräte 72 und 74 die selbe Nachricht auf den Bus transmittieren und in einer Ersatzsituation, wo beispielsweise das Interface-Gerät 72, welches ausgefallen ist, ruhig ist und das Interface-Gerät 74 zwei Nachrichten (jeweils eine für den Sensor 12 und den Sensor 14) auf den Bus 40 transmittiert.
5 ist ein Flussdiagramm 120 für ein Verfahren, das dazu verwendet werden kann, Geräte in dem Bordnetz 70 der 3 im Fall eines Interface-Geräteausfalls oder eines ECU-Ausfalls zu re-konfigurieren. Das Verfahren beginnt mit den Interface-Geräten 72 und 74 und den ECUs 20 und 30 im Normalbetrieb. Im Kasten 122 wird der Betrieb der Geräte überwacht. In der Entscheidungsraute 124 wird bestimmt, ob es einen ECU-Ausfall gegeben hat. Falls es einen ECU-Ausfall gegeben hat, geht das Verfahren zu der Entscheidungsraute 126, wobei bestimmt wird, ob es einen Interface-Geräteausfall gegeben hat.
Wenn es keinen Interface-Geräteausfall gegeben hat, geht das Verfahren zurück zur Überwachung im Kasten 122.
Falls ein ECU-Ausfall detektiert wird, verzweigt das Verfahren von der Entscheidungsraute 124 zum Kasten 128, wobei eine arbeitende ECU Interface-Geräte-Re-Konfigurationsnachrichten sendet. Nehmen wir den Fall an, dass die ECU 20 ausfällt. Im Kasten 128 sendet die ECU, die immer noch arbeitet, das ist in diesem Fall die ECU 30, eine Nachricht an das Interface-Gerät 72, um es zu instruieren, seine Nachrichtentabelle zu re-konfigurieren, um an die ECU 30 diejenigen Nachrichten zu leiten, die vorher an die ECU 20 geleitet wurden. Im Kasten 130 empfängt das Interface-Gerät 72 die Instruktion von der ECU 30 und re-konfiguriert seine Nachrichtentabelle, um Daten von dem Sensor 12 an die ECU 30 zu leiten. Im Kasten 132 startet die ECU 30 die Ausführung jeglicher Aufgaben von der ausgefallenen ECU 20, in diesem Fall beispielsweise die Aufgabe 22. Nach Ausführung der Re-Konfigurationsschritte der Kästen 128–132 kann die Netzwerkoperation mit voller Funktionalität weitergehen und das Verfahren geht zurück zum Überwachen in dem Kasten 122.
Falls ein Interface-Geräteausfall detektiert wird, geht das Verfahren aus der Entscheidungsraute 126 in den Kasten 134, wobei eine ECU Nachrichten sendet, um ein Interface-Gerät, welches immer noch arbeitet, zu re-konfigurieren. Nehmen wir den Fall an, dass das Interface-Gerät 72 ausgefallen ist. Im Kasten 134 sendet eine der ECUs, beispielsweise die ECU 20, Nachrichten an das Interface-Gerät, das immer noch arbeitet, nämlich das Interface-Gerät 74, um es zu instruieren, seine Kanalverwendungstabelle und seine Nachrichtentabelle zu rekonfigurieren. Im Kasten 136 würde das Interface-Gerät 74 seine Kanalverwendungstabelle und seine Nachrichtentabelle nach den Instruktionen aus der ECU 20 im Kasten 134 rekonfigurieren. In diesem Beispiel würde das Interface-Gerät 74 seine Kanalverwendungstabelle re-konfigurieren müssen, um den Kanal, der den Sensor 12 auf die Leitung 82 verbindet, zu aktivieren und das Interface-Gerät 74 würde seine Nachrichtentabelle re-konfigurieren müssen, um Nachrichtendaten von dem Sensor 12 an die ECU 20 zu leiten. Nach Ausführung der Re-Konfigurationsschritte der Kästen 134–136 kann die Netzwerkoperation mit voller Funktionalität weitergehen und das Verfahren geht zurück zur Überwachung in dem Kasten 122.
Es versteht sich wiederum, dass das Verfahren aus dem Flussdiagramm 120 auf ein E/E-Netzwerk angewendet werden kann, welches mehr als zwei Interface-Geräte und zwei ECUs aufweist. In einem größeren Netzwerk könnte das Verfahren nach einer Re-Konfiguration weiter ausgeführt werden und zusätzliche Re-Konfigurationen könnten ausgeführt werden im Falle, dass eine andere ECU oder ein anderes Interface-Gerät ausfallen würde.
6 ist ein schematisches Diagramm für ein Bordnetz 140, das eine andere Ausführungsform für ein flexibles und fehlertolerantes Bordnetz aus der 2 zeigt. In dem Bordnetz 140 werden die Interface-Geräte 142 und 146 jeweils mit Drahtlos-Transceivern 144 und 148 ausgestattet. Analog dazu sind die ECUs 150 und 154 mit Drahtlos-Transceivern 152 und 156 jeweils ausgestattet. Demzufolge können die Interface-Geräte 142 und 146 drahtlos mit den ECUs 150 und 154 kommunizieren und die Notwendigkeit für physische Drahtverbindungen zwischen diesen entfällt. Diese Anordnung bietet einige Design- und Packaging-Flexibilität, so zum Beispiel das Positionieren der Interface-Geräte 142 und 146 in optimaler Weise auf den Sensor- und Aktuator-Plätzen, welche entfernt zu den optimalen Plätzen für die ECUs 150 und 154 sein können.
In dieser Ausführungsform würde jeder der Interface-Geräte-Drahtlos-Transceiver 144 und 148 in der Lage sein müssen, mit den ECU-Drahtlos-Transceivern 152 und 156 zu kommunizieren, um die oben diskutierte Ersatzflexibilität anzubieten. Das bedeutet beispielsweise, falls die ECU 150 ausfällt, dass das Interface-Gerät 142 in der Lage sein muss, drahtlos mit der ECU 154 zu kommunizieren, um die Systemleistung aufrecht zu erhalten. Falls ein Interface-Gerät ausfällt, könnte das verbleibende funktionale Interface-Gerät direkt mit beiden ECUs kommunizieren oder es könnte mit nur einer ECU kommunizieren, welche Nachrichten für die andere ECU auf den Bus 40 legen könnte.
7 ist ein schematisches Diagramm einer Architektur 160, die eine andere Ausführungsform für ein flexibles und fehlertolerantes Bordnetz aus der 2 zeigt. In der Architektur 160 beinhaltet die ECU 170 ein integriertes Interface-Gerät 172 und einen Micro-Controller 174. Das Interface-Gerät 172 kann mit den Sensoren 12 und 14 und dem Aktuator 16 kommunizieren und darüber hinaus mit dem Bus 40 kommunizieren. Das Interface-Gerät 172 beinhaltet eine re-konfigurierbare Nachrichtentafel und eine re-konfigurierbare Kanalverwendungstafel, wie oben schon erörtert, für das Interface-Gerät 72 in dem Bordnetz 70. Analog dazu beinhaltet die ECU 180 ein integriertes Interface-Gerät 182 und einen Micro-Controller 184. In dieser Ausführungsform vollführen die Micro-Controller 174 und 184 die Funktionen, die den ECUs in den vorhergehenden Ausführungsformen zugeordnet waren, wohingegen die ECUs 170 und 180 als eine Integrationsplattform mit den Interface-Geräten dienen.
In gleicher Art und Weise wie oben diskutiert können die Interface-Geräte 172 und 182 durch ihre Nachrichtentabellen und Kanalverwendungstabellen konfiguriert werden, um je nach Notwendigkeit mit den Sensoren 12 und 14, dem Aktuator 16 und den Micro-Controllern 174 und 184 zu kommunizieren. Beispielsweise würde das Interface-Gerät 172 Daten von dem Sensor 12 unter Normalbedingungen empfangen und die Daten direkt an den Micro-Controller 174 bereitstellen. Falls das Interface-Gerät 172 ausfallen würde, würde der Micro-Controller 184 eine Nachricht an das Interface-Gerät 182 senden, um es zu instruieren, seinen Ausgangskanal für den Sensor 12 zu aktivieren und Daten des Sensors 12 an den Micro-Controller 184 abzugeben. Gleichzeitig würde der Micro-Controller 184 damit beginnen, die Aufgaben, die vorher von dem Micro-Controller 174 ausgeführt worden sind, auszuführen. Es ist auch möglich, auf einer Kanal-für-Kanal-Basis zu re-konfigurieren. Beispielsweise kann das Interface-Gerät 172 die Kommunikation mit dem Sensor 12 auf Grund eines Ausfalls eines individuellen Drahts oder Verbinders verlieren. Sofern aber das Interface-Gerät 72 immer noch einsatzfähig ist, können die Daten von dem Sensor 12 durch das Interface-Gerät 182 auf den Bus 40 und durch das Interface-Gerät 172 an den Micro-Controller 174 weitergeleitet werden, welcher immer noch seine Aufgabe ausführen könnte unter Verwendung der Daten von dem Sensor 12. Ähnliche Re-Konfigurationsstrategien können leicht vergegenwärtigt werden, um einen Ausfall der Micro-Controller 174 oder 184 oder der gesamten ECU 170 oder 180 abzuarbeiten.
Durch Bereitstellen eines re-konfigurierbaren Interface-Layers zwischen dem Sensor/Aktuator-Layer und dem ECU-Layer und dabei dem Entkoppeln der Sensoren und Aktuatoren von den ECUs bietet jede der Bordnetz-Architekturen, die oben diskutiert wurden, Flexibilität und Fehlertoleranz, die in herkömmlichen Bordnetzen nicht verfügbar ist. Diese Fähigkeiten befähigen eine Komponentenintegration, Kostenreduktion und Verbesserung in der Verlässlichkeit und bieten eine Möglichkeit für Hersteller von Fahrzeugen und anderen Systemen, welche extensiven Gebrauch von vernetzten elektrischen oder elektronischen Geräten machen.
Die vorhergehende Diskussion offenbart und beschreibt rein beispielhafte Ausführungsformen der vorliegenden Erfindung. Ein Fachmann wird leicht aus dieser Diskussion und aus den beigefügten Figuren und Patentansprüchen erkennen, dass verschiedene Änderungen, Modifikationen und Variationen ausgeführt werden können, ohne dabei den Geist und den Schutzbereich der Erfindung, wie er in den folgenden Patentansprüchen definiert wird, zu verlassen.

Claims

Ein automatisch re-konfigurierbares elektrisches Netzwerk für ein System, wobei das Netzwerk umfasst: – eine Vielzahl von Sensoren und Aktuatoren, wobei die Sensoren Parameter des Systems messen und die Aktuatoren eine Handlung in dem System ausführen; – zwei oder mehr elektronische Kontrolleinheiten (ECUs) zum Verarbeiten von Daten von den Sensoren und zum Erlassen von Befehlen an die Aktuatoren; – zwei oder mehr Interface-Geräte zum Verbinden der Sensoren und Aktuatoren an die ECUs, wobei die Interface-Geräte Software-re-konfigurierbar sind, um die Konnektivität zu modifizieren; und – ein Kommunikations-Bus zum Tragen von Nachrichten zwischen den Interface-Geräten und den ECUs.
Netzwerk nach Anspruch 1, wobei die ECUs das Netzwerk überwachen, um einen ECU-Ausfall oder einen Interface-Geräteausfall zu detektieren.
Netzwerk nach Anspruch 1, wobei jede der ECUs konfiguriert ist, um Aufgaben ausführen zu können, die normalerweise auf den anderen ECUs laufen.
Netzwerk nach Anspruch 1, wobei jedes der Interface-Geräte einen Kommunikations-Controller, eine rekonfigurierbare Kanalverwendungstabelle und eine rekonfigurierbare Nachrichtentabelle beinhaltet.
Netzwerk nach Anspruch 4, wobei die Kanalverwendungstabelle für jedes der Interface-Geräte durch einen Befehl von einer der ECUs re-konfiguriert werden kann, um Eingangs- und Ausgangskanalaktivität zu modifizieren.
Netzwerk nach Anspruch 5, wobei die Kanalverwendungstabelle für eine der Interface-Geräte re-konfiguriert ist, falls eines der anderen Interface-Geräte ausfällt.
Netzwerk nach Anspruch 4, wobei die Nachrichtentabelle für jedes der Interface-Geräte durch einen Befehl von einer der ECUs re-konfiguriert werden kann, um Nachrichtenquellgerät-Identifizierer und Nachrichtenbestimmungsgerät-Identifizierer zu modifizieren.
Netzwerk nach Anspruch 7, wobei die Nachrichtentabelle für eines der Interface-Geräte re-konfiguriert ist, falls eine der ECUs ausfällt.
Netzwerk nach Anspruch 4, wobei der Kommunikations-Controller in jedem der Interface-Geräte eine Information in der Kanalverwendungstabelle und der Nachrichtentabelle verwendet, um Nachrichten von den Sensoren an die ECUs und von den ECUs an die Aktuatoren zu leiten.
Netzwerk nach Anspruch 1, wobei das System ein Fahrzeug ist.