DE60026734T2 - Brücke zur can-tcp/ip-verbindung - Google Patents
Brücke zur can-tcp/ip-verbindung Download PDFInfo
- 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
Links
- 230000005540 biological transmission Effects 0.000 claims description 15
- 238000000034 method Methods 0.000 claims description 13
- 239000000284 extract Substances 0.000 claims description 6
- 125000004122 cyclic group Chemical group 0.000 claims description 4
- 230000001419 dependent effect Effects 0.000 claims description 4
- 238000012790 confirmation Methods 0.000 claims 3
- 238000004891 communication Methods 0.000 description 20
- 238000004886 process control Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 238000001514 detection method Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
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 Netzwerk11a für die Kommunikation von vorbestimmten Nachrichten zwischen Stationen12a (Knoten des CAN-Netzwerkes, die jeweils eine Kontrolleinheit sind), die in einer linearen Busstruktur durch einen CAN-Bus14a 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 in3 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 in4 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ücke10a zum Verbinden eines Feldbussystems (CAN)11a mit einer Internetverbindung16 , die ein Übertragungskontrollprotokoll/Internetprotokoll (TCP/IP) fordert, gezeigt, einen lokalen CAN-Kontroller21 zum Übertragen über das CAN-Netzwerk11a ; TCP/IP-Protokoll-Utility23 zum Übertragen über das Internet anhand der Internetverbindung16 zu umfassen; und eine Schnittstellenanwendung22 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-Netzwerk11a umfasst CAN-Stationen12a , die über einen CAN-Bus14a übertragen, durch den die Brücke10a ebenfalls mit den CAN-Stationen12a kommuniziert. - Unter weiterer Bezugnahme auf die
1 kann eine CAN-Station12a in einem ersten CAN-Netzwerk11a über eine Brücke10a gemäß der vorliegenden Erfindung eine Nachricht übertragen, die auf einer Annahmeliste einer CAN-Station24 in einem zweiten CAN-Netzwerk11b , das durch das Internet mit dem ersten CAN-Netzwerk verbunden ist, steht. - Hierzu hängt die CAN-Station
24 des zweiten CAN-Netzwerks11b von einer zweiten Brücke10b ab. - Neben der Fähigkeit, eine Nachricht zu übertragen, die durch eine CAN-Station
24 von einem zweiten CAN-Netzwerk11b empfangen wurde, kann eine CAN-Station12a des ersten CAN-Netzwerks11a eine Nachricht derart übertragen, dass sie von einem Browser gesehen wird, der durch die Internetverbindung16 über das Internet überträgt. Hierzu stützt sich der Browser18 auf die Service der Brücke10a , 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ücke10a 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-Kontroller21 die CAN- Nachricht empfängt, der lokale CAN-Kontroller21 (am CAN-Bus14a ) jeden Fehler in der Kommunikation über den CAN-Bus14a anzeigen wird. Und wenn eine CAN-Nachricht durch die Brücke10a über das Internet übertragen wird, sorgt das Internet TCP/IP für die Fehlererkennung und -korrektur. Letztlich, wenn eine Nachricht für eine CAN-Station12b des zweiten CAN-Netzwerks11b vorgesehen ist, extrahiert die Brücke10b , die mit dem CAN-Bus14b 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-Bus14b für das zweite CAN-Netzwerk11b . Ab diesem Punkt wird das CAN-Protokoll zur Fehlererkennung und -korrektur effektiv. Folgendermaßen ist es für die Brücke10a 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-Kontroller21 der Brücke10a , die um einen Standard CAN-Chip gebildet ist, z.B. der SJA1000 , die Brücke10a mit dem CAN-Netzwerk11a . In dieser Verbindung sorgt der lokale CAN-Kontroller21 für eigenes Bit-Timing und führt Bit-Codierung und Synchronisation aus. Als Schnittstelle zum CAN-Netzwerk11a , reagiert er ebenfalls auf Fehlerframes beim Übertragen einer CAN-Nachricht, die durch eine oder mehrere CAN-Stationen am CAN-Netzwerk11a 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-Netzwerk11a 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-Netzwerk11b , vorgesehen sind, mit dem Kommunikation durch die Brücke10a und über das Internet besteht. - Die Brücke
10a , die den lokalen CAN-Kontroller21 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-Kontroller21 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)-Puffer24 , 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-Kontroller21 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ücke10a mit dem CAN-Netzwerk11a verbindet, verbindet das TCP/IP-Protokoll-Utility23 die Brücke10a mit der TCP/IP-Verbindung über das Internet16 . In der bevorzugten Ausführungsform führt das TCP/IP-Protokoll-Utility23 , 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ücke10a 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 Schnittstellenanwendungs22 -Seite, sind die übertragenen Daten in Form von Dateien, gemäß dem Betriebssystem, das von der Brücke10a 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ücke10a hostet, aus, gemeinsam mit dem TCP/IP-Protokoll-Utility23 . Die Schnittstellenanwendung22 muss Tasks ausführen, wenn die Brücke entweder über das Internet oder von ihrem direkt verbundenen CAN-Netzwerk11a eine CAN-Nachricht empfängt. - Unter jetziger Bezugnahme auf die
1 und6 , wenn eine CAN-Nachricht von dem ersten CAN-Netzwerk11a über das Internet über die Brücke10a übertragen werden soll, wird die CAN-Nachricht durch den lokalen CAN-Kontroller21 von der Brücke10a empfangen, da die CAN-Nachricht auf einer Annahmeliste des lokalen CAN-Kontrollers steht, wie weiter oben beschrieben wird, und in den FIFO-Puffer24 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-Kontroller21 meldet dann der Schnittstellenanwendung22 die CAN-Nachricht durch Einstellen einer Unterbrechung, in der bevorzugten Ausführungsform, oder beim Aufrufen durch die Schnittstellenanwendung22 . Die Schnittstellenanwendung erhält daraufhin die CAN-Nachricht vom FIFO-Puffer24 des lokalen CAN-Kontrollers21 . - 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-Kontroller21 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 veranschaulicht das Routingformular, das von der Schnittstellenanwendung
22 für die Brücke12a durch Senden einer CAN-Nachricht vom ersten CAN-Netzwerk11a über das Internet entweder zu einem anderen CAN-Netzwerk11b oder zu einem Browser18 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-Utility23 die neue Datei und jede Empfängeradresse (am TCP/IP-Netzwerk). Das für jeden Empfänger bereit gestellte TCP/IP-Protokoll-Utility23 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 Schnittstellenanwendung22 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 Schnittstellenanwendung22 eine vorbestimmte Zeit, bevor die neue Datei mit der ersten CAN-Nachricht-Payload gespeichert wird, falls andere CAN-Nachrichten durch den lokalen CAN-Kontroller21 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ücke10a eine CAN-Nachricht-Payload, die in ein TCP/IP-Datenframe von einem Remote-CAN-Netzwerk11b eingebettet ist, empfängt, extrahiert sie die CAN-Nachricht-Payload und speichert sie in einer neuen Datei. Dann meldet das TCP/IP-Protokoll-Utility23 der Schnittstellenanwendung22 die neu erstellte Datei, indem es die Datei durch Namen und Lokalisierung im Hostcomputer identifiziert, und liefert der Schnittstellenanwendung22 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 Schnittstellenanwendung22 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-Utility23 bereit gestellt wird. Die Schnittstellenanwendung22 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-Puffer24 des lokalen CAN-Kontrollers21 zu erreichen, gibt die Schnittstellenanwendung22 die CAN-Nachricht-Payload in den FIFO-Puffer24 , wobei der Senderidentifier durch den entsprechenden Identifier für das lokale CAN-Netzwerk10a ersetzt ist. - Als Antwort auf die Unterbrechung, die durch die Schnittstellenanwendung –
22 eingestellt ist, wartet der lokale CAN-Kontroller21 eine vorbestimmte Zeit, die ausreicht, damit die Schnittstellenanwendung22 die CAN-Nachricht-Payload in den FIFO-Puffer24 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-Netzwerk11a ü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)
- 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. - 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.
- 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.
- 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.
- 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.
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)
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0882342B1 (de) * | 1996-02-22 | 2006-07-05 | Kvaser Consultant Ab | Vorrichtung zur Beeinflussung von Nachrichten in einem CAN-System |
WO2000052706A2 (de) * | 1999-02-26 | 2000-09-08 | 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 |
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 |
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 |
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 |
US7092972B2 (en) * | 2002-05-09 | 2006-08-15 | Sun Microsystems, Inc. | Delta transfers in distributed file systems |
US7277913B2 (en) * | 2002-05-09 | 2007-10-02 | Sun Microsystems, Inc. | Persistent queuing for distributed file systems |
US20030212763A1 (en) * | 2002-05-09 | 2003-11-13 | Ravi Kashyap | Distributed configuration-managed file synchronization 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 | Necエレクトロニクス株式会社 | 通信メッセージ変換装置、通信方法及び通信システム |
US7120725B2 (en) * | 2004-11-23 | 2006-10-10 | Motorola, Inc. | Method of communicating a VMEbus signal over IP packet network |
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 |
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总线通信方法 |
WO2012101662A1 (en) * | 2011-01-25 | 2012-08-02 | Power-One Italy S.P.A. | Transmission protocol |
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 |
JP6962697B2 (ja) * | 2016-05-27 | 2021-11-05 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America | ネットワークハブ、転送方法及び車載ネットワークシステム |
WO2017203905A1 (ja) * | 2016-05-27 | 2017-11-30 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | ネットワークハブ、転送方法及び車載ネットワークシステム |
JP6890025B2 (ja) * | 2016-05-27 | 2021-06-18 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America | 電子制御ユニット、フレーム生成方法及びプログラム |
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5732074A (en) * | 1996-01-16 | 1998-03-24 | Cellport Labs, Inc. | Mobile portable wireless communication system |
CA2306767C (en) * | 1997-10-13 | 2007-05-01 | 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. |
-
1999
- 1999-12-14 US US09/460,575 patent/US6654355B1/en not_active Expired - Lifetime
-
2000
- 2000-12-07 WO PCT/US2000/033187 patent/WO2001045348A2/en active IP Right Grant
- 2000-12-07 DE DE60026734T patent/DE60026734T2/de not_active Expired - Lifetime
- 2000-12-07 CA CA2362961A patent/CA2362961C/en not_active Expired - Lifetime
- 2000-12-07 MX MXPA01008197A patent/MXPA01008197A/es active IP Right Grant
- 2000-12-07 EP EP00984005A patent/EP1198926B1/de not_active Expired - Lifetime
Cited By (8)
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 |
---|---|
EP1198926A2 (de) | 2002-04-24 |
DE60026734D1 (de) | 2006-05-11 |
CA2362961A1 (en) | 2001-06-21 |
US6654355B1 (en) | 2003-11-25 |
WO2001045348A2 (en) | 2001-06-21 |
MXPA01008197A (es) | 2002-03-20 |
CA2362961C (en) | 2012-01-03 |
EP1198926B1 (de) | 2006-03-15 |
WO2001045348A3 (en) | 2002-02-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE60026734T2 (de) | Brücke zur can-tcp/ip-verbindung | |
DE69328578T2 (de) | Leistungsfähiges und betriebssicheres Übertragungsverfahren und System für grosse Datenmengen | |
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 | |
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 | |
DE60117109T2 (de) | Drahtloses Kommunikationsgerät, drahtloses Kommunikationssystem zu seiner Verwendung und Kommunikationsverfahren hierfür | |
WO2018077528A1 (de) | Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern | |
EP2586162A1 (de) | Priorisierte übertragung von datentelegrammen | |
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 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition |