DE102014226875A1 - Netzwerksystem für Fahrzeug und Datenübertragungsverfahren heterogener Kommunikationscontroller in dem gleichen System - Google Patents

Netzwerksystem für Fahrzeug und Datenübertragungsverfahren heterogener Kommunikationscontroller in dem gleichen System Download PDF

Info

Publication number
DE102014226875A1
DE102014226875A1 DE102014226875.3A DE102014226875A DE102014226875A1 DE 102014226875 A1 DE102014226875 A1 DE 102014226875A1 DE 102014226875 A DE102014226875 A DE 102014226875A DE 102014226875 A1 DE102014226875 A1 DE 102014226875A1
Authority
DE
Germany
Prior art keywords
communication
controller
controllers
selected transmission
transmission controller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102014226875.3A
Other languages
English (en)
Inventor
You Keun Kim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hyundai Motor Co
Original Assignee
Hyundai Motor Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hyundai Motor Co filed Critical Hyundai Motor Co
Publication of DE102014226875A1 publication Critical patent/DE102014226875A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40169Flexible bus arrangements
    • H04L12/40176Flexible bus arrangements involving redundancy
    • H04L12/40189Flexible bus arrangements involving redundancy by using a plurality of bus systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215Controller Area Network CAN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)

Abstract

Ein Netzwerksystem für ein Fahrzeug enthält einen oder mehrere erste Kommunikationscontroller und einen oder mehrere zweite Kommunikationscontroller. Der eine oder die mehreren ersten Kommunikationscontroller übertragen eine Nachricht in einem ersten Kommunikationsschema. Der eine oder die mehreren zweiten Kommunikationscontroller sind mit dem einen oder den mehreren ersten Kommunikationscontrollern durch ein Netzwerk verbunden und übertragen eine Nachricht in einem zweiten Kommunikationsschema, das sich von dem ersten Kommunikationsschema unterscheidet. Wenn ein Übertragungscontroller, der aus dem einen oder den mehreren ersten Kommunikationscontrollern und dem einen oder den mehreren zweiten Kommunikationscontrollern ausgewählt wird, eine Nachricht überträgt, beendet ein Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, die eigene Nachrichtenübertragung desselben und nimmt die eigene Nachrichtenübertragung desselben wieder auf, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.

Description

  • HINTERGRUND
  • (a) Technisches Gebiet
  • Die vorliegende Offenbarung betrifft ein Netzwerksystem für ein Fahrzeug und ein Datenübertragungsverfahren eines heterogenen Kommunikationscontrollers in dem gleichen System. Genauer betrifft die vorliegende Offenbarung ein Netzwerksystem für ein Fahrzeug und ein Datenübertragungsverfahren heterogener Kommunikationscontroller in dem gleichen System, das heterogenen Kommunikationscontrollern, die verschiedene Kommunikationsschemen verwenden, ermöglicht, Daten durch ein Netzwerk ohne jegliches Gateway zu übertragen.
  • (b) Verwandte Technik
  • In letzter Zeit wurde in Fahrzeugkommunikationsnetzwerken die Buslast von Highspeed-Controller-Area-Networks (Highspeed-CANs) selbst während kritischen Situationen aufgrund einer rapiden Zunahme von elektronischen Vorrichtungen überlastet. Zudem ist in letzter Zeit der Bedarf, eine große Datenmenge mit einer hohen Geschwindigkeit zwischen elektronischen Vorrichtungen zu übertragen, gestiegen.
  • Um diese Probleme zu lösen, ist die Kommunikation über CAN mit flexibler Datenrate (CAN-FD), mit der die Geschwindigkeit basierend auf bestehenden CAN-Kommunikationen erhöht wird, als eine alternative Lösung ins Rampenlicht gerückt. Herkömmlich wurde FlexRay auf einige Fahrzeuge angewandt, um Probleme einer überhöhten Buslast und dergleichen zu lösen. Jedoch ist dieser Ansatz aufgrund der mit demselben verbundenen Kosten nicht optimal.
  • Andererseits ist die CAN-FD-Kommunikation ein Verfahren zum Erhöhen der Kommunikationsgeschwindigkeit und Datenübertragungsmenge basierend auf gegenwärtigen CAN-Kommunikationsnetzwerken und infolgedessen ein effektiver Ansatz zu relativ geringen Kosten. Folglich gilt die CAN-FD-Kommunikation als ein alternativer Plan zum Lösen von Problemen einer überhöhten Buslast und dergleichen.
  • Wenn die CAN-Kommunikation und CAN-FD-Kommunikation auf das gleiche Netzwerk angewandt werden, kann ein Fehler aufgrund eines Unterschieds der Kommunikationsgeschwindigkeit zwischen der CAN-Kommunikation und CAN-FD-Kommunikation auftreten. Folglich wird es unmöglich, Signale zu erkennen.
  • Da die gegenwärtigen Schemen zur CAN-Kommunikation und CAN-FD-Kommunikation nicht auf das gleiche Netzwerk angewandt werden können, können zwei separate Netzwerke zur CAN-Kommunikation und CAN-FD-Kommunikation konfiguriert werden. Ein Nur-Kommunikations-Gateway zum Umwandeln von Signalen zwischen den zwei Netzwerken kann dann konfiguriert sein, um Daten zwischen den Netzwerken zur CAN-Kommunikation und CAN-FD-Kommunikation zu übermitteln.
  • Wenn das Nur-Kommunikations-Gateway verwendet wird, erhöhen sich jedoch die Stückkosten und eine Signalverzögerung tritt häufiger als bei Nichtverwendung des Gateways auf. Daher kann sich die Leistung eines Controllers verschlechtern, wenn der Controller eine Funktion durchführen muss.
  • [Dokument der verwandten Technik]
    • (Patentdokument 1) Koreanische Patentanmeldung mit der Veröffentlichungsnr. 2008-0108833 (2008,12,16).
  • ZUSAMMENFASSUNG DER OFFENBARUNG
  • Die vorliegende Offenbarung liefert ein Netzwerksystem für ein Fahrzeug und ein Datenübertragungsverfahren heterogener Kommunikationscontroller in dem gleichen System, das heterogenen Kommunikationscontrollern, die verschiedene Kommunikationsschemen verwenden, ermöglicht, Daten durch ein Netzwerk ohne jegliches Gateway zu übertragen.
  • In einem Aspekt liefert die vorliegende Offenbarung ein Netzwerksystem für ein Fahrzeug, das Folgendes enthält: einen oder mehrere erste Kommunikationscontroller, die zum Übertragen von Nachrichten in einem ersten Kommunikationsschema konfiguriert sind; und einen oder mehrere zweite Kommunikationscontroller, die mit dem einen oder den mehreren ersten Kommunikationscontrollern durch ein Netzwerk verbunden sind und zum Übertragen von Nachrichten in einem zweiten Kommunikationsschema, das sich von dem ersten Kommunikationsschema unterscheidet, konfiguriert sind, wobei, wenn ein Übertragungscontroller, der aus dem einen oder den mehreren ersten Kommunikationscontrollern und dem einen oder den mehreren zweiten Kommunikationscontrollern ausgewählt wird, eine Nachricht überträgt, ein Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem ausgewählten Übertragungscontroller unterscheidet, die eigene Nachrichtenübertragung desselben anhält bzw. beendet und die eigene Nachrichtenübertragung desselben wieder aufnimmt, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  • Der ausgewählte Übertragungscontroller kann basierend auf einem Identifier-Feld (ID-Feld) eines Arbitration-Feldes sequenziell ausgewählt werden, das eine Nachrichtenübertragungs-Prioritätenfolge unter Nachrichten determiniert bzw. festlegt, die von dem einen oder den mehreren ersten und zweiten Kommunikationscontrollern übertragen werden.
  • Die anderen Kommunikationscontroller als der ausgewählte Übertragungscontroller können durch Vergleichen des Kommunikationsschemas der anderen Kommunikationscontroller mit dem des ausgewählten Übertragungscontrollers unter Verwendung eines nächsten Bits eines Identifier-Extension-Bits (IDE-Bit) in einem Kontroll- bzw. Control-Feld, das einen Standard-Datenframe bildet, bestimmen, ob das Kommunikationsschema der anderen Kommunikationscontroller mit dem des ausgewählten Übertragungscontrollers identisch ist.
  • Wenn der ausgewählte Übertragungscontroller das erste Kommunikationsschema verwendet, das sich von dem zweiten Kommunikationsschema unterscheidet, kann/können der eine oder die mehreren zweiten Kommunikationscontroller die Kommunikationsteilnahme beenden, wenn sich eine Kommunikationsgeschwindigkeit eines Standard-Datenframes von dem einen oder den mehreren zweiten Kommunikationscontrollern von der eines Standard-Datenframes des ausgewählten Übertragungscontrollers unterscheidet, und nehmen die Kommunikationsteilnahme wieder auf, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  • Wenn der ausgewählte Übertragungscontroller das zweite Kommunikationsschema verwendet, das sich von dem ersten Kommunikationsschema unterscheidet, kann/können der eine oder die mehreren ersten Kommunikationscontroller die Kommunikationsteilnahme beenden, wenn sich eine Kommunikationsgeschwindigkeit eines Standard-Datenframes des einen oder der mehreren ersten Kommunikationscontroller von der eines Standard-Datenframes des ausgewählten Übertragungscontrollers unterscheidet, und nehmen die Kommunikationsteilnahme wieder auf, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  • Jeder Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, kann eine Wartezeit basierend auf einem Datenframe des ausgewählten Übertragungscontrollers berechnen und dann ein Signal des ausgewählten Übertragungscontrollers vernachlässigen, das während der berechneten Wartezeit empfangen wird, ohne das Signal als einen Fehler zu verarbeiten.
  • Jeder Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, kann eine Wartezeit basierend auf einem Datenframe des ausgewählten Übertragungscontrollers berechnen. Der Kommunikationscontroller kann die Wartezeit basierend auf einer Übertragungszeit eines Bestätigungs- bzw. Acknowledge-Feldes (ACK-Feld) in dem Datenframe des ausgewählten Übertragungscontrollers berechnen.
  • Einer des ersten und zweiten Kommunikationscontrollers kann ein Controller-Area-Network-Kommunikationscontroller (CAN-Kommunikationscontroller) sein, der ein CAN-Kommunikationsschema verwendet, während der andere Controller des ersten und zweiten Kommunikationscontrollers ein Kommunikationscontroller für CAN mit flexibler Datenrate (CAN-FD-Kommunikationscontroller) sein kann, der ein CAN-FD-Kommunikationsschema verwendet.
  • Ein Diagnosestecker bzw. Diagnoseanschluss (diagnostic connector), der einen Fehler eines Kommunikationsnetzwerkes diagnostiziert, kann mit den ersten und zweiten Kommunikationscontrollern durch das Netzwerk verbunden sein. Der Diagnoseanschluss kann die ersten oder zweiten Kommunikationsschemen verwenden.
  • In einem anderen Aspekt liefert die vorliegende Offenbarung ein Datenübertragungsverfahren heterogener Kommunikationscontroller in einem Netzwerksystem für ein Fahrzeug, wobei das Datenübertragungsverfahren Folgendes enthält: Verbinden eines oder mehrerer erster Kommunikationscontroller, die Nachrichten in einem ersten Kommunikationsschema übertragen, mit einem Netzwerk; Verbinden eines oder mehrerer zweiter Kommunikationscontroller, die Nachrichten in einem zweiten Kommunikationsschema übertragen, das sich von dem ersten Kommunikationsschema unterscheidet, mit dem Netzwerk; Auswählen eines Übertragungscontrollers, der eine Nachricht überträgt, aus dem einen oder den mehreren ersten Kommunikationscontrollern und dem einen oder den mehreren zweiten Kommunikationscontrollern; und Vergleichen des ersten Kommunikationsschemas und des zweiten Kommunikationsschemas mit dem des ausgewählten Übertragungscontrollers, wobei ein Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, die eigene Nachrichtenübertragung desselben beendet und die eigene Nachrichtenübertragung desselben wieder aufnimmt, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  • Beim Auswählen des Übertragungscontrollers kann der ausgewählte Übertragungscontroller basierend auf einem ID-Feld eines Arbitration-Feldes sequenziell ausgewählt werden, das eine Nachrichtenübertragungs-Prioritätenfolge unter Nachrichten festlegt, die von dem einen oder den mehreren ersten und zweiten Kommunikationscontrollern übertragen werden.
  • Das Vergleichen des ersten Kommunikationsschemas und des zweiten Kommunikationsschemas mit dem des ausgewählten Übertragungscontrollers kann Folgendes enthalten: Bestimmen eines Kommunikationsschemas des ausgewählten Übertragungscontrollers unter Verwendung eines nächsten Bits eines IDE-Bits in einem Control-Feld, das einen Standard-Datenframe bildet; und Bestimmen, ob das Kommunikationsschema der anderen Kommunikationscontroller als dem ausgewählten Übertragungscontroller mit dem des ausgewählten Übertragungscontrollers identisch ist, durch Vergleichen des Kommunikationsschemas der anderen Kommunikationscontroller mit dem des ausgewählten Übertragungscontrollers.
  • Wenn bestimmt wird, dass der ausgewählte Übertragungscontroller das erste Kommunikationsschema verwendet, das sich von dem zweiten Kommunikationsschema unterscheidet, kann/können der eine oder die mehreren zweiten Kommunikationscontroller die Kommunikationsteilnahme beenden, wenn sich eine Kommunikationsgeschwindigkeit eines Standard-Datenframes des einen oder mehreren zweiten Kommunikationscontroller von der eines Standard-Datenframes des ausgewählten Übertragungscontrollers unterscheidet, und nimmt die Kommunikationsteilnahme wieder auf, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  • Wenn bestimmt wird, dass der ausgewählte Übertragungscontroller das zweite Kommunikationsschema verwendet, das sich von dem ersten Kommunikationsschema unterscheidet, kann/können der eine oder die mehreren ersten Kommunikationscontroller die Kommunikationsteilnahme beenden, wenn sich eine Kommunikationsgeschwindigkeit eines Standard-Datenframes des einen oder der mehreren ersten Kommunikationscontroller von der eines Standard-Datenframes des ausgewählten Übertragungscontrollers unterscheidet, und nimmt die Kommunikationsteilnahme wieder auf, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  • Jeder Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, kann eine Wartezeit basierend auf einem Datenframe des ausgewählten Übertragungscontrollers berechnen und dann ein Signal des ausgewählten Übertragungscontrollers vernachlässigen, das während der berechneten Wartezeit empfangen wird, ohne das Signal als einen Fehler zu verarbeiten.
  • Jeder Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, kann eine Wartezeit basierend auf einem Datenframe des ausgewählten Übertragungscontrollers berechnen. Der Kommunikationscontroller kann die Wartezeit basierend auf einer Übertragungszeit eines ACK-Feldes in dem Datenframe des ausgewählten Übertragungscontrollers berechnen.
  • Einer des ersten und zweiten Kommunikationscontrollers kann ein CAN-Kommunikationscontroller sein, der ein CAN-Kommunikationsschema verwendet, während der andere Controller des ersten und zweiten Kommunikationscontrollers ein CAN-FD-Kommunikationscontroller sein kann, der ein CAN-FD-Kommunikationsschema verwendet.
  • Nach der vorliegenden Offenbarung können die folgenden Effekte erhalten werden.
  • Erstens werden die CAN- und CAN-FD-Kommunikationscontroller kombiniert und in dem gleichen Netzwerk angewandt, ohne ein Nur-Kommunikations-Gateway zu verwenden, so dass es möglich ist, eine Zunahme der Stückkosten zu vermeiden, die durch Anwenden eines herkömmlichen Gateways bei einer Kommunikation zwischen CAN- und CAN-FD-Netzwerken verursacht werden, und eine schnelle Datenverarbeitung zwischen den zwei Kommunikationsnetzwerken durchzuführen. Das heißt, es ist möglich, das Nur-Kommunikations-Gateway zu entfernen, und infolgedessen können die Stückkosten verringert werden. Ferner kann ein(e) schnelle(r) Datenübertragung/Datenempfang zwischen Controllern erzielt werden.
  • Zweitens werden, wenn einige Controller in einem Fahrzeug in CAN-FD-Kommunikationscontroller umgewandelt werden, nur die erforderten Controller in die CAN-FD-Kommunikationscontroller umgewandelt, ohne alle Kommunikationsschemen der Controller in dem Fahrzeug zu verändern, und das Netzwerk kann beibehalten werden, ohne zusätzlich ein Netzwerk zu bilden. Folglich wird nur ein Anteil von Softwareentwicklungskosten, die mit den Controllern assoziiert werden, die verschiedene Kommunikationen, wie beispielsweise CAN und CAN-FD verwenden, erzeugt, so dass es möglich ist, Investitionskosten zu reduzieren und signifikante Ergebnisse gegenüber geringen Kosten hervorzubringen.
  • Drittens kann der Freiheitsgrad beim Bilden eines Netzwerkes verbessert werden. Ferner wird die Anzahl von Netzwerken im Vergleich zu den herkömmlichen Techniken verringert, so dass es möglich ist, Stückkosten einer Verdrahtungs-/Anschlusskomponente zum Bilden des Netzwerkes zu reduzieren.
  • Die oben erwähnten und andere Merkmale der Offenbarung werden unten erörtert.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die oben erwähnten und andere Merkmale der vorliegenden Offenbarung werden nun in Bezug auf Ausführungsformen derselben detailliert beschrieben werden, die in den beiliegenden Zeichnungen veranschaulicht sind, die nachstehend nur zur Veranschaulichung dienen und die vorliegende Offenbarung folglich nicht beschränken und in denen:
  • 1 eine Konfigurationsansicht ist, die ein Netzwerksystem für ein Fahrzeug nach Ausführungsformen der vorliegenden Offenbarung schematisch veranschaulicht;
  • 2 eine Ansicht ist, die die Struktur einer allgemeinen Highspeed-CAN-Kommunikations-Nachricht veranschaulicht;
  • 3 eine Ansicht ist, die die Struktur einer allgemeinen CAN-FD-Kommunikations-Nachricht veranschaulicht;
  • 4 eine Ansicht ist, die die Strukturen von Standard-Datenframes von CAN- und CAN-FD-Kommunikations-Nachrichten unter Verwendung des Netzwerksystems nach Ausführungsformen der vorliegenden Offenbarung vergleicht;
  • 5 eine Ansicht ist, die eine Wartezeit eines CAN-Kommunikationscontrollers veranschaulicht, wenn ein CAN-FD-Kommunikationscontroller eine Nachricht in dem Netzwerksystem nach Ausführungsformen der vorliegenden Offenbarung überträgt;
  • 6 eine Ansicht ist, die eine Wartezeit des CAN-FD-Kommunikationscontrollers veranschaulicht, wenn der CAN-Kommunikationscontroller eine Nachricht in dem Netzwerksystem nach Ausführungsformen der vorliegenden Offenbarung überträgt; und
  • 7 ein Ablaufplan ist, der ein Datenübertragungsverfahren heterogener Kommunikationscontroller, die das gleiche Netzwerk in dem Netzwerksystem verwenden, nach Ausführungsformen der vorliegenden Offenbarung veranschaulicht.
  • Es sollte klar sein, dass die beigefügten Zeichnungen nicht unbedingt maßstabsgetreu sind und eine etwas vereinfachte Darstellung verschiedener bevorzugter Merkmale aufzeigen, die für die grundlegenden Prinzipien der Offenbarung veranschaulichend sind. Die spezifischen Ausgestaltungsmerkmale der vorliegenden Offenbarung, die hierin offenbart sind und beispielsweise bestimmte Maße, Orientierungen, Plätze und Formen enthalten, werden zum Teil durch die bestimmte vorgesehene Anwendung und Einsatzumgebung bestimmt werden. Überall in den verschiedenen Figuren der Zeichnung beziehen sich die Bezugsnummern auf gleiche oder äquivalente Teile der vorliegenden Offenbarung.
  • DETAILLIERTE BESCHREIBUNG
  • Die hierin verwendete Terminologie dient nur zum Zweck des Beschreibens bestimmter Ausführungsformen und soll die Offenbarung nicht beschränken. Wie hierin verwendet, sollen die Singularformen „ein/eine” und „der/die/das” auch die Pluralformen enthalten, sofern der Kontext dies nicht anderweitig klar erkennen lässt. Es wird zudem klar sein, dass die Ausdrücke „weist auf” und/oder „aufweisend”, wenn in dieser Beschreibung verwendet, das Vorhandensein der genannten Merkmale, ganzen Zahlen, Schritte, Operationen, Elemente und/oder Bauteile spezifizieren, aber nicht das Vorhandensein oder den Zusatz von einem/einer oder mehreren anderen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen, Bauteilen und/oder Gruppen derselben ausschließen. Wie hierin verwendet, enthält der Ausdruck „und/oder” jedes beliebige und alle Kombinationen von einem oder mehreren der assoziierten, aufgelisteten Elemente.
  • Es ist klar, dass der Ausdruck „Fahrzeug” oder „Fahrzeug-” oder ein anderer ähnlicher Ausdruck, der hierin verwendet wird, Kraftfahrzeuge im Allgemeinen enthält, wie beispielsweise Personenkraftwagen, die Geländefahrzeuge (SUV), Busse, Lastwagen, verschiedene Geschäftswagen enthalten, Wasserfahrzeuge, die eine Vielzahl von Booten und Schiffen enthalten, Luftfahrzeuge und Ähnliches, und Hybridfahrzeuge, Elektrofahrzeuge, Plug-In-Hybridelektrofahrzeuge, Fahrzeuge mit Wasserstoffantrieb und andere Fahrzeuge mit alternativen Brennstoffen enthält (z. B. Brennstoffe, die aus anderen Rohstoffen als Erdöl gewonnen werden). Wie hierin bezeichnet, ist ein Hybridfahrzeug ein Fahrzeug, das zwei oder mehr Leistungsquellen aufweist, wie beispielsweise sowohl benzinbetriebene als auch elektrisch betriebene Fahrzeuge.
  • Zudem ist klar, dass eines oder mehrere der nachstehenden Verfahren oder Aspekte derselben durch zumindest eine Steuerung bzw. einen Controller ausgeführt werden können. Der Ausdruck „Controller” kann sich auf eine Hardwarevorrichtung beziehen, die einen Speicher und einen Prozessor enthält. Der Speicher ist zum Speichern von Programmbefehlen konfiguriert und der Prozessor ist zum Ausführen der Programmbefehle konfiguriert, um einen oder mehrere Prozesse durchzuführen, die weiter unten beschrieben werden. Zudem ist klar, dass die nachstehenden Verfahren durch ein Gerät ausgeführt werden können, das den Controller aufweist, wobei das Gerät in der Technik bekannt ist, zum Durchführen eines Datenübertragungsverfahrens eines heterogenen Kommunikationscontrollers in einem Netzwerksystem für ein Fahrzeug geeignet zu sein.
  • Zudem kann der Controller der vorliegenden Offenbarung als nicht-transitorische computerlesbare Medien auf einem computerlesbaren Datenträger ausgeführt werden, der ausführbare Programmbefehle enthält, die durch einen Prozessor, einen Controller oder Ähnliches ausgeführt werden. Beispiele computerlesbarer Datenträger enthalten Festwertspeicher, Direktzugriffsspeicher, Compact-Disc-Festwertspeicher (CD-ROMs), Magnetbänder, Disketten, Flash-Laufwerke, Chipkarten und optische Datenspeichervorrichtungen, sind aber nicht darauf beschränkt. Das computerlesbare Aufnahmemedium kann auch in netzwerkgekoppelten Computersystemen verteilt sein, so dass das computerlesbare Medium auf verteilte Weise gespeichert und ausgeführt wird, z. B. durch einen Telematikserver oder ein Controller Area Network (CAN).
  • Nachstehend wird nun auf verschiedene Ausführungsformen der vorliegenden Offenbarung detailliert Bezug genommen werden, deren Beispiele in den beiliegenden Zeichnungen veranschaulicht und unten beschrieben sind. Zwar wird die Offenbarung in Verbindung mit Ausführungsformen beschrieben werden, aber es wird klar sein, dass die vorliegende Beschreibung die Offenbarung nicht auf diese Ausführungsformen beschränken soll. Im Gegenteil soll die Offenbarung nicht nur die offenbarten Ausführungsformen, sondern auch verschiedene Alternativen, Modifikationen, Äquivalente und andere Ausführungsformen decken, die innerhalb des Wesens und Bereiches der Offenbarung enthalten sein können, die durch die beigefügten Ansprüche definiert sind.
  • Die vorliegende Offenbarung liefert ein Verfahren zum Kombinieren und Anwenden von Controllern, die verschiedene Kommunikationsprotokolle verwenden, in einem Netzwerk, um eine Zunahme der Stückkosten zu verhindern, die durch das Anwenden eines herkömmlichen Gateways bei der Kommunikation zwischen CAN- und CAN-FD-Kommunikationsnetzwerken verursacht werden, und um eine schnelle Datenverarbeitung zwischen den zwei Kommunikationsnetzwerken durchzuführen. Das heißt, bei der vorliegenden Offenbarung werden, wenn zwei Netzwerke, die verschiedene Kommunikationsprotokolle verwenden, verbunden werden, um eine Datenübertragung durchzuführen, Controller, die heterogene Kommunikationsschemen verwenden, mit unterschiedlichen Kommunikationsgeschwindigkeiten in einem einzigen Netzwerk kombiniert und angewandt, ohne irgendein Nur-Kommunikations-Gateway zur Verbindung zwischen den heterogenen Netzwerken zu verwenden.
  • Folglich ist ein Netzwerksystem für ein Fahrzeug nach Ausführungsformen der vorliegenden Offenbarung ein Netzwerksystem in einem Fahrzeug, das eine Kommunikation zwischen elektronischen Komponenten in dem Fahrzeug durchführt. Wie in 1 gezeigt, kann das Netzwerksystem konfiguriert sein, um einen Bus 10, der durch Verdrehen von zwei Drahtlitzen 11 und 12 ausgebildet wird, und eine Vielzahl von Controllern 20 und 30 zu enthalten, die mit dem Bus 10 verbunden sind.
  • Abschlusswiderstände 13 und 14 (die im Allgemeinen 120 Ω verwenden) sind jeweils mit beiden Enden des Busses 10 verbunden und die Controller 20 und 30 sind mit einer Vielzahl von CAN-Kommunikationscontrollern (alternativ hierin als „erste Kommunikationscontroller” bezeichnet) 20, die ein CAN-Kommunikationsprotokoll (alternativ hierin als ein „erstes Kommunikationsschema” bezeichnet) verwenden, und einer Vielzahl von CAN-FD-Kommunikationscontrollern (alternativ hierin als „zweite Kommunikationscontroller” bezeichnet) 30 konfiguriert, die ein CAN-FD-Kommunikationsprotokoll (alternativ hierin als ein „zweites Kommunikationsschema” bezeichnet) verwenden. Die CAN-Kommunikationscontroller 20 und die CAN-FD-Kommunikationscontroller 30 sind alle (gleichzeitig) mit dem Bus 10 verbunden, um Daten durch den Bus 10 zu übertragen. Das heißt, bei dem Netzwerksystem nach Ausführungsformen der vorliegenden Offenbarung sind die heterogenen Kommunikationscontroller 20 und 30, die verschiedene Kommunikationsschemen (z. B. Protokolle) verwenden, gleichzeitig mit dem gleichen Netzwerk verbunden und führen eine Datenübertragung durch das gleiche Netzwerk ohne jegliches bestehendes Nur-Kommunikations-Gateway durch. Zum Zwecke der vorliegenden Offenbarung kann das Kommunikationsschema, das durch den einen oder die mehreren ersten Kommunikationscontroller verwendet wird, alternativ als ein „erstes Kommunikationsschema” bezeichnet werden, wohingegen das Kommunikationsschema, das durch den einen oder die mehreren zweiten Kommunikationscontroller verwendet wird, alternativ als ein „zweites Kommunikationsschema” bezeichnet werden kann.
  • Das Netzwerksystem kann konfiguriert sein, um einen Diagnoseanschluss 40 zum Diagnostizieren eines Datenübertragungsfehlers, der in einem Netzwerk auftritt, zu enthalten. Der Diagnoseanschluss 40 kann konfiguriert sein, um gleichzeitig mit dem Bus 10 verbunden zu sein. In diesem Zustand kann ein Diagnoseanschluss, der allgemein auf ein Kommunikationsnetzwerk in einem Fahrzeug angewandt wird, als der Diagnoseanschluss 40 verwendet werden. Die Technik zum Diagnostizieren des Auftretens eines Fehlers in dem Netzwerk durch den Diagnoseanschluss ist eine in der Technik bekannte Technik und daher wird eine detaillierte Beschreibung derselben ausgelassen werden.
  • Wenn ein Auftreten eines Fehlers in dem Netzwerk diagnostiziert wird, wird jedoch der Diagnoseanschluss 40 auf sowohl das CAN- als auch das CAN-FD-Kommunikationsnetzwerk angewandt, um das Auftreten eines Fehlers zu diagnostizieren. Wenn der Diagnoseanschluss 40 mit dem Netzwerk verbunden ist, kann der Diagnoseanschluss 40 als ein Kommunikationscontroller behandelt werden. Das heißt, der Diagnoseanschluss 40 ist ein Kommunikationscontroller zum Diagnostizieren eines Fehlers eines Kommunikationsnetzwerkes. Der Diagnoseanschluss 40 diagnostiziert einen Fehler des Kommunikationsnetzwerkes durch einen Prozess zum Übertragen und Empfangen von Nachrichten. Wenn ein Fehler des Kommunikationsnetzwerkes diagnostiziert wird, verwendet der Diagnoseanschluss 40 das gleiche Kommunikationsschema wie der erste oder zweite Kommunikationscontroller 20 oder 30 (z. B. das erste oder zweite Kommunikationsschema). Bei dem Netzwerksystem, das wie oben beschrieben konfiguriert ist, wählt jeder Controller ein Kommunikationsschema, das für die Funktionsleistung desselben geeignet ist, unter CAN- und CAN-FD-Kommunikationen aus und verwendet dasselbe.
  • Nachstehend wird ein Datenübertragungsverfahren heterogener Kommunikationscontroller, die ein gleiches Netzwerk in dem Netzwerksystem verwenden, beschrieben werden. Vor der Beschreibung des Verfahrens werden die Strukturen von CAN- und CAN-FD-Kommunikations-Nachrichten beschrieben werden.
  • 2 veranschaulicht die Struktur einer Highspeed-CAN-Kommunikations-Nachricht und 3 veranschaulicht die Struktur einer CAN-FD-Kommunikations-Nachricht. Die CAN-Kommunikations-Nachricht ist konfiguriert, um einen Standard-Datenframe zu enthalten, der in 2 gezeigt ist. Die maximale Kommunikationsgeschwindigkeit übertragbarer Daten beträgt 1 Mbps und die maximale Datenmenge übertragbarer Daten beträgt 8 Bytes (64 Bits).
  • Wie in 2 gezeigt, sind ein Start of Frame (SOF) von 1 Bit, ein Arbitration-Feld von 12 Bits, ein Control-Feld von 6 Bits, ein Daten-Feld von 64 Bits, ein Cyclic-Redundancy-Check-Feld (CRC-Feld) von 16 Bits, ein Acknowledge-Feld (ACK-Feld) von 2 Bits und ein End Of Frame (EOF) von 7 Bits in dem Standard-Datenframe sequenziell konfiguriert. Ein Identifier-Feld (ID-Feld) von 11 Bits, das eine Nachrichtenübertragungs-Prioritätenfolge bestimmt, ist in dem Arbitration-Feld enthalten und eine CRC-Sequenz von 15 Bits und ein CRC-Begrenzungszeichen bzw. CRC-Delimiter von 1 Bit sind in dem CRC-Feld konfiguriert. Die CAN-FD-Kommunikations-Nachricht ist konfiguriert, um einen Standard-Datenframe zu enthalten, der in 3 gezeigt ist. Die maximale Kommunikationsgeschwindigkeit übertragbarer Daten beträgt 15 Mbps und die maximale Datenmenge übertragbarer Daten beträgt 64 Bytes (512 Bits).
  • Wie in 3 gezeigt, sind ein SOF von 1 Bit, ein Arbitration-Feld von 12 Bits, ein Control-Feld von 9 Bits, ein Daten-Feld von 512 Bits, ein CRC-Feld von 18 Bits oder 22 Bits, ein ACK-Feld von 2 Bits und ein EOF von 10 Bits in dem Standard-Datenframe sequenziell konfiguriert. Ähnlich der CAN-Kommunikations-Nachricht, ist ein ID-Feld von 11 Bits, das eine Nachrichtenübertragungs-Prioritätenfolge bestimmt, in dem Arbitration-Feld enthalten und eine CRC-Sequenz von 17 Bits (wenn das Daten-Feld 16 Bytes oder weniger beträgt) oder 21 Bits (wenn das Daten-Feld 16 Bytes überschreitet) und ein CRC-Delimiter von 1 Bit sind in dem CRC-Feld konfiguriert.
  • 4 ist eine Ansicht, die die Strukturen der Datenframes der CAN- und CAN-FD-Kommunikations-Nachrichten vergleicht, und es ist ersichtlicht, dass die CAN- und CAN-FD-Kommunikations-Nachrichten unterschiedliche Bit-Zustände in den Control-Feldern der Standard-Datenframes aufweisen. Folglich unterscheiden sich die Kommunikationsgeschwindigkeiten von Daten voneinander in den Control-Feldern. Wenn zwei verschiedene Kommunikationsschemen in dem gleichen Netzwerk angewandt werden, tritt daher ein Kommunikationsfehler aufgrund eines Unterschieds zwischen den Kommunikationsgeschwindigkeiten auf.
  • Folglich wird bei der vorliegenden Offenbarung bestimmt, dass der Unterschied der Kommunikationsgeschwindigkeit zwischen den CAN- und CAN-FD-Kommunikationen normal ist, und der Unterschied der Kommunikation nicht als ein Fehler verarbeitet, so dass die heterogenen Kommunikationscontroller, die unterschiedliche Kommunikationsprotokolle verwenden, eine Datenübertragung in einem gleichen Netzwerk durchführen können. Mit anderen Worten vernachlässigt ein Controller, der ein Kommunikationsschema aufweist, dass ich von einem Übertragungscontroller unterscheidet, durch Bestimmen der Kommunikationsschemen vor einem Unterschied der Kommunikationsgeschwindigkeit zwischen den CAN- und CAN-FD-Kommunikationen Signale, bis die Übertragung einer Nachricht (von Daten) des Übertragungscontrollers abgeschlossen wird, und verarbeitet den Unterschied der Kommunikationsgeschwindigkeit nicht als einen Fehler.
  • Zu diesem Zweck empfängt und identifiziert jeder Controller der CAN- und CAN-FD-Controller, d. h., Controller in einem einzigen Netzwerk, r0 (z. B. in der CAN-Kommunikations-Nachricht), das das nächste Bit eines Identifier-Extension-Bits (IDE-Bit) der Nachricht oder ein Extended-Data-Length-Bit (EDL-Bit) (z. B. in der CAN-FD-Kommunikations-Nachricht) ist, und bestimmt dadurch das Kommunikationsschema des Übertragungscontrollers. Wenn das nächste Bit des IDE-Bits beispielsweise als ein dominantes (z. B. '0') identifiziert wird, bestimmt jeder heterogene Kommunikationscontroller, dass der Übertragungscontroller das CAN-Kommunikationsschema verwendet. Wenn das nächste Bit des IDE-Bits als ein rezessives (z. B. '1') identifiziert wird, bestimmt jeder heterogene Kommunikationscontroller, dass der Übertragungscontroller das CAN-FD-Kommunikationsschema verwendet.
  • In Bezug auf 4 sind in der CAN-Kommunikations-Nachricht ein Identifier Extension (IDE) von 1 Bit, ein reserviertes Bit (r0) von 1 Bit und ein Data Length Code (DLC) von 4 Bits in dem Control-Feld des Standard-Datenframes sequenziell konfiguriert. In der CAN-FD-Kommunikations-Nachricht sind ein IDE von 1 Bit, ein Extended Data Length (EDL) von 1 Bit, ein r0 von 1 Bit, ein Bit Rate Switch (BRS) von 1 Bit, ein Error State Indicator (ESI) von 1 Bit und ein DLC von 4 Bits in dem Control-Feld des Standard-Datenframes sequenziell konfiguriert. Das heißt, das nächste Bit (r0) des IDE-Bits ist '0' bei der CAN-Kommunikation und im Gegensatz dazu ist das nächste Bit (EDL) des IDE-Bits ”1” bei der CAN-FD-Kommunikation.
  • Jeder Kommunikationscontroller identifiziert und bestimmt ein Kommunikationsschema des Übertragungscontrollers durch das r0 (z. B. bei der CAN-Kommunikation) oder EDL (z. B. bei der CAN-FD-Kommunikation), das das nächste Bit des IDE-Bits ist. Wenn sich das Kommunikationsschema des Übertragungscontrollers von dem des Kommunikationscontrollers unterscheidet, verarbeitet dann der Kommunikationscontroller ein Übertragungssignal (z. B. Nachricht) des Übertragungscontrollers nicht als Fehler und vernachlässigt das Übertragungssignal, bis die Nachrichtenübertragung des Übertragungscontrollers abgeschlossen wird.
  • In diesem Zustand wird der Übertragungscontroller durch das ID-Feld, das eine Nachrichtenübertragungs-Prioritätenfolge festlegt, in dem Datenframe sequenziell festgelegt und die anderen Controller mit Ausnahme des Übertragungscontrollers (die CAN- und CAN-FD-Kommunikationscontroller mit Ausnahme eines Übertragungscontrollers) tasten des Kommunikationsschema des Übertragungscontrollers durch das empfangene r0 oder EDL-Bit des Übertragungscontrollers ab und erkennen dasselbe. Das heißt, wenn bestimmt wird, dass jeder Kommunikationscontroller mit Ausnahme des Übertragungscontrollers ein Kommunikationsschema aufweist (mit dem nächsten Bit des IDE-Bits identifiziert), das sich von dem des Übertragungscontrollers unterscheidet, erkennt der Kommunikationscontroller, dass sich das Kommunikationsschema des Kommunikationscontrollers von dem des Übertragungscontrollers unterscheidet. Anschließend beenden die Empfangscontroller (d. h. die anderen Kommunikationscontroller mit Ausnahme des Übertragungscontrollers) die Kommunikationsteilnahme (die CAN-Kommunikation beendet eine Kommunikationsteilnahme nach dem r0 des Control-Feldes und die CAN-FD-Kommunikation beendet eine Kommunikationsteilnahme nach dem EDL des Control-Feldes) und warten, bis die Nachrichtenübertragung des Übertragungscontrollers abgeschlossen wird.
  • 5 ist eine Ansicht, die eine Wartezeit des CAN-Kommunikationscontrollers veranschaulicht, wenn der CAN-FD-Kommunikationscontroller eine Nachricht in dem Netzwerksystem nach Ausführungsformen der vorliegenden Offenbarung überträgt.
  • Als Beispiel wird angenommen, dass der CAN-Kommunikationscontroller eine Kommunikationsgeschwindigkeit von 500 Kbps, eine Datenlänge von 8 Bytes (64 Bits) und eine Übertragungszeit pro Bit von μs aufweist und der CAN-FD-Kommunikationscontroller eine Kommunikationsgeschwindigkeit von 5 Mbps, eine Datenlänge von 64 Bytes (512 Bits) und eine Übertragungszeit pro Bit von 200 ns aufweist. Wenn der CAN-FD-Kommunikationscontroller eine Nachricht überträgt, beendet der CAN-Kommunikationscontroller die Nachrichtenübertragung nach dem Abtasten eines Kommunikationsprotokolls des Übertragungscontrollers (d. h. CAN-FD-Controller) und nimmt die Übertragung wieder auf, sobald die Nachrichtenübertragung des Übertragungscontrollers abgeschlossen ist.
  • Der CAN-Kommunikationscontroller berechnet eine Wartezeit basierend auf dem CAN-FD-Datenframe (z. B. Standard-Datenframe einer durch den CAN-FD-Kommunikationscontroller übertragenen Nachricht). Dann beendet der CAN-Kommunikationscontroller die Nachrichtenübertragung während der Wartezeit und wartet, bis die Übertragung der CAN-FD-Kommunikations-Nachricht (z. B. CAN-FD-Daten) abgeschlossen wird, durch einen internen Zähler. In diesem Zustand verarbeitet der CAN-Kommunikationscontroller kein CAN-FD-Signal, das während der Wartezeit empfangen wird, als einen Fehler und vernachlässigt das CAN-FD-Signal.
  • Der CAN-Kommunikationscontroller beendet die Nachrichtenübertragung und wartet nach dem Abtasten, dass sich das Nachrichtenübertragungsschema (z. B. Kommunikationsprotokoll) des CAN-Kommunikationscontrollers von dem des Übertragungscontrollers (z. B. CAN-FD-Kommunikationskontroller) unterscheidet, durch Identifikation des EDL-Bits des CAN-FD-Datenframes. Folglich kann in Bezug auf 5 die Wartezeit des CAN-Kommunikationscontrollers als Übertragungszeit von dem r0 bis ACK-Delimiter des CAN-FD-Datenframes (d. h. von nach dem EDL bis vor dem EOF) berechnet werden. Daher ist die Wartezeit des CAN-Kommunikationscontrollers = 3 Bits·2 μs/Bit + 540 Bits·200 ns/Bit = 6 μs + 108 μs = 114 μs.
  • Die Kommunikationsgeschwindigkeit des Arbitration-Feldes der CAN-Kommunikation ist gleich der des Arbitration-Feldes der CAN-FD-Kommunikation, die 500 kps beträgt. Die Kommunikationsgeschwindigkeit des Arbitration-Feldes ist jedoch nicht 500 kbps, sondern kann ein anderer Wert sein. Die Kommunikationsgeschwindigkeit des Arbitration-Feldes der CAN-Kommunikation ist notwendigerweise gleich der des Arbitration-Feldes der CAN-FD-Kommunikation. Nachdem die Wartezeit verstreicht, nimmt der CAN-Kommunikationscontroller normal an der Kommunikation teil. Wenn eine Nachrichtenübertragung durch Bestimmen der Nachrichtenübertragung basierend auf einer ID-Folge festgelegt wird, beginnt der CAN-Kommunikationscontroller mit der Nachrichtenübertragung. Das heißt, der CAN-Kommunikationscontroller tastet durch den internen Zähler während der Zeit, zu der die Übertragung einer Nachricht (z. B. von Daten) des CAN-FD-Kommunikationscontrollers abgeschlossen wird, ab, dass die Wartezeit verstreicht, und nimmt an der Netzwerkkommunikation teil, nachdem die Wartezeit verstreicht.
  • Als weiteres Beispiel wird angenommen, dass der CAN-Kommunikationscontroller eine Kommunikationsgeschwindigkeit von 500 Kbps, eine Datenlänge von 8 Bytes (64 Bits) und eine Übertragungszeit pro Bit von 2 μs aufweist und der CAN-FD-Kommunikationscontroller eine Kommunikationsgeschwindigkeit von 5 Mbps, eine Datenlänge von 64 Bytes (512 Bits) und eine Übertragungszeit pro Bit von 200 ns aufweist. Wenn der CAN-Kommunikationscontroller eine Nachricht überträgt, beendet der CAN-FD-Kommunikationscontroller die Nachrichtenübertragung nach dem Abtasten eines Kommunikationsprotokolls des Übertragungscontrollers (z. B. CAN-Kommunikationscontroller) und nimmt die Übertragung wieder auf, sobald die Nachrichtenübertragung des Übertragungscontrollers abgeschlossen ist.
  • Der CAN-FD-Kommunikationscontroller berechnet eine Wartezeit basierend auf dem CAN-Datenframe (z. B. Standard-Datenframe einer durch den CAN-Kommunikationscontroller übertragenen Nachricht). Dann beendet der CAN-FD-Kommunikationscontroller die Nachrichtenübertragung während der Wartezeit und wartet, bis die Übertragung der CAN-Kommunikations-Nachricht (z. B. CAN-Daten) abgeschlossen wird, durch einen internen Zähler. In diesem Zustand verarbeitet der CAN-FD-Kommunikationscontroller kein CAN-Signal, das während der Wartezeit empfangen wird, als einen Fehler und vernachlässigt das CAN-Signal.
  • Der CAN-FD-Kommunikationscontroller beendet die Kommunikationsteilnahme und wartet nach dem Abtasten, dass sich das Nachrichtenübertragungsschema (z. B. Kommunikationsprotokoll) des CAN-FD-Kommunikationscontrollers von dem des Übertragungscontrollers (z. B. CAN-Kommunikationscontroller) unterscheidet, durch Identifikation des nächsten Bits (EDL) des IDE-Bits. In Bezug auf 6 kann folglich die Wartezeit des CAN-FD-Kommunikationscontrollers als Übertragungszeit von dem reservierten Bit bis ACK-Delimiter des CAN-Datenframes (d. h., von nach dem DLC bis vor dem EOF) berechnet werden. Daher ist die Wartezeit des CAN-FD-Kommunikationscontrollers = {4 Bits (DLC) + 64 Bits (Daten) + 16 Bits (CRC) + 2 Bits (ACK)}·2 μs/Bit = 8 Bits·2 μs/Bit = 172 μs.
  • Hier ist der Grund, warum die Übertragungszeit des ACK-Feldes in der Wartezeit des Kommunikationscontrollers enthalten ist, dass die CAN-Kommunikation und die CAN-FD-Kommunikation die Signale derselben nicht als normale Signale erkennen und die Signale aufgrund eines Unterschieds der Kommunikationsgeschwindigkeit zwischen denselben vernachlässigen. Folglich ist es nicht erforderlich, ein ACK-Signal separat zu übertragen. Der Kommunikationscontroller wartet durch Ermöglichen, dass selbst das ACK-Feld in der Wartezeit des Controllers enthalten ist, und reduziert dadurch eine Wellenformverzerrung der Übertragungsnachricht. Wenn die Wartezeit verstreicht, nimmt der wartende Kommunikationscontroller (z. B. CAN-FD-Kommunikationscontroller) an der normalen Netzwerkkommunikation teil und überträgt anschließend die Nachricht, deren Übertragung beendet wird. Das heißt, während der Zeit, zu der die Übertragung einer Nachricht (z. B. von Daten) des CAN-Kommunikationscontrollers abgeschlossen wird, tastet der CAN-FD-Kommunikationscontroller durch den internen Zähler ab, dass die Wartezeit verstreicht, und kehrt normal zu der Netzwerkkommunikation zurück, nachdem die Wartezeit verstreicht.
  • Die Wartezeit des CAN- oder CAN-FD-Kommunikationscontrollers wird abhängig von der Kommunikationsgeschwindigkeit und Datenlänge verändert. Das heißt, die Wartezeit des Controllers kann abhängig von einer Kommunikationsgeschwindigkeit und einer Datenlänge verändert werden, die festgelegt werden, wenn die CAN- oder CAN-FD-Kommunikation für jede Art von Fahrzeug angewandt wird.
  • Wie in 7 gezeigt, werden daher die Kommunikationsgeschwindigkeit und Datenlänge jedes Controllers der CAN- und CAN-FD-Kommunikationscontroller vor der Übertragung von Daten (z. B. Nachricht) angemessen ausgewählt. Anschließend wird das Kommunikationsschema des Übertragungscontrollers bei der Datenübertragung abgetastet (d. h., es wird identifiziert, welches Kommunikationsschema der CAN- und CAN-FD-Kommunikationen der Übertragungscontroller verwendet). Wenn der Übertragungscontroller die CAN-FD-Kommunikation verwendet, vernachlässigt der CAN-Kommunikationscontroller ein Datensignal, ohne das Datensignal als einen Fehler zu verarbeiten, während der Übertragungszeit der CAN-FD-Daten und kehrt normal zu dem Kommunikationsnetzwerk zurück, wenn die Übertragung der CAN-FD-Daten abgeschlossen wird. Wenn der Übertragungscontroller die CAN-Kommunikation verwendet, vernachlässigt der CAN-FD-Kommunikationscontroller ein Datensignal, ohne das Datensignal als einen Fehler zu verarbeiten, während der Übertragungszeit der CAN-Daten und kehrt normal zu dem Kommunikationsnetzwerk zurück, wenn die Übertragung der CAN-Daten abgeschlossen wird.
  • Wie oben beschrieben wurde, ist es bei dem Netzwerksystem der vorliegenden Offenbarung möglich, eine(n) Datenübertragung/Datenempfang zwischen CAN-Kommunikationscontrollern und eine(n) Datenübertragung/Datenempfang zwischen CAN-FD-Kommunikationscontrollern durchzuführen. Wenn ein Mikrocomputer des CAN-FD-Kommunikationscontrollers die CAN-Kommunikation unterstützt, kann der CAN-FD-Kommunikationscontroller zudem Daten des CAN-Kommunikationscontrollers empfangen. Da die/der Datenübertragung/Datenempfang zwischen den CAN-Kommunikationscontrollern möglich ist, wird ein Controller, der nur CAN-Kommunikation verwendet, notwendigerweise im Voraus ausgewählt, wenn eine Netzwerkarchitektur ausgestaltet wird. Des Weiteren werden bei dem Netzwerksystem der vorliegenden Offenbarung, wenn erfordert wird, dass einige Controller in einem Fahrzeug die CAN-FD-Kommunikation verwenden, nur die erforderten Controller in CAN-FD-Kommunikationscontroller umgewandelt, ohne alle Controller, die das CAN-Kommunikationsschema verwenden, in dem Fahrzeug zu verändern, wobei dadurch ein Netzwerk gebildet wird. Folglich ist es möglich, Kosten zu verringern und einen hohen Ertrag zu erwarten.
  • Die Offenbarung wurde in Bezug auf Ausführungsformen derselben detailliert beschrieben. Es wird jedoch von jemandem mit technischen Fähigkeiten eingesehen werden, dass an diesen Ausführungsformen Änderungen vorgenommen werden können, ohne von den Prinzipien und dem Wesen der Offenbarung abzuweichen, deren Bereich in den beigefügten Ansprüchen und Äquivalenten derselben definiert ist.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • KR 2008-0108833 [0008]

Claims (17)

  1. Netzwerksystem für ein Fahrzeug, aufweisend: einen oder mehrere erste Kommunikationscontroller, die zum Übertragen von Nachrichten in einem ersten Kommunikationsschema konfiguriert sind; und einen oder mehrere zweite Kommunikationscontroller, die mit dem einen oder den mehreren ersten Kommunikationscontrollern durch ein Netzwerk verbunden sind und zum Übertragen von Nachrichten in einem zweiten Kommunikationsschema konfiguriert sind, das sich von dem ersten Kommunikationsschema unterscheidet, wobei, wenn ein Übertragungscontroller, der aus dem einen oder den mehreren ersten Kommunikationscontrollern und dem einen oder den mehreren zweiten Kommunikationscontrollern ausgewählt wird, eine Nachricht übertragt, ein Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, die eigene Nachrichtenübertragung desselben beendet und die eigene Nachrichtenübertragung desselben wieder aufnimmt, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  2. Netzwerksystem nach Anspruch 1, wobei der ausgewählte Übertragungscontroller basierend auf einem Identifier-Feld (ID-Feld) eines Arbitration-Feldes sequenziell ausgewählt wird, das eine Nachrichtenübertragungs-Prioritätenfolge unter Nachrichten festlegt, die von dem einen oder den mehreren ersten und zweiten Kommunikationscontrollern übertragen werden.
  3. Netzwerksystem nach Anspruch 1, wobei andere Kommunikationscontroller als der ausgewählte Übertragungscontroller durch Vergleichen des Kommunikationsschemas der anderen Kommunikationscontroller mit dem des ausgewählten Übertragungscontrollers unter Verwendung eines nächsten Bits eines Identifier-Extension-Bits (IDE-Bit) in einem Control-Feld, das einen Standard-Datenframe bildet, bestimmen, ob das Kommunikationsschema der anderen Kommunikationscontroller mit dem des ausgewählten Übertragungscontrollers identisch ist.
  4. Netzwerksystem nach Anspruch 1, wobei, wenn der ausgewählte Übertragungscontroller das erste Kommunikationsschema verwendet, das sich von dem zweiten Kommunikationsschema unterscheidet, der eine oder die mehreren zweiten Kommunikationscontroller die Kommunikationsteilnahme beenden, wenn sich eine Kommunikationsgeschwindigkeit eines Standard-Datenframes des einen oder der mehreren zweiten Kommunikationscontroller von der eines Standard-Datenframes des ausgewählten Übertragungscontrollers unterscheidet, und die Kommunikationsteilnahme wieder aufnehmen, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  5. Netzwerksystem nach Anspruch 1, wobei, wenn der ausgewählte Übertragungscontroller das zweite Kommunikationsschema verwendet, das sich von dem ersten Kommunikationsschema unterscheidet, der eine oder die mehreren ersten Kommunikationscontroller die Kommunikationsteilnahme beenden, wenn sich eine Kommunikationsgeschwindigkeit eines Standard-Datenframes des einen oder der mehreren ersten Kommunikationscontroller von der eines Standard-Datenframes des ausgewählten Übertragungscontrollers unterscheidet, und die Kommunikationsteilnahme wieder aufnehmen, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  6. Netzwerksystem nach Anspruch 1, wobei jeder Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, eine Wartezeit basierend auf einem Datenframe des ausgewählten Übertragungscontrollers berechnet und dann ein Signal des ausgewählten Übertragungscontrollers vernachlässigt, das während der berechneten Wartezeit empfangen wird, ohne das Signal als einen Fehler zu verarbeiten.
  7. Netzwerksystem nach Anspruch 1, wobei jeder Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, eine Wartezeit basierend auf einem Datenframe des ausgewählten Übertragungscontrollers basierend auf einer Übertragungszeit eines Acknowledge-Feldes (ACK-Feld) in dem Datenframe des ausgewählten Übertragungscontrollers berechnet.
  8. Netzwerksystem nach Anspruch 1, wobei ein Controller des ersten und zweiten Kommunikationscontrollers ein Controller-Area-Network-Kommunikationscontroller (CAN-Kommunikationscontroller) ist, der ein CAN-Kommunikationsschema verwendet, während der andere Controller des ersten und zweiten Kommunikationscontrollers ein Kommunikationscontroller für CAN mit flexibler Datenrate (CAN-FD-Kommunikationscontroller) ist, der ein CAN-FD-Kommunikationsschema verwendet.
  9. Netzwerksystem nach Anspruch 1, wobei ein Diagnoseanschluss, der einen Fehler eines Kommunikationsnetzwerkes diagnostiziert, mit den ersten und zweiten Kommunikationscontrollern durch das Netzwerk verbunden ist und das erste oder zweite Kommunikationsschema verwendet.
  10. Datenübertragungsverfahren heterogener Kommunikationscontroller in einem Netzwerksystem für ein Fahrzeug, wobei das Datenübertragungsverfahren Folgendes aufweist: Verbinden eines oder mehrerer erster Kommunikationscontroller, die Nachrichten in einem ersten Kommunikationsschema übertragen, mit einem Netzwerk; Verbinden eines oder mehrerer zweiter Kommunikationscontroller, die Nachrichten in einem zweiten Kommunikationsschema übertragen, das sich von dem ersten Kommunikationsschema unterscheidet, mit dem Netzwerk; Auswählen eines Übertragungscontrollers, der eine Nachricht überträgt, aus dem einen oder den mehreren ersten Kommunikationscontrollern und dem einen oder den mehreren zweiten Kommunikationscontrollern; und Vergleichen des ersten Kommunikationsschemas und des zweiten Kommunikationsschemas mit dem des ausgewählten Übertragungscontrollers, wobei ein Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, die eigene Nachrichtenübertragung desselben beendet und die eigene Nachrichtenübertragung desselben wieder aufnimmt, sobald die ausgewählte Nachrichtenübertragung des Übertragungscontrollers abgeschlossen ist.
  11. Datenübertragungsverfahren nach Anspruch 10, wobei beim Auswählen des Übertragungscontrollers der ausgewählte Übertragungscontroller basierend auf einem ID-Feld eines Arbitration-Feldes sequenziell ausgewählt wird, das eine Nachrichtenübertragungs-Prioritätenfolge unter Nachrichten festlegt, die von dem einen oder den mehreren ersten und zweiten Kommunikationscontrollern übertragen werden.
  12. Datenübertragungsverfahren nach Anspruch 10, wobei das vergleichen des ersten Kommunikationsschemas und des zweiten Kommunikationsschemas mit dem des ausgewählten Übertragungscontrollers Folgendes enthält: Bestimmen eines Kommunikationsschemas des ausgewählten Übertragungscontrollers unter Verwendung eines nächsten Bits eines IDE-Bits in einem Control-Feld, das einen Standard-Datenframe bildet; und Bestimmen, ob das Kommunikationsschema der anderen Kommunikationscontroller als dem ausgewählten Übertragungscontroller mit dem des ausgewählten Übertragungscontrollers identisch ist, durch Vergleichen des Kommunikationsschemas der anderen Kommunikationscontroller mit dem des ausgewählten Übertragungscontrollers.
  13. Datenübertragungsverfahren nach Anspruch 10, wobei, wenn bestimmt wird, dass der ausgewählte Übertragungscontroller das erste Kommunikationsschema verwendet, das sich von dem zweiten Kommunikationsschema unterscheidet, der eine oder die mehreren zweiten Kommunikationscontroller die Kommunikationsteilnahme beenden, wenn sich eine Kommunikationsgeschwindigkeit eines Standard-Datenframes des einen oder der mehreren zweiten Kommunikationscontroller von der eines Standard-Datenframes des ausgewählten Übertragungscontrollers unterscheidet, und die Kommunikationsteilnahme wieder aufnehmen, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  14. Datenübertragungsverfahren nach Anspruch 10, wobei, wenn bestimmt wird, dass der ausgewählte Übertragungscontroller das zweite Kommunikationsschema verwendet, das sich von dem ersten Kommunikationsschema unterscheidet, der eine oder die mehreren ersten Kommunikationscontroller die Kommunikationsteilnahme beenden, wenn sich eine Kommunikationsgeschwindigkeit eines Standard-Datenframes des einen oder der mehreren ersten Kommunikationscontroller von der eines Standard-Datenframes des ausgewählten Übertragungscontrollers unterscheidet, und die Kommunikationsteilnahme wieder aufnehmen, sobald die Nachrichtenübertragung des ausgewählten Übertragungscontrollers abgeschlossen ist.
  15. Datenübertragungsverfahren nach Anspruch 10, wobei jeder Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, eine Wartezeit basierend auf einem Datenframe des ausgewählten Übertragungscontrollers berechnet und dann ein Signal des ausgewählten Übertragungscontrollers vernachlässigt, das während der berechneten Wartezeit empfangen wird, ohne das Signal als einen Fehler zu verarbeiten.
  16. Datenübertragungsverfahren nach Anspruch 10, wobei jeder Kommunikationscontroller, der ein Kommunikationsschema verwendet, das sich von dem des ausgewählten Übertragungscontrollers unterscheidet, eine Wartezeit basierend auf einem Datenframe des ausgewählten Übertragungscontrollers basierend auf einer Übertragungszeit eines ACK-Feldes in dem Datenframe des ausgewählten Übertragungscontrollers berechnet.
  17. Datenübertragungsverfahren nach Anspruch 10, wobei ein Controller des ersten und zweiten Kommunikationscontrollers ein CAN-Kommunikationscontroller ist, der ein CAN-Kommunikationsschema verwendet, während der andere Controller des ersten und zweiten Kommunikationscontrollers ein CAN-FD-Kommunikationscontroller ist, der ein CAN-FD-Kommunikationsschema verwendet.
DE102014226875.3A 2014-06-24 2014-12-22 Netzwerksystem für Fahrzeug und Datenübertragungsverfahren heterogener Kommunikationscontroller in dem gleichen System Pending DE102014226875A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2014-0077145 2014-06-24
KR1020140077145A KR101519793B1 (ko) 2014-06-24 2014-06-24 차량용 네트워크 시스템 및 이 시스템 내 이종 통신 제어기의 데이터 전송 방법

Publications (1)

Publication Number Publication Date
DE102014226875A1 true DE102014226875A1 (de) 2015-12-24

Family

ID=53394570

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014226875.3A Pending DE102014226875A1 (de) 2014-06-24 2014-12-22 Netzwerksystem für Fahrzeug und Datenübertragungsverfahren heterogener Kommunikationscontroller in dem gleichen System

Country Status (4)

Country Link
US (1) US10051091B2 (de)
KR (1) KR101519793B1 (de)
CN (1) CN105282209B (de)
DE (1) DE102014226875A1 (de)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5310761B2 (ja) * 2011-03-04 2013-10-09 トヨタ自動車株式会社 車両ネットワークシステム
US11016925B2 (en) * 2015-03-26 2021-05-25 Nxp Usa, Inc. Protocol-tolerant communications in controller area networks
DE102015213522A1 (de) * 2015-07-17 2017-01-19 Robert Bosch Gmbh Bussystem, Teilnehmerstation dafür und Verfahren zur Konfiguration eines statischen Bussystems für eine dynamische Kommunikation
KR101715319B1 (ko) 2015-11-18 2017-03-13 울산과학기술원 카운터의 오버플로우 신호를 이용한 차량 통신 송수신기용 딜레이 타이머 회로
KR101715331B1 (ko) 2016-01-19 2017-03-27 울산과학기술원 복수의 통신 방식을 선택적으로 이용하는 차량용 통신 송수신기
JP6846991B2 (ja) * 2016-07-05 2021-03-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 異常検知電子制御ユニット、車載ネットワークシステム及び異常検知方法
KR102474800B1 (ko) * 2016-12-15 2022-12-06 현대자동차주식회사 게이트웨이 및 게이트웨이 제어방법
KR102495463B1 (ko) * 2017-09-29 2023-02-02 르노코리아자동차 주식회사 차량 통신 규약의 can 프레임에서 프레임 레이턴시를 경감하는 방법
US10218499B1 (en) 2017-10-03 2019-02-26 Lear Corporation System and method for secure communications between controllers in a vehicle network
CN108667705A (zh) * 2018-05-09 2018-10-16 江苏恩达通用设备有限公司 一种canfd总线的仲裁方法
CN109409138B (zh) * 2018-11-13 2020-12-01 天津市滨海新区信息技术创新中心 一种高安全的拟态微处理器装置和数据处理方法
US11648895B2 (en) * 2018-12-27 2023-05-16 GM Global Technology Operations LLC Bounded timing analysis of intra-vehicle communication
CN111756607B (zh) * 2019-03-27 2022-02-01 北京新能源汽车股份有限公司 一种报文传输方法及装置
KR20200129260A (ko) * 2019-05-08 2020-11-18 현대자동차주식회사 차량용 리프로그래밍 장치 및 그의 리프로그래밍 방법과 그를 포함하는 차량
EP3780507A1 (de) * 2019-08-11 2021-02-17 Yamar Electronics Ltd. Verfahren und system zur durchführung doppelter nachrichtenarbitrierung
CN112805645B (zh) * 2019-09-02 2023-07-04 深圳市元征科技股份有限公司 一种车辆远程诊断方法及相关装置
CA3150313A1 (en) * 2019-09-23 2021-04-01 Anthony Cooper DUAL CAN MESSAGING BATTERY MANAGEMENT SYSTEM
KR20210054939A (ko) * 2019-11-06 2021-05-14 현대자동차주식회사 차량 제어 장치, 그를 포함한 시스템 및 그 방법
KR20220006906A (ko) * 2020-07-09 2022-01-18 주식회사 엘지에너지솔루션 통신 시스템 및 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080108833A (ko) 2007-06-11 2008-12-16 성균관대학교산학협력단 상호 상이한 복수의 네트워크 프로토콜을 사용하는 차량에적용되는 게이트웨이 디바이스, 네트워크 시스템 및 데이터변환방법

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05308373A (ja) * 1992-04-28 1993-11-19 Matsushita Electric Ind Co Ltd スター型分散制御ネットワークおよびそれに用いる端末装置
US6493335B1 (en) * 1996-09-24 2002-12-10 At&T Corp. Method and system for providing low-cost high-speed data services
US7277451B1 (en) * 2001-10-11 2007-10-02 Oxford Semiconductor, Inc. Recognition scheme for moderating wireless protocols
EP1551281A4 (de) 2002-10-09 2007-11-21 Bodymedia Inc Verfahren und gerät zur automatischen aufzeichnung von kontinuierlichen oder diskreten körperzuständen anhand von physiologischen und/oder kontext-parametern
US7191256B2 (en) * 2003-12-19 2007-03-13 Adams Lyle E Combined host interface controller for conducting communication between a host system and multiple devices in multiple protocols
JP5303617B2 (ja) 2005-10-03 2013-10-02 日立オートモティブシステムズ株式会社 車両制御システム
EP2037631B1 (de) * 2006-07-21 2017-04-26 Panasonic Intellectual Property Management Co., Ltd. Wettstreitsteuerung ausführende kommunikationseinrichtung
JP4888396B2 (ja) * 2007-03-05 2012-02-29 ソニー株式会社 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム
US20080225723A1 (en) * 2007-03-16 2008-09-18 Futurewei Technologies, Inc. Optical Impairment Aware Path Computation Architecture in PCE Based Network
JP4958640B2 (ja) * 2007-05-29 2012-06-20 三菱電機株式会社 通信装置、設備機器及び設備機器通信システム
US8516079B2 (en) * 2008-09-25 2013-08-20 Aten International Co., Ltd. Remote desktop control system using USB interface and method thereof
KR20110035247A (ko) * 2009-09-30 2011-04-06 한국전자통신연구원 Can 기반 시스템에서의 id 동적 할당 방법
JP5598259B2 (ja) * 2010-10-29 2014-10-01 株式会社オートネットワーク技術研究所 処理システム、処理装置及び電源制御方法
RU2603534C2 (ru) * 2011-06-29 2016-11-27 Роберт Бош Гмбх Способ и устройство для последовательной передачи данных с гибким размером сообщений и переменной длительностью бита
JP5335869B2 (ja) 2011-09-07 2013-11-06 三菱電機株式会社 制御システム
US9231789B2 (en) * 2012-05-04 2016-01-05 Infineon Technologies Ag Transmitter circuit and method for operating thereof
DE102012224024A1 (de) * 2012-12-20 2014-06-26 Robert Bosch Gmbh Datenübertragung unter Nutzung eines Protokollausnahmezustands
EP2800316A1 (de) * 2013-05-01 2014-11-05 Renesas Electronics Europe GmbH Can fd
EP3025426B1 (de) * 2013-07-24 2019-01-30 NXP USA, Inc. Sendeempfängerschaltung und verfahren für steuergerätenetze
JP6032247B2 (ja) * 2013-10-09 2016-11-24 株式会社デンソー 歪み補償システム及び通信装置
JP6126980B2 (ja) * 2013-12-12 2017-05-10 日立オートモティブシステムズ株式会社 ネットワーク装置およびネットワークシステム
JP2015144353A (ja) * 2014-01-31 2015-08-06 株式会社デンソー 通信システム
US9425992B2 (en) * 2014-02-20 2016-08-23 Freescale Semiconductor, Inc. Multi-frame and frame streaming in a controller area network (CAN) with flexible data-rate (FD)
US9852104B2 (en) * 2014-02-20 2017-12-26 Qualcomm Incorporated Coexistence of legacy and next generation devices over a shared multi-mode bus

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080108833A (ko) 2007-06-11 2008-12-16 성균관대학교산학협력단 상호 상이한 복수의 네트워크 프로토콜을 사용하는 차량에적용되는 게이트웨이 디바이스, 네트워크 시스템 및 데이터변환방법

Also Published As

Publication number Publication date
CN105282209A (zh) 2016-01-27
KR101519793B1 (ko) 2015-05-12
CN105282209B (zh) 2020-03-27
US20150373158A1 (en) 2015-12-24
US10051091B2 (en) 2018-08-14

Similar Documents

Publication Publication Date Title
DE102014226875A1 (de) Netzwerksystem für Fahrzeug und Datenübertragungsverfahren heterogener Kommunikationscontroller in dem gleichen System
DE102015216121B4 (de) Weiterleitungsvorrichtung
DE102016107923B4 (de) Detektion eines ECU-Erdungsfehlers mit Spannungsmessungen am CAN-Bus
EP2090031B1 (de) Verfahren und anordnung zur kommunikation auf einem lin-bus
DE102011005515B4 (de) Kommunikationsnetzwerksystem mit einem Netzwerk hohen Ranges und Netzwerken niedrigen Ranges, Austauschanschluss zur Verbindung des Netzwerks hohen Ranges und eines Netzwerks niedrigen Ranges, Mikrocomputer zur Steuerung der Verbindung zwischen einer Übertragungsleitung eines Netzwerks niedrigen Ranges und einer Übertragungsleitung des Netzwerks hohen Ranges, und Kommunikations-Sender/Empfänger, der mit der Übertragungsleitung eines Netzwerks niedrigen Ranges und der Übertragungsleitung des Netzwerks hohen Ranges verbunden ist
DE102014224877A1 (de) Fahrzeugvorrichtung für eine Signalwandlung zwischen Ethernet und Can-Kommunikation und einSteuerverfahren dazu
DE102017113564A1 (de) Betriebsverfahren eines Kommunikationsknotens zum Erfassen von Verbindungsfehlern in einem Netzwerk
DE102017202895A1 (de) Verfahren zur Zeitsynchronisation zwischen Kommunikationsknoten im Netzwerk
DE102019130502A1 (de) Fahrzeug und Verfahren für eine fahrzeuginterne Mitteilungsübertragung
DE102013217595A1 (de) Bereitstellung unterschiedlicher Datenübertragungsraten und Redundanz durch gemeinsame und getrennte Nutzung von physikalischen Übertragungskanälen im Kraftfahrzeug
DE102013020277A1 (de) Bit-timing-symmetrisierung
DE102015213378A1 (de) Verfahren und Gerät zum Diagnostizieren eines Netzes
DE102012207642A1 (de) Verbindungsverfahren für Bus-Controller und Kommunikationssystem
DE102018114778A1 (de) Verfahren zum Verhindern von Diagnosefehlern im Fahrzeugnetzwerk und Vorrichtung dafür
EP3172871B1 (de) Zugriffsverfahren mit zugriffsschlitzen und prioritätsauflösung
DE102017200958A1 (de) Betriebsmodus-übergangsverfahren in einem netz
DE102017123251A1 (de) Betriebsverfahren eines Kommunikationsknotens für selektives Aufwecken im Fahrzeugnetzwerk
DE102016210274A1 (de) Betriebsverfahren eines kommunikationsknotens in einem fahrzeugnetz
DE102013227169A1 (de) Gateway-Vorrichtung und Nachrichtenroutingverfahren
DE102016219940A1 (de) Intelligente Ladekommunikationsumschaltung bei CAN-basierten Ladesystemen
DE102017200936A1 (de) Verfahren des Sendens von Daten, basierend auf Prioritäten in Netzwerk
DE112016005087T5 (de) Relaisvorrichtung, elektronische Steuervorrichtung und fahrzeugmontiertes Netzsystem
DE102017127284A1 (de) Betriebsverfahren eines Kommunikationsknotens zur Zeitsynchronisation im Fahrzeugnetzwerk
DE102010028485A1 (de) Verfahren und Vorrichtung zur Absicherung von über eine Schnittstelle zu übertragenden Datenpaketen
DE102017123270A1 (de) Betriebsverfahren eines Kommunikationsknotens für eine Spiegelung in einem Fahrzeugnetzwerk

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012400000

Ipc: H04L0012407000

R016 Response to examination communication