AT510121A1 - Sternkoppler für controller area network (can) - Google Patents

Description

Sternkoppler für Controller Area Network (CAN)

Zitierte Patente: [1] DE 19951 261 Optischer Stemverteiler für Kollisionserkennende Busarchitekturen (CAN-HUB oder Device-Net-HUB) [2] US 2001/0004751 Decoupling Unit for Bus Systems [3] EP 1 052 760 CAN-Bus-System mit bei Störungen automatisch abschaltbaren Teilnetzen [4] GB 2 382 508 Segmented Controller area network bus for an automobile [5] US 2008/0186870 Controller Area Network Condition Monitoring and Bus Health on In-Vehicle Communication Networks

Sonstige Literatur: [6] M. Barranco, J. Proenza, G.R. Navas, L. Almeida. An Active Star Topology for Improving Fault Confinement in CAN Networks. IEEE TRANSACTIONS ON INDUSTRIAL INFOR-MATICS, VOL. 2, NO. 2, MAY 2006.

Technisches Umfeld:

Der Standard „Controller Area Network“ (CAN) wird in zahlreichen Applikationsdomänen (z.B. Automobilindustrie, Flugzeugindustrie, Industrieautomatisierung) für asynchrone Feldbussysteme verwendet, CAN bietet die Grundlage für die Vernetzung von Steuergeräten und Sensoren/Aktuatoren wobei typisch bis zu 64 Teilnehmer am CAN-Bus betrieben werden. CAN funktioniert nach dem Multi-Master-Prinzip und Kollisionen auf dem asynchronen Bus werden durch Arbitrierung nach dem Verfahren „Carrier Sense Multiple Access/Collision Avoidance“ (CSMA/CA) aufgelöst.

Vorteile des CAN-Standards liegen in dessen Einfachheit, dem dezentralen Aufbau und den geringen Kosten für CAN-Controller und Verkabelung. Heutige Fahrzeuge enthalten beispielsweise mehrere CAN-Busse für Applikationssubsysteme wie Antriebsstrang, Infotainment oder Komfortfunktionen.

Hintergrund dieser Erfindung: CAN besitzt technische Einschränkungen in Bezug auf Zuverlässigkeit, Diagnose und Ska-lierbarkeit. Eine Einschränkung der Zuverlässigkeit ist das Fehlen geeigneter Mechanismen zur Fehlerisolation bei „Babbüng Idiot Failures“. Ein fehlerhaftes CAN-Steuergerät kann durch das permanente Versenden hoch-priorer Nachrichten die Kommunikationsfahigkeit der anderen Steuergeräte beeinträchtigen. Daher unterstützt ein einzelner CAN-Bus nicht die Konstruktion eingebetteter Systeme, in welchen das korrekte Funktionieren des Kommunikationssystems für Safety erforderlich ist. Zudem kann eine fehlerhaft gesendete Absenderadresse von anderen Busteilnehmem im allgemeinen nicht als fehlerhaft erkannt werden. Ein weiterer Nachteil ist die Einschränkung der maximalen Buslänge und der Bandbreite (z.B. 1 Mbit/s bei 40 m).

Bestehende Patente [1,2] schlagen Lösungen zur Verbesserung der Zuverlässigkeit von CAN-Netzwerken auf Bit-Ebene vor. Diese Patente isolieren Steuergeräte bzw. deren Kommunikation um ein permanentes dominantes Bussignal zu unterbinden. Durch diesen Ansatz auf Bitebene werden jedoch zahlreiche Fehlerarten nicht behandelt (z.B. Verletzung von minimalen Nachrichtenzwischen-ankunftszeiten, Konflikte in der Verwendung der CAN-Identifier). Die vorliegende Erfindung bietet Fehlerisoiation für diese Fehlerarten.

Die Patente [3] und [4] unterstützen das Abschalten von Subnetzen durch eine überwachende Steuereinheit. Im Vergleich zur vorliegenden Erfindung erlaubt dieser Ansatz keine effizientere Nutzung der Bandbreite oder Konversionen zwischen CAN-Identifiers, Im Gegensatz zu [3] und [4] bietet die vorliegende Erfindung zudem die Entkopplung der CAN-Segmente durch einen MPSoC und nennt Maßnahmen zur Fehlerisoiation und Überwachung.

[5] schlägt einen „CAN Health Index“-Monitor vor, welcher im Gegensatz zur vorliegenden Erfindung auf Diagnosefunktionen eingeschränkt ist.

Neben den erwähnten Patenten existieren Publikationen für Fehlerisolation in CAN durch Stemtopo-logien. [6] schlägt eine Lösung für bestimmte Fehlerarten vor (z,B, stuck-at-node fault, shorted medium). Zahlreiche wichtige Fehlerarten, welche durch die vorliegende Erfindung behandelt werden (z.B. Babbling-Idiot-Fehler, Konflikte bei CAN-Identifiers), können jedoch durch [6] nicht isoliert werden. Außerdem schränkt die quasi-gleichzeitige Sicht auf jedes Bit das Überwinden der CAN-Limitationen ein.

Die vorliegende Erfindung besteht aus einem Sternkoppler für CAN, welcher Einschränkungen des CAN-Standards überwindet und gleichzeitig die Kompatibilität zu existierenden CAN-Steuergeräten beibehält. Bei Verwendung des Stemkopplers wird die Bustopologie konventioneller CAN-Netzwerke durch eine Stemtopologie ersetzt. Der Stemkoppler erhöht die Ska-lierbarkeit durch bessere Bandbreitennutzung, eine höhere maximale Gesamtkabellänge und mehrere Namensräume. Die bessere Bandbreitennutzung entsteht durch das selektive Multicasting von Nachrichten zu jenen Steuergeräten welche eine bestimmte Nachricht benötigen. Durch die Stemtopologie sind individuelle physikalische Leitungen kürzer im Vergleich zur Bustopologie. Der Stemkoppler konvertiert Nachrichten-Tdentifier um mehrere Namensräume zu bieten. Gleichzeitig unterstützt der Stemkoppler Transformationen des Nachrichteninhalts unter Beibehaltung der semantischen Information. Ein Beispiel ist ein CAN-Steuergerät, welches eine CAN-Nachricht mit einem Temperaturwert in Grad Celsius versendet, wobei die Messung der Temperatur zu einem definierten Zeitpunkt und einem definierten Ort der Umgebung stattgefunden hat, Der Stemkoppler verändert die Nachricht mit einer Transferfunktion, indem der CAN-Identifier des sendenden CAN-Steuergeräts auf den erwarteten CAN-Identifier der empfangenden CAN-Steuergeräte übersetzt wird. Zudem werden Transformationen des Nachrichten-Inhalts vorgenommen, z.B. zur Konversion des Temperaturwerts in Grad Fahrenheit. Der semantische Inhalt (d.h. physikalische Größe Temperatur mit Ort und Zeit der Messung) bleibt dabei unverändert. Fehlerisolation entsteht durch das Blockieren fehlerhafter Nachrichten (z.B. bei Verletzung der spezifizierten Nachrichtenzwischenan-kunftszeiten).

Wirtschaftliche Vorteile:

Der Markt für CAN-basierte Anwendungen ist gerade im Automobil-Bereich bedeutend. Durch die Überwindungen der erwähnten Einschränkungen von CAN in Bezug auf Zuverlässigkeit, Diagnose und Skalierbarkeit ergeben sich folgende wirtschaftliche Vorteile: • Reduktion der Integrationskosten: Der Stemkoppler unterstützt strikte Kontrolle über die Interaktionen zwischen Steuergeräten (z.B. Nachrichtenzwischenankunflszei-ten, Nachrichtenidentifier). Hierdurch wird der Integrationsaufwand reduziert, da die Auswirkungen eines zusätzlichen Steuergeräts auf bereits integrierte Steuergeräte eingeschränkt werden. • Verbesserung der Robustheit des Gesamtsystems: Durch die Fehlerisolation zwischen Steuergeräten wird verhindert, dass der lokale Fehler eines Steuergeräts zum globalen Versagen des Gesamtsystems fuhrt. Diese Eigenschaft reduziert Wartungskosten und erhöht die Kundenzufriedenheit. • Neue Applikationsfunktionen auf Basis von CAN: Der Stemkoppler gestattet die Konstruktion von Applikationsfunktionen auf Basis von CAN, welche ohne den Stemkoppler aufgrund von Zuverlässigkeits- und Bandbreitenanforderungen nicht möglich wären. Insbesondere im Automobilbereich weisen Netzwerke auf Basis von CAN deutlich geringere Kosten auf als andere Netzwerk-Standards (z.B. FlexRay) mit höherer Zuverlässigkeit und Bandbreite.

Zusammenfassung:

Der Standard „Controller Area Network“ (CAN) bietet eine einfache und kostensparende Lösung zur Vernetzung von Steuergräten in zahlreichen Applikationsdomänen. Die Verwendung von CAN ist jedoch durch Einschränkungen in Bezug auf Fehlerisolation, Bandbreite, Kabellänge, Namensräume und Diagnose limitiert. Diese Erfindung beschreibt eine Lösung um diese Einschränkungen durch einen CAN-Stemkoppler auf Grundlage eines Multi-Processor Systems-on-a-Chip (MPSoC) zu überwinden. Der Stemkoppler erkennt und isoliert fehlerhafte Steuergeräte im Wert- und Zeitbereich. Im Zeitbereich überwacht der Stemkoppler die Nachrichtenhäufigkeit und stellt sicher, dass Knoten eine minimale Nachrichtenzwischenan-kunftszeit einhalten. Im Wertebereich wird garantiert, dass die CAN-Identifier der von einem Steuergerät gesendeten Nachrichten in einer Menge gültiger CAN-Identifier enthalten sind, welche für jedes Steuergerät individuell definiert wurden. CAN-Identifier werden vom Stemkoppler übersetzt sodass mehrere Steuergeräte Nachrichten mit dem gleichen CAN-Identifier senden können ohne Kollisionen am CAN-Netzwerk zu bewirken. Ein Management-Port dient zum Auslesen von Diagnoseinformationen und zum Verändern der Konfiguration des Stemkopplers.

KURZE BESCHREIBUNG DER ABBILDUNGEN

Das vorab beschriebene Ziel und andere neue Eigenschaften der vorliegenden Erfindung werden an Hand der angeführten Abbildungen erläutert.

Fig. 1 zeigt den Aufbau und die Struktur eines Sternkopplers der Nachrichten zwischen unterschiedlichen CAN-Segmenten vermittelt.

Fig. 2 zeigt den inneren Aufbau des Schnittstellensubsystems für ein CAN-Segment.

BESCHREIBUNG EINER REALISIERUNG

Im folgenden Abschnitt wird eine mögliche Realisierung des neuen Verfahrens an einem Beispiel mit 6 CAN-Segmenten und einer Anzahl an CAN-Steuergeräten gezeigt. Dieses Beispiel zeigt eine konkrete von vielen möglichen Realisierungen des in den Patentansprüchen beschriebenen Verfahrens,

Fig. 1 zeigt eine Konfiguration mit einem Stemkoppler (101), der seinerseits über 6 Schnittstellen (111, 112, 113, 114, 115, 116) zur Verarbeitung von CAN-Nachrichten verfugt. Auf diesen Schnittstellen - im folgenden CAN-Ports genannt - kann der Stemkoppler Nachrichten aus den dazugehörigen CAN-Segmenten (121, 122, 123, 124, 125, 126) empfangen, diese verarbeiten und an ein oder mehrere entsprechende CAN-Segmente weiter leiten. Zu beachten ist, dass zum Verarbeiten der Nachrichten für jedes CAN-Segment in dem als MPSoC realisierten Sternkoppler eine dezidierte Hardwareeinheit (200) - im folgenden Schnittstellensubsystem genannt - zur Verfügung steht. Die Schnittstellensubsysteme sind untereinander durch ein Network-on-a-Chip (NoC) (241) verbunden.

Jedes CAN-Segment (121-126) kann seinerseits aus einem oder mehreren CAN-Steuergeräten bestehen (131, 132, 133, 134, 135, 136, 137, 138). In dem gezeigten Beispiel beinhaltet das CAN-Segment (121) drei CAN-Steuergeräten (131, 132, 133), wobei beispielsweise das CAN-Segment (122) aus nur einem CAN-Steuergeräten (134) besteht. CAN-Segmente die aus wenigen, idealerweise nur einem CAN-Steuergerät bestehen, erhöhen die Fehlerisolationseigenschaften des Stemkopplers. Die CAN-Segmente sind mit den CAN-Ports über einen durch das CAN-Protokoll spezifizierten Bus (141, 142, 143, 144, 145, 146) verbunden. Zusätzlich beinhaltet der Stemkoppler eine Diagnose- und Konfigurationsschnittstelle (151) die über eine Verbindung (161) mit dem Ethemet-Protokoll mit einer Diagnose- und Konfigurationseinheit (171) verbunden ist. Einerseits werden in der Diagnose- und Konfigurationseinheit Diagnosenachrichten vom Stemkoppler empfangen und ausgewertet (z.B,: Visualisierung von Nachrichtenfehlverhalten auf der zeitlichen Ebene), andererseits ist es möglich über den Konfigurationsteil der Einheit eine neue Konfiguration einzuspielen, die im folgenden Verlauf das Vermittlungsverhalten des Stemkopplers anpasst.

Fig. 2 zeigt den internen Aufbau eines Schnittstellensubsystems. Jedes Schnittstellensubsystembesteht aus einem Prozessor (201), einem CAN-Controller (221), Warteschlangen mit Nachrichten zwischen Prozessor und CAN-Controller (212, 213), SchnittstelJenlogik (231) und Nachrichtenpufler (242,243,244,245) zum NoC.

Die Abarbeitung von CAN-Nachrichten erfolgt im Block 201. Er selbst unterteilt sich in eine Recheneinheit (202), die die Abarbeitung von Nachrichten koordiniert und eine Filtereinheit (203), die eingehende Nachrichten prüft und entsprechend verarbeitet. Die zu prüfenden Ei- genschaften einer Nachricht sind in einer internen Datenstruktur (204) gespeichert. Noch nicht weitergeleitete Nachrichten werden in einer Warteschlange (205) im Schnittstellensubsystem zwischengespeichert.

Die Abarbeitung von Nachrichten gliedert sich prinzipiell in zwei Teile: • Empfang einer neuen Nachricht aus einem CAN-Segment und Weiterleitung in das NoC. Dies entspricht in Fig. 2 einem Fluss von links nach rechts. • Empfang einer Nachricht aus dem NoC und Weiterleitung dieser Nachricht an das Ziel-CAN-Scgment. ln Fig. 2 entspricht dies einem Fluss von rechts nach links.

Beide Teile der Verarbeitung w'erden nachfolgend erläutert:

Bevor eine Verarbeitung stattfindet, muss eine Nachricht die CAN-Schnittstelle (211) passieren. Pro Verarbeitungszyklus prüft der Stemkoppler ob der CAN-Controller (221) eine Nachricht von einem seiner CAN-Steuergeräte empfangen hat. Ist dies der Fall, so wird die Nachricht aus dem Speicher (213) des CAN-Controllers in den internen Speicher der CPU (202) geladen. Ab diesen Zeitpunkt erfolgt die Überprüfung und Verarbeitung der neuen Nachricht. Es wird überprüft ob die neue Nachricht ihre minimale Zwischenankunftszeit verletzt, also ob Nachrichten mit dem gleichen CAN-Identifier zu schnell hintereinander gesendet wurden. Zu diesem Zweck wird die aktuelle Ankunftszeit mit dem Zeitpunkt verglichen an dem eine Nachricht mit dem gleichen CAN-Identifier empfangen wurde. Unterschreitet die Differenz aus der aktuellen Zeit und dem Zeitpunkt des letzten Empfangs ein konfigurierbares Minimum, wird die aktuelle Nachricht nicht weiter verarbeitet. Die Verletzung der minimalen Zwischenankunftszeit wird an die Konfigurations- und Diagnoseeinheit (171) gemeldet. Ist die Eigenschaft der minimalen Zwischenankunftszeit nicht verletzt, wird der Zeitstempel des letzten Empfangs einer Nachricht mit diesem CAN-Identifier aktualisiert. Im Weiteren wird in der internen Datenstruktur (204) geprüft, ob der aktuelle CAN-Identifier durch einen anderen CAN-Identifier ersetzt werden soll. Ist dies der Fall, wird eine Namensübersetzung durchgeführt. Falls in der internen Datenstruktur eine Transferfunktion für den CAN-Identifier vorliegt (d.h., Abbildung von 8 Byte Applikationsdaten auf 8 Byte Applikationsdaten), wird zudem die Transferfunktion auf den Nachrichteninhalt angewendet. Der letzte Schritt beim Weiterleiten der Nachricht in das NoC beinhaltet die Auflösung des aktuellen CAN-Identifiers zu seinen entsprechenden Ziel-CAN-Segmenten. Eine Nachricht kann zu mindestens einem, maximal zu allen CAN-Segmenten weitergeleitet werden. Schlägt diese Auflösung fehl, handelt es sich also um eine Nachricht mit einem CAN-Identifier der in diesem CAN-Segment nicht gesendet werden darf. Dieses Fehlverhalten wird ebenfalls an die Konfigurations- und Diagnoseeinheit gemeldet.

Die soweit vorverarbeitete Nachricht wird nun an die NoC-Schnittstelle (231) weitergeleitet. Für jedes CAN-Zielsegment steht ein dezidierter Ausgangsport (142) zur Verfügung. Je nach Zielsegment verlässt die Nachricht einen dem CAN-Zielsegment zugeordneten Port. Soll eine Nachricht an mehrere CAN-Zielsegmente geleitet werden, so wird die ursprüngliche Nachricht mehreren Ausgangsports zugeordnet. Dies wird durch ein mehrfaches Kopieren der ursprünglichen Nachricht an die Speicherbereiche realisiert, die den entsprechenden Aus- gangsports zugeordnet sind. Ab diesem Zeitpunkt kümmert sich das unterliegende NoC um den Transport der Nachricht zu einer weiteren Verarbeitungseinheit gleicher Bauweise,

Der Aufbau des unterliegenden NoCs (241) garantiert, dass von jeder einem CAN-Segment zugeordneten CPU zu jeder einem anderen möglichen CAN-Segment zugeordneten CPU eine dezidierte Verbindung bereit steht. Zudem sind diese Kanäle zeitlich und räumlich getrennt, wodurch eine hohe Fehlerisolationseigenschaft garantiert wird.

Pro Abarbeitungszyklus wir jeder der eingehenden Ports (243) des NoCs überprüft und fest-gestellt, ob eine neue Nachricht aus dem NoC anliegt. Diese Nachrichten, die auf den Eingangsports (243) anliegen, werden in den internen Speicher der Einheit (202) transferiert. Abhängig vom CAN-Identifier, der im CAN-Protokoll mit der Priorität einer Nachricht gleichzusetzen ist, werden die Nachrichten in eine Warteschlange eingeordnet. In diesem Fall wird die Nachricht mit der höchsten Priorität an den Anfang der Warteschlange (205) gereiht. Dies ist notwendig und garantiert, dass die Nachrichten in der gleichen Reihenfolge ihr Ziel erreichen, wie sie es auf einem klassischen CAN-Bus erreicht hätten.

Pro Abarbeitungszyklus wird die erste Nachricht der Warteschlange über die CAN-Schnittstelle (211) an den CAN-Controller (221) weiter gegeben. Dazu wird sie in den Speicher (212) des CAN-Controllers kopiert. Die entsprechende Nachricht wird aus der Warteschlange gelöscht. Der CAN-Controller leitet schließlich die Nachricht an den CAN-Bus, der mit dem entsprechenden CAN-Segment verbunden ist, weiter.

Der Ausgangsport 244 und der Eingangsport 245 stellen Kommunikationskanäle zu und von der Konfigurations- und Diagnoseeinheit dar.

Die Konfigurations- und Diagnoseeinheit (171) wird in ihrer Funktion als Konfigurationseinheit dahingehend verwendet, dass zur Laufzeit des Stemkopplers eine neue Konfiguration in das System eingespielt werden kann. In der gezeigten Realisierung werden in der Konfigurationseinheit für jede Hardwareeinheit (200), im speziellen für jede interne Datenstruktur (204) des CAN-Schnittstellensubsystems, entsprechende Speicherabbilder erzeugt. Diese umfassen die erlaubten CAN-Identifier für das entsprechende CAN-Segment und Transferfunktionen, pro erlaubtem CAN-Identifier eine minimale Zwischenankunftszeit, und pro erlaubtem CAN-Identifier eine Menge an Ziel-CAN-Segmenten zu denen eine Nachricht weitergeleitet werden soll. Um das vorhersagbare Verhalten der Schnittstellensubsysteme nicht zu beeinträchtigen, ist die Konfigurationseinheit ein dezidiertes Hardwareelement und nicht Teil der Schnittstellensubsysteme. Die so erstellten Speicherabbilder werden über die Schnittstelle 151 und dem ihr zugordneten Eingangsport 245 auf die Hardwareeinheit (200) verteilt. Um ein konsistentes Umschalten zwischen alter und neuer Konfiguration zu ermöglichen, werden die neuen Speicherabbilder zuerst in einen Shadowpuffer der Filtereinheit (203) kopiert. Erst wenn die Konfigurations- und Diagnoseeinheit das Verteilen der neuen Konfigurationen auf alle CAN-Schnittstellensubsysteme abgeschlossen hat, sendet sie eine spezielle Nachricht an die CAN-Schnittstellensubsystcme, worauf die zuvor übertragene Konfiguration Gültigkeit erhält.

Claims (5)

1. Patentansprüche 1. Verfahren zur Realisierung einer Kommunikationsinfrastruktur zur Vernetzung von Steuergeräten anhand des CAN-Protokolls wobei die Kommunikationsinfrastruktur als Stemtopologie mit einem Stemkoppler aufgebaut ist, welcher die Verbindung zu mehreren CAN-Segmenten über CAN-Ports herstellt, wobei die CAN-Segmente jeweils aus einem oder mehreren Steuergeräten bestehen dadurch gekennzeichnet dass der Stemkoppler als Multi-Processor System-on-a-Chip (MPSoC) realisiert wird und für jedes CAN-Segment einen dezidierten IP-Core bereitstellt, wobei die IP-Cores durch ein Network-on-a-Chip (NoC) verbunden sind, und die Konfiguration des Stemkopplers durch einen Management-Port gesetzt wird, und der Stemkoppler die selektive Weiterleitung von Nachrichten zwischen CAN-Segmenten durch Multicasting unterstützt, wobei die vom Stemkoppler produzierten und konsumierten Nachrichten dem CAN-Standard entsprechen, wobei die Konfiguration des Sternkopplers Wissen des erlaubten Verhaltens im Zeitbereich als minimale Nachrichtenzwischen-ankunftszeiten einschließt und für Fehlerisolation benutzt wird sodass Nachrichten bei einer Verletzung der minimalen Nachrichtenzwischenankunftszeit blockiert werden, und wo die Konfiguration des CAN- Stemkopplers Wissen über erlaubte Nachrichten-Identifier jedes CAN-Segments einschließt und für Fehlerisolation im Wertebereich benutzt wird sodass Nachrichten mit nicht erlaubten Identifiers blockiert werden
2. 2. Verfahren nach Anspruch (1) dadurch gekennzeichnet dass der Sternkoppler Nach-richtenidentifier zwischen CAN-Segmenten übersetzt wobei der semantische Inhalt der Nachrichten unverändert bleibt.
3. 3. Verfahren nach Anspruch (1) dadurch gekennzeichnet dass der Stemkoppler Aufzeichnungen über Verletzungen der minimalen Nachrichtenzwischenankunftszeiten und der erlaubten Nachrichtenidentifi er führt und diese über den Managementport abrufbar macht.
4. 4. Verfahren nach Anspruch (1 -3) dadurch gekennzeichnet dass die Konfiguration des Stemkopplers mit Informationen zu Nachrichtenzwischenankunftszeiten, erlaubten Identifiers und Identifiertransformationen dynamisch während des Betriebs mittels des Management-Ports verändert werden kann
5. 5. Apparat zur Realisierung einer Kommunikationsinfrastruktur zur Vernetzung von Steuergeräten anhand des CAN-Protokolls wobei die Kommunikationsinfrastruktur als Stemtopologie mit einem Stemkoppler aufgebaut ist, welcher die Verbindung zu mehreren CAN-Segmenten über CAN-Ports herstellt, wobei die CAN-Segmente jeweils aus einem oder mehreren Steuergeräten bestehen dadurch gekennzeichnet dass einer oder mehrere der Verfahrensschritte 1 bis 4 realisiert werden