DE60026734T2 - Brücke zur can-tcp/ip-verbindung - Google Patents

Brücke zur can-tcp/ip-verbindung Download PDF

Info

Publication number
DE60026734T2
DE60026734T2 DE60026734T DE60026734T DE60026734T2 DE 60026734 T2 DE60026734 T2 DE 60026734T2 DE 60026734 T DE60026734 T DE 60026734T DE 60026734 T DE60026734 T DE 60026734T DE 60026734 T2 DE60026734 T2 DE 60026734T2
Authority
DE
Germany
Prior art keywords
tcp
message
network
frame
node
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.)
Expired - Lifetime
Application number
DE60026734T
Other languages
English (en)
Other versions
DE60026734D1 (de
Inventor
Alain Belmont MARBACH
Wolfgang Portsmouth LANGER
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.)
Schneider Automation SAS
Schneider Electric USA Inc
Original Assignee
Schneider Automation SAS
Schneider Automation Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Schneider Automation SAS, Schneider Automation Inc filed Critical Schneider Automation SAS
Application granted granted Critical
Publication of DE60026734D1 publication Critical patent/DE60026734D1/de
Publication of DE60026734T2 publication Critical patent/DE60026734T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H04L12/4135—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
    • 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
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • 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
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/106—Mapping addresses of different types across networks, e.g. mapping telephone numbers to data network addresses
    • 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
    • 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
    • H04L2212/00—Encapsulation of packets
    • 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/08—Protocols for interworking; Protocol conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • ALLGEMEINER STAND DER TECHNIK
  • 1. TECHNISCHES FELD
  • Die vorliegende Erfindung betrifft das Feld der Netzwerkkommunikation. Die vorliegende Erfindung betrifft insbesondere dem Ermöglichen der Kommunikation zwischen einem Feldbussystem (CAN) und einem Netzwerk, das ein Übertragungskontrollprotokoll/Internetprotokoll (TCP/IP) einsetzt, wie das Internet oder ein Ethernet.
  • 2. BESCHREIBUNG DES STANDES DER TECHNIK
  • Eine neue Innovation in lokalen Netzwerken ist der Feldbussystem (CAN)-Standard, dessen Basisniveau in ISO 11898 und ISO 11519-1 identifiziert ist. Der CAN-Standard wurde ursprünglich entwickelt, um verteilte Echtzeit-Kontrollsystemanforderungen in automobiltechnischen Anwendungen zu spezifizieren. An Implementierung gemäß dem CAN-Standard ist ein in Echtzeit verteiltes Kontrollsystem mit verschiedenen elektronischen Bauteilen, die miteinander kommunizieren, und dies nicht durch von dedizierten Kabeln getragene Signale, sondern durch Signale, die durch einen linearen Bus gemäß dem CAN-Protokoll befördert werden. Hersteller wie Intel, Phillips, National Semiconductor, Nippon Electric Company, Siemens und Motorola liefern besonders kostengünstige CAN-Chips, die dem Protokoll entsprechen. Die Verwendung der CAN-Technologie wurde auf andere kundenspezifische Anwendungen ausgedehnt, inklusive industrielle Kontrollanwendungen.
  • Wie in 1 gezeigt wird, sorgt ein CAN-artiges Netzwerk 11a für die Kommunikation von vorbestimmten Nachrichten zwischen Stationen 12a (Knoten des CAN-Netzwerkes, die jeweils eine Kontrolleinheit sind), die in einer linearen Busstruktur durch einen CAN-Bus 14a miteinander verbunden sind. Jede CAN-Station ist der Partner von jeder anderen Station. Anstatt eine Nachricht zu einer anderen Station zu schicken, indem die andere Station angegeben wird, gibt eine Übertragungsstation allen anderen Stationen den Inhalt der Nachricht an, und dies durch Verwendung eines Identifiers, der mit der Nachricht geliefert wird. Bei einer derartigen inhaltsbasierten Adress ierung wird jede Nachricht zu allen anderen Empfangsstationen gebroadcastet, und jede Empfangsstation rangiert die Nachricht aus, bis die Nachricht auf einer vorbestimmten Annahmeliste für den Empfänger steht.
  • Es gibt nunmehr zwei CAN-Versionen, die sich in der Länge des Identifiers unterscheiden. Eine CAN-Implementierung gemäß der CAN-Spezifizierung, Teil A, verwendet einen 11-Bit-Identifier. Gemäß der CAN-Spezifizierung, Teil B, verwendet eine einen 29-Bit-Identifier. Siehe CAN-Spezifizierung, Version 2.0, von Robert Bosch GmbH, Postfach 50, D-7000 Stuttgart 1.
  • Jede Station eines CAN-Netzwerkes kann den CAN-Bus verwenden, um eine Nachricht zu übertragen (broadcasten), wenn der Bus unbesetzt ist. Beim Übertragen einer Nachricht überwacht eine Station den Bus, um anzugeben, dass eine andere Station ebenfalls versucht, eine Nachricht zu übertragen. Wenn es eine andere Station ebenfalls versucht, den Bus zu verwenden, wird die Konkurrenz für den Bus entschieden, indem ein Schema verwendet wird, in dem jeder Nachricht zuvor eine Priorität zugeordnet ist, die die Nachricht begleitet.
  • In einem CAN-artigen Netzwerk wird der Nachrichtentransfer unter Verwendung von vier Framearten erreicht. Ein Datenframe, wie es in 2 gezeigt wird, befördert Daten von einer Sendestation zu Empfängerstationen, und verfügt über einen Identifier (von verschiedener Länge je nach der CAN-Version, wie weiter oben beschrieben wird), der die Nachrichtenart angibt, d.h. deren Inhalt, die für die Inhalt-Adressierung verwendet wird. Ein Remoteframe, wie es in 3 gezeigt wird, befördert eine Anforderung für ein Datenframe mit einem Identifier, der der Gleiche wie derjenige ist, der im Remoteframe verwendet wird. Ein Remoteframe verwendet ein Remote-Übertragungsanforderungs (RTR)-Bit, um sich selbst zu identifizieren, d.h. um anzugeben, dass es eine Anforderung für eine CAN-Nachricht ist. Ein Fehlerframe, wie es in 4 gezeigt wird, wird von jeder Station übertragen, wenn die Station einen Kommunikations (Bus)-Fehler erkennt, d.h. wenn die Station eine Nachricht empfängt, die zyklische Redundanzprüfung (CRC) für die Nachricht jedoch versagt. Ein Overloadframe (nicht dargestellt) wird verwendet, um Extraverzögerung zwischen Datenframes oder Remoteframes bereit zu stellen, eine Verzögerung, die zusätzlich zum Interframe-Spacing (2) kommt.
  • Es wurden verschiedene Anwendungsschichten mit Spezifizierungen entwickelt, die sich insbesondere an Industrie- und Prozesssteuerungsanwendungen, Kontrollnetzwerke für Hochleistungslastkraftwagen und -busse, verteilte Kontrollsysteme und Kontrollnetzwerke für Autos orientieren. All diese Systeme sind jedoch auf die Interknotenkommunikation eingeschränkt und unterstützen nicht das Übertragen mit Knoten durch ein intervenierendes Netzwerk, das ein anderes Protokoll, wie TCP/IP, verwendet, das für die Kommunikation im Internet verwendet wird.
  • WO99/19782 offenbart eine Prozesseinheit, die dazu geeignet ist, mit einer Prozesssteuerungsschleife verbunden zu werden und an der Prozesssteuerungsschleife zu kommunizieren. Die Kommunikation an der Prozesssteuerungsschleife erfolgt in Übereinstimmung mit einem Internetprotokoll. Es ist ebenfalls eine Prozesskommunikationseinheit bereit gestellt, die mit der Prozesssteuerungsschleife verbunden ist. und ein Internet. Die Prozesskommunikationseinheit liefert Prozesssteuerungsinformationen, die von der Prozesssteuerungsschleife empfangen werden, zum Internet. Umgekehrt liefert die Prozesskommunikationseinheit ebenfalls Informationen, die vom Internet empfangen werden, zur Prozesssteuerungsschleife.
  • Benötigt wird eine Einheit, die die Kommunikation zwischen Stationen von zwei verschiedenen CAN-artigen Netzwerken ermöglicht, die durch ein intervenierendes Netzwerk miteinander verbunden sind, und insbesondere ein intervenierendes Netzwerk, das TCP/IP verwendet, wie das Internet. Eine derartige Einheit muss die Schwierigkeit meistern können, dass ein TCP/IP-Netzwerk physikalische Adressierung verwendet, während ein CAN-Netzwerk inhaltsbasierte Adressierung, wie weiter oben dargelegt, verwendet.
  • Benötigt wird ebenfalls ein Weg, um den Inhalt der Nachrichten zu sehen, die in einem CAN-artigen Netzwerk übertragen werden, das einen Remotecomputer verwendet, der mit dem CAN-artigen Netzwerk über ein intervenierendes Netzwerk verbunden ist, das TCP/IP verwendet, wie das Internet. Dies würde sowohl die Überwachung eines CAN-artigen Netzwerkes, als auch das Diagnostizieren von Problemen für das CAN-artige Netzwerk ermöglichen, und all dies von einem entfernten Standort.
  • Demgemäß stellt die vorliegende Erfindung ein Verfahren und eine entsprechende Vorrichtung zum Übertragen einer Feldbussystem (CAN)-Nachricht zwischen einem Sendeknoten, der mit einem sendenden CAN-Netzwerk verbunden ist, und einem Empfangsknoten bereit; wobei die Sende- und Empfangsknoten durch ein Netzwerk miteinander verbunden sind, das gemäß eines Übertragungskontrollprotokoll/Internetprotokolls (TCP/IP) überträgt; wobei die CAN-Nachricht eine CAN-Nachricht-Payload umfasst, die ihrerseits ein Identifierfeld umfasst, das dazu vorgesehen ist, den Inhalt der CAN-Nachricht zu identifizieren, auf Basis einer vorbestimmten Identifier-Inhalt Korrespondenz, die CAN-Netzwerk-abhängig oder genereller knotenabhängig ist, ein Remote-Übertragungsanforderungs-Bit, ein Kontrollfeld, und ein Datenfeld, falls vorhanden; und wobei das Übertragen gemäß TCP/IP, das durch das Übertragen von TCP/IP-Frames ausgeführt wird, einen Header, einen Footer und ein TCP/IP-Datenfeld umfasst. Die Erfindung sorgt dafür, dass der Sendeknoten die CAN-Nachricht-Payload aus der CAN-Nachricht extrahiert; der Sendeknoten die CAN-Nachricht-Payload in den TCP/IP-Frame einbettet, wie das TCP/IP-Datenfeld vom TCP/IP-Frame; sich der Sendeknoten auf ein Routingformular bezieht; wobei das Routingformular für jeden einer Vielzahl von verschiedenen möglichen CAN-Nachricht-Identifierfeld-Werten, eine Adresse im TCP/IP-Netzwerk für andere CAN-Netzwerke, die mit dem sendenden CAN-Netzwerk über das TCP/IP-Netzwerk verbunden sind, angibt.
  • In einem weiteren Aspekt der Erfindung extrahiert der Empfangsknoten die CAN-Nachricht-Payload aus dem TCP/IP-Frame; ändert den Identifier der CAN-Nachricht-Payload im Bedarfsfall ab, um dem CAN-Nachricht- Inhalt im Empfangsknoten zu entsprechen, wobei die Abänderung ausgeführt wird unter Bezugnahme auf abbildungsbezogene Identifier gemäß deren Verwendung bei verschiedenen Netzwerk-Adressen; und, wenn der Empfangsknoten mit einem CAN-Netzwerk verbunden (direkt verbunden) ist, der Empfangsknoten die CAN-Nachricht dem CAN-Netzwerk, mit dem es direkt verbunden ist, broadcastet. Hostet der Empfangsknoten einen Browser, erfolgt kein Broadcasten der empfangenen CAN-Nachricht-Payload, sondern nur ein Anzeigen der CAN-Nachricht durch den Browser zum Prüfen des Browsers durch den Benutzer.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die vorstehenden und weiteren Aufgaben, Merkmale und Vorteile der Erfindung ergeben sich aus der Berücksichtigung der nachfolgenden detaillierten Beschreibung, die in Verbindung mit den beiliegenden Zeichnungen erfolgt. Es zeigen:
  • 1 ein Blockschaltbild, das die Verbindung durch ein TCP/IP-Netzwerk eines CAN-artigen Netzwerks mit einem anderen CAN-artigen Netzwerk und auch mit einem Browser zeigt, gemäß der vorliegenden Erfindung; und
  • 2 ein Datenstrukturdiagramm für ein CAN-Datenframe;
  • 3 ein Datenstrukturdiagramm für ein CAN-Remoteframe;
  • 4 ein Datenstrukturdiagramm für ein CAN-Fehlerframe;
  • 5 ein Datenstrukturdiagramm, das eine CAN-Nachricht zeigt, die in einem TCP/IP-Frame inbegriffen ist, gemäß der vorliegenden Erfindung;
  • 6 ein Flussbild/Task-Allocation-Diagramm, gemäß der vorliegenden Erfindung, zum Übertragen einer CAN-Nachricht über ein TCP/IP-Netzwerk; und
  • 7 ein Flussbild/Task-Allocation-Diagramm, gemäß der vorliegenden Erfindung, zum Empfangen einer CAN-Nachricht über ein TCP/IP-Netzwerk.
  • BEVORZUGTE AUSFÜHRUNGSFORM DER ERFINDUNG
  • Nun wird die bevorzugte Ausführungsform in der besonderen Anwendung beschrieben, in der Feldbussystem (CAN)-Nachrichten über das Internet geliefert werden. Das Internet wird hier als ein Beispiel eines Netzwerkes verwendet, das gemäß dem Übertragungskontrollprotokoll/Internetprotokoll (TCP/IP) kommuniziert. Es versteht sich, dass die vorliegende Erfindung die Kommunikation von CAN-Nachrichten über jegliches Netzwerk, das TCP/IP verwendet, wie jedes Ethernet und nicht nur das Internet, betrifft.
  • Unter jetziger Bezugnahme auf die 1 wird eine Brücke 10a zum Verbinden eines Feldbussystems (CAN) 11a mit einer Internetverbindung 16, die ein Übertragungskontrollprotokoll/Internetprotokoll (TCP/IP) fordert, gezeigt, einen lokalen CAN-Kontroller 21 zum Übertragen über das CAN-Netzwerk 11a; TCP/IP-Protokoll-Utility 23 zum Übertragen über das Internet anhand der Internetverbindung 16 zu umfassen; und eine Schnittstellenanwendung 22 zum Konvertieren von CAN-Nachrichten in eine Form, die für das Übertragen über das Internet geeignet ist, d.h. in eine Form gemäß TCP/IP, und ebenfalls zum Konvertieren von Internetkommunikationen in eine Form, die für die Kommunikation über ein CAN-Netzwerk geeignet ist, d.h. in eine Form gemäß einer oder einer anderen von verschiedenen vorgeschriebenen CAN-Nachrichtenarten. Das CAN-Netzwerk 11a umfasst CAN-Stationen 12a, die über einen CAN-Bus 14a übertragen, durch den die Brücke 10a ebenfalls mit den CAN-Stationen 12a kommuniziert.
  • Unter weiterer Bezugnahme auf die 1 kann eine CAN-Station 12a in einem ersten CAN-Netzwerk 11a über eine Brücke 10a gemäß der vorliegenden Erfindung eine Nachricht übertragen, die auf einer Annahmeliste einer CAN-Station 24 in einem zweiten CAN-Netzwerk 11b, das durch das Internet mit dem ersten CAN-Netzwerk verbunden ist, steht.
  • Hierzu hängt die CAN-Station 24 des zweiten CAN-Netzwerks 11b von einer zweiten Brücke 10b ab.
  • Neben der Fähigkeit, eine Nachricht zu übertragen, die durch eine CAN-Station 24 von einem zweiten CAN-Netzwerk 11b empfangen wurde, kann eine CAN-Station 12a des ersten CAN-Netzwerks 11a eine Nachricht derart übertragen, dass sie von einem Browser gesehen wird, der durch die Internetverbindung 16 über das Internet überträgt. Hierzu stützt sich der Browser 18 auf die Service der Brücke 10a, um die CAN-Nachricht in eine Form zu konvertieren, die für die TCP/IP-Kommunikation geeignet ist.
  • Unter jetziger Bezugnahme auf die 5, ist gemäß der bevorzugten Ausführungsform eine CAN-Nachricht-Payload, d.h. eine CAN-Nachricht ohne Synchronisierbits und deren CRC- und Bestätigungs (ACK)-Felder (wobei das ACK-Feld verwendet wird, um es einer sendenden Station anzuzeigen, wenn eine CAN-Nachricht ohne Fehler empfangen ist), in einem TCP/IP-Datenfeld von einem TCP/IP-Frame eingebettet ist. Ein TCP/IP-Datenfeld kann bis zu mehrere Kilobytes in Länge umfassen, im Vergleich zu 11 Bytes als maximale Länge einer CAN-Nachricht-Payload. In einigen Aspekten der vorliegenden Erfindung wird Vorteil aus dieser Disparität gezogen, indem mehr als eine CAN-Nachricht-Payload in ein TCP/IP-Frame eingebettet ist. Wenn in der bevorzugten Ausführungsform die Brücke 10a eine erste CAN-Nachricht in ein TCP/IP-Frame einbettet, und eine zweite CAN-Nachricht (für denselben Bestimmungsort) erkannt wird, bevor ein vorbestimmter Zeitintervall abläuft, richtet es die Schnittstellenanwendung ein, dass die zweite CAN-Nachricht-Payload demselben TCP/IP-Datenfeld, und so weiter, wie weiter unten beschrieben wird, hinzugefügt wird. Die vorbestimmte Wartezeit ist typischerweise eine Sekunde, beträgt derweilen jedoch 5 Sekunden.
  • Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung, sind die einzigen zwei CAN-Nachrichtenarten, die in ein TCP/IP-Frame eingebettet sind, ein CAN-Datenframe und ein CAN-Remoteframe. Das CAN-Fehlerframe ist unnötig, da, wenn eine lokale Station 12a eine CAN-Nachricht broadcastet und der lokale CAN-Kontroller 21 die CAN- Nachricht empfängt, der lokale CAN-Kontroller 21 (am CAN-Bus 14a) jeden Fehler in der Kommunikation über den CAN-Bus 14a anzeigen wird. Und wenn eine CAN-Nachricht durch die Brücke 10a über das Internet übertragen wird, sorgt das Internet TCP/IP für die Fehlererkennung und -korrektur. Letztlich, wenn eine Nachricht für eine CAN-Station 12b des zweiten CAN-Netzwerks 11b vorgesehen ist, extrahiert die Brücke 10b, die mit dem CAN-Bus 14b verbunden ist, für das zweite Netzwerk die CAN-Nachricht aus dem TCP/IP-Datenframe, konstruiert ein CAN-Datenframe oder CAN-Remoteframe (was einfach davon abhängt, ob die CAN-Nachricht Daten enthält), und broadcastet die CAN-Nachricht am CAN-Bus 14b für das zweite CAN-Netzwerk 11b. Ab diesem Punkt wird das CAN-Protokoll zur Fehlererkennung und -korrektur effektiv. Folgendermaßen ist es für die Brücke 10a nicht notwendig, entweder ein CRC-Feld oder ein ACK-Feld in einem TCP/IP-Datenframe zu umfassen, wenn eine CAN-Nachricht über das Internet übertragen wird.
  • Unter erneuter Bezugnahme auf die 1, verbindet der lokale CAN-Kontroller 21 der Brücke 10a, die um einen Standard CAN-Chip gebildet ist, z.B. der SJA 1000, die Brücke 10a mit dem CAN-Netzwerk 11a. In dieser Verbindung sorgt der lokale CAN-Kontroller 21 für eigenes Bit-Timing und führt Bit-Codierung und Synchronisation aus. Als Schnittstelle zum CAN-Netzwerk 11a, reagiert er ebenfalls auf Fehlerframes beim Übertragen einer CAN-Nachricht, die durch eine oder mehrere CAN-Stationen am CAN-Netzwerk 11a nicht richtig empfangen wird. Wie bereits weiter oben erwähnt wird, zeigt er zusätzlich einen Fehler in der Kommunikation an, wenn er eine CAN-Nachricht über das CAN-Netzwerk 11a empfängt, für die die CRC versagt.
  • Letztlich verfügt der lokale CAN-Kontroller 21 in der bevorzugten Ausführungsform über seine eigene Annahmeliste, und er bestätigt den erfolgreichen Empfang aller CAN-Nachrichten auf dieser Annahmeliste. Eine derartige Liste wird verwendet, wenn einige CAN-Nachrichten für CAN-Stationen eines anderen CAN-Netzwerks, wie das zweite CAN-Netzwerk 11b, vorgesehen sind, mit dem Kommunikation durch die Brücke 10a und über das Internet besteht.
  • Die Brücke 10a, die den lokalen CAN-Kontroller 21 umfasst, wird durch einen Computer (nicht dargestellt) gehostet, der in der bevorzugten Ausführungsform einen internen Bus (nicht dargestellt) zum Übertragen zwischen verschiedenen Kontrollern verwendet, wie zwischen dem lokalen CAN-Kontroller 21 und der CPU (nicht dargestellt) des Computers. Der lokale CAN-Kontroller ist beispielsweise eine Karte in einem ISA-Bus und verfügt über eine zugewiesene I/O-basierte Adresse. Er verwendet einen First-in/First-out (FIFO)-Puffer 24, um CAN-Nachrichten zu speichern, und er kommuniziert mit Modulen, die in der CPU des Computers durch Aufrufen oder Unterbrechungen ausführen. Für den lokalen CAN-Kontroller 21 kann im Falle eines Computers, der DOS oder ein Windows-Betriebssystem einsetzt, beispielsweise eine so genannte ISACAN-PC Karte, die bei der Hitex-Systementwicklung GmbH erhältlich ist, verwendet werden.
  • Dort, wo der lokale CAN-Kontroller 21 die Brücke 10a mit dem CAN-Netzwerk 11a verbindet, verbindet das TCP/IP-Protokoll-Utility 23 die Brücke 10a mit der TCP/IP-Verbindung über das Internet 16. In der bevorzugten Ausführungsform führt das TCP/IP-Protokoll-Utility 23, das in der CPU des Computers, der die Brücke hostet, ausführt, Internetkommunikation genauso wie ein Standard-Internetserver aus. Folgendermaßen scheint die Brücke 10a für das Internet ein Internetserver zu sein. An der Internetseite des TCP/IP-Protokoll-Utility sind die übertragenen Daten in Form von Paketen, gemäß TCP/IP. An der Schnittstellenanwendungs 22 -Seite, sind die übertragenen Daten in Form von Dateien, gemäß dem Betriebssystem, das von der Brücke 10a verwendet wird. Das Betriebssystem ist in der bevorzugten Ausführungsform LINUX.
  • Die Schnittstellenanwendung 22 ist diejenige, die für die Konvertierung zwischen TCP/IP und CAN-Nachrichtenprotokoll sorgt. Sie führt im CPU des Computers, der die Brücke 10a hostet, aus, gemeinsam mit dem TCP/IP-Protokoll-Utility 23. Die Schnittstellenanwendung 22 muss Tasks ausführen, wenn die Brücke entweder über das Internet oder von ihrem direkt verbundenen CAN-Netzwerk 11a eine CAN-Nachricht empfängt.
  • Unter jetziger Bezugnahme auf die 1 und 6, wenn eine CAN-Nachricht von dem ersten CAN-Netzwerk 11a über das Internet über die Brücke 10a übertragen werden soll, wird die CAN-Nachricht durch den lokalen CAN-Kontroller 21 von der Brücke 10a empfangen, da die CAN-Nachricht auf einer Annahmeliste des lokalen CAN-Kontrollers steht, wie weiter oben beschrieben wird, und in den FIFO-Puffer 24 gibt, vorzugsweise nur die Payload, d.h. die Teile der CAN-Nachricht, die in ein TCP/IP-Datenframe einzubetten sind, nämlich das Entscheidungsfeld, das Kontrollfeld und das Datenfeld, sofern vorhanden (keines für ein CAN-Remoteframe). Der lokale CAN-Kontroller 21 meldet dann der Schnittstellenanwendung 22 die CAN-Nachricht durch Einstellen einer Unterbrechung, in der bevorzugten Ausführungsform, oder beim Aufrufen durch die Schnittstellenanwendung 22. Die Schnittstellenanwendung erhält daraufhin die CAN-Nachricht vom FIFO-Puffer 24 des lokalen CAN-Kontrollers 21.
  • Daraufhin muss die Schnittstellenanwendung 22 bestimmen, wie die CAN-Nachricht für die Internetkommunikation adressiert wird. Hierzu verwendet sie ein Routingformular, das angibt, wohin jede CAN-Nachricht, die sie vom lokalen CAN-Kontroller 21 erhalten hat, geschickt werden soll, und dies auf Basis des Identifiers der CAN-Nachricht. Das Routingformular gibt jedem anderen CAN-Netzwerk an, das durch das Internet mit dem ersten Netzwerk verbunden ist, zu welchem eine CAN-Nachricht geschickt werden soll, und dies auf Basis des Identifiers der CAN-Nachricht, der im ersten lokalen CAN-Netzwerk verwendet wird.
  • Tabelle 1. Routingformular, das beim Senden einer CAN-Nachricht über ein TCP/IP-Netzwerk von der Schnittstellenanwendung verwendet wird.
    Figure 00110001
  • Tabelle 1 veranschaulicht das Routingformular, das von der Schnittstellenanwendung 22 für die Brücke 12a durch Senden einer CAN-Nachricht vom ersten CAN-Netzwerk 11a über das Internet entweder zu einem anderen CAN-Netzwerk 11b oder zu einem Browser 18 verwendet wird. Die Identifier in der Tabelle (nicht die tatsächliche Abbildung) sind symbolisch. Folgendermaßen stellt id-CAN-A-x1 den Identifier einer Nachricht x1 im CAN-Netzwerk A dar, (wobei der Designator x1 symbolisch den Nachrichteninhalt angibt, so dass z.B. id-CAN-A-x1 und id-CAN-B-x1 zwei verschiedene Identifier für denselben Nachrichteninhalt sind). Der tatsächliche Identifier ist selbstverständlich anders. Die Tabelle zeigt, dass das durch die Schnittstellenanwendung verwendete Routing die Nachricht vom CAN-Netzwerk A mit dem Identifier id-CAN-A-x1, wobei die erste Internetadresse 111.111.111.111 (oder ein äquivalenter Domainname) ist, und so weiter, zu vier Internetadressen senden wird.
  • Mit einer vorbereiteten Empfängerliste erstellt die Schnittstellenanwendung 22 eine neue Datei mit der CAN-Nachricht-Payload und meldet wiederum dem TCP/IP-Protokoll-Utility 23 die neue Datei und jede Empfängeradresse (am TCP/IP-Netzwerk). Das für jeden Empfänger bereit gestellte TCP/IP-Protokoll-Utility 23 gibt danach den Inhalt der neuen Datei in ein TCP/IP-Datenframe und überträgt ihn über das Internet, anhand jeder Adresse, die durch die Schnittstellenanwendung 22 bereit gestellt ist.
  • Wie bereits weiter oben erwähnt kann in der bevorzugten Ausführungsform die Brücke 10a mehr als eine CAN-Nachricht-Payload in ein TCP/IP-Datenframe geben. Hierzu wartet die Schnittstellenanwendung 22 eine vorbestimmte Zeit, bevor die neue Datei mit der ersten CAN-Nachricht-Payload gespeichert wird, falls andere CAN-Nachrichten durch den lokalen CAN-Kontroller 21 für jeden derselben Bestimmungsorte wie für die erste CAN-Nachricht bereit gestellt werden.
  • Unter jetziger Bezugnahme auf die 7 wird eine Brücke gemäß der vorliegenden Erfindung gezeigt, die als ein Empfangsknoten wirkt, der eine CAN-Nachricht über das Internet empfängt, wobei die CAN-Nachricht durch eine Brücke gemäß der vorliegenden Erfindung, die als ein Sendeknoten wirkt, bereit gestellt wurde. Wenn eine Brücke 10a eine CAN-Nachricht-Payload, die in ein TCP/IP-Datenframe von einem Remote-CAN-Netzwerk 11b eingebettet ist, empfängt, extrahiert sie die CAN-Nachricht-Payload und speichert sie in einer neuen Datei. Dann meldet das TCP/IP-Protokoll-Utility 23 der Schnittstellenanwendung 22 die neu erstellte Datei, indem es die Datei durch Namen und Lokalisierung im Hostcomputer identifiziert, und liefert der Schnittstellenanwendung 22 die Internetadresse des Senders (wobei der Sender eine Brücke ist, die ein Remote-CAN-Netzwerk mit dem Internet verbindet).
  • Nach dem Empfangen der Meldung des TCP/IP-Protokoll-Utility 23, extrahiert die Schnittstellenanwendung 22 die CAN-Nachricht-Payload mit einem Entscheidungsfeld mit einem Identifier, der dem sendenden Remote-CAN-Netzwerk angepasst ist, und verbindet die CAN-Nachricht mit der Internetadresse des sendenden Remote-CAN-Netzwerkes, wie es durch das TCP/IP-Protokoll-Utility 23 bereit gestellt wird. Die Schnittstellenanwendung 22 verwendet danach eine Abbildung (wie zum Beispiel in der Tabelle 2), um zu bestimmen welcher Identifier im lokalen CAN-Netzwerk dem Identifier in der neuen Datei entspricht (d.h. dem Identifier, der vom sendenden Remote-CAN-Netzwerk verwendet wird), in Anbetracht der Internetadresse des Senders. Durch Verwenden einer Unterbrechung oder eines Aufrufprozesses, um den Zugang zum FIFO-Puffer 24 des lokalen CAN-Kontrollers 21 zu erreichen, gibt die Schnittstellenanwendung 22 die CAN-Nachricht-Payload in den FIFO-Puffer 24, wobei der Senderidentifier durch den entsprechenden Identifier für das lokale CAN-Netzwerk 10a ersetzt ist.
  • Tabelle 2. Abbildung, die beim Empfangen einer CAN-Nachricht über ein TCP/IP-Netzwerk von der Schnittstellenanwendung verwendet wird.
    Figure 00130001
  • Als Antwort auf die Unterbrechung, die durch die Schnittstellenanwendung – 22 eingestellt ist, wartet der lokale CAN-Kontroller 21 eine vorbestimmte Zeit, die ausreicht, damit die Schnittstellenanwendung 22 die CAN-Nachricht-Payload in den FIFO-Puffer 24 gibt, und dann die CAN-Nachricht-Payload aufruft, die zusätzlichen CAN-Nachrichtenfelder liefert, die die CRC- und ACK-Felder umfassen, die notwendig sind, um eine komplette CAN-Nachricht (CAN-Datenframe oder CAN-Remoteframe) aufzubauen, und die komplette CAN-Nachricht über das lokale CAN-Netzwerk 11a überträgt (broadcastet).
  • Wie bereits weiter oben erwähnt, ist die vorliegende Erfindung dazu vorgesehen, einen Knoten, der nur einen Browser (nicht eine Brücke gemäß der vorliegenden Erfindung) hostet, aufzuweisen, der eine CAN-Nachricht durch eine Brücke, die als ein Sendeknoten wirkt, liefert, in welchem Fall der Browser, der als der Empfangsknoten wirkt, in einigen Ausführungsformen einfach die CAN-Nachricht-Payload vom TCP/IP-Frame extrahiert und die CAN-Nachricht-Payload für die Prüfung durch den Benutzer des Browsers präsentiert. In der bevorzugten Ausführungsform verwendet der Empfangsknoten, der den Browser hostet, jedoch ebenfalls eine Abbildung, um den Identifier in der empfangenen CAN-Nachricht derart zu ändern, um der Identifier-Inhalt-Verwendung am Empfangsknoten zu entsprechen, wobei die Abänderung auf der Internetadresse des Sendeknotens beruht.
  • Es versteht sich, dass die weiter oben beschriebenen Anordnungen nur die Anwendung der Prinzipien der vorliegenden Erfindung veranschaulichen. Wie bereits weiter oben dargelegt, ist die vorliegende Erfindung insbesondere nicht auf die Verwendung des Sendens von CAN-Nachrichten über das Internet eingeschränkt; sie umfasst das Senden von CAN-Nachrichten über jegliches Netzwerk, in dem Kommunikation per TCP/IP erfolgt, wie in jedem Ethernet. Zusätzlich können zahlreiche Änderungen und alternative Anordnungen vom Fachmann entworfen werden, ohne den Rahmen der vorliegenden Erfindung zu sprengen, und die beiliegenden Ansprüche sind dazu vorgesehen, derartige Änderungen und Anordnungen zu decken.

Claims (5)

  1. Verfahren zum Übertragen einer Feldbussystem (CAN)-Nachricht, wobei das Feldbussystem nachstehend als CAN bezeichnet wird, zwischen einem Sendeknoten (12a), der mit einem sendenden CAN-Netzwerk (11a) verbunden ist, und einem Empfangsknoten (12b), wobei die Sende- und Empfangsknoten durch ein Netzwerk miteinander verbunden sind, das gemäß eines Übertragungskontrollprotokolls/Internetprotokolls überträgt, das nachstehend als TCP/IP bezeichnet wird, wobei die CAN-Nachricht Folgendes umfasst: – ein Start-of-Frame-Bit, – eine CAN-Nachricht-Payload, – ein Feld für zyklische Redundanzprüfung, – ein Bestätigungsfeld, und – ein End-of-Frame-Feld; wobei die CAN-Nachricht-Payload Folgendes umfasst: – ein Identifierfeld, das dazu vorgesehen ist, den Inhalt der CAN-Nachricht zu identifizieren, auf Basis einer vorbestimmten Identifier-Inhalt Korrespondenz, die knotenabhängig ist, – ein Remote-Übertragungsanforderungs-Bit, – ein Kontrollfeld, und – ein optionales Datenfeld; wobei das Übertragen gemäß TCP/IP, das durch das Übertragen von TCP/IP-Frames ausgeführt wird, einen Header, einen Footer und ein TCP/IP-Datenfeld umfasst; wobei das Verfahren durch die Schritte gekennzeichnet ist, in denen: a) der Sendeknoten die CAN-Nachricht-Payload aus der CAN-Nachricht extrahiert; b) der Sendeknoten die CAN-Nachricht-Payload in den TCP/IP-Frame einbettet, wie das TCP/IP-Datenfeld vom TCP/IP-Frame; c) sich der Sendeknoten auf ein Routingformular bezieht, um die Adresse im TCP/IP-Netzwerk vom Empfangsknoten zu bestimmen; und d) der Sendeknoten den TCP/IP-Frame über das TCP/IP-Netzwerk unter Verwendung der Adresse für den Empfangsknoten vom Routingformular überträgt; wobei das Routingformular für jeden einer Vielzahl von verschiedenen möglichen CAN-Nachricht-Identifierfeld- Werten, eine Adresse im TCP/IP-Netzwerk für andere CAN-Netzwerke, die mit dem sendenden CAN-Netzwerk über das TCP/IP-Netzwerk verbunden sind, angibt.
  2. Verfahren nach Anspruch 1, wobei der Empfangsknoten mit einem empfangenden CAN-Netzwerk verbunden ist und wobei das Verfahren ferner die Schritte umfasst, in denen: a) der Empfangsknoten die CAN-Nachricht-Payload aus dem TCP/IP-Frame extrahiert: b) der Empfangsknoten den Identifier der CAN-Nachricht-Payload im Bedarfsfall abändert, um dem CAN-Nachricht-Inhalt im empfangenden CAN-Netzwerk zu entsprechen, wobei die Abänderung unter Bezugnahme auf einen abbildungsbezogenen Identifier in verschiedenen CAN-Netzwerken ausgeführt wird, wobei die verschiedenen CAN-Netzwerke durch ihre Netzwerk-Adressen unterschieden werden: und c) der Empfangsknoten die CAN-Nachricht im empfangenden CAN-Netzwerk broadcastet.
  3. Verfahren nach Anspruch 1, wobei der Empfangsknoten einen Browser hostet, und wobei das Verfahren ferner die Schritte umfasst, in denen: a) der Empfangsknoten die CAN-Nachricht-Payload aus dem TCP/IP-Frame extrahiert: b) der Empfangsknoten den Identifier der CAN-Nachricht-Payload im Bedarfsfall abändert, um dem CAN-Nachricht-Inhalt am Empfangsknoten entsprechen, wobei die Abänderung unter Bezugnahme auf einen abbildungsbezogenen Identifier auf Basis der Netzwerk-Adresse vom Sendeknoten ausgeführt wird.
  4. Vorrichtung zum Senden einer Feldbussystem (CAN)-Nachricht, wobei das Feldbussystem nachstehend als CAN bezeichnet wird, von einem Sendeknoten, der mit einem sendenden CAN-Netzwerk verbunden ist, zu einem Empfangsknoten, wobei die Sende- und Empfangsknoten durch ein Netzwerk miteinander verbunden sind, das gemäß eines Übertragungskontrollprotokolls/Internetprotokolls überträgt, das nachstehend als TCP/IP bezeichnet wird. wobei die CAN-Nachricht Folgendes umfasst: – ein Start-of-Frame-Bit, – ein CAN-Nachricht-Payload, – ein Feld für zyklische Redundanzprüfung, – ein Bestätigungsfeld, und – ein End-of-Frame-Feld; wobei die CAN-Nachricht-Payload Folgendes umfasst: – Inhalt der CAN-Nachricht zu identifizieren, auf Basis einer vorbestimmten Identifier-Inhalt Korrespondenz, die knotenabhängig ist, – ein Remote-Übertragungsanforderungs-Bit, – ein Kontrollfeld, und ein Datenfeld variabler Länge; wobei das Übertragen gemäß TCP/IP, das durch das Übertragen von TCP/IP-Frames ausgeführt wird, einen Header, einen Footer und ein TCP/IP-Datenfeld umfasst; dadurch gekennzeichnet, dass die Vorrichtung Folgendes umfasst: a) ein lokaler CAN-Controller, der auf die CAN-Nachricht reagiert, die über das sendende CAN-Netzwerk gebroadcastet wurde, um die CAN-Nachricht-Payload aus der CAN-Nachricht zu extrahieren und um die CAN-Nachricht-Payload in einem Puffer zu speichern; b) eine Schnittstellenanwendung, die auf die CAN-Nachricht-Payload im Puffer reagiert, um die CAN-Nachricht-Payload in den TCP/IP-Frame wie das TCP/IP-Datenfeld vom TCP/IP-Frame einzubetten, und um die Adresse im TCP/IP-Netzwerk vom Empfangsknoten unter Bezugnahme auf ein Routingformular bereit zu stellen; und d) ein TCP/IP-Protokoll-Dienstprogramm, das auf die Adresse vom Empfangsknoten reagiert und das ferner auf den TCP/IP-Frame reagiert, in dem die CAN-Nachricht-Payload eingebettet ist, um den TCP/IP-Frame über das TCP/IP-Netzwerk unter Verwendung der Adresse für den Empfangsknoten, die vom Routingformular festgelegt ist, zu übertragen; wobei das Routingformular für jeden einer Vielzahl von verschiedenen möglichen CAN-Nachricht-Identifierfeld-Werten, ein Adresse im TCP/IP-Netzwerk für andere CAN-Netzwerke, die mit dem sendenden CAN-Netzwerk über das TCP/IP-Netzwerk verbunden sind, angibt.
  5. Vorrichtung zum Empfangen an einem Empfangsknoten einer Feldbussystem (CAN)-Nachricht, wobei das Feldbussystem nachstehend als CAN bezeichnet wird, die von einem Sendeknoten gesendet wurde, wobei der Sendeknoten mit einem sendenden CAN-Netzwerk verbunden ist, wobei der Empfangsknoten mit einem empfangenden CAN-Netzwerk verbunden ist, wobei die Sende- und Empfangsknoten durch ein Netzwerk miteinander verbunden sind, das gemäß eines Übertragungskontrollprotokolls/Internetprotokolls überträgt, das nachstehend als TCP/IP bezeichnet wird, wobei die CAN-Nachricht Folgendes umfasst: – ein Start-of-Frame-Bit, – ein CAN-Nachricht-Payload, – ein Feld für zyklische Redundanzprüfung, – ein Bestätigungsfeld, und – ein End-of-Frame-Feld; wobei die CAN-Nachricht-Payload Folgendes umfasst: – ein Identifierfeld, das dazu vorgesehen ist, den Inhalt der CAN-Nachricht zu identifizieren, auf Basis einer vorbestimmten Identifier-Inhalt Korrespondenz für das CAN-Netzwerk, in dem die CAN-Nachricht übertragen wird, – ein Remote-Übertragungsanforderungs-Bit, – ein Kontrollfeld, und – ein optionales Datenfeld; wobei das Übertragen gemäß TCP/IP, das durch das Übertragen von TCP/IP-Frames ausgeführt wird, einen Header, einen Footer und ein TCP/IP-Datenfeld umfasst; dadurch gekennzeichnet, dass die Vorrichtung Folgendes umfasst: a) ein TCP/IP-Protokoll-Dienstprogramm, das auf den TCP/IP-Frame reagiert, in dem die CAN-Nachricht-Payload eingebettet ist, um die CAN-Nachricht-Payload aus dem TCP/IP-Frame zu extrahieren, und um die Netzwerk-Adresse vom Sendeknoten bereit zu stellen; b) eine Schnittstellenanwendung, die auf die CAN-Nachricht-Payload reagiert, die aus der TCP/IP-Frame extrahiert wurde, und die auf die Netzwerk-Adresse vom Sendeknoten reagiert, um den Identifier der CAN-Nachricht-Payload im Bedarfsfall abzuändern, um dem CAN-Nachricht-Inhalt im empfangenden CAN-Netzwerk zu entsprechen, wobei die Abänderung unter Bezugnahme auf einen abbildungsbezogenen Identifier in verschiedenen CAN-Netzwerken ausgeführt wird, wobei die verschiedenen CAN-Netzwerke durch ihre TCP/IP-Netzwerk-Adressen unterschieden werden, um der CAN-Nachricht-Payload den im Bedarfsfall abgeänderten Identifier in einem Puffer bereit zu stellen; und c) ein lokaler CAN-Controller, der auf die CAN-Nachricht-Payload im Puffer reagiert, um die CAN-Nachricht-Payload mit zusätzlichen Feldern zu erweitern, die notwendig sind, um eine vollständige CAN-Nachricht bereit zu stellen, und um die vollständige CAN-Nachricht über das empfangende CAN-Netzwerk zu broadcasten.
DE60026734T 1999-12-14 2000-12-07 Brücke zur can-tcp/ip-verbindung Expired - Lifetime DE60026734T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/460,575 US6654355B1 (en) 1999-12-14 1999-12-14 Bridge for CAN to TCP/IP connection
US460575 1999-12-14
PCT/US2000/033187 WO2001045348A2 (en) 1999-12-14 2000-12-07 Bridge for can to tcp/ip connection

Publications (2)

Publication Number Publication Date
DE60026734D1 DE60026734D1 (de) 2006-05-11
DE60026734T2 true DE60026734T2 (de) 2006-09-14

Family

ID=23829266

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60026734T Expired - Lifetime DE60026734T2 (de) 1999-12-14 2000-12-07 Brücke zur can-tcp/ip-verbindung

Country Status (6)

Country Link
US (1) US6654355B1 (de)
EP (1) EP1198926B1 (de)
CA (1) CA2362961C (de)
DE (1) DE60026734T2 (de)
MX (1) MXPA01008197A (de)
WO (1) WO2001045348A2 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7948998B2 (en) 2006-09-13 2011-05-24 Autonetworks Technologies, Ltd. Vehicle-mounted LAN system, electronic control unit, relay connection unit, and vehicle-mounted LAN communication means
DE102011089420A1 (de) * 2011-12-21 2013-06-27 Bayerische Motoren Werke Aktiengesellschaft Umsetzeinrichtung und Kommunikationsnetz mit einer Umsetzeinrichtung
US9088436B2 (en) 2007-11-08 2015-07-21 Continental Automotive Gmbh Interconnection of subnetworks by a uniform network layer
DE102014108455A1 (de) * 2014-06-16 2015-12-17 Beckhoff Automation Gmbh Verfahren zum Betreiben eines Netzwerks

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69736278T2 (de) 1996-02-22 2007-06-06 Kvaser Consultant Ab Vorrichtung zur Beeinflussung von Nachrichten in einem CAN-System
EP1155549B1 (de) * 1999-02-26 2005-04-20 Siemens Aktiengesellschaft Verfahren zum übertragen von ethernet-frames
US6732254B1 (en) * 1999-09-15 2004-05-04 Koninklijke Philips Electronics N.V. Can device featuring advanced can filtering and message acceptance
US7289994B2 (en) * 1999-10-18 2007-10-30 Fisher-Rosemount Systems, Inc. Interconnected zones within a process control system
US7333504B2 (en) 2001-03-08 2008-02-19 Honeywell International Inc. Simultaneous serial transmission of messages with data field arbitration
DE10119472A1 (de) * 2001-04-20 2002-10-31 Harman Becker Automotive Sys Schnittstelle für die Datenübertragung zwischen zwei Bussystemen und Betriebsverfahren dafür
US20040143628A1 (en) * 2001-04-20 2004-07-22 Bradford Jonathan D. Systems and methods that discover and configure non-TCP/IP networks and devices residing therein
ATE427521T1 (de) * 2001-07-26 2009-04-15 Freescale Semiconductor Inc Uhrensynchronisation in einem verteilten system
DE10152235B4 (de) * 2001-10-20 2015-01-08 Robert Bosch Gmbh Verfahren zum Erkennen von Fehlern bei der Datenübertragung innerhalb eines CAN-Controllers und ein CAN-Controller zur Durchführung dieses Verfahrens
US7933998B2 (en) * 2002-01-11 2011-04-26 Motorola Mobility, Inc. Dynamic CAN bus system configuration and messaging
US20030212763A1 (en) * 2002-05-09 2003-11-13 Ravi Kashyap Distributed configuration-managed file synchronization systems
US7277913B2 (en) * 2002-05-09 2007-10-02 Sun Microsystems, Inc. Persistent queuing for distributed file systems
US7092972B2 (en) 2002-05-09 2006-08-15 Sun Microsystems, Inc. Delta transfers in distributed file systems
JP3630418B2 (ja) * 2002-09-11 2005-03-16 三菱電機株式会社 ネットワーク通信装置
US20040218591A1 (en) * 2003-04-29 2004-11-04 Craig Ogawa Bridge apparatus and methods of operation
ES2239537B1 (es) * 2004-03-05 2006-11-16 Seat, S.A. Sistema de monitorizacion y control de elementos de un vehiculo.
JP4401239B2 (ja) 2004-05-12 2010-01-20 Ｎｅｃエレクトロニクス株式会社 通信メッセージ変換装置、通信方法及び通信システム
US7620047B2 (en) * 2004-11-23 2009-11-17 Emerson Network Power - Embedded Computing, Inc. Method of transporting a RapidIO packet over an IP packet network
US7120725B2 (en) * 2004-11-23 2006-10-10 Motorola, Inc. Method of communicating a VMEbus signal over IP packet network
CN1855920A (zh) * 2005-04-28 2006-11-01 西门子（中国）有限公司 磁共振系统多点总线上的通信方法
US8265800B2 (en) * 2007-08-20 2012-09-11 Raytheon Company Unmanned vehicle message conversion system
US20090067616A1 (en) * 2007-09-07 2009-03-12 Kerby William Suhre CAN echo cancellation level shifter
FR2939591A1 (fr) 2008-12-10 2010-06-11 Airbus France Procede et dispositif de communication par virtualisation des adresses pour la simulation d'integration de composants
DE102009026995A1 (de) * 2009-06-17 2011-03-31 Robert Bosch Gmbh Verfahren zum Betreiben eines Bussystems, insbesondere eines CAN-Busses
DE102009050767B4 (de) * 2009-10-27 2017-06-14 Siemens Healthcare Gmbh Verfahren und Vorrichtung zur Datenübertragung
CN101977094B (zh) * 2010-10-18 2012-09-26 航天东方红卫星有限公司 一种适于多主通信的星载can总线通信方法
US9219597B2 (en) * 2011-01-25 2015-12-22 Abb Technology Ag Method and transmission protocol for transmission of data among devices sharing a communication channel
ES2441376T3 (es) 2011-03-31 2014-02-04 Siemens Aktiengesellschaft Sistema de automatización redundante
DE102011121255B3 (de) * 2011-12-15 2013-04-18 Lear Corporation Gmbh Steuersystem eines Kraftfahrzeugs mit vereinfachtem Informationsaustausch
EP2660726A1 (de) * 2012-05-02 2013-11-06 SMSC Europe GmbH Verfahren und Vorrichtung zur Emulation eines Bussystems
US9112721B2 (en) * 2012-05-28 2015-08-18 Freescale Semiconductor, Inc. System and methods for enabling a controller area network (CAN) device to operate in different power modes based upon the payload of a wake-up message
DE102012219940A1 (de) * 2012-10-31 2014-04-30 Trumpf Werkzeugmaschinen Gmbh + Co. Kg Repeater, CAN-Kommunikationssystem und Verfahren zur Übertragung eines Datentelegramms innerhalb eines CAN-Kommunikationssystems
US9537332B2 (en) 2013-05-30 2017-01-03 Canara, Inc. Apparatus, system and method for charge balancing of individual batteries in a string of batteries using battery voltage and temperature, and detecting and preventing thermal runaway
CN104580543A (zh) * 2013-10-16 2015-04-29 福达新创通讯科技(厦门)有限公司 数据传输方法、系统及其记录媒体
EP3245856B1 (de) 2014-06-18 2019-11-20 Deere & Company Anordnung zur kontrolle einer geräteschnittstelle eines landwirtschaftlichen arbeitsfahrzeugs
CN104464254B (zh) * 2014-12-08 2018-05-01 中北大学 一种分布式数据同步采集装置及方法
DE102015200301A1 (de) * 2015-01-13 2016-07-14 Robert Bosch Gmbh Verfahren zum Klassifizieren eines Datensegments bezüglich dessen Weiterverarbeitung
DE102015201019A1 (de) * 2015-01-22 2016-07-28 Wobben Properties Gmbh Windenergieanlage und Windenergieanlagen-Bussystem
US10120034B2 (en) 2015-10-07 2018-11-06 Canara, Inc. Battery string monitoring system
US10129150B2 (en) * 2015-12-01 2018-11-13 Marvell World Trade Ltd. Systems and methods for implementing a switched controller area network
WO2017203905A1 (ja) * 2016-05-27 2017-11-30 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ ネットワークハブ、転送方法及び車載ネットワークシステム
JP6962697B2 (ja) * 2016-05-27 2021-11-05 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America ネットワークハブ、転送方法及び車載ネットワークシステム
JP6890025B2 (ja) * 2016-05-27 2021-06-18 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 電子制御ユニット、フレーム生成方法及びプログラム
CN106100955B (zh) * 2016-06-23 2020-01-17 北京东土科技股份有限公司 工业互联网现场层宽带总线数据深度检测实现方法
US10333887B2 (en) * 2016-08-15 2019-06-25 Cisco Technology, Inc. Internet protocol (IP) network virtualization of serial network endpoints
US20180062988A1 (en) * 2016-08-31 2018-03-01 Faraday&Future Inc. Ethernet communication of can signals
DE102016221690A1 (de) * 2016-11-04 2018-05-09 Audi Ag Verfahren zum Übertragen von Datenpaketen zwischen einem Ethernet und einem Bussystem in einem Kraftfahrzeug sowie Gatewayvorrichtung und Kraftfahrzeug
US20180343326A1 (en) * 2017-05-26 2018-11-29 Cisco Technology, Inc. Can to ip internetworking
CN107426073A (zh) * 2017-08-08 2017-12-01 深圳市三旺通信技术有限公司 一种控制器局域网总线延长的方法及装置
DE102017216833A1 (de) * 2017-09-22 2019-03-28 Siemens Aktiengesellschaft Verfahren zum Bereitstellen von Datenpaketen aus einem CAN-Bus; Steuergerät sowie System mit einem CAN-Bus
KR102360168B1 (ko) * 2017-11-01 2022-02-09 현대자동차주식회사 데이터 종류에 따른 프로토콜 변환 장치 및 방법, 그리고 차량 시스템
GB201809308D0 (en) * 2018-06-06 2018-07-25 Canis Automotive Labs Ltd A serial communication system
KR20200079595A (ko) * 2018-12-26 2020-07-06 현대자동차주식회사 메시지 라우팅 시스템 및 그 방법
US11082449B2 (en) * 2019-10-24 2021-08-03 Cypress Semiconductor Corporation Remote memory diagnostics
KR20220001350A (ko) 2020-06-29 2022-01-05 주식회사 엘지에너지솔루션 네트워크 라우팅 장치 및 방법
CN112187936B (zh) * 2020-09-29 2024-03-29 北京车和家信息技术有限公司 车辆数据处理方法、装置、设备、存储介质及车辆
FR3121303B1 (fr) * 2021-03-23 2024-03-15 Psa Automobiles Sa Procédé et dispositif d’émission d’un signal par un premier composant électronique d’un véhicule à destination d’au moins un second composant électronique du véhicule

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
AU9795598A (en) * 1997-10-13 1999-05-03 Rosemount Inc. Communication technique for field devices in industrial processes
US6434156B1 (en) * 1998-07-24 2002-08-13 Nortel Networks Limited Virtual switching for interconnected networks
US6292862B1 (en) * 1998-07-28 2001-09-18 Siemens Aktiengesellschaft Bridge module
US7046638B1 (en) * 2000-10-12 2006-05-16 Robert Bosch Gmbh Wireless access to closed embedded networks
ITTO20010151A1 (it) * 2001-02-20 2002-08-20 Magneti Marelli Spa Modulo circuitale di interconnessione tra reti locali in un sistema elettronico distribuito per autoveicoli.

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7948998B2 (en) 2006-09-13 2011-05-24 Autonetworks Technologies, Ltd. Vehicle-mounted LAN system, electronic control unit, relay connection unit, and vehicle-mounted LAN communication means
DE112007002147B4 (de) * 2006-09-13 2012-08-02 Sumitomo Wiring Systems, Ltd. Fahrzeuginternes LAN-System, elektronische Steuereinheit, Vermittlungsverbindungseinheit und fahrzeuginterne LAN-Kommunikationseinrichtung
DE112007002147B8 (de) * 2006-09-13 2012-10-25 Autonetworks Technologies, Ltd. Fahrzeuginternes LAN-System, elektronische Steuereinheit, Vermittlungsverbindungseinheit und fahrzeuginterne LAN-Kommunikationseinrichtung
US9088436B2 (en) 2007-11-08 2015-07-21 Continental Automotive Gmbh Interconnection of subnetworks by a uniform network layer
DE102011089420A1 (de) * 2011-12-21 2013-06-27 Bayerische Motoren Werke Aktiengesellschaft Umsetzeinrichtung und Kommunikationsnetz mit einer Umsetzeinrichtung
US9344531B2 (en) 2011-12-21 2016-05-17 Bayerische Motoren Werke Aktiengesellschaft Conversion device and communication network having a conversion device
DE102014108455A1 (de) * 2014-06-16 2015-12-17 Beckhoff Automation Gmbh Verfahren zum Betreiben eines Netzwerks
US10116465B2 (en) 2014-06-16 2018-10-30 Beckhoff Automation Gmbh Method for operating a network

Also Published As

Publication number Publication date
CA2362961C (en) 2012-01-03
CA2362961A1 (en) 2001-06-21
WO2001045348A3 (en) 2002-02-14
MXPA01008197A (es) 2002-03-20
US6654355B1 (en) 2003-11-25
EP1198926B1 (de) 2006-03-15
WO2001045348A2 (en) 2001-06-21
EP1198926A2 (de) 2002-04-24
DE60026734D1 (de) 2006-05-11

Similar Documents

Publication Publication Date Title
DE60026734T2 (de) Brücke zur can-tcp/ip-verbindung
EP3429136B1 (de) Verfahren zur übertragung von daten über einen seriellen kommunikationsbus, entsprechend ausgelegter busschnittstelle sowie entsprechend ausgelegtem computerprogramm
DE69729040T2 (de) Netzwerkübertragung
DE69433098T2 (de) Vorrichtung zur Übertragung von Daten
DE60021692T2 (de) Datenübertragungsverfahren und Funk-Endgerät zur Ausführung von Transportschichtprotokoll in einem Funknetz
DE102006011829B4 (de) Verfahren zur Datenkommunikation
EP2090031B1 (de) Verfahren und anordnung zur kommunikation auf einem lin-bus
DE102006058818A1 (de) Vorrichtung und Verfahren zur Umwandlung von Textmitteilungen
DE112005003194B4 (de) Verteilter Domain Name Service
DE112008000598T5 (de) Relaisschaltungseinheit für ein Fahrzeug
EP1675311B1 (de) Verfahren zur Übertragung kurzer Datentelegramme via eines Feldbusses
EP2586162A1 (de) Priorisierte übertragung von datentelegrammen
DE60117109T2 (de) Drahtloses Kommunikationsgerät, drahtloses Kommunikationssystem zu seiner Verwendung und Kommunikationsverfahren hierfür
DE112017006750T5 (de) Schaltvorrichtung, Kommunikationssteuerverfahren und Kommunikationssteuerprogramm
WO2016087584A1 (de) Verfahren und steuergerät zur übertragung sicherheitsrelevanter daten in einem kraftfahrzeug mittels eines ethernet-standards
DE102017207285A1 (de) Datenübertragungsvorrichtung und Verfahren zur Übertragung von Daten für ein Fahrzeug
DE102017012214B4 (de) Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
EP1482701A1 (de) Verfahren zum paketorientierten Übertragen von Daten in Telekommunikationsnetzen mittels Umsetzung in einem Zwischenknoten von einem verbindungslosen zu einem verbindungsorientierten Übertragungsprotokoll und umgekehrt
DE102009050767B4 (de) Verfahren und Vorrichtung zur Datenübertragung
EP1435027A2 (de) Verfahren zur übertragung eines datentelegramms zwischen einer echtzeit-domain und einer nicht-echtzeit-domain und koppeleinheit
EP1540895B1 (de) Verfahren zur permanenten redundanten übertragung von datentelegrammen in kommunikationssystemen
EP1312992B1 (de) Verfahren zum Tunneln eines höherwertigen Protokolls auf einem Feldbussystem
DE102019213322A1 (de) Ethernet Physical Layer Transceiver für Zweidraht-Bustopologie
DE60320567T2 (de) Adressenverwaltungsverfahren
EP0133577B1 (de) Datenübertragungsverfahren in einem digitalen Übertragungsnetzwerk und Vorrichtung zur Durchführung des Verfahrens

Legal Events

Date Code Title Description
8364 No opposition during term of opposition