DE102017121049A1 - Kommunikationsverfahren, welches auf einer Fahrzeugsicherheitsintegritätsstufe im Fahrzeugnetzwerk basiert, und Vorrichtung für dasselbige - Google Patents

Kommunikationsverfahren, welches auf einer Fahrzeugsicherheitsintegritätsstufe im Fahrzeugnetzwerk basiert, und Vorrichtung für dasselbige Download PDF

Info

Publication number
DE102017121049A1
DE102017121049A1 DE102017121049.0A DE102017121049A DE102017121049A1 DE 102017121049 A1 DE102017121049 A1 DE 102017121049A1 DE 102017121049 A DE102017121049 A DE 102017121049A DE 102017121049 A1 DE102017121049 A1 DE 102017121049A1
Authority
DE
Germany
Prior art keywords
message
ethernet
communication node
asil
authentication information
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
DE102017121049.0A
Other languages
English (en)
Inventor
Jeong Seok Han
Sang Woo Yu
Dong Ok Kim
Jin Hwa YUN
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
Kia Corp
Original Assignee
Hyundai Motor Co
Kia Motors Corp
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
Priority claimed from KR1020170095218A external-priority patent/KR102352527B1/ko
Application filed by Hyundai Motor Co, Kia Motors Corp filed Critical Hyundai Motor Co
Publication of DE102017121049A1 publication Critical patent/DE102017121049A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40097—Interconnection with other networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40104—Security; Encryption; Content protection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/44—Star or tree networks
    • H04L2012/445—Star or tree networks with switching in a hub, e.g. ETHERNET switch

Landscapes

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

Abstract

Ein Betriebsverfahren eines ersten Kommunikationsknotens (200), welcher Kommunikationen zwischen einem Ethernet-basierten Netzwerk und einem Steuergerätenetzwerk (CAN) unterstützt, weist auf: Empfangen einer Ethernet-Nachricht von einem zweiten Kommunikationsknoten (211), der zu dem Ethernetbasierten Netzwerk gehört, Durchführen einer Integritätsverifikation (S1005) auf eine erste Fahrzeugsicherheitsintegritätsstufe-(ASIL-)Authentifizierungsinformation, welche in der Ethernet-Nachricht enthalten ist, Erzeugen einer CAN-Nachricht (S1009) basierend auf der Ethernet-Nachricht, für welche die Integritätsverifikation abgeschlossen wurde, und Senden der CAN-Nachricht (S1010) an einen dritten Kommunikationsknoten (231), der zum CAN gehört.

Description

  • Querverweis auf verwandte Anmeldungen
  • Diese Anmeldung beruht auf und beansprucht den Prioritätsvorteil der am 13. September 2016 beim koreanischen Patentamt (KIPO) eingereichten koreanischen Patentanmeldung Nr. 10-2016-0118340 sowie der am 27. Juli 2017 beim KIPO eingereichten koreanischen Patentanmeldung Nr. 10-2017-0095128 , deren Gesamtheit durch Bezugnahme hierin einbezogen ist, als wäre sie hierin vollständig beschrieben.
  • Technisches Gebiet
  • Die vorliegende Erfindung betrifft eine Kommunikationstechnologie in einem Fahrzeugnetzwerk und insbesondere eine Fahrzeugsicherheitsintegritätsstufe-(ASIL-)basierte Kommunikationstechnologie in einem Fahrzeugnetzwerk, welches ein Steuergerätenetzwerk-(CAN-)basiertes und ein Ethernet-basiertes Netzwerk aufweist.
  • Hintergrund
  • Elektronische Vorrichtungen, welche in Fahrzeugen installiert sind, haben sich in ihrer Anzahl und Vielfalt mit der jüngsten Digitalisierung von Fahrzeugteilen signifikant erhöht. Im Allgemeinen können elektronische Vorrichtungen im gesamten Fahrzeug verwendet werden, wie beispielsweise in einem Antriebsstrangsteuerungssystem (z. B. einem Motorsteuerungssystem, einem Automatikgetriebesteuerungssystem oder dergleichen), einem Karosseriesteuerungssystem (z. B. einem Karosserie-Elektronikausstattung-Steuerungssystem, einem Komfortvorrichtungssteuerungssystem, einem Leuchtensteuerungssystem oder dergleichen), einem Chassissteuerungssystem (z. B. einem Lenkungsvorrichtungssteuerungssystem, einem Bremsensteuerungssystem, einem Aufhängungssteuerungssystem oder dergleichen), einem Fahrzeugnetzwerk (z. B. einem Steuergerätenetzwerk (Controller Area Network, CAN), einem FlexRay-basierten Netzwerk, einem Media-Oriented-System-Transport-(MOST-)basierten Netzwerk, einem Multimediasystem (z. B. einem Navigationsvorrichtungssystem, einem Telematiksystem, einem Infotainmentsystem oder dergleichen) und so weiter.
  • Die elektronischen Vorrichtungen, welche in jedem dieser Systeme verwendet werden, sind mittels des Fahrzeugnetzwerks, welches Funktionen der elektronischen Vorrichtungen unterstützt, verbunden. Beispielsweise kann das CAN eine Übertragungsrate von bis zu 1 Mbps unterstützen und automatisches erneutes Übertragen von kollidierenden Nachrichten, eine auf einer Zyklus-Redundanzschnittstelle (CRC) basierende Fehlerdetektion oder dergleichen unterstützen. Das FlexRay-basierte Netzwerk kann eine Übertragungsrate von bis zu 10 Mbps unterstützen und kann simultane Datenübertragung durch zwei Kanäle, synchrone Datenübertragung oder dergleichen unterstützen. Das MOST-basierte Netzwerk ist ein Kommunikationsnetzwerk für hochqualitatives Multimedia, welches eine Übertragungsrate von bis zu 150 Mbps unterstützt.
  • Das Telematiksystem und das Infotainmentsystem erfordern indessen, wie die meisten verbesserten Sicherheitssysteme eines Fahrzeugs es tun, höhere Übertragungsraten und Systemerweiterbarkeit. Das CAN, das FlexRay-basierte Netzwerk und dergleichen können jedoch solche Erfordernisse nicht ausreichend unterstützen. Das MOST-basierte Netzwerk kann insbesondere eine höhere Übertragungsrate als das CAN oder als das FlexRay-basierte Netzwerk unterstützen. Jedoch kann das Anwenden des MOST-basierten Netzwerks auf Fahrzeugnetzwerke kostspielig sein. Aufgrund dieser Nachteile wird häufig ein Ethernet-basiertes Netzwerk als ein Fahrzeugnetzwerk verwendet. Das Ethernet-basierte Netzwerk kann bidirektionale Kommunikation durch ein Paar aus Windungen unterstützen und kann eine Übertragungsrate von bis zu 10 Gbps unterstützen.
  • Das Fahrzeugnetzwerk kann unterschiedliche Kommunikationsprotokolle unterstützen. Beispielsweise kann das Fahrzeugnetzwerk das CAN, ein Ethernet-basiertes Netzwerk und dergleichen aufweisen. In diesem Fall ist es erforderlich, ein Protokoll zu haben, welches Kommunikationen zwischen dem CAN und dem Ethernetbasierten Netzwerk unterstützt. Außerdem sind Techniken zum Verbessern der Kommunikationszuverlässigkeit in dem Nachrichtenverkehr zwischen dem CAN und dem Ethernet-basierten Netzwerk erforderlich.
  • Erläuterung
  • Die vorliegende Erfindung schafft Fahrzeugsicherheitsintegritätsstufe-(ASIL-)basiertes Kommunikationsverfahren und -Vorrichtungen in einem Fahrzeugnetzwerk, welches ein CAN-basiertes und ein Ethernet-basiertes Netzwerk aufweist.
  • Gemäß Ausführungsformen der vorliegenden Erfindung kann ein Betriebsverfahren eines ersten Kommunikationsknotens, welcher Kommunikationen bzw. Nachrichtenverkehr zwischen einem Ethernet-basierten Netzwerk und einem Steuergerätenetzwerk (Controller Area Network, CAN) unterstützt, aufweisen Empfangen einer Ethernet-Nachricht von einem zweiten Kommunikationsknoten, der zu dem Ethernet-basierten Netzwerk gehört, Durchführen einer Integritätsverifikation auf eine erste Fahrzeugsicherheitsintegritätsstufe-(ASIL-)Authentifizierungsinformation, welche in der Ethernet-Nachricht enthalten ist, Erzeugen einer CAN-Nachricht basierend auf der Ethernet-Nachricht, für welche die Integritätsverifikation abgeschlossen wurde, und Senden der CAN-Nachricht an einen dritten Kommunikationsknoten, der zum CAN gehört.
  • Der zweite Kommunikationsknoten kann ein Endknoten sein, und die erste ASIL-Authentifizierungsinformation kann durch den Endknoten erzeugt werden.
  • Die Integritätsverifikation kann durchgeführt werden, wenn ein Ziel der Ethernet-Nachricht das CAN ist.
  • Die Integritätsverifikation kann durchgeführt werden, wenn die Ethernet-Nachricht eine Steuerungsinformation oder eine Verwaltungsinformation aufweist.
  • Die CAN-Nachricht kann eine zweite ASIL-Authentifizierungsinformation aufweisen, die zweite ASIL-Authentifizierungsinformation kann für eine Integritätsverifikation auf die CAN-Nachricht verwendet werden, und die zweite ASIL-Authentifizierungsinformation kann durch den ersten Kommunikationsknoten erzeugt werden.
  • Die CAN-Nachricht kann mindestens eine durch eine Routingtabelle angegebene Dateneinheit unter einer Mehrzahl/Vielzahl von Dateneinheiten, welche in der Ethernet-Nachricht enthalten sind, aufweisen, und die Routingtabelle kann zum CAN zu übertragende Dateneinheiten angeben.
  • Die CAN-Nachricht kann mindestens eine Dateneinheit, welche eine von in einem Speicher des ersten Kommunikationsknotens gespeicherten Dateneinheiten aus aktualisierte Information aufweist, unter einer Mehrzahl/Vielzahl von Dateneinheiten, welche in der Ethernet-Nachricht enthalten sind, aufweisen.
  • Die CAN-Nachricht kann gemäß einer Übertragungsperiode des CANs gesendet werden.
  • Gemäß Ausführungsformen der vorliegenden Erfindung kann ferner ein Betriebsverfahren eines ersten Kommunikationsknotens, welcher Kommunikationen zwischen einem Ethernet-basierten Netzwerk und einem Steuergerätenetzwerk (CAN) unterstützt, aufweisen Empfangen einer CAN-Nachricht von einem zweiten Kommunikationsknoten, welcher zu dem CAN gehört, Durchführen einer Integritätsverifikation auf eine erste Fahrzeugsicherheitsintegritätsstufe-(ASIL-)Authentifizierungsinformation, welche in der CAN-Nachricht enthalten ist, Erzeugen einer Ethernet-Nachricht basierend auf der CAN-Nachricht, für welche die Integritätsverifikation abgeschlossen wurde, und Senden der Ethernet-Nachricht an einen dritten Kommunikationsknoten, welcher zu dem Ethernet-basierten Netzwerk gehört.
  • Der zweite Kommunikationsknoten kann ein Endknoten sein, und die erste ASIL-Authentifizierungsinformation kann durch den Endknoten erzeugt werden.
  • Die Ethernet-Nachricht kann eine zweite ASIL-Authentifizierungsinformation aufweisen, die zweite ASIL-Authentifizierungsinformation kann für eine Integritätsverifikation auf die Ethernet-Nachricht verwendet werden, und die zweite ASIL-Authentifizierungsinformation kann durch den ersten Kommunikationsknoten erzeugt werden.
  • Die Ethernet-Nachricht kann mindestens eine durch eine Routingtabelle angegebene Dateneinheit unter einer Mehrzahl/Vielzahl von Dateneinheiten, welche in der CAN-Nachricht enthalten sind, aufweisen, und die Routingtabelle kann zum Ethernet-basierten Netzwerk zu übertragende Dateneinheiten angeben.
  • Gemäß Ausführungsformen der vorliegenden Erfindung kann ferner ein erster Kommunikationsknoten, welcher Kommunikationen zwischen einem Ethernet-basierten Netzwerk und einem Steuergerätenetzwerk (CAN) unterstützt, aufweisen einen Prozessor und einen Speicher, welcher mindestens eine durch den Prozessor ausgeführte Instruktion speichert. Die mindestens eine Instruktion kann dazu eingerichtet sein, eine Ethernet-Nachricht von einem zweiten Kommunikationsknoten, welcher zu dem Ethernet-basierten Netzwerk gehört, zu empfangen, eine Integritätsverifikation auf eine erste Fahrzeugsicherheitsintegritätsstufe-(ASIL-)Authentifizierungsinformation, welche in der Ethernet-Nachricht enthalten ist, durchzuführen, eine CAN-Nachricht basierend auf der Ethernet-Nachricht, für welche die Integritätsverifikation durchgeführt wurde, zu erzeugen und die CAN-Nachricht an einen dritten Kommunikationsknoten, welcher zu dem CAN gehört, zu senden.
  • Der zweite Kommunikationsknoten kann ein Endknoten sein, und die erste ASIL-Authentifizierungsinformation kann durch den Endknoten erzeugt werden.
  • Die Integritätsverifikation kann durchgeführt werden, wenn ein Ziel der Ethernet-Nachricht das CAN ist.
  • Die Integritätsverifikation kann durchgeführt werden, wenn die Ethernet-Nachricht eine Steuerungsinformation oder eine Verwaltungsinformation aufweist.
  • Die CAN-Nachricht kann eine zweite ASIL-Authentifizierungsinformation aufweisen, die zweite ASIL-Authentifizierungsinformation kann für eine Integritätsverifikation auf die CAN-Nachricht verwendet werden, und die zweite ASIL-Authentifizierungsinformation kann durch den ersten Kommunikationsknoten erzeugt werden.
  • Die CAN-Nachricht kann mindestens eine durch eine Routingtabelle angegebene Dateneinheit unter einer Mehrzahl/Vielzahl von Dateneinheiten, welche in der Ethernet-Nachricht enthalten sind, aufweisen, und die Routingtabelle kann zum CAN zu übertragende Dateneinheiten angeben.
  • Die CAN-Nachricht kann mindestens eine Dateneinheit, welche eine von in einem Speicher des ersten Kommunikationsknotens gespeicherten Dateneinheiten aus aktualisierte Information aufweist, unter einer Mehrzahl/Vielzahl von Dateneinheiten, welche in der Ethernet-Nachricht enthalten sind, aufweisen.
  • Die CAN-Nachricht kann gemäß einer Übertragungsperiode des CANs gesendet werden.
  • Gemäß Ausführungsformen der vorliegenden Erfindung kann ein Endknoten (z. B. eine elektronische Steuereinheit (ECU)), welcher zu einem CAN oder einem Ethernet-basierten Netzwerk gehört, eine ASIL-Authentifizierungsinformation unter Verwendung eines Authentifikationsalgorithmus, welcher Anforderungen gemäß der ASIL erfüllt, erzeugen, eine Nachricht (z. B. eine CAN-Nachricht oder eine Ethernet-Nachricht), welche eine Nutzinformation bzw. Nutzlast und die ASIL-Authentifizierungsinformation aufweist, erzeugen und die erzeugte Nachricht senden.
  • Ein Gateway, welches Nachrichtenverkehr zwischen dem CAN und dem Ethernet-basierten Netzwerk unterstützt, kann die Nachricht von dem Endknoten empfangen und einen Integritätsverifikationsvorgang auf die Nachricht basierend auf der ASIL-Authentifizierungsinformation durchführen. Wenn die Integritätsverifikation der Nachricht erfolgreich abgeschlossen ist, kann das Gateway eine neue Nachricht, welche eine integritätsverifizierte Dateneinheit enthält, erzeugen und die erzeugte Nachricht an das CAN oder das Ethernet-basierte Netzwerk senden. Die an das CAN oder das Ethernet-basierte Netzwerk gesendete Nachricht kann ferner ASIL-Authentifizierungsinformationen für die Nachricht aufweisen. Falls andererseits die Integritätsverifikation der Nachricht scheitert, kann das Gateway die Nachricht verwerfen. Dementsprechend kann die Kommunikationszuverlässigkeit in dem Nachrichtenverkehr zwischen dem CAN und dem Ethernet-basierten Netzwerk verbessert werden und kann die Leistungsfähigkeit des Fahrzeugnetzwerks verbessert werden.
  • Kurze Beschreibung der Zeichnungen
  • Ausführungsformen der vorliegenden Erfindung werden ersichtlicher, indem Ausgestaltungen der vorliegenden Erfindung unter Bezugnahme auf die beigefügten Zeichnungen detailliert beschrieben werden, wobei:
  • 1 ein Blockdiagramm ist, welches eine erste Ausführungsform einer Fahrzeugnetzwerktopologie darstellt,
  • 2 ein Blockdiagramm ist, welches eine zweite Ausführungsform einer Fahrzeugnetzwerktopologie darstellt,
  • 3 ein Blockdiagramm ist, welches eine erste Ausführungsform einer Ethernet-Nachricht in einem Fahrzeugnetzwerk darstellt,
  • 4 ein Blockdiagramm ist, welches eine erste Ausführungsform eines Kopfs, der in einer Ethernet-Nachricht enthalten ist, darstellt,
  • 5 ein Blockdiagramm ist, welches eine erste Ausführungsform einer CAN-Nachricht in einem Fahrzeugnetzwerk darstellt,
  • 6 ein Blockdiagramm ist, welches eine zweite Ausführungsform einer CAN-Nachricht in einem Fahrzeugnetzwerk darstellt,
  • 7 ein Blockdiagramm ist, welches eine erste Ausführungsform eines zu einem Fahrzeugnetzwerk zugehörenden Kommunikationsknotens darstellt,
  • 8 ein Blockdiagramm ist, welches eine zweite Ausführungsform eines zu einem Fahrzeugnetzwerk zugehörenden Kommunikationsknotens darstellt,
  • 9 ein Blockdiagramm ist, welches eine erste Ausführungsform eines zu einem Fahrzeugnetzwerk zugehörenden Gateways darstellt,
  • 10 ein Ablaufdiagramm ist, welches eine erste Ausführungsform eines Betriebsverfahrens eines Kommunikationsknotens in einem Fahrzeugnetzwerk darstellt,
  • 11 ein Blockdiagramm ist, welches eine zweite Ausführungsform einer Ethernet-Nachricht in einem Fahrzeugnetzwerk darstellt,
  • 12 ein konzeptionelles Diagramm ist, welches eine erste Ausführungsform einer Parsing-Operation und eines Kandidat-Nutzinformation-Erzeugungsvorgangs darstellt,
  • 13 ein konzeptionelles Diagramm ist, welches eine erste Ausführungsform eines Finale-Nutzinformation-Erzeugungsvorgangs darstellt,
  • 14 ein Blockdiagramm ist, welches eine dritte Ausführungsform einer CAN-Nachricht in einem Fahrzeugnetzwerk darstellt,
  • 15 ein Blockdiagramm ist, welches eine vierte Ausführungsform einer CAN-Nachricht in einem Fahrzeugnetzwerk darstellt, und
  • 16 ein Ablaufdiagramm ist, welches eine zweite Ausführungsform eines Betriebsverfahrens eines Kommunikationsknotens in einem Fahrzeugnetzwerk darstellt.
  • Es ist zu verstehen, dass die oben genannten Zeichnungen nicht notwendigerweise maßstabsgetreu sind und eine etwas vereinfachte Darstellungsweise von verschiedenen bevorzugten Eigenschaften darstellen, welche die Grundprinzipien der Erfindung veranschaulichen. Die spezifischen Ausgestaltungsmerkmale der vorliegenden Erfindung, einschließlich z. B. konkrete Abmessungen, Ausrichtungen, Positionen und Formen werden teilweise von der jeweiligen geplanten Anwendung und Nutzungsumgebung vorgegeben.
  • Detaillierte Beschreibung
  • Nachstehend werden Ausführungsformen der vorliegenden Erfindung unter Bezugnahme auf die beigefügten Zeichnungen im Detail beschrieben. Wie es den Fachmännern auf dem Gebiet jedoch klar wird, können die beschriebenen Ausführungsformen auf zahlreiche verschiedene Weisen modifiziert werden, ohne dabei vom Wesen oder Umfang der vorliegenden Erfindung abzuweichen. Gleiche Bezugszeichen beziehen sich ferner durchgehend durch die Beschreibung auf gleiche oder gleichartige Elemente.
  • Die hierin verwendete Terminologie dient lediglich dem Zweck des Beschreibens von bestimmten Ausführungsformen und ist nicht dazu gedacht, die Erfindung zu beschränken. Die wie hierin verwendeten Singular-Formen „ein”, „eine”, „eines” und „der”, „die”, „das” sind dazu gedacht, auch die Mehrzahlformen einzuschließen, außer der Kontext weist eindeutig auf etwas anderes hin. Ferner ist zu verstehen, dass die Begriffe „aufweisen” und/oder „aufweisend” bei Verwendung in dieser Beschreibung das Vorliegen von genannten Merkmalen, ganzen Zahlen, Schritten, Vorgängen, Elementen und/oder Bauteilen spezifizieren, jedoch nicht die Anwesenheit oder das Hinzufügen von einem oder mehreren Merkmalen, ganzen Zahlen, Schritten, Vorgängen, Elementen, Bauteilen und/oder Gruppen davon ausschließen. Wie hierin verwendet, umfasst der Begriff ”und/oder” irgendeine sowie alle Kombinationen von einem oder mehreren der dazugehörig aufgezählten Gegenstände.
  • Es ist zu verstehen, dass der Begriff „Fahrzeug” oder „Fahrzeug-...” oder irgendein ähnlicher Begriff, welcher hier verwendet wird, Kraftfahrzeuge im Allgemeinen, wie z. B. Personenkraftfahrzeuge, einschließlich sogenannter Sportnutzfahrzeuge (SUV), Busse, Lastwagen, zahlreiche kommerzielle Fahrzeuge, Wasserfahrzeuge, einschließlich einer Vielzahl an Booten und Schiffen, Flugzeuge und dergleichen einschließt und Hybridfahrzeuge, elektrische Fahrzeuge, Verbrenner, Plug-in-Hybridelektrofahrzeuge, wasserstoffbetriebene Fahrzeuge und andere Fahrzeuge für alternative Treibstoffe (z. B. Treibstoffe, welche aus anderen Ressourcen als Erdöl hergestellt werden) einschließt.
  • Obwohl beispielhafte Ausführungsformen als eine Mehrzahl an Einheiten nutzend, um die beispielhaften Vorgänge durchzuführen, beschrieben werden, ist es zu verstehen, dass die beispielhaften Vorgänge auch durch ein einziges Modul oder eine Mehrzahl an Modulen durchgeführt werden können. Es ist außerdem zu verstehen, dass eine Steuereinrichtung/Steuereinheit einen oder mehrere der nachstehend beschriebenen Vorgänge durchführen kann und dass sich der Begriff Steuereinrichtung/Steuereinheit auf eine Hardware-Vorrichtung bezieht, welche einen Speicher und einen Prozessor aufweist. Der Speicher ist dazu eingerichtet, die Module zu speichern, und der Prozessor ist speziell dazu eingerichtet, die Module auszuführen, um einen oder mehr Vorgänge, welche weiter unten beschrieben werden, durchzuführen. Ferner ist zu verstehen, dass die hierin beschriebenen Einheiten oder Module eine Steuereinrichtung/Steuereinheit zum Steuern des Betriebs der Einheit oder des Moduls verkörpern können.
  • Ferner kann eine Steuerlogik der vorliegenden Erfindung als nichtflüchtige, computerlesbare Medien auf einem computerlesbaren Medium ausgeführt sein, welches ausführbare Programminstruktionen enthält, die mittels eines Prozessors, einer Steuereinrichtung/Steuereinheit oder dergleichen ausgeführt werden. Beispiele des computerlesbaren Mediums weisen auf, sind aber nicht beschränkt auf, Nur-Lese-Speicher (ROM), Speicher mit wahlfreiem Zugriff (RAM), Compact-Disk-(CD)-ROMs, Magnetbänder, Disketten, Flash-Speicher, Chipkarten und optische Datenspeichervorrichtungen. Das computerlesbare Aufzeichnungsmedium kann auch in netzwerkverbundenen Computersystemen verteilt werden, so dass die computerlesbaren Medien auf eine verteilte Art gespeichert und ausgeführt werden, z. B. mittels eines Telematikservers oder eines Steuergerätenetzwerks bzw. Controller Area Network (CAN).
  • Da die vorliegende Erfindung auf zahlreiche Weisen modifiziert werden kann und diverse Formen haben kann, werden bestimmte Ausführungsformen in den beigefügten Zeichnungen gezeigt und in der detaillierten Beschreibung im Detail beschrieben. Es ist jedoch zu verstehen, dass diese nicht dazu gedacht ist, die vorliegende Erfindung auf die bestimmten Ausführungsformen zu beschränken, sondern dass die vorliegende Erfindung im Gegenteil alle Modifikationen und Alternativen, welche in das Wesen und den Umfang der vorliegenden Erfindung fallen, abdecken soll.
  • Relationale Begriffe, wie z. B. erster, zweiter und dergleichen, können zum Beschreiben verschiedener Elemente verwendet werden, jedoch sind die Elemente nicht durch diese Begriffe beschränkt. Diese Begriffe werden nur verwendet, um ein Element von einem anderen zu unterscheiden. Beispielsweise kann ein erstes Bauteil ein zweites Bauteil genannt werden, ohne dabei vom Umfang der vorliegenden Erfindung abgewichen zu sein, und das zweite Bauteil kann auch auf ähnliche Weise das erste Bauteil genannt werden. Der Begriff „und/oder” bedeutet irgendeine oder jede Kombination einer Mehrzahl an betreffenden und beschriebenen Gegenständen.
  • Wenn davon gesprochen wird, dass eine bestimmte Komponente „gekuppelt ist mit” oder „verbunden ist mit” einer anderen Komponenten, ist zu verstehen, dass die bestimmte Komponente direkt mit der anderen Komponente „verbunden ist” oder „gekuppelt ist” oder zwischen diesen eine weitere Komponenten angeordnet sein kann. Wenn im Gegensatz dazu erwähnt ist, dass eine bestimmte Komponente „direkt verbunden ist mit” oder „direkt gekuppelt ist mit” einer anderen Komponente, ist zu verstehen, dass zwischen diesen keine weitere Komponente angeordnet ist.
  • Soweit nicht besonders erwähnt oder aus dem Kontext naheliegend, ist der hierin verwendete Begriff „etwa” als innerhalb einer normalen Toleranz in der Technik, z. B. innerhalb 2 Standardabweichungen vom Mittelwert, zu verstehen. „Etwa” kann als innerhalb von 10%, 9%, 8%, 7%, 6%, 5%, 4%, 3%, 2%, 1%, 0,5%, 0,1%, 0,05% oder 0,01% vom genannten Wert verstanden werden. Wenn nichts Gegenteiliges aus dem Kontext deutlich ist, sind alle hierin bereitgestellten Zahlenwerte durch den Begriff „etwa” modifiziert.
  • Wenn nicht andersartig definiert, haben alle hierin verwendeten Begriffe (einschließlich technische und wissenschaftliche Begriffe) die gleiche Bedeutung wie von einem Fachmann in der Technik, zu welcher diese Erfindung gehört, im Allgemeinen verstanden wird. Begriffe, wie z. B. Begriffe, welche allgemein verwendet werden und welche in Wörterbüchern vorhanden sind, sollten als Bedeutungen, welche mit den kontextabhängigen Bedeutungen in der Technik übereinstimmen, aufweisend interpretiert werden. Soweit nicht klar definiert, sind Begriffe in dieser Beschreibung nicht vollkommen, unverhältnismäßig als deren formale Bedeutungen zu interpretieren.
  • Nachstehend werden Ausführungsformen der vorliegenden Erfindung im Detail unter Bezugnahme auf die beigefügten Zeichnungen beschrieben. Beim Beschreiben der Erfindung beziehen sich durchgehend durch die Beschreibung der Figuren gleiche Bezugszeichen auf gleiche Elemente und wird eine erneute Beschreibung davon weggelassen, um das Gesamtverständnis der Erfindung zu erleichtern.
  • 1 ist ein Blockdiagramm, welches eine erste Ausführungsform einer Fahrzeugnetzwerktopologie darstellt.
  • Unter Bezugnahme auf 1 kann ein ein Fahrzeugnetzwerk bildender Kommunikationsknoten ein Gateway, ein Switch (oder eine Bridge) oder ein Endknoten sein. Das Gateway 100 kann mit mindestens einem Switch 110, 110-1, 110-2, 120 und 130 verbunden sein und kann dazu eingerichtet sein, unterschiedliche Netzwerke zu verbinden. Beispielsweise kann das Gateway 100 Verbindungen zwischen einem Switch, welcher ein Steuergerätenetzwerk bzw. Controller Area Network (CAN) (oder ein FlexRay-Netzwerk, ein Media-Oriented-System-Transport-(MOST-)Netzwerk oder ein Lokalverbindungsnetzwerk-(Local Interconnect Network, LIN-)Netzwerk) unterstützt, und einem Switch, welcher ein Ethernet-Protokoll unterstützt, unterstützen. Jeder der Switches 110, 110-1, 110-2, 120 und 130 kann mit mindestens einem der Endknoten 111, 112, 113, 121, 122, 123, 131, 132 und 133 verbunden sein. Jeder der Switches 110, 110-1, 110-2, 120 und 130 kann die Endknoten 111, 112, 113, 121, 122, 123, 131, 132 und 133 miteinander verbinden und mindestens einen der Endknoten 111, 112, 113, 121, 122, 123, 131, 132 und 133, welcher mit dem Switch verbunden ist, steuern.
  • Jeder der Endknoten 111, 112, 113, 121, 122, 123, 131, 132 und 133 kann eine elektronische Steuereinheit (ECU), welche dazu eingerichtet ist, zahlreiche Arten von in einem Fahrzeug montierten Vorrichtungen zu steuern, aufweisen. Beispielsweise kann jeder der Endknoten 111, 112, 113, 121, 122, 123, 131, 132 und 133 eine ECU, welche in einer Infotainment-Vorrichtung (z. B. einer Anzeigevorrichtung, einer Navigationsvorrichtung und einer Rundumsichtmonitor-(AVM-)Vorrichtung) vorhanden ist, aufweisen.
  • 2 ist ein Blockdiagramm, welches eine zweite Ausführungsform einer Fahrzeugnetzwerktopologie darstellt.
  • Bezugnehmend auf 2 kann ein Fahrzeugnetzwerk ein Ethernet-basiertes Netzwerk, ein CAN und dergleichen aufweisen. Ein Gateway 200, welches dem Fahrzeugnetzwerk angehört, kann Nachrichtenverkehr zwischen dem Ethernetbasierten Netzwerk und dem CAN unterstützen. Das Ethernet-basierte Netzwerk kann einen Switch #1 210, einen Switch #2 220, einen Endknoten #1 211, einen Endknoten #2 212, einen Endknoten #3 213, einen Endknoten #4 221, einen Endknoten #5 222 und dergleichen aufweisen. Der Endknoten #1 211, der Endknoten #2 212 und der Endknoten #3 213 können mit dem Switch #1 210 verbunden sein, und der Endknoten #4 221 und der Endknoten #5 222 können mit dem Switch #2 220 verbunden sein. Außerdem können der Switch #1 210 und der Switch #2 220 mit dem Gateway 200 verbunden sein. Eine auf dem Ethernet-Protokoll basierende Nachricht kann als eine ,Ethernet-Nachricht' bezeichnet werden, und die Ethernet-Nachricht kann auch als ein ,Ethernet-Rahmen', ein ,Ethernet-Signal', ein ,Ethernet-Paket' oder dergleichen bezeichnet werden. Die Kommunikationsknoten 210, 211, 212, 213, 220, 221 und 222 in dem Ethernet-basierten Netzwerk können Kommunikationen mittels der Ethernet-Nachrichten durchführen, und die Kommunikationen zwischen dem Gateway 200 und dem Ethernet-basierten Netzwerk können auch mittels der Ethernet-Nachrichten durchgeführt werden.
  • Das CAN kann einen Endknoten #6 231, einen Endknoten #7 232, einen Endknoten #8 233 und dergleichen aufweisen, und der Endknoten #6 231, der Endknoten #7 232 und der Endknoten #8 233 können mit dem Gateway 200 über eine Busleitung verbunden sein. Eine auf dem CAN-Protokoll basierende Nachricht kann als eine ,CAN-Nachricht' bezeichnet werden, und die CAN-Nachricht kann auch als ein ,CAN-Rahmen', ein ,CAN-Signal', ein ,CAN-Paket' oder dergleichen bezeichnet werden. Die Kommunikationsknoten 231, 232 und 233, welche dem CAN angehören, können Kommunikationen mittels der CAN-Nachrichten durchführen, und die Kommunikationen zwischen dem CAN und dem Gateway 200 können auch mittels der CAN-Nachrichten durchgeführt werden.
  • Ausführungsformen gemäß der vorliegenden Erfindung können auf das oben beschriebene Fahrzeugnetzwerk angewendet werden, jedoch ist das Fahrzeugnetzwerk, auf welches die Ausführungsformen gemäß der vorliegenden Erfindung angewendet werden, nicht darauf beschränkt und kann auf zahlreiche Weisen modifiziert werden. In dem Fahrzeugnetzwerk, auf welches die Ausführungsformen gemäß der vorliegenden Erfindung angewendet werden, kann jede von der Ethernet-Nachricht und der CAN-Nachricht wie folgt ausgestaltet sein.
  • 3 ist ein Blockdiagramm, welches eine erste Ausführungsform einer Ethernet-Nachricht in einem Fahrzeugnetzwerk darstellt.
  • Unter Bezugnahme auf 3 kann eine Ethernet-Nachricht 300 einen Kopf (Header) 310, mindestens eine Dateneinheit (DU) 321, 322 und 323 und dergleichen aufweisen. Die DU #1 321, die DU #2 322 und die DU #3 323 können Protokolldateneinheiten (PDU), User-Datagram-Protocol-(UDP-)Dateneinheiten oder dergleichen sein und können eine Nutzinformation bilden. Außerdem kann die Ethernet-Nachricht 300 ferner eine Fahrzeugsicherheitsintegritätsstufe-(ASIL-)Authentifizierungsinformation 330 aufweisen. Die ASIL-Authentifizierungsinformation 330 kann basierend auf einem Authentifikationsalgorithmus, welcher Anforderungen gemäß der ASIL erfüllt, erzeugt werden und kann einen Authentifikationsschlüssel, einen Hash-Wert, eine zyklische Redundanzprüfung (CRC), eine Rahmenprüfzeichenfolge (FCS) und dergleichen aufweisen. Die ASIL-Authentifizierungsinformation 330 kann durch einen Kommunikationsknoten (z. B. einen Endknoten, einen Switch, eine Bridge, ein Gateway, etc.), welcher die Ethernet-Nachricht 300 erzeugt, ausgestaltet werden. Der Kopf 310 der Ethernet-Nachricht 300 kann wie folgt ausgestaltet sein.
  • 4 ist ein Blockdiagramm, welches eine erste Ausführungsform eines Kopfs, welcher in einer Ethernet-Nachricht enthalten ist, darstellt.
  • Unter Bezugnahme auf 4 kann der Kopf 310 ein Zieladresse-(DA-)Feld 310-1, ein Quelladresse-(SA-)Feld 310-2, ein Ethernet-Typ-Feld 310-3, einen Internetprotokoll-(IP-)-Kopf 310-3, einen UDP-Kopf 310-5, ein Nachrichten-Identifikator-(ID-)Feld 310-6, ein Markierung-Feld (FLAG-Feld) 310-8, ein Reserviert-Feld 310-9, ein Sequenznummer-Feld 310-10 und dergleichen aufweisen.
  • Das DA-Feld 310-1 kann eine Größe von 6 Byte haben und kann eine Identifizierungsinformation (z. B. eine Mediumzugriffssteuerung-(MAC-)Adresse) eines die Ethernet-Nachricht 300 empfangenden Kommunikationsknotens aufweisen. Das SA-Feld 310-2 kann eine Größe von 6 Byte haben und kann eine Identifizierungsinformation (z. B. eine MAC-Adresse) eines die Ethernet-Nachricht 300 sendenden Kommunikationsknotens aufweisen.
  • Das Ethernet-Typ-Feld 310-3 kann eine Größe von 2 Byte haben und kann den Typ der Ethernet-Nachricht 300 angeben. Beispielsweise gibt in einem Fall, dass ein Wert, welcher durch das Ethernet-Typ-Feld 310-3 angegeben wird, größer als eine Hexadezimalzahl 0 × 600 ist, das Ethernet-Typ-Feld 310-3 ein DIX-Format, welches in der Kommentaranforderung (RFC) 894 definiert ist, an. In einem Fall, dass der Wert, welcher durch das Ethernet-Typ-Feld 310-3 angegeben wird, kleiner als die Hexadezimalzahl 0 × 600 ist, kann das Ethernet-Typ-Feld 310-3 ein Subnetzwerkzugangsprotokoll-(SNAP-)Format oder ein Dienstzugangspunkt-(SAP-)Format, welche durch das „Institute of Electrical and Electronics Engineers” (IEEE) definiert sind, angeben. Das Ethernet-Typ-Feld 310-3 kann hier ausgestaltet sein, so dass es eine Hexadezimalzahl 0 × 800 beträgt, welche eine Internetprotokollversion 4 (IPv4) angibt.
  • Der IP-Kopf 310-4 kann eine Länge von 20 bis 60 Byte haben und kann eine Protokoll-ID, eine Prüfsummeninformation, eine SA-IP-Adresse, eine DA-IP-Adresse und dergleichen aufweisen. Der UDP-Kopf 310-5 kann eine Länge von 8 Byte haben und kann eine Quellportnummer, eine Zielportnummer und eine Prüfsummeninformation aufweisen. Das Nachrichten-ID-Feld 310-6 kann eine Länge von 4 Byte haben und kann dazu verwendet werden, um die Ethernet-Nachricht 300 in dem Fahrzeugnetzwerk zu identifizieren. Das Längenfeld 310-7 kann eine Länge von 4 Byte haben und kann die Länge der Nutzinformation der Ethernet-Nachricht 300 angeben. Das Markierung-Feld 310-8 kann eine Größe von 1 Byte haben und kann auf einen spezifischen Wert gesetzt sein, welcher eine spezifische Information angibt (oder einen spezifischen Vorgang durchführt). Das Reserviert-Feld 310-9 kann eine Größe von 1 Byte haben. Das Sequenznummer-Feld 310-10 kann eine Größe von zwei Byte haben und kann eine Sequenznummer der Ethernet-Nachricht 300 (z. B. der in der Nachricht enthaltenen Nutzinformation) angeben.
  • Der Kopf 310 kann außerdem einen Indikator aufweisen, welcher die Art der Information angibt, die in der Nutzinformation der Ethernet-Nachricht 300 enthalten ist (z. B. Steuerungsinformation, Verwaltungsinformation, Daten (z. B. Multimediadaten, Audio/Video-Bridging-(AVB-)Daten)). Der Indikator kann in dem Ethernet-Typ-Feld310-3, dem Nachrichten-ID-Feld 310-6, dem Markierung-Feld 310-8 oder dem Reserviert-Feld 310-9 des Kopfs 310 enthalten sein.
  • 5 ist ein Blockdiagramm, welches eine erste Ausführungsform einer CAN-Nachricht in einem Fahrzeugnetzwerk darstellt.
  • Unter Bezugnahme auf 5 kann eine CAN-Nachricht 500 basierend auf einem CAN-Flexible-Daten-(FD-)Format erzeugt sein. Die CAN-Nachricht 500 kann eine CRC 510 mit einer Länge von 2 Byte, einen Am-Leben-Zähler 520 mit einer Länge von 1 Byte, eine Nutzinformation 530 mit einer Länge von 29 Byte, etc. aufweisen. Der Am-Leben-Zähler 520 kann ein Anwendungsniveau angeben. Die Nutzinformation 530 kann mindestens eine Dateneinheit aufweisen. Die ASIL-Authentifizierungsinformation für die CAN-Nachricht 500 kann in der Nutzinformation 530 enthalten sein.
  • 6 ist ein Blockdiagramm, welches eine zweite Ausführungsform einer CAN-Nachricht in einem Fahrzeugnetzwerk darstellt.
  • Unter Bezugnahme auf 6 kann eine CAN-Nachricht 600 basierend auf einem Hochgeschwindigkeit-CAN-Format oder einem Niedriggeschwindigkeit-CAN-Format erzeugt sein. Die CAN-Nachricht 600 kann eine CRC 610 mit einer Länge von 1 Byte, ein Reserviert-Feld 620 mit einer Länge von 4 Bit, einen Am-Leben-Zähler 630 mit einer Länge von 4 Bit, eine Nutzinformation 640 mit einer Länge von 6 Byte und dergleichen aufweisen. Der Am-Leben-Zähler 630 kann ein Anwendungsniveau angeben. Die Nutzinformation 640 kann mindestens eine Dateneinheit aufweisen. Die ASIL-Authentifizierungsinformation für die CAN-Nachricht 600 kann in der Nutzinformation 640 enthalten sein.
  • Ferner können die das Fahrzeugnetzwerk bildenden Kommunikationsknoten (z. B. Gateways, Switches, Endknoten, etc.) in einer Stern-Topologie, einer Bus-Topologie, einer Ring-Topologie, einer Baum-Topologie, einer Vermascht-Topologie oder dergleichen verbunden sein. Außerdem kann jeder der das Fahrzeugnetzwerk bildenden Kommunikationsknoten das CAN-Protokoll, das FlexRay-Protokoll, das MOST-Protokoll, das LIN-Protokoll, das Ethernet-Protokoll oder dergleichen unterstützen. Ein dem Fahrzeugnetzwerk angehörender Kommunikationsknoten kann wie folgt ausgestaltet sein.
  • 7 ist ein Blockdiagramm, welches eine erste Ausführungsform eines zu einem Fahrzeugnetzwerk zugehörenden Kommunikationsknotens darstellt.
  • Unter Bezugnahme auf 7 kann ein das Fahrzeugnetzwerk (z. B. das in 1 oder 2 dargestellte Fahrzeugnetzwerk) bildender Kommunikationsknoten 700 eine physische Schicht (PHY-Schicht) 710 und eine Steuereinrichtung 720 aufweisen. Außerdem kann der Kommunikationsknoten 700 ferner einen Regulierer (nicht gezeigt) zur Versorgung mit Energie aufweisen. Insbesondere kann die Steuereinrichtung 720 umgesetzt sein, so dass sie eine Medienzugriffssteuerung-(MAC-)Schicht aufweist. Die PHY-Schicht 710 kann dazu eingerichtet sein, Signale von einem anderen Kommunikationsknoten zu empfangen oder an den anderen Kommunikationsknoten zu senden. Die Steuereinrichtung 720 kann dazu eingerichtet sein, die PHY-Schicht 710 zu steuern und diverse Funktionen (z. B. eine Infotainment-Funktion oder dergleichen) durchzuführen. Die PHY-Schicht 710 und die Steuereinrichtung 720 können als einzelnes System auf einem Chip (SoC) realisiert sein oder können alternativ als separate Chips realisiert sein.
  • Die PHY-Schicht 710 und die Steuereinrichtung 720 können mittels einer medienunabhängigen Schnittstelle (MII) 730 verbunden sein. Die MII 730 kann eine Schnittstelle, welche in dem IEEE 802.3 definiert ist, aufweisen und kann eine Datenschnittstelle und eine Verwaltungsschnittstelle zwischen der PHY-Schicht 710 und der Steuereinrichtung 720 aufweisen. Eine von einer reduzierten MII (RMII), einer Gigabit-MII (GMII), einer reduzierten GMII (RGMII), einer seriellen GMII (SGMII), einer 10-GMII (XGMII) kann an Stelle der MII 730 verwendet werden. Die Datenschnittstelle kann einen Sendekanal und einen Empfangskanal aufweisen, von welchen jeder ein unabhängiges Takt-, Daten- und Steuersignal aufweisen kann. Die Verwaltungsschnittstelle kann eine Zwei-Signal-Schnittstelle, wobei ein Signal für den Takt und ein Signal für die Daten ist, aufweisen.
  • Die PHY-Schicht 710 kann eine PHY-Schicht-Schnittstelle 711, einen PHY-Schicht-Prozessor 712 und einen PHY-Schicht-Speicher 713 aufweisen. Die Konfiguration der PHY-Schicht 710 ist nicht darauf beschränkt und die PHY-Schicht 710 kann auf zahlreiche Weisen ausgestaltet sein. Die PHY-Schicht-Schnittstelle 711 kann dazu eingerichtet sein, ein von der Steuereinrichtung 720 empfangenes Signal an den PHY-Schicht-Prozessor 712 zu senden und ein von dem PHY-Schicht-Prozessor 712 empfangenes Signal an die Steuereinrichtung 720 zu senden. Der PHY-Schicht-Prozessor 712 kann dazu eingerichtet sein, Betriebe der PHY-Schicht-Schnittstelle 711 und des PHY-Schicht-Speichers 713 zu steuern. Der PHY-Schicht-Prozessor 712 kann dazu eingerichtet sein, ein zu sendendes Signal zu modulieren oder ein empfangenes Signal zu demodulieren. Der PHY-Schicht-Prozessor 712 kann dazu eingerichtet sein, den PHY-Schicht-Speicher 713 zu steuern, um ein Signal einzugeben oder auszugeben. Der PHY-Schicht-Speicher 713 kann dazu eingerichtet sein, das empfangene Signal zu speichern und basierend auf einer Anforderung von dem PHY-Schicht-Prozessor 712 das gespeicherte Signal auszugeben.
  • Die Steuereinrichtung 720 kann dazu eingerichtet sein, unter Verwendung der MII 730 die PHY-Schicht 710 zu überwachen und zu steuern. Die Steuereinrichtung 720 kann eine Steuereinrichtungsschnittstelle 721, einen Steuereinrichtungsprozessor 722, einen Hauptspeicher 723 und einen Zusatzspeicher 724 aufweisen. Die Ausgestaltung der Steuereinrichtung 720 ist nicht darauf beschränkt und die Steuereinrichtung 720 kann auf zahlreiche Weisen ausgestaltet sein. Die Steuereinrichtungsschnittstelle 721 kann dazu eingerichtet sein, ein Signal von der PHY-Schicht 710 (z. B. der PHY-Schicht-Schnittstelle 211) oder einer übergeordneten Schicht (nicht gezeigt) zu empfangen, das empfangene Signal an den Steuereinrichtungsprozessor 722 zu senden und das von dem Steuereinrichtungsprozessor 722 empfangene Signal an die PHY-Schicht 710 oder die übergeordnete Schicht zu senden. Der Steuereinrichtungsprozessor 722 kann ferner eine unabhängige Speichersteuerungslogik oder eine integrierte Speichersteuerungslogik zum Steuern der Steuereinrichtungsschnittstelle 721, des Hauptspeichers 723 und des Zusatzspeichers 724 aufweisen. Die Speichersteuerungslogik kann umgesetzt sein, so dass sie in dem Hauptspeicher 723 und dem Zusatzspeicher 724 enthalten ist, oder kann umgesetzt sein, so dass sie in dem Steuereinrichtungsprozessor 722 enthalten ist.
  • Jeder von dem Hauptspeicher 723 und dem Zusatzspeicher 724 kann dazu eingerichtet sein, ein durch den Steuereinrichtungsprozessor 722 verarbeitetes Signal zu speichern, und kann dazu eingerichtet sein, basierend auf einer Anforderung von dem Steuereinrichtungsprozessor 722 das gespeicherte Signal auszugeben. Der Hauptspeicher 723 kann ein flüchtiger Speicher (z. B. RAM) sein, der dazu eingerichtet ist, temporär Daten, welche für den Betrieb des Steuereinrichtungsprozessors 722 erforderlich sind, zu speichern. Der Zusatzspeicher 724 kann ein nichtflüchtiger Speicher sein, in welchem ein Betriebssystemcode (z. B. ein Systemkern und ein Gerätetreiber) und ein Anwendungsprogrammcode zum Durchführen einer Funktion der Steuereinrichtung 720 gespeichert sein können. Ein Flashspeicher, welcher eine hohe Verarbeitungsgeschwindigkeit hat, eine Festplatte (HDD) oder ein Compact-Disk-Nur-Lese-Speicher (CD-ROM) zur Datenspeicherung hoher Kapazität können als der nichtflüchtige Speicher verwendet werden. Der Steuereinrichtungsprozessor 722 kann typischerweise eine Logikschaltung, welche mindestens einen Verarbeitungskern aufweist, aufweisen. Ein Kern einer Advanced-RISC-Machines-(ARM-)Familie oder ein Kern einer Atom-Familie kann als der Steuereinrichtungsprozessor 722 verwendet werden.
  • 8 ein Blockdiagramm ist, welches eine zweite Ausführungsform eines zu einem Fahrzeugnetzwerk zugehörenden Kommunikationsknotens darstellt.
  • Bezugnehmend auf 8 kann ein Kommunikationsknoten 800, welcher ein Fahrzeugnetzwerk (z. B. das in 1 oder 2 dargestellte Fahrzeugnetzwerk) bildet, eine Hardware-Schicht 810, eine Hardwareabstraktionsschicht (HAL) 830, eine Middleware-Schicht 850 und eine Anwendungsschicht 870 aufweisen. Die Hardware-Schicht 810 kann eine PHY-Schicht 811 und eine MAC-Schicht 812 aufweisen. Die PHY-Schicht 811 kann das Ethernet-Protokoll unterstützen und kann der unter Bezugnahme auf 7 beschriebenen PHY-Schicht 710 entsprechen. Die MAC-Schicht 812 kann das Ethernet-Protokoll (z. B. IEEE 802.3, etc.) unterstützen und kann der unter Bezugnahme auf 7 beschriebenen Steuereinrichtung 720 entsprechen.
  • Die Hardware-Schicht 810 kann das Audio/Video-Bridging-(AVB-)Protokoll unterstützen. Die Hardware-Schicht 810 kann beispielsweise das IEEE-802.1AS-Zeitstempelung-Protokoll, das IEEE-802.1Q-Datenstromreservierungsprotokoll (SRP), das IEEE-802.1Q-Weiterleiten&Warteschlangenbildung-für-zeitsensitiven-Datenstrom(FQTSS-)Protokoll, etc. unterstützen. Das IEEE-802.1AS-Zeitstempelung-Protokoll kann einen Stempelungsvorgang auf eine Übertragungs- oder Empfangszeit einer Nachricht gemäß IEEE 802.1AS unterstützen. Das IEEE-802.1Q-SRP-Protokoll kann Reservierungsvorgänge von Datenstromressourcen, Reservierungsvorgänge von Verkehrsformern und dergleichen unterstützen. Das IEEE-802.1Q-FQTSS-Protokoll kann einen Formungsvorgang auf zu sendende Nachrichten und dergleichen unterstützen. Die Hardware-Schicht 810 kann die HAL 830 unterstützen, um es der Middleware-Schicht 850 zu ermöglichen, zu arbeiten.
  • Die Hardware-Schicht 810 kann drei Modi unterstützen. Beispielsweise kann die Hardware-Schicht 810 einen Normalmodus, einen Schlafmodus und einen Energieabschaltungsmodus unterstützen. Im Normalmodus können Ethernet-Kommunikationen durchgeführt werden. Die PHY-Schicht 811 kann in einem Normalmodus (z. B. ein INH-Anschluss in einem Aktiv-Zustand) arbeiten und die MAC-Schicht 812 kann in einem Aktiv-Modus (z. B. einem Zustand, welcher ein Senden und Empfangen von Nachrichten ermöglicht) arbeiten. In dem Schlafmodus können Ethernet-Kommunikationen mit begrenzter Nutzung einer minimalen Leistung durchgeführt werden. Wenn die Hardware-Schicht 810 im Schlafmodus ist, kann die PHY-Schicht 811 in einem Schlafmodus (z. B. ein INH-Anschluss in einem Inaktiv-Zustand) arbeiten und aufgeweckt werden, wenn ein Fernereignis detektiert wird. Die MAC-Schicht 812 kann außerdem in einem Inaktiv-Zustand (z. B. einem Zustand, in welchem Nachrichten nicht gesendet oder empfangen werden können) arbeiten und kann aufgeweckt werden, wenn ein lokales Ereignis detektiert wird.
  • In einem Fall, dass der Zustand der Hardware-Schicht 810 in dem Energieabschaltungsmodus ist, kann die PHY-Schicht 811 in dem Schlafmodus (z. B. ein INH-Anschluss in einem Inaktiv-Zustand) arbeiten und aufgeweckt werden, wenn ein Fernereignis detektiert wird. Außerdem kann die MAC-Schicht 812 in dem Inaktiv-Zustand arbeiten und kann die MAC-Schicht 812 nicht mit Energie versorgt werden. Das heißt, dass die MAC-Schicht 812 nicht durch ein lokales Ereignis aufgeweckt werden kann. Die Konfiguration der Hardware-Schicht 810 ist nicht auf das oben beschriebene beschränkt, und die Hardware-Schicht 810 kann auf zahlreiche Weisen eingerichtet sein.
  • Die Middleware-Schicht 850 kann eine IP-Middleware-Schicht, welche basierend auf einem Übertragungssteuerungsprotokoll/Internetprotokoll (TCP/IP) arbeitet, eine AVB-Middleware, welche basierend auf dem AVB-Protokoll arbeitet, und eine OSAL 851 aufweisen. Die IP-Middleware-Schicht kann eine Diagnose-über-Internet-Protokoll-(DoIP-)Einheit 852, eine EthCC-Einheit 853, eine EthNM-Einheit 854 und dergleichen aufweisen. Die DoIP-Einheit 852 kann dazu eingerichtet sein, eine Diagnosekommunikation durchzuführen. Die EthCC-Einheit 853 kann dazu eingerichtet sein, Steuerungsnachrichten zu senden und zu empfangen. Die EthNM-Einheit 854 kann dazu eingerichtet sein, eine Netzwerkverwaltung durchzuführen. Die IP-Middleware-Schicht kann IPv4, das Internetsteuerungsnachrichtenprotokoll (ICMP), das Adressauflösungsprotokoll (ARP), TCP und UDP unterstützen. Das UDP kann die CRC, den Am-Leben-Zähler, etc. für Steuerungsnachrichten oder Verwaltungsnachrichten verarbeiten.
  • Die AVB-Middleware-Schicht kann eine Sender-Einheit 855 und eine Empfänger-Einheit 856 und dergleichen aufweisen. Die Sender-Einheit 855 kann dazu eingerichtet sein, eine Übertragung eines AVB-Datenstroms basierend auf dem AVB-Protokoll durchzuführen. Die Empfänger-Einheit 856 kann dazu eingerichtet sein, einen Empfang des AVB-Datenstroms basierend auf dem AVB-Protokoll durchzuführen. Die AVB-Middleware-Schicht kann das IEEE-802.1AS-Generalisierte-Präzisionszeit-Protokoll (gPTP), das IEEE-1722-AVB-Transportprotokoll (AVTP), etc. unterstützen. Das IEEE-802.1AS-gPTP kann einen Vorgang zum Auswählen eines Großmeisters basierend auf einem Best-Master-Clock-Algorithmus (BMCA), einen Vorgang für eine Uhrsynchronisation, einen Vorgang zum Berechnen einer Verbindungsverzögerung und dergleichen unterstützen. Das IEEE-1722-AVTP kann Vorgänge, wie beispielsweise Erzeugen einer Ethernet-Nachricht, welche eine Audio-Dateneinheit und eine Video-Dateneinheit aufweist, unterstützen.
  • Die Anwendungsschicht 870 kann eine Softwareschnittstelle 871, eine Anwendung 872 und dergleichen aufweisen. Die Softwareschnittstelle 871 kann Eingabe- und Ausgabevorgänge von Signalen für die Anwendung 872 unterstützen. Die Anwendung 872 kann eine auf TCP/IP arbeitende Anwendung, eine auf dem AVB-Protokoll arbeitende Anwendung und dergleichen aufweisen.
  • 9 ist ein Blockdiagramm, welches eine erste Ausführungsform eines zu einem Fahrzeugnetzwerk zugehörenden Gateways darstellt.
  • Unter Bezugnahme auf 9 kann ein Gateway 900 das Gateway 100, welches zu dem Fahrzeugnetzwerk von 1 gehört, oder das Gateway 200, welche zu dem Fahrzeugnetzwerk von 2 gehört, sein. Das Gateway 900 kann Kommunikationen zwischen dem CAN und dem Ethernet-basierten Netzwerk unterstützen. Beispielsweise kann das Gateway 900 eine CAN-Nachricht, welche vom CAN empfangen wird, in eine Ethernet-Nachricht umwandeln und die umgewandelte Ethernet-Nachricht an das Ethernet-basierte Netzwerk senden. Außerdem kann das Gateway 900 eine Ethernet-Nachricht, welche von dem Ethernet-basierten Netzwerk empfangen wird, in eine CAN-Nachricht umwandeln und die umgewandelte CAN-Nachricht an das CAN senden.
  • Das Gateway 900 kann einen CAN-Funktionsblock 910, welches Funktionen des CAN-Protokolls durchführt, und einen Ethernet-Funktionsblock 920, welcher Funktionen des Ethernet-Protokolls durchführt, aufweisen. Der CAN-Funktionsblock 910 kann eine CAN-PHY-Schicht-Einheit 911, eine CAN-Integrität-Verifikationseinheit 912, eine CAN-Integrität-Verarbeitungseinheit 913, eine CAN-Nachricht-Erzeugungseinheit 914, eine CAN-Nachricht-Verarbeitungseinheit 915, eine CAN-Filtereinheit 916 und dergleichen aufweisen. Die CAN-PHY-Schicht-Einheit 911 kann eine CAN-Nachricht empfangen, indem sie einen Überwachungsvorgang auf einer Busleitung durchführt, und kann eine CAN-Nachricht über die Busleitung senden. Die CAN-Integrität-Verifikationseinheit 912 kann einen Integritätsverifikationsvorgang auf die in der CAN-Nachricht enthaltene ASIL-Authentifizierungsinformation durchführen und kann die korrespondierende CAN-Nachricht verwerfen, falls die Integritätsverifikation scheitert. Die CAN-Integrität-Verarbeitungseinheit 913 kann einen Vorgang des Erzeugens einer in die CAN-Nachricht einzubeziehenden ASIL-Authentifizierungsinformation durchführen.
  • Die CAN-Nachricht-Erzeugungseinheit 914 kann einen Erzeugungsvorgang einer CAN-Nachricht, welche eine CRC, einen Am-Leben-Zähler, eine Nutzinformation (z. B. eine Dateneinheit), eine ASIL-Authentifizierungsinformation und dergleichen aufweist, durchführen. Die CAN-Nachricht-Verarbeitungseinheit 915 kann einen Steuerungsvorgang zum Senden und Empfangen einer CAN-Nachricht durchführen. Die CAN-Filtereinheit 916 kann verifizieren, dass die Dateneinheit, welche in der CAN-Nachricht enthalten ist, die gleiche wie die Dateneinheit, welche in einem CAN-Puffer (z. B. Speicher) gespeichert ist, ist. Falls die in der CAN-Nachricht enthaltene Dateneinheit von der in dem CAN-Puffer gespeicherten Dateneinheit verschieden ist (z. B. falls die in der CAN-Nachricht enthaltene Dateneinheit eine aktualisierte Steuerungsinformation oder eine aktualisierte Verwaltungsinformation aufweist), kann die CAN-Nachricht gesendet werden. Falls andererseits die in der CAN-Nachricht enthaltene Dateneinheit die gleiche wie die in dem CAN-Puffer gespeicherte Dateneinheit ist (z. B. falls die in der CAN-Nachricht enthaltene Dateneinheit eine existierende Steuerungsinformation oder eine existierende Verwaltungsinformation aufweist), kann die CAN-Filtereinheit 916 die Dateneinheit verwerfen. Folglich kann die Dateneinheit, welche gleich der in dem CAN-Puffer gespeicherten Dateneinheit ist, nicht gesendet werden.
  • Der Ethernet-Funktionsblock 920 kann eine Ethernet-PHY-Schicht-Einheit 921, eine Ethernet-Integrität-Verifikationseinheit 922, eine Ethernet-Integrität-Verarbeitungseinheit 923, eine Ethernet-Nachricht-Erzeugungseinheit 924, eine Ethernet-Nachricht-Verarbeitungseinheit 925, eine Ethernet-Routingeinheit 926 und dergleichen aufweisen. Die Ethernet-PHY-Schicht-Einheit 921 kann eine Ethernet-Nachricht empfangen, indem sie einen Überwachungsvorgang auf eine Ethernet-Verbindung durchführt, und kann eine Ethernet-Nachricht über die Ethernet-Verbindung senden. Die Ethernet-PHY-Schicht-Einheit 921 kann eine Ethernet-Switch-Funktion (z. B. eine Routingfunktion, eine Filterfunktion, etc.) durchführen. Die Ethernet-Integrität-Verifikationseinheit 922 kann einen Integritätsverifikationsvorgang auf die in der Ethernet-Nachricht enthaltene ASIL-Authentifizierungsinformation durchführen und kann die korrespondierende Ethernet-Nachricht verwerfen, falls die Integritätsverifikation scheitert. Die Ethernet-Integrität-Verarbeitungseinheit 923 kann einen Vorgang des Erzeugens einer in die Ethernet-Nachricht einzubeziehende ASIL-Authentifizierungsinformation durchführen.
  • Die Ethernet-Nachricht-Erzeugungseinheit 924 kann einen Erzeugungsvorgang einer Ethernet-Nachricht, welche einen Kopf, eine Nutzinformation (z. B. eine Dateneinheit), eine ASIL-Authentifizierungsinformation und dergleichen aufweist, durchführen. Die Ethernet-Nachricht-Verarbeitungseinheit 925 kann einen Steuerungsvorgang zum Senden und Empfangen einer Ethernet-Nachricht durchführen. Die Ethernet-Routing-Einheit 926 kann den Übertragungsvorgang der Ethernet-Nachricht basierend auf einer vorkonfigurierten Routingtabelle steuern.
  • Ein Verfahren, welches an einem zu einem Fahrzeugnetzwerk gehörenden Kommunikationsknoten und einem korrespondierender Gegenstück-Kommunikationsknoten durchgeführt wird, wird nachstehend beschrieben. Sogar wenn nachstehend ein Verfahren (z. B. Senden oder Empfang einer Nachricht), das an einem ersten Kommunikationsknoten durchzuführen ist, beschrieben wird, kann ein korrespondierender zweiter Kommunikationsknoten ein Verfahren, das mit dem an dem ersten Kommunikationsknoten durchgeführten Verfahren korrespondiert, (z. B. Empfang oder Senden der Nachricht) durchführen. Das bedeutet, dass, wenn der Betrieb des ersten Kommunikationsknotens beschrieben wird, der korrespondierende zweite Kommunikationsknoten einen mit dem Betrieb des ersten Kommunikationsknotens korrespondieren Betrieb durchführen kann. Wenn umgekehrt der Betrieb des zweiten Kommunikationsknotens beschrieben wird, kann der korrespondierende erste Kommunikationsknoten einen mit dem Betrieb des Switchs korrespondierenden Betrieb durchführen.
  • 10 ist ein Ablaufdiagramm, welches eine erste Ausführungsform eines Betriebsverfahrens eines Kommunikationsknotens in einem Fahrzeugnetzwerk darstellt.
  • Das Gateway 200, der Endknoten #1 211 und der Endknoten #6 231 können unter Bezugnahme auf 10 das Gateway 200, der Endknoten #1 211 und der Endknoten #6 231, welche zu dem Fahrzeugnetzwerk von 2 gehören, sein. Beispielsweise kann ein in 10 dargestelltes Betriebsverfahren eines Endknotens in dem in 2 gezeigten Fahrzeugnetzwerk durchgeführt werden, und jedes/jeder von dem Gateway 200, dem Endknoten #1 211 und dem Endknoten #6 231 kann auf identische Weise oder ähnliche Weise wie der in 7 dargestellte Kommunikationsknoten 700 (oder der in 8 dargestellte Kommunikationsknoten 800) ausgestaltet sein. Außerdem kann das Gateway 200 auf identische Weise oder ähnliche Weise wie das in 9 dargestellte Gateway 900 ausgestaltet sein.
  • Der Endknoten #1 211 kann eine Ethernet-Nachricht (z. B. die in 3 und 4 dargestellte Ethernet-Nachricht 300) erzeugen (S1001). Die durch den Endknoten #1 211 erzeugte Ethernet-Nachricht kann wie folgt ausgestaltet sein.
  • 11 ist ein Blockdiagramm, welches eine zweite Ausführungsform einer Ethernet-Nachricht in einem Fahrzeugnetzwerk darstellt.
  • Unter Bezugnahme auf 11 kann der Endknoten #1 211 eine Ethernet-Nachricht #1, eine Ethernet-Nachricht #2 und eine Ethernet-Nachricht #3 erzeugen. Jede von der Ethernet-Nachricht #1, der Ethernet-Nachricht #2 und der Ethernet-Nachricht #3 kann einen Kopf, eine Nutzinformation, eine ASIL-Authentifizierungsinformation und dergleichen aufweisen.
  • Der Kopf kann eine Ziel-Information der jeweiligen der Ethernet-Nachricht #1, der Ethernet-Nachricht #2 und der Ethernet-Nachricht #3 aufweisen. Die Ziel-Information kann mindestens einen von Kommunikationsknoten (z. B. dem Endknoten #2 212 und dem Endknoten #3 213), welche mit dem Switch #1 210, der zu dem Ethernet-basierten Netzwerk gehört, verbunden sind, von Kommunikationsknoten, (z. B. dem Endknoten #4 221 und dem Endknoten #5 222), welche mit dem Switch #2 220, der zu dem Ethernet-basierten Netzwerk gehört, verbunden sind, und von Kommunikationsknoten (z. B. dem Endknoten 64 231, dem Endknoten #7 232 und dem Endknoten #9 233), welche zu dem CAN gehören, angeben.
  • Die Nutzinformation kann eine Steuerungsinformation, eine Verwaltungsinformation, Daten (z. B. Multimediadaten, AVB-Daten, etc.) und dergleichen aufweisen. Die Nutzlast kann außerdem fünf DUs (z. B., DU #1, DU #2, DU #3, DU #4 und DU #5', DU #6, DU #7, DU #8, DU #9 und DU #10' oder , DU #11, DU #12, DU #13, DU #14 und DU #15') aufweisen. Die ASIL-Authentifizierungsinformation kann basierend auf einem Authentifikationsalgorithmus, welcher die Anforderungen gemäß der ASIL erfüllt, erzeugt werden und kann einen Authentifikationsschlüssel, einen Hash-Wert, einen CRC-Wert, eine FCS und dergleichen aufweisen. Die ASIL-Authentifizierungsinformation kann nicht für jede der Dateneinheiten, welche in der Ethernet-Nachricht enthalten sind, ausgestaltet sein, sondern kann für die Ethernet-Nachricht (d. h. die gesamte Nutzinformation, welche in der Ethernet-Nachricht enthalten ist) ausgestaltet sein.
  • Falls die Nutzinformation der Ethernet-Nachricht Daten (z. B. Multimediadaten, AVB-Daten, etc.) aufweist, kann die ASIL-Authentifizierungsinformation für die Ethernet-Nachricht nicht erzeugt werden. Dementsprechend kann die Ethernet-Nachricht, welche für die Übertragung der Daten verwendet wird, keine ASIL-Authentifizierungsinformation aufweisen. Falls die Nutzinformation der Ethernet-Nachricht eine Steuerungsinformation oder Verwaltungsinformation aufweist, kann die ASIL-Authentifizierungsinformation für die Ethernet-Nachricht erzeugt werden. Dementsprechend kann die Ethernet-Nachricht, welche für die Übertragung der Steuerungsinformation oder Verwaltungsinformation verwendet wird, eine ASIL-Authentifizierungsinformation aufweisen.
  • Zurückkehrend zu 10 kann der Endknoten #1 211 Ethernet-Nachrichten (z. B. die Ethernet-Nachricht #1, die Ethernet-Nachricht #2 und die Ethernet-Nachricht #3, welche in 11 dargestellt sind) senden (S1002). Die Ethernet-Nachrichten können entsprechend einer Übertragungsperiode des Ethernet-basierten Netzwerks gesendet werden. Falls beispielsweise die Übertragungsperiode des Ethernet-basierten Netzwerks 50 Millisekunden beträgt, kann der Endknoten #1 211 die Ethernet-Nachricht #2 nach 50 Millisekunden ausgehend von der Sendezeit der Ethernet-Nachricht #1 und die Ethernet-Nachricht #3 nach 50 Millisekunden ausgehend von der Sendezeit der Ethernet-Nachricht #2 senden.
  • In einem Fall, dass das Ziel der Ethernet-Nachricht der Endknoten #2 212 oder der Endknoten #3 213, welche mit dem Switch #1 210, der zu dem Ethernetbasierten Netzwerk gehört, verbunden sind, ist, kann die Ethernet-Nachricht des Endknotens #1 211 über den Switch #1 210 an den Endknoten #2 212 oder den Endknoten #3 213 gesendet werden. In einem Fall, dass das Ziel der Ethernet-Nachricht ein Kommunikationsknoten, welcher mit dem Switch #2 220 in dem Ethernetbasierten Netzwerk verbunden ist, oder ein Kommunikationsknoten, welcher zu dem CAN gehört, ist, kann die Ethernet-Nachricht des Endknotens #1 211 andererseits über den Switch #1 210 an das Gateway 200 gesendet werden.
  • Das Gateway 200 kann die Ethernet-Nachrichten des Endknotens #1 211 (z. B. die Ethernet-Nachricht #1, die Ethernet-Nachricht #2 und die Ethernet-Nachricht #3, welche in 11 dargestellt sind) empfangen und das Ziel der Ethernet-Nachrichten basierend auf den Informationen, welche in dem Kopf der Ethernet-Nachrichten enthalten sind, identifizieren (S1003). In dem Fall, dass das Ziel der Ethernet-Nachricht ein Kommunikationsknoten, welcher mit dem Switch #2 220, der zu dem Ethernetbasierten Netzwerk gehört, verbunden ist, ist, kann das Gateway 200 die Ethernet-Nachricht an den Switch #2 220 senden und kann der die Ethernet-Nachricht von dem Gateway 200 aus empfangende Switch #2 220 die Ethernet-Nachricht an den Endknoten #4 221 oder den Endknoten #5 222 senden.
  • In dem Fall, dass das Ziel der Ethernet-Nachricht ein zum CAN gehöriger Kommunikationsknoten ist, kann das Gateway 200 die Art der Information, welche in der Nutzinformation der Ethernet-Nachricht enthalten ist, basierend auf der in dem Kopf der Ethernet-Nachricht enthaltenen Information identifizieren (S1004). Wenn ermittelt wird, dass die Nutzinformation der Ethernet-Nachricht Daten (z. B. Multimediadaten, AVB-Daten, etc.) aufweist, kann das Gateway 200 eine CAN-Nachricht (z. B. die in 5 oder 6 dargestellte CAN-Nachricht) erzeugen und die erzeugte CAN-Nachricht an den entsprechenden Kommunikationsknoten (z. B. den Endknoten #6 231, den Endknoten #7 232 oder den Endknoten #8 233) senden. Hier kann die CAN-Nachricht eine CRC, einen Am-Leben-Zähler, eine Nutzinformation, etc. aufweisen, und die Nutzinformation kann eine ASIL-Authentifizierungsinformation für die CAN-Nachricht aufweisen.
  • Wenn die Nutzinformation der Ethernet-Nachricht als eine Steuerungsinformation oder Verwaltungsinformation enthaltend ermittelt wird, kann das Gateway 200 einen Integritätsverifikationsvorgang basierend auf der ASIL-Authentifizierungsinformation, welche in der Ethernet-Nachricht (z. B. der Ethernet-Nachricht #1, der Ethernet-Nachricht #2 und der Ethernet-Nachricht #3, welche in 11 gezeigt sind) enthalten sind, durchführen (S1005). Falls beispielsweise die Integritätsverifikation der ASIL-Authentifizierungsinformation der Ethernet-Nachricht #3 in 11 scheitert, kann das Gateway 200 die Ethernet-Nachricht #3 verwerfen. Falls die Integritätsverifikation der ASIL-Authentifizierungsinformation der Ethernet-Nachricht #1 und der Ethernet-Nachricht #2 von 11 erfolgreich ist, kann das Gateway 200 eine Parsing-Operation für die Ethernet-Nachricht #1 und die Ethernet-Nachricht #2 durchführen (S1006). Das bedeutet, dass das Gateway 200 mindestens eine DU, welche an das CAN zu senden ist, durch Durchführen der Parsing-Operation auf die integritätsverifizierte Ethernet-Nachricht auswählen kann, und eine Kandidat-Nutzinformation (z. B. eine in die CAN-Nachricht einzubeziehende Kandidat-Nutzinformation), welche die ausgewählte mindestens eine DU aufweist, erzeugen kann (S1007). Die Parsing-Operation und der Erzeugungsvorgang der Kandidat-Nutzinformation können wie folgt durchgeführt werden.
  • 12 ist ein konzeptionelles Diagramm, welches eine erste Ausführungsform einer Parsing-Operation und eines Kandidat-Nutzinformation-Erzeugungsvorgangs darstellt.
  • Bezugnehmend auf 12 kann das Gateway 200 eine vordefinierte CAN-Routingtabelle mit DU #1 bis DU #10, für welche die Integritätsverifikation abgeschlossen wurde, vergleichen. Die CAN-Routingtabelle kann DUs, die an das CAN zu übertragen sind, angeben. Wenn die CAN-Routingtabelle DU #1, DU #2, DU #6, DU #7, DU #9 bis DU #12 und DU #15 angibt, kann das Gateway 200 die DU #1, DU #2, DU #6, DU #7, DU #9 und DU #10 aus der DU #1 bis DU #10, für welche die Integritätsverifikation abgeschlossen wurde, auswählen und Kandidatennutzinformationen basierend auf den ausgewählten DUs erzeugen. Dadurch kann das Gateway 200 für die CAN-Nachricht eine Kandidat-Nutzinformation #1, welche DU #1 und DU #2 aufweist, eine Kandidat-Nutzinformation #2, welche DU #6 und DU #7 aufweist, und eine Kandidat-Nutzinformation #3, welche DU #9 und DU #10 aufweist, erzeugen.
  • Da die zuvor ans CAN übermittelte Information in dem CAN-Puffer gespeichert ist, kann das Gateway 200 unter erneuter Bezugnahme auf 10 eine finale Nutzinformation mittels Prüfens der Gleichheit zwischen der in den DUs der Kandidat-Nutzinformation enthaltenen Information und der Information, welche in den im CAN-Puffer gespeicherten DUs enthalten ist, erzeugen (S1008). Der CAN-Puffer kann ein Speicher (z. B. der PHY-Schicht-Speicher 713, der Hauptspeicher 723 und der Zusatzspeicher 724, welche in 7 gezeigt sind) sein. Der Erzeugungsvorgang der finalen Nutzinformation der CAN-Nachricht kann wie folgt durchgeführt werden.
  • 13 ist ein konzeptionelles Diagramm, welches eine erste Ausführungsform eines Finale-Nutzinformation-Erzeugungsvorgangs darstellt.
  • Bezugnehmend auf 13 kann das Gateway 200 DU #1, DU #2, DU #6, DU #7, DU #9 und DU #10, welche in den Kandidat-Nutzinformationen enthalten sind, mit DU #1, DU #2, DU #6, DU #7, DU #9 und DU #10, welche in dem CAN-Puffer gespeichert sind, vergleichen. Beispielsweise kann das Gateway 200 die Versionen der Informationen (z. B. Steuerungsinformation, Verwaltungsinformation), welche in den DUs der Kandidat-Nutzinformationen enthalten sind, mit denjenigen der Informationen (z. B. Steuerungsinformation, Verwaltungsinformation), welche in den im CAN-Puffer gespeicherten DUs enthalten sind, vergleichen.
  • In einem Fall, dass die Information, welche in DU #1, DU #2, DU #6 und DU #7 der Kandidat-Nutzinformationen enthalten ist, von der Information, welche in DU #1, DU #2, DU #6 und DU #7 des CAN-Puffers enthalten ist, verschieden ist (z. B. einem Fall, dass die Information, welche in DU #1, DU #2, DU #6 und DU #7 der Kandidat-Nutzinformationen enthalten ist, eine im Vergleich zur in DU #1, DU #2, DU #6 und DU #7 des CAN-Puffers enthaltenen Information aktualisierte Information ist), kann das Gateway 200 finale Nutzinformationen, welche die aktualisierten DU #1, DU #2, DU #6 und DU #7 aufweisen, erzeugen. Dementsprechend kann das Gateway 200 eine finale Nutzinformation #1, welche die DU #1 und die DU #2 aufweist, und eine finale Nutzinformation #2, welche die DU #6 und die DU #7 aufweist, für die CAN-Nachricht erzeugen. Falls andererseits die in DU #9 und DU #10 der Kandidat-Nutzinformationen enthaltene Information die gleiche wie die in DU #9 und DU #10 des CAN-Puffers enthaltene Information ist, kann das Gateway 200 die DU #9 und die DU #10 verwerfen.
  • Unter Rückkehr zu 10 kann das Gateway 200 die CAN-Nachricht unter Berücksichtigung der Übertragungsperiode des CANs erzeugen (S1009). Wenn beispielsweise die Übertragungsperiode der Ethernet-Nachricht 50 Millisekunden beträgt und die Übertragungsperiode der CAN-Nachricht 100 Millisekunden beträgt, kann das Gateway 200 eine einzelne CAN-Nachricht, welche mit der Ethernet-Nachricht korrespondiert, gemäß der Übertragungsperiode der CAN-Nachricht senden, sogar falls das Gateway 200 zwei Ethernet-Nachrichten während eines Übertragungsintervalls, das eine Länge von 100 ms hat, empfängt. Wenn beispielsweise die Ethernet-Nachricht #1 und die Ethernet-Nachricht #2 in einem Übertragungsintervall, das eine Länge von 100 ms hat, empfangen werden, kann das Gateway 200 eine CAN-Nachricht, welche die zur Ethernet-Nachricht #2 gehörenden DUs aufweist, erzeugen. Die CAN-Nachricht kann wie folgt ausgestaltet sein.
  • 14 ist ein Blockdiagramm, welches eine dritte Ausführungsform einer CAN-Nachricht in einem Fahrzeugnetzwerk darstellt, und 15 ist ein Blockdiagramm, welches eine vierte Ausführungsform einer CAN-Nachricht in einem Fahrzeugnetzwerk darstellt.
  • Unter Bezugnahme auf 14 und 15 kann, wenn das CAN-FD-Format verwendet wird, eine CAN-Nachricht 1400 eine CRC 1410, einen Am-Leben-Zähler 1420, die DU #6 1430 und die DU #7 1440 aufweisen. Das Gateway 200 kann eine ASIL-Authentifizierungsinformation für die CAN-Nachricht 1400 erzeugen, und die ASIL-Authentifizierungsinformation kann in der DU #6 1430 oder der DU #7 1440 enthalten sein. Alternativ kann die ASIL-Authentifizierungsinformation unabhängig von der DU #6 1430 und der DU #7 1440 in der CAN-Nachricht 1400 enthalten sein.
  • Wenn ein Niedriggeschwindigkeit-CAN-Format oder ein Hochgeschwindigkeit-CAN-Format verwendet wird, kann eine CAN-Nachricht 1500 eine CRC 1510, ein Reserviert-Feld 1520, einen Am-Leben-Zähler 1530, die DU #6 1540 und die DU #7 1550 aufweisen. Das Gateway 200 kann eine ASIL-Authentifizierungsinformation für die CAN-Nachricht 1500 erzeugen, und die ASIL-Authentifizierungsinformation kann in der DU #6 1540 oder der DU #7 1550 enthalten sein. Alternativ kann die ASIL-Authentifizierungsinformation unabhängig von der DU #6 1540 und der DU #7 1550 in der CAN-Nachricht 1500 enthalten sein.
  • Zurückkehrend zu 10 kann, da die Größe der in der Ethernet-Nachricht enthaltenen Nutzinformation größer als die Größe der in der CAN-Nachricht enthaltenen Nutzinformation ist, in Schritt S1009 eine Mehrzahl an CAN-Nachrichten basierend auf einer einzelnen Ethernet-Nachricht erzeugt werden. Das Gateway 200 kann die CAN-Nachricht gemäß der Übertragungsperiode des CANs senden (S1010). Die ans CAN gesendete CAN-Nachricht kann in dem CAN-Puffer des Gateways 200 gespeichert werden. Das bedeutet, dass die DU, welche die aktualisierte Steuerungsinformation oder die aktualisierte Verwaltungsinformation aufweist, in den CAN-Puffer überschrieben werden kann. Falls das Ziel der CAN-Nachricht der Endknoten #6 231 ist, kann das Gateway 200 die CAN-Nachricht an den Endknoten #6 231 senden.
  • Alternativ kann das Gateway 200 die CAN-Nachricht ungeachtet der CAN-Übertragungsperiode erzeugen und die erzeugte CAN-Nachricht senden. In diesem Fall kann das Gateway 200 eine CAN-Nachricht #1, welche die finale Nutzinformation #1 (z. B. die DU #1 und die DU #2) von 3 aufweist, und eine CAN-Nachricht #2, welche die finale Nutzinformation #2 (z. B. die DU #6 und die DU #7) aufweist, erzeugen und jeweilig die CAN-Nachricht #1 und die CAN-Nachricht #2 senden.
  • Der Endknoten # 231 kann auf der anderen Seite die CAN-Nachricht durch Durchführen eines Überwachungsvorgangs auf der Busleitung empfangen und kann einen Integritätsverifikationsvorgang auf die ASIL-Authentifizierungsinformation, welche in der empfangenen CAN-Nachricht enthalten ist, durchführen. Falls die Integritätsverifikation der ASIL-Authentifizierungsinformation der CAN-Nachricht erfolgreich ist, kann der Endknoten #6 231 die in der CAN-Nachricht enthaltene Nutzinformation erlangen und die Steuerungsinformation oder die Verwaltungsinformation aus der erlangten Nutzinformation ermitteln. Falls alternativ die Integritätsverifikation der ASIL-Authentifizierungsinformation der CAN-Nachricht scheitert, kann der Endknoten #6 231 die CAN-Nachricht verwerfen.
  • 16 ist ein Ablaufdiagramm, welches eine zweite Ausführungsform eines Betriebsverfahrens eines Kommunikationsknotens in einem Fahrzeugnetzwerk darstellt.
  • Das Gateway 200, der Endknoten #1 211 und der Endknoten #6 231 können unter Bezugnahme auf 16 das Gateway 200, der Endknoten #1 211 und der Endknoten #6 231, welche zu dem Fahrzeugnetzwerk von 2 gehören, sein. Beispielsweise kann ein in 16 dargestelltes Betriebsverfahren eines Endknotens in dem in 2 gezeigten Fahrzeugnetzwerk durchgeführt werden, und jedes/jeder von dem Gateway 200, dem Endknoten #1 211 und dem Endknoten #6 231 kann auf identische Weise oder ähnliche Weise wie der in 7 dargestellte Kommunikationsknoten 700 (oder der in 8 dargestellte Kommunikationsknoten 800) ausgestaltet sein. Außerdem kann das Gateway 200 auf identische Weise oder ähnliche Weise wie das in 9 dargestellte Gateway 900 ausgestaltet sein.
  • Der Endknoten #6 231 kann eine CAN-Nachricht (z. B. die in 5 gezeigte CAN-Nachricht 500 oder die in 6 gezeigte CAN-Nachricht 600) erzeugen (S1601). Das Ziel der CAN-Nachricht kann ein Kommunikationsknoten (z. B. der Endknoten #7 232 oder der Endknoten #8 233), welcher zum CAN gehört, oder ein Kommunikationsknoten (z. B. der Switch #1 210, der Switch #2 220, der Endknoten #1 211, der Endknoten #2 212, der Endknoten #3 213, der Endknoten #4 221 oder der Endknoten #5 222), welcher zum Ethernet-basierten Netzwerk gehört, sein. Die Nutzinformation der CAN-Nachricht kann eine Steuerungsinformation, eine Verwaltungsinformation und dergleichen aufweisen.
  • Der Endknoten #6 231 kann die CAN-Nachricht an das Gateway 200 senden (S1602). Das Gateway 200 kann die CAN-Nachricht von dem Endknoten #6 231 empfangen und kann einen Integritätsverifikationsvorgang auf die ASIL-Authentifizierungsinformation, welche in der CAN-Nachricht enthalten ist, durchführen (S1603). Das Gateway 200 kann annehmen, dass die vom CAN aus empfangene CAN-Nachricht Steuerungsinformation oder Verwaltungsinformation aufweist. Falls der Integritätsverifikationsvorgang für die ASIL-Authentifizierungsinformation der CAN-Nachricht scheitert, kann das Gateway 200 die korrespondierende CAN-Nachricht verwerfen. Falls andererseits der Integritätsverifikationsvorgang für die ASIL-Authentifizierungsinformation der CAN-Nachricht erfolgreich ist, kann das Gateway 200 das Ziel der korrespondierenden CAN-Nachricht identifizieren (S1604).
  • Falls das Ziel der CAN-Nachricht ein Kommunikationsknoten, welcher zu dem Ethernet-basierten Netzwerk gehört, ist, kann das Gateway 200 eine Ethernet-Nachricht (z. B. die in 3 und 4 gezeigte Ethernet-Nachricht 300) basierend auf der korrespondierenden CAN-Nachricht erzeugen (S1605). Das Gateway 200 kann zum Beispiel eine ASIL-Authentifizierungsinformation für die Ethernet-Nachricht erzeugen und kann die Ethernet-Nachricht, welche einen Kopf, eine Nutzinformation (z. B. die Nutzinformation, welche in der CAN-Nachricht von dem Endknoten #6 231 enthalten ist) und die ASIL-Authentifizierungsinformation aufweist, erzeugen. Das Gateway 200 kann außerdem die Ethernet-Nachricht basierend auf einer Ethernet-Routingtabelle erzeugen. Die Ethernet-Routingtabelle kann DUs angeben, welche über das Ethernetbasierte Netzwerk zu versenden sind. Die Ethernet-Routingtabelle kann beispielsweise ausgestaltet sein, so dass sie gleich oder ähnlich der in 12 gezeigten CAN-Routingtabelle ist. Dementsprechend kann das Gateway 200 die Ethernet-Nachricht, welche mindestens eine durch die Ethernet-Routingtabelle angegebene DU aus den in der Nutzinformation der CAN-Nachricht enthaltenen DUs aufweist, erzeugen.
  • Falls das Ziel der von dem Endknoten #6 231 aus empfangenen CAN-Nachricht der Endknoten #1 211 ist, kann das Gateway 200 die Ethernet-Nachricht an den Endknoten #1 211 senden (S1606). Die Ethernet-Nachricht kann an den Endknoten #1 211 über den Switch #1 210 gesendet werden. Der Endknoten #1 211 kann die Ethernet-Nachricht durch Durchführen eines Überwachungsvorgangs auf die Ethernet-Verbindung empfangen und kann einen Integritätsverifikationsvorgang auf die in der empfangenen Ethernet-Nachricht enthaltene ASIL-Authentifizierungsinformation durchführen. Falls die Integritätsverifikation der ASIL-Authentifizierungsinformation der Ethernet-Nachricht erfolgreich ist, kann der Endknoten #1 211 die in der Ethernet-Nachricht enthaltene Nutzinformation erlangen und die Steuerungsinformation oder die Verwaltungsinformation aus der erlangten Nutzinformation ermitteln. Falls alternativ die Integritätsverifikation der ASIL-Authentifizierungsinformation der Ethernet-Nachricht scheitert, kann der Endknoten #1 211 die Ethernet-Nachricht verwerfen.
  • Die Verfahren gemäß Ausführungsformen der vorliegenden Erfindung können als Programmbefehle implementiert sein, welche durch eine Vielzahl von Computern ausführbar sind und welche auf einem computerlesbaren Medium gespeichert sind. Das computerlesbare Medium kann einen Programmbefehl, eine Datendatei, eine Datenstruktur oder eine Kombination daraus aufweisen. Die auf dem computerlesbaren Medium gespeicherten Programmbefehle können spezifisch für die vorliegende Erfindung entworfen und eingerichtet sein oder können denjenigen Fachmänner in dem Gebiet der Computersoftware öffentlich bekannt und für diese zugänglich sein. Beispiele des computerlesbaren Mediums können eine Hardwarevorrichtung, wie z. B. ROM, RAM und Flashspeicher, welche spezifisch dazu eingerichtet sind, die Programmbefehle zu speichern und auszuführen, aufweisen. Beispiele der Programmbefehle weisen Maschinencodes, welche durch beispielsweise einen Compiler erzeugt werden, sowie Codes höherer Programmiersprachen, die unter Verwendung eines Interpreters durch einen Computer ausführbar sind, auf. Die vorstehende beispielhafte Hardwarevorrichtung kann dazu eingerichtet sein, als mindestens ein Softwaremodul zu arbeiten, um den Betrieb der vorliegenden Erfindung durchzuführen, und umgekehrt.
  • Obwohl die Ausführungsformen der vorliegenden Erfindung und ihre Vorteile vorstehend im Detail beschrieben wurden, ist zu verstehen, dass zahlreiche Änderungen, Ersetzungen und Abwandlungen darin gemacht vorgenommen werden können, ohne dabei vom Umfang der Erfindung abzuweichen.
  • 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 10-2016-0118340 [0001]
    • KR 10-2017-0095128 [0001]
  • Zitierte Nicht-Patentliteratur
    • IEEE 802.3 [0081]
    • IEEE 802.3 [0086]
    • IEEE-802.1AS-Zeitstempelung-Protokoll [0087]
    • IEEE-802.1Q-Datenstromreservierungsprotokoll (SRP) [0087]
    • IEEE-802.1Q-Weiterleiten&Warteschlangenbildung-für-zeitsensitiven-Datenstrom(FQTSS-)Protokoll [0087]
    • IEEE-802.1AS-Zeitstempelung-Protokoll [0087]
    • IEEE 802.1AS [0087]
    • IEEE-802.1Q-SRP-Protokoll [0087]
    • IEEE-802.1Q-FQTSS-Protokoll [0087]
    • IEEE-802.1AS-Generalisierte-Präzisionszeit-Protokoll [0091]
    • IEEE-1722-AVB-Transportprotokoll (AVTP) [0091]
    • IEEE-802.1AS-gPTP [0091]
    • IEEE-1722-AVTP [0091]

Claims (20)

  1. Ein Betriebsverfahren eines ersten Kommunikationsknotens (200), welcher Kommunikationen zwischen einem Ethernet-basierten Netzwerk und einem Steuereinrichtungsbereichsnetzwerk (CAN) unterstützt, aufweisend: Empfangen einer Ethernet-Nachricht von einem zweiten Kommunikationsknoten (211), der zu dem Ethernet-basierten Netzwerk gehört, Durchführen einer Integritätsverifikation (S1005) auf eine erste Fahrzeugsicherheitsintegritätsstufe-(ASIL-)Authentifizierungsinformation, welche in der Ethernet-Nachricht enthalten ist, Erzeugen einer CAN-Nachricht (S1009) basierend auf der Ethernet-Nachricht, für welche die Integritätsverifikation abgeschlossen wurde, und Senden der CAN-Nachricht (S1010) an einen dritten Kommunikationsknoten (231), der zum CAN gehört.
  2. Das Betriebsverfahren gemäß Anspruch 1, wobei der zweite Kommunikationsknoten (211) ein Endknoten ist und die erste ASIL-Authentifizierungsinformation durch den Endknoten erzeugt wird.
  3. Das Betriebsverfahren gemäß Anspruch 1 oder 2, wobei die Integritätsverifikation durchgeführt wird (S1005), wenn ein Ziel der Ethernet-Nachricht das CAN ist.
  4. Das Betriebsverfahren gemäß irgendeinem der Ansprüche 1 bis 3, wobei die Integritätsverifikation durchgeführt wird (S1005), wenn die Ethernet-Nachricht eine Steuerungsinformation oder eine Verwaltungsinformation aufweist.
  5. Das Betriebsverfahren gemäß irgendeinem der Ansprüche 1 bis 4, wobei die CAN-Nachricht eine zweite ASIL-Authentifizierungsinformation aufweist, die zweite ASIL-Authentifizierungsinformation für eine Integritätsverifikation auf die CAN-Nachricht verwendet wird, und die zweite ASIL-Authentifizierungsinformation durch den ersten Kommunikationsknoten (200) erzeugt wird.
  6. Das Betriebsverfahren gemäß irgendeinem der Ansprüche 1 bis 5, wobei die CAN-Nachricht mindestens eine durch eine Routingtabelle angegebene Dateneinheit (DU #1, DU #2, DU #6, DU #7, DU #9, DU #10) unter einer Mehrzahl von Dateneinheiten (DU #1–DU #10), welche in der Ethernet-Nachricht enthalten sind, aufweist und die Routingtabelle zum CAN zu übertragende Dateneinheiten (DU #1, DU #2, DU #6, DU #7, DU #9–DU #12, DU #15) angibt.
  7. Das Betriebsverfahren gemäß irgendeinem der Ansprüche 1 bis 6, wobei die CAN-Nachricht mindestens eine Dateneinheit (DU #1, DU #2, DU #6, DU #7), welche eine von in einem Speicher des ersten Kommunikationsknotens gespeicherten Dateneinheiten aus aktualisierte Information aufweist, unter einer Mehrzahl von Dateneinheiten (DU #1, DU #2, DU #6, DU #7, DU #9, DU #10), welche in der Ethernet-Nachricht enthalten sind, aufweisen.
  8. Das Betriebsverfahren gemäß irgendeinem der Ansprüche 1 bis 6, wobei die CAN-Nachricht gemäß einer Übertragungsperiode des CANs gesendet wird.
  9. Ein Betriebsverfahren eines ersten Kommunikationsknotens (200), welcher Kommunikationen zwischen einem Ethernet-basierten Netzwerk und einem Steuergerätenetzwerk (CAN) unterstützt, aufweisend: Empfangen einer CAN-Nachricht von einem zweiten Kommunikationsknoten (231), welcher zu dem CAN gehört, Durchführen einer Integritätsverifikation auf eine erste Fahrzeugsicherheitsintegritätsstufe-(ASIL-)Authentifizierungsinformation (S1603), welche in der CAN-Nachricht enthalten ist, Erzeugen einer Ethernet-Nachricht basierend auf der CAN-Nachricht (S1605), für welche die Integritätsverifikation abgeschlossen wurde, und Senden der Ethernet-Nachricht (S1606) an einen dritten Kommunikationsknoten (211), welcher zu dem Ethernet-basierten Netzwerk gehört.
  10. Das Betriebsverfahren gemäß Anspruch 9, wobei der zweite Kommunikationsknoten (231) ein Endknoten ist, und die erste ASIL-Authentifizierungsinformation durch den Endknoten erzeugt wird.
  11. Das Betriebsverfahren gemäß Anspruch 9 oder 10, wobei die Ethernet-Nachricht eine zweite ASIL-Authentifizierungsinformation aufweisen, die zweite ASIL-Authentifizierungsinformation für eine Integritätsverifikation auf die Ethernet-Nachricht verwendet wird, und die zweite ASIL-Authentifizierungsinformation durch den ersten Kommunikationsknoten (200) erzeugt wird.
  12. Das Betriebsverfahren gemäß irgendeinem der Ansprüche 9 bis 11, wobei die Ethernet-Nachricht mindestens eine durch eine Routingtabelle angegebene Dateneinheit unter einer Mehrzahl von Dateneinheiten, welche in der CAN-Nachricht enthalten sind, aufweist und die Routingtabelle zum Ethernet-basierten Netzwerk zu übertragende Dateneinheiten angibt.
  13. Ein erster Kommunikationsknoten (200), welcher Kommunikationen zwischen einem Ethernet-basierten Netzwerk und einem Steuergerätenetzwerk (CAN) unterstützt, aufweisend: einen Prozessor, und einen Speicher, welcher mindestens eine durch den Prozessor ausgeführte Instruktion speichert, wobei die mindestens eine Instruktion dazu eingerichtet ist: eine Ethernet-Nachricht von einem zweiten Kommunikationsknoten (211), welcher zu dem Ethernet-basierten Netzwerk gehört, zu empfangen, eine Integritätsverifikation auf eine erste Fahrzeugsicherheitsintegritätsstufe-(ASIL-)Authentifizierungsinformation, welche in der Ethernet-Nachricht enthalten ist, durchzuführen (S1005), eine CAN-Nachricht basierend auf der Ethernet-Nachricht, für welche die Integritätsverifikation durchgeführt wurde, zu erzeugen (S1009), und die CAN-Nachricht an einen dritten Kommunikationsknoten (231), welcher zu dem CAN gehört, zu senden (S1010).
  14. Der erste Kommunikationsknoten (200) gemäß Anspruch 13, wobei der zweite Kommunikationsknoten (211) ein Endknoten ist, und die erste ASIL-Authentifizierungsinformation durch den Endknoten erzeugt wird.
  15. Der erste Kommunikationsknoten (200) gemäß Anspruch 13 oder 14, wobei die Integritätsverifikation durchgeführt wird (S1005), wenn ein Ziel der Ethernet-Nachricht das CAN ist.
  16. Der erste Kommunikationsknoten (200) gemäß irgendeinem der Ansprüche 13 bis 15, wobei die Integritätsverifikation durchgeführt wird (S1005), wenn die Ethernet-Nachricht eine Steuerungsinformation oder eine Verwaltungsinformation aufweist.
  17. Der erste Kommunikationsknoten (200) gemäß irgendeinem der Ansprüche 13 bis 16, wobei die CAN-Nachricht eine zweite ASIL-Authentifizierungsinformation aufweist, die zweite ASIL-Authentifizierungsinformation für eine Integritätsverifikation auf die CAN-Nachricht verwendet wird, und die zweite ASIL-Authentifizierungsinformation durch den ersten Kommunikationsknoten (200) erzeugt wird.
  18. Der erste Kommunikationsknoten (200) gemäß irgendeinem der Ansprüche 13 bis 17, wobei die CAN-Nachricht mindestens eine durch eine Routingtabelle angegebene Dateneinheit (DU #1, DU #2, DU #6, DU #7, DU #9, DU #10) unter einer Mehrzahl von Dateneinheiten (DU #1–DU #10), welche in der Ethernet-Nachricht enthalten sind, aufweist und die Routingtabelle zum CAN zu übertragende Dateneinheiten (DU #1, DU #2, DU #6, DU #7, DU #9–DU #12, DU #15) angibt.
  19. Der erste Kommunikationsknoten (200) gemäß irgendeinem der Ansprüche 13 bis 18, wobei die CAN-Nachricht mindestens eine Dateneinheit (DU #1, DU #2, DU #6, DU #7), welche eine von in einem Speicher des ersten Kommunikationsknotens gespeicherten Dateneinheiten aus aktualisierte Information aufweist, unter einer Mehrzahl von Dateneinheiten (DU #1, DU #2, DU #6, DU #7, DU #9, DU #10), welche in der Ethernet-Nachricht enthalten sind, aufweist.
  20. Der erste Kommunikationsknoten (200) gemäß irgendeinem der Ansprüche 13 bis 19, wobei die CAN-Nachricht gemäß einer Übertragungsperiode des CANs gesendet wird.
DE102017121049.0A 2016-09-13 2017-09-12 Kommunikationsverfahren, welches auf einer Fahrzeugsicherheitsintegritätsstufe im Fahrzeugnetzwerk basiert, und Vorrichtung für dasselbige Pending DE102017121049A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2016-0118340 2016-09-13
KR20160118340 2016-09-13
KR10-2017-0095218 2017-07-27
KR1020170095218A KR102352527B1 (ko) 2016-09-13 2017-07-27 차량 네트워크에서 asil에 기초한 통신 방법 및 장치

Publications (1)

Publication Number Publication Date
DE102017121049A1 true DE102017121049A1 (de) 2018-03-15

Family

ID=61246941

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017121049.0A Pending DE102017121049A1 (de) 2016-09-13 2017-09-12 Kommunikationsverfahren, welches auf einer Fahrzeugsicherheitsintegritätsstufe im Fahrzeugnetzwerk basiert, und Vorrichtung für dasselbige

Country Status (3)

Country Link
US (1) US10382221B2 (de)
CN (1) CN107819736B (de)
DE (1) DE102017121049A1 (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102486151B1 (ko) * 2018-10-16 2023-01-10 현대자동차주식회사 통신 장치, 그를 가지는 차량 및 그 제어 방법
US11197158B2 (en) * 2018-11-19 2021-12-07 Hyundai Motor Company Vehicle and method for controlling the same
KR20200073448A (ko) * 2018-12-14 2020-06-24 현대자동차주식회사 게이트웨이 프로세서, 그 제어 로직, 프로그램 및 기록매체
JP7132132B2 (ja) * 2019-01-09 2022-09-06 国立大学法人東海国立大学機構 車載通信システム、車載通信制御装置、車載通信装置、コンピュータプログラム、通信制御方法及び通信方法
US11654926B2 (en) * 2019-03-18 2023-05-23 Mobileye Vision Technologies Ltd. Secure system that includes an open source operating system
KR20200117619A (ko) * 2019-04-05 2020-10-14 현대자동차주식회사 차량, 차량과 통신하는 서버 및 차량의 제어 방법
CN111835627B (zh) * 2019-04-23 2022-04-26 华为技术有限公司 车载网关的通信方法、车载网关及智能车辆
KR20200125133A (ko) * 2019-04-26 2020-11-04 현대자동차주식회사 차량 및 차량 내 메시지 전송 방법
KR20200131639A (ko) * 2019-05-14 2020-11-24 현대자동차주식회사 게이트웨이 장치 및 그 제어방법
DE102019004790A1 (de) * 2019-07-11 2021-01-14 Infineon Technologies Ag Authentizität und Sicherheit auf der Sicherungsschicht für Fahrzeugkommunikationssystem
CN112477779B (zh) 2019-09-12 2024-03-26 华为技术有限公司 实现汽车中电子控制功能的系统、方法以及汽车
CN115716455A (zh) * 2019-09-12 2023-02-28 华为技术有限公司 实现汽车中电子控制功能的系统、方法以及汽车
CN114651456A (zh) 2019-09-20 2022-06-21 桑纳特斯公司 用于交通工具外通信控制的系统、方法和装置
CN110758289B (zh) * 2019-10-31 2021-08-20 上海赫千电子科技有限公司 一种包括车载以太网的车内混合网络的睡眠与唤醒方法
JP7192747B2 (ja) * 2019-11-13 2022-12-20 株式会社オートネットワーク技術研究所 車載中継装置及び情報処理方法
EP4097923A4 (de) * 2020-03-06 2024-04-10 Sonatus Inc System, verfahren und vorrichtung zur verwaltung der erfassung von fahrzeugdaten
US11321442B2 (en) * 2020-03-20 2022-05-03 Infineon Technologies Ag Data link layer authenticity and security for automotive communication system
CN113381918B (zh) * 2020-08-04 2022-09-16 长城汽车股份有限公司 车内信号传输方法及其系统
CN113542265B (zh) * 2021-07-13 2023-11-07 深圳南方德尔汽车电子有限公司 局部网络安全管理、装置、计算机设备及存储介质
JP2023131641A (ja) * 2022-03-09 2023-09-22 株式会社オートネットワーク技術研究所 車載通信装置及び車載通信システム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160118340A (ko) 2014-02-07 2016-10-11 올싸거널 인코포레이티드 교차-결합 가능한 플루오르화된 포토폴리머
KR20170095128A (ko) 2016-02-12 2017-08-22 가부시키가이샤 한도오따이 에네루기 켄큐쇼 반도체 장치 및 전자 기기

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9215168B2 (en) * 2012-07-23 2015-12-15 Broadcom Corporation Controller area network communications using ethernet
US20140109062A1 (en) * 2012-10-11 2014-04-17 Tata Constultancy Services Limited Mumbai System and method to provide compliance scrutiny and in-depth analysis of a software application
CN105730398B (zh) * 2014-12-12 2019-03-26 上海修源网络科技有限公司 移动终端双向控制汽车的系统与方法
DE102015211451A1 (de) * 2015-06-22 2017-01-05 Volkswagen Aktiengesellschaft Verfahren zu einem Manipulationsschutz von über ein Bussystem zwischen Systemkomponenten zu übertragenden Nutzdatenpaketen
CN105227642A (zh) * 2015-09-10 2016-01-06 上海修源网络科技有限公司 用于传输车辆数据的装置及其数据传输方法
CN105242605A (zh) * 2015-10-26 2016-01-13 北京腾控科技有限公司 车联网终端及车联网终端的配置方法
US20170150361A1 (en) * 2015-11-20 2017-05-25 Faraday&Future Inc. Secure vehicle network architecture

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160118340A (ko) 2014-02-07 2016-10-11 올싸거널 인코포레이티드 교차-결합 가능한 플루오르화된 포토폴리머
KR20170095128A (ko) 2016-02-12 2017-08-22 가부시키가이샤 한도오따이 에네루기 켄큐쇼 반도체 장치 및 전자 기기

Non-Patent Citations (11)

* Cited by examiner, † Cited by third party
Title
IEEE 802.1AS
IEEE 802.3
IEEE-1722-AVB-Transportprotokoll (AVTP)
IEEE-1722-AVTP
IEEE-802.1AS-Generalisierte-Präzisionszeit-Protokoll
IEEE-802.1AS-gPTP
IEEE-802.1AS-Zeitstempelung-Protokoll
IEEE-802.1Q-Datenstromreservierungsprotokoll (SRP)
IEEE-802.1Q-FQTSS-Protokoll
IEEE-802.1Q-SRP-Protokoll
IEEE-802.1Q-Weiterleiten&Warteschlangenbildung-für-zeitsensitiven-Datenstrom(FQTSS-)Protokoll

Also Published As

Publication number Publication date
US10382221B2 (en) 2019-08-13
CN107819736B (zh) 2021-12-31
US20180076970A1 (en) 2018-03-15
CN107819736A (zh) 2018-03-20

Similar Documents

Publication Publication Date Title
DE102017121049A1 (de) Kommunikationsverfahren, welches auf einer Fahrzeugsicherheitsintegritätsstufe im Fahrzeugnetzwerk basiert, und Vorrichtung für dasselbige
US10574348B2 (en) Method for time synchronization between communication nodes in network
DE102017121073A1 (de) Diagnostic methods and apparatuses in vehicle network
CN106453148B (zh) 网络中通信节点的操作方法
CN105388858B (zh) 网络中通信节点的操作方法
DE102017217636A1 (de) Verfahren zum Senden und Empfangen von Daten in einem Fahrzeugnetz und Vorrichtung für dieses
DE102020203261A1 (de) Verfahren und einrichtung zum senden und empfangen von aufwecksignalen in fahrzeugnetzwerk
KR102337548B1 (ko) 네트워크의 진단 방법 및 장치
US10122580B2 (en) Operation methods of communication node in network
DE102018104933A1 (de) Betriebsverfahren eines Kommunikationsknotens, welcher Netzwerkverwaltung-Funktionen im Fahrzeugnetzwerk unterstützt
KR102352527B1 (ko) 차량 네트워크에서 asil에 기초한 통신 방법 및 장치
DE102017120505A1 (de) System zur Verifikation einer unregistrierten Vorrichtung basierend auf Informationen eines Ethernet-Switchs und Verfahren für dasselbige
DE102018114778A1 (de) Verfahren zum Verhindern von Diagnosefehlern im Fahrzeugnetzwerk und Vorrichtung dafür
US11368404B2 (en) Method of releasing resource reservation in network
KR20170101046A (ko) 분할된 차량 네트워크에서 통신 방법
KR102452615B1 (ko) 네트워크에서 우선순위에 기초한 데이터의 전송 방법
KR20170011826A (ko) 이더넷 기반의 네트워크를 위한 보안 방법
DE102017127428B4 (de) Verfahren und Vorrichtung zum Wiedergeben von Inhalten basierend auf einer Präsentationszeit im Fahrzeugnetzwerk
DE102017110169A1 (de) Verfahren zum Konfigurieren eines Kommunikationspfads in einem Netzwerk
DE102017127284A1 (de) Betriebsverfahren eines Kommunikationsknotens zur Zeitsynchronisation im Fahrzeugnetzwerk
KR102355085B1 (ko) 차량 네트워크에서 선택적 웨이크업을 위한 통신 노드의 동작 방법
DE102017123270A1 (de) Betriebsverfahren eines Kommunikationsknotens für eine Spiegelung in einem Fahrzeugnetzwerk
KR102342000B1 (ko) 차량 네트워크에서 프레젠테이션 타임에 기초한 콘텐츠의 재생 방법 및 장치
KR102362611B1 (ko) 차량 네트워크에서 데이터의 송수신 방법 및 장치
KR102228331B1 (ko) 네트워크에서 통신 노드의 동작 방법

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication