DE102009050767A1 - Verfahren und Vorrichtung zur Datenübertragung - Google Patents

Verfahren und Vorrichtung zur Datenübertragung Download PDF

Info

Publication number
DE102009050767A1
DE102009050767A1 DE102009050767A DE102009050767A DE102009050767A1 DE 102009050767 A1 DE102009050767 A1 DE 102009050767A1 DE 102009050767 A DE102009050767 A DE 102009050767A DE 102009050767 A DE102009050767 A DE 102009050767A DE 102009050767 A1 DE102009050767 A1 DE 102009050767A1
Authority
DE
Germany
Prior art keywords
network
interface
cam
telegram
transmission
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.)
Granted
Application number
DE102009050767A
Other languages
English (en)
Other versions
DE102009050767B4 (de
Inventor
Harald Karl
Friedrich Lindner
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.)
Siemens Healthcare GmbH
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE102009050767.1A priority Critical patent/DE102009050767B4/de
Priority to PCT/EP2010/065861 priority patent/WO2011051157A1/de
Publication of DE102009050767A1 publication Critical patent/DE102009050767A1/de
Application granted granted Critical
Publication of DE102009050767B4 publication Critical patent/DE102009050767B4/de
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/4616LAN interconnection over a LAN backbone
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/188Time-out mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40006Architecture of a communication node
    • H04L12/40032Details regarding a bus interface enhancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0094Bus
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215Controller Area Network CAN

Abstract

Die Erfindung betrifft ein Verfahren zur Datenübertragung mit einem CAN-Bus (1). Der CAN-Bus (1) wird in wenigstens zwei CAN-Segmente (1.1 bis 1.n) aufgeteilt und die CAN-Segmente (1.1 bis 1.n) des CAN-Busses (1) werden durch ein paketorientiertes Netzwerk (2) logisch miteinander verbunden, wobei CAN-Telegramme mittels des Netzwerkes (2) zwischen CAN-Segmenten (1.1 bis 1.n) übertragen werden. Die Übertragung der CAN-Telegramme über das Netzwerk (2) wird auf Fehlerfreiheit geprüft und ein erkannter Übertragungsfehler wird korrigiert, indem ein von einem sendenden CAN-Segment (1.1 bis 1.n) gesendetes und fehlerhaft übertragenes CAN-Telegramm von diesem CAN-Segment (1.1 bis 1.n) erneut über das Netzwerk (2) gesendet wird. Ferner betrifft die Erfindung eine Vorrichtung zur Datenübertragung mit einem in wenigstens zwei CAN-Segmente (1.1 bis 1.n) aufgeteilten CAN-Bus (1) und einem paketorientierten Netzwerk (2), das die CAN-Segmente (1.1 bis 1.n) logisch miteinander verbindet.

Description

  • Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Datenübertragung mit einem CAN-Bus (CAN = Controller Area Network).
  • CAN-Busse sind Feldbusse, mittels derer verschiedene Geräte zwecks Datenaustausch miteinander vernetzt werden. Sie werden vor allem in sicherheitsrelevanten Bereichen verwendet, bei denen eine hohe Datensicherheit benötigt wird, beispielsweise in der Automobiltechnik zur Vernetzung unterschiedlicher Steuergeräte und Sensoreinheiten, in der Automatisierungstechnik für überwachungstechnische Zwecke oder in der Medizintechnik in Magnetresonanz- und Computertomographen oder Herz-Lungen-Maschinen.
  • In verschiedenen Bereichen, in denen ein CAN-Bus eingesetzt wird, beispielsweise in bekannten Computertomographen mit einem CAN-Bus, wird neben dem CAN-Bus mindestens ein weiteres Netzwerk verwendet.
  • Es ist eine Aufgabe der Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Datenübertragung mit einem CAN-Bus und einem weiteren Netzwerk anzugeben.
  • Die Aufgabe wird erfindungsgemäß hinsichtlich des Verfahrens durch die Merkmale des Anspruchs 1 und hinsichtlich der Vorrichtung durch die Merkmale des Anspruchs 11 gelöst.
  • Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
  • Bei dem erfindungsgemäßen Verfahren zur Datenübertragung wird ein CAN-Bus in wenigstens zwei CAN-Segmente aufgeteilt und die CAN-Segmente des CAN-Busses werden durch ein paketorientiertes Netzwerk logisch miteinander verbunden, wobei CAN-Telegramme mittels des Netzwerkes zwischen CAN-Segmenten übertragen werden. Die Übertragung der CAN-Telegramme über das Netzwerk wird auf Fehlerfreiheit geprüft und ein erkannter Übertragungsfehler wird korrigiert, indem ein von einem sendenden CAN-Segment gesendetes und fehlerhaft übertragenes CAN-Telegramm von diesem CAN-Segment erneut über das Netzwerk gesendet wird.
  • Unter einem paketorientierten Netzwerk wird dabei ein Netzwerk verstanden, in dem Daten paketweise, d. h. in Form einzelner Datenpakete, übertragen werden.
  • Bei dem erfindungsgemäßen Verfahren wird somit ein CAN-Bus mit einem paketorientierten Netzwerk kombiniert, so dass das Netzwerk zwischen einzelnen CAN-Segmenten des CAN-Busses als ein Datentunnel wirkt, über den CAN-Telegramme zwischen den CAN-Segmenten übertragen werden. Mit anderen Worten: Das Netzwerk verbindet die CAN-Segmente logisch zu einem CAN-Bus. Auf diese Weise können vorteilhaft Endgeräte mit Schnittstellen für einen CAN-Bus in den einzelnen CAN-Segmenten über das Netzwerk vernetzt werden, ohne dass ein physikalisch zusammenhängender CAN-Bus zusätzlich zu dem Netzwerk verlegt werden muss. Gegenüber Anlagen oder Geräten, in denen ein herkömmlicher CAN-Bus und ein zusätzliches Netzwerk nebeneinander eingesetzt werden, kann dadurch der Aufwand zur Vernetzung der an den CAN-Bus angeschlossenen Endgeräte erheblich reduziert werden.
  • Durch die Prüfung der Übertragung von CAN-Telegrammen auf Fehlerfreiheit und die Korrektur von Übertragungsfehlern durch wiederholtes Senden eines fehlerhaft übertragenen CAN-Telegramms werden dabei Datenverluste und Datenverfälschungen vorteilhaft reduziert. Insbesondere können dadurch bei der Übertragung von CAN-Telegrammen über das Netzwerk die datensichernden Mechanismen eines CAN-Busses weitgehend beibehalten werden, insbesondere eine deterministische Zugriffssteuerung für das Bandbreitenmanagement, eine Quittierung eines Empfangs eines CAN-Telegramms bzw. ein Melden von Empfangsfehlern und eine Wiederholung des Senden von fehlerhaft übertragenen CAN-Telegrammen. Dadurch eignet sich das erfindungsgemäße Verfahren auch für sicherheitsrelevante Anwendungen, in denen CAN-Busse üblicherweise bevorzugt eingesetzt werden.
  • Moderne paketorientierte Netzwerke ermöglichen außerdem eine erheblich größere Ausdehnung als CAN-Busse. Die Verbindung der CAN-Segmente durch das Netzwerk ermöglicht daher die Realisierung eines logischen CAN-Busses, der eine deutlich größere Ausdehnung als herkömmliche CAN-Busse hat. Dadurch wird die Verwendung insbesondere der sicherheitsrelevanten Vorteile eines CAN-Busses auf deutlich größere Systeme als bisher erweitert.
  • In einer bevorzugten Ausgestaltung des Verfahrens wird jedes CAN-Segment über jeweils eine zugehörige CAN-Schnittstelle an das Netzwerk gekoppelt und das Senden von CAN-Telegrammen aus einem CAN-Segment über das Netzwerk und das Empfangen von CAN-Telegrammen aus dem Netzwerk mittels der zugehörigen CAN-Schnittstelle durchgeführt.
  • Dadurch werden alle Komponenten und Mechanismen zur Anbindung eines CAN-Segmentes an das Netzwerk, insbesondere diejenigen zur Datensicherung, in einer zugehörigen CAN-Schnittstelle vereint. Insbesondere ermöglicht dies vorteilhaft, die speziellen Eigenschaften des verwendeten Netzwerkes durch die Ausbildung der CAN-Schnittstellen zu berücksichtigen, während die einzelnen CAN-Segmente wie bei einem üblichen CAN-Bus und insbesondere unabhängig von den speziellen Eigenschaften des verwendeten Netzwerkes gestaltet werden können.
  • Vorzugsweise wird dabei für jede CAN-Schnittstelle, mittels derer über das Netzwerk ein CAN-Telegramm empfangen wird, überprüft, ob das empfangene CAN-Telegramm fehlerfrei übertragen wurde.
  • Dadurch können fehlerhaft übertragene CAN-Telegramme erkannt werden. Dies erhöht vorteilhaft die Datensicherheit.
  • Dabei wird zur Überprüfung der fehlerfreien Übertragung eines CAN-Telegramms über das Netzwerk vorzugsweise eine CRC-Prüfsumme (CRC = Cyclic Redundancy Check) verwendet, die dem CAN-Telegramm vor dessen Sendung über das Netzwerk mittels der CAN-Schnittstelle des sendenden CAN-Segmentes hinzugefügt wird und die von jeder ein CAN-Telegramm über das Netzwerk empfangenden CAN-Schnittstelle überprüft wird.
  • Unter einer CRC-Prüfsumme wird dabei ein geeigneter Prüfwert verstanden, der zusammen mit einem Datenpaket übertragen wird, um Übertragungsfehler zu erkennen. Dabei wird von einem Empfänger eines Datenpaketes der empfangene Prüfwert mit dem gesendeten Soll-Prüfwert verglichen und auf einen Übertragungsfehler geschlossen, wenn die beiden Prüfwerte voneinander abweichen.
  • Die Verwendung einer CRC-Prüfsumme ist ein einfaches und erprobtes Verfahren, das sich deshalb vorteilhaft zur Erkennung von Übertragungsfehlern eignet.
  • Übertragungsfehler bei der Übertragung von CAN-Telegrammen über das Netzwerk werden vorzugsweise folgendermaßen erkannt und korrigiert:
    • – das CAN-Telegramm wird mittels einer sendenden CAN-Schnittstelle an alle anderen CAN-Schnittstellen gesendet;
    • – wenn mittels einer CAN-Schnittstelle ein CAN-Telegramm aus dem Netzwerk empfangen und dessen Übertragung als fehlerfrei eingestuft wird, wird von dieser CAN-Schnittstelle über das Netzwerk eine positive Bestätigungsnachricht an die sendende CAN-Schnittstelle gesendet;
    • – mittels der sendenden CAN-Schnittstelle wird das CAN-Telegramm erneut über das Netzwerk an alle anderen CAN-Schnittstellen gesendet, wenn die sendende CAN Schnittstelle von wenigstens einer der anderen CAN-Schnittstellen innerhalb einer vorgebbaren Timeout-Zeit keine positive Bestätigungsnachricht empfängt.
  • Auf diese Weise wird einer sendenden CAN-Schnittstelle von einer empfangenden CAN-Schnittstelle eine fehlerfreie Übertragung eines CAN-Telegramms quittiert und die sendende CAN-Schnittstelle kann anhand der von ihr empfangenen Quittierungen die Fehlerfreiheit der Übertragung des CAN-Telegramms überprüfen. Dazu prüft sie, ob sie von allen anderen CAN-Schnittstellen eine positive Bestätigungsnachricht erhält. Ist dies der Fall, wird auf eine fehlerfreie Übertragung des CAN-Telegramms geschlossen. Andernfalls wird auf einen Übertragungsfehler geschlossen und versucht, diesen durch erneutes Senden eines fehlerhaft übertragenen CAN-Telegramms zu korrigieren. Dies reduziert vorteilhaft die Wahrscheinlichkeit eines Datenverlustes und einer Datenverfälschung und erhöht somit die Datensicherheit bei der Übertragung von CAN-Telegrammen über das Netzwerk.
  • Die Vorgabe einer Timeout-Zeit für das Warten auf Bestätigungsnachrichten verhindert dabei vorteilhaft, dass eine CAN-Schnittstelle beliebig lange auf eine Bestätigungsnachricht wartet, dadurch blockiert wird und ein Übertragungsfehler nicht korrigiert wird.
  • Ferner wird vorzugsweise ein von einer CAN-Schnittstelle aus dem Netzwerk empfangenes CAN-Telegramm nur dann mittels dieser CAN-Schnittstelle dem zugehörigen CAN-Segment übergeben, wenn die Übertragung des CAN-Telegramms als fehlerfrei eingestuft wird.
  • Dadurch wird verhindert, dass fehlerhaft übertragene CAN-Telegramme in ein CAN-Segment übertragen werden. Dies verringert einerseits vorteilhaft unnötigen Datenverkehr in den CAN-Segmenten und verhindert andererseits vorteilhaft, dass den an den logischen CAN-Bus angeschlossenen Endgeräten verfälschte Nachrichten zugestellt werden, die möglicherweise zu unerwünschten Reaktionen eines oder mehrerer dieser Endgeräte führen.
  • In einer bevorzugten Ausgestaltung des Verfahrens wird ein von einer CAN-Schnittstelle über das Netzwerk empfangenes CAN-Telegramm in einem Zwischenspeicher der CAN-Schnittstelle zwischengespeichert, bevor es von der CAN-Schnittstelle an das zugehörige CAN-Segment weitergeleitet wird.
  • Durch die Zwischenspeicherung kann ein von einer CAN-Schnittstelle aus dem Netzwerk empfangenes CAN-Telegramm zeitverzögert an das zugehörige CAN-Segment weitergeleitet werden. Dadurch können vorteilhaft Totzeiten überbrückt werden, in denen ein CAN-Segment nicht empfangsbereit ist oder eine Weiterleitung eines CAN-Telegramms an das CAN-Segment aus anderen Gründen nicht möglich ist, insbesondere wenn das CAM-Segment durch den dortigen lokalen Datenverkehr bereits überlastet ist. Insbesondere wird dadurch ein Datenverlust während derartiger Totzeiten vermieden.
  • In einer bevorzugten Weitergestaltung dieser Ausgestaltung des Verfahrens wird von einer CAM-Schnittstelle an alle anderen CAM-Schnittstellen eine entsprechende Speicherstatusnachricht gesendet, sobald die Speicherauslastung ihres Zwischenspeichers einen vorgebbaren ersten Füllschwellwert übeschreitet oder unterschreitet.
  • Alternativ oder zusätzlich wird von jeder CAM-Schnittstelle zyklisch in vorgebbaren Zeitabständen an alle anderen CAN-Schnittstellen eine Speicherstatusnachricht darüber gesendet wird, ob eine aktuelle Speicherauslastung des Zwischenspeichers der jeweiligen CAM-Schnittstelle einen ersten Füllschwellwert überschreitet.
  • Dadurch können alle anderen CAM-Schnittstellen über die Gefahr eines Speicherüberlaufes in dem Zwischenspeicher einer CAM-Schnittstelle oder über die Beseitigung einer derartigen Gefahr informiert werden.
  • Vorzugsweise werden bei dieser Weitergestaltung des Verfahrens ferner von jeder CAM-Schnittstelle anhand der von ihr empfangenen Speicherstatusnachrichten die aktuellen Speicherauslastungen der Zwischenspeicher aller anderen CAN-Schnittstellen überwacht und CAN-Telegramme nur dann versendet, wenn die Speicherauslastungen der Zwischenspeicher aller anderen CAN-Schnittstellen den ersten Füllschwellwert unterschreiten.
  • Dies verhindert, dass CAN-Telegramme über das Netzwerk versendet werden, solange in einer CAN-Schnittstelle ein Speicherüberlauf in deren Zwischenspeicher droht, da das zugehörige CAN-Segment überlastet ist. Dadurch wird das für einen üblichen CAN-Bus charakteristische Bandbreitenmanagement über eine Busarbitrierung mittels CAN-Identifiern nachgebildet und vorteilhaft ein Speicherüberlauf in den Zwischenspeichern der CAN-Schnittstellen und somit ein Datenverlust durch einen derartigen Speicherüberlauf verhindert.
  • Die erfindungsgemäße Vorrichtung zur Datenübertragung weist dementsprechend einen in wenigstens zwei CAN-Segmente aufgeteilten CAN-Bus und ein paketorientiertes Netzwerk auf. Das Netzwerk verbindet die CAN-Segmente logisch derart miteinander, dass von jedem CAN-Segment ein CAN-Telegramm mittels des Netzwerkes sowohl zu allen anderen CAN-Segmenten als auch gezielt zu einem auswählbaren anderen CAN-Segment sendbar ist.
  • Dadurch ermöglicht die erfindungsgemäße Vorrichtung die Durchführung des erfindungsgemäßen Verfahrens mit den oben genannten Vorteilen. Insbesondere ermöglicht sie die Versendung eines CAN-Telegramms über das Netzwerk an alle anderen CAN-Segmente und an ein auswählbares anderes CAN-Segment und damit die oben beschriebene Erkennung und Korrektur von Übertragungsfehlern bei der Übertragung eines CAN-Telegramms über das Netzwerk durch eine Quittierung fehlerfrei empfangener CAN-Datenpakete.
  • Vorzugsweise weist die erfindungsgemäße Vorrichtung jeweils eine CAN-Schnittstelle für jedes CAN-Segment zu dessen Ankopplung an das Netzwerk und zur Steuerung des Sendens von CAN-Telegrammen aus dem CAN-Segment über das Netzwerk und des Empfangens von CAN-Telegrammen aus dem Netzwerk auf.
  • Dadurch wird das Senden und Empfangen von CAN-Telegrammen mittels der CAN-Schnittstellen gemäß dem erfindungsgemäßen Verfahren mit den oben beschriebenen Vorteilen ermöglicht.
  • Ferner weist jede CAN-Schnittstelle vorzugsweise einen Zwischenspeicher zum Speichern aus dem Netzwerk empfangener CAN-Telegramme auf.
  • Dies ermöglicht die Zwischenspeicherung aus dem Netzwerk empfangener CAN-Telegramme und deren zeitverzögerte Weiterleitung an die CAN-Segmente mit den oben beschriebenen Vorteilen.
  • Weitere Vorteile, Merkmale und Einzelheiten der Erfindung werden im Folgenden anhand von Ausführungsbeispielen unter Bezugnahme auf Zeichnungen beschrieben. Dabei zeigen:
  • 1 schematisch eine Vorrichtung zur Datenübertragung mit mehreren CAN-Segmenten eines CAN-Busses, die über ein Netzwerk logisch miteinander verbunden sind,
  • 2 ein Blockschaltbild einer CAN-Schnittstelle,
  • 3 schematisch einen Ablauf einer fehlerfreien Übertragung von CAN-Telegrammen zwischen CAN-Segmenten über ein Netzwerk in einem Blockschaltbild,
  • 4 schematisch einen Ablauf einer Übertragung von CAN-Telegrammen zwischen CAN-Segmenten über ein Netzwerk bei Paketverlust in einem Blockschaltbild, und
  • 5 schematisch einen Ablauf einer Übertragung von CAN-Telegrammen zwischen CAN-Segmenten über ein Netzwerk bei Speicherüberlauf in einer CAN-Schnittstelle in einem Blockschaltbild.
  • Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugszeichen versehen.
  • 1 zeigt schematisch eine Vorrichtung zur Datenübertragung mit einem CAN-Bus 1 mit mehreren CAN-Teilnehmern C.1 bis C.m, der in n CAN-Segmente 1.1 bis 1.n aufgeteilt ist. Die CAN-Segmente 1.1 bis 1.n sind über ein paketorientiertes Netzwerk 2 logisch miteinander verbunden, indem CAN-Telegramme zwischen den CAN-Segmenten 1.1 bis 1.n über das Netzwerk 2 austauschbar sind. Das Netzwerk 2 bildet also einen Tunnel zwischen den CAN-Segmenten 1.1 bis 1.n und verbindet diese logisch zu dem CAN-Bus 1. Die CAN-Teilnehmer C.1 bis C.m sind Endgeräte, die von der jeweiligen Verwendung des CAN-Busses 1 abhängen. Die Gesamtheit der CAN-Teilnehmer C.1 bis C.m und der sie verbindende logische CAN-Bus 1 wird im Folgenden auch als CAN-Netzwerk bezeichnet.
  • Jedes CAN-Segment 1.1 bis 1.n ist über eine unten näher beschriebene ihm zugeordnete CAN-Schnittstelle 3.1 bis 3.n an das Netzwerk 2 gekoppelt. CAN-Telegramme, die in einem der CAN-Segmente 1.1 bis 1.n gesendet werden, werden über die jeweilige CAN-Schnittstelle 3.1 bis 3.n an das Netzwerk 2 und durch das Netzwerk 2 zu jeder anderen CAN-Schnittstelle 3.1 bis 3.n übertragen.
  • Die Paketgröße des CAN-Busses 1 (3 bis 13 Byte zuzüglich einer Prüfsumme zur zyklischen Redundanzprüfung) wird auf die Paketgröße des Netzwerks 2 umgesetzt. Falls das Netzwerk 2 ein CAN-Telegramm eines CAN-Segmentes 1.1 bis 1.n nicht in einem Datenpaket transportieren kann, wird das CAN-Telegramm vor seiner Übertragung in das Netzwerk 2 in CAN-Datenpakete zerlegt, die jeweils von dem Netzwerk 2 übertragen werden können, und diese CAN-Datenpakete werden nach der Übertragung über das Netzwerk 2 wieder zu CAN-Telegrammen zusammengesetzt. Dazu wird in den CAN-Schnittstellen 3.1 bis 3.n ein entsprechender SAR-Mechanismus (SAR = Segmentation and Reassembly) zum Zerlegen und Zusammensetzen von CAN-Telegrammen implementiert.
  • Auf den einzelnen sendenden und empfangenden CAN-Segmenten 1.1 bis 1.n erfolgt der Buszugriff mittels einer Arbitrierung wie bei einem üblichen CAN-Bus durch ein CD-Verfahren (CD = Carrier Detect) und einen zerstörungsfreien, prioritätsgesteuerten Zugang zum Übertragungsmedium. Die Übertragungskapazität des Netzwerkes 2 ist so ausgelegt, dass sie im Mittel ausreicht, um die anfallenden CAN-Telegramme und die Datenpakete zu deren Management (insbesondere zur unten beschriebenen Datensicherung) zu übertragen. Kurzzeitige Überlastsituationen werden in unten näher beschriebener Weise durch interne Bufferspeicher überbrückt. Im Netzwerk 2 wird daher keine Arbitrierung von Netzwerkressourcen benötigt.
  • Die End-to-End-Datensicherung eines üblichen CAN-Busses (von Sender zu Empfänger) wird durch eine segmentierte Datensicherung ersetzt. Dabei stellt jedes CAN-Segment 1.1 bis 1.n für sich die Integrität der übertragenen Daten sicher und bei der Übertragung über das paketorientierte Netzwerk 2 werden im Folgenden näher beschriebene Sicherheitsmechanismen verwendet. Nur korrekt empfangene CAN-Telegramme werden von einem CAN-Segment 1.1 bis 1.n an das Netzwerk 2 oder von dem Netzwerk 2 an ein CAN-Segment 1.1 bis 1.n weitergeleitet.
  • Bei der Übertragung im Netzwerk 2 werden übliche CAN-Sicherheitsmechanismen zur Datensicherung weitestgehend beibehalten. Übertragungsfehler innerhalb des Netzwerks 2 werden über einen Quittierungsmechanismus erkannt und durch erneutes Senden eines fehlerhaft übertragenen CAN-Datenpaktes korrigiert.
  • Dabei werden CAN-Datenpakete durch eine zyklische Redundanzprüfung mittels einer CRC-Prüfsumme (CRC = Cyclic Redundancy Check) und charakteristische Bitwerte gesichert, falls das Netzwerk 2 keine ausreichenden eigenen Sicherheitsmechanismen aufweist. Empfängt eine CAN-Schnittstelle 3.1 bis 3.n ein CAN-Telegramm, so überprüft sie gegebenenfalls dessen CRC-Prüfsumme und quittiert im Fall einer als fehlerfrei eingestuften Übertragung den Empfang des CAN-Datenpaketes, indem sie eine positive Bestätigungsnachricht (Acknowledge-Paket ACK) an den Sender des CAN-Datenpaketes, d. h. an die betreffende CAN-Schnittstelle 3.1 bis 3.n, sendet. Im Falle einer fehlerhaften Übertragung sendet die empfangende CAN-Schnittstelle 3.1 bis 3.n kein Acknowledge-Paket ACK oder sie sendet eine negative Bestätigungsnachricht an den Sender.
  • Die CAN-Schnittstelle 3.1 bis 3.n des Senders überprüft während einer vorgebbaren Timeout-Zeit nach dem Senden eines CAN-Telegramms, ob von allen anderen CAN-Schnittstellen 3.1 bis 3.n von CAN-Segmenten 1.1 bis 1.n ein Acknowledge-Paket ACK eingeht. Wenn nach Ablauf der Timeout-Zeit mindestens ein Acknowledge-Paket ACK fehlt oder eine negative Bestätigungsnachricht empfangen wurde, sendet die CAN-Schnittstelle 3.1 bis 3.n des Senders das CAN-Telegramm erneut an die anderen CAN-Segmente 1.1 bis 1.n des CAN-Busses 1. Die Anzahl der Wiederholungen im Fehlerfall ist konfigurierbar. Die Timeout-Zeit wird dem jeweiligen Netzwerk 2 angepasst. Sie wird insbesondere so gewählt, dass sie länger ist als die zweifache Zeit, die benötigt wird, um ein Datenpaket im Netzwerk 2 zu übertragen, da die Übertragungszeiten eines CAN-Datenpaketes und der Acknowledge-Pakete ACK sowie eine zusätzliche Zeitreserve zu berücksichtigen sind.
  • Da an das Netzwerk 2 in der Regel auch Netzwerkteilnehmer angeschlossen sind, die nicht zu dem CAN-Netzwerk des CAN-Busses 1 gehören, verfügen die zu dem CAN-Netzwerk gehörenden Netzwerkteilnehmer über ein charakteristisches Adressmerkmal, z. B. eine Ethernet-Multicastadresse oder eine spezielle Verbindung. Dadurch wird sichergestellt, dass CAN-Datenpakete nur zwischen den CAN-Segmenten 1.1 bis 1.n ausgetauscht und nicht auch anderen Netzwerkteilnehmern des Netzwerkes 2 zugestellt werden.
  • In einer Weitergestaltung des hier beschriebenen Ausführungsbeispiels können durch geeignete Vergabe von Ordnungs-Kriterien innerhalb des Netzwerks 2, beispielsweise von Adressen, auch mehrere logisch verschiedene CAN-Busse 1 an dem Netzwerk 2 betrieben werden.
  • Das Netzwerk 2 ist sowohl multicast- als auch unicastfähig ausgebildet, d. h. über das Netzwerk 2 können Datenpakete sowohl in Form von Multicast-Datenpaketen an eine Gruppe von Netzwerkteilnehmern als auch als Unicast-Datenpakete gezielt an jeweils einen bestimmten Netzwerkteilnehmer versendet werden.
  • Dabei ermöglicht die Multicast-Fähigkeit, CAN-Datenpakete an alle CAN-Teilnehmer C.1 bis C.m des logischen CAN-Busses 1 zu versenden. Die Unicast-Fähigkeit ermöglicht den oben beschriebenen Quittierungsmechanismus durch die gezielte Übertragung der Acknowledge-Pakete ACK an den Sender eines CAN-Telegramms.
  • Ferner ist das Netzwerk 2 derart ausgebildet, dass eine Zeit angebbar ist, nach der in der Regel ein CAN-Datenpaket über das Netzwerk 2 übertragen ist. Dies ermöglicht, die Timeout-Zeit für das Warten auf Acknowledge-Pakete ACK festzulegen. Durch geeignete Priorisierung der CAN-Telegramme oder andere Echtzeiteigenschaften des Netzwerks 2 kann diese Zeit reduziert und damit die Deterministik der CAN-Tunnelung durch das Netzwerk 2 erhöht werden.
  • Das Netzwerk 2 kann auf verschiedene Weisen realisiert werden, beispielsweise als Ethernetnetzwerk, als IP-Netzwerk (IP = Internetprotokoll) oder als so genanntes SiDaNet-Netzwerk, das aus der DE 10 2005 008 503 B3 bekannt ist.
  • Bei einer Realisierung als Ethernetnetzwerk nach IEEE 802.3 auf Layer 2 können für die Multicastverbindungen die Multicastadressen von Ethernet verwendet werden. Jedes logische CAN-Netzwerk verfügt über eine eigene Multicastadresse. Die Zuordnung der Multicast-Adresse zu einem logischen CAM-Netzwerk kann per Konfiguration der betroffenen Netzwerkteilnehmer oder die Definition und Installation eines entsprechenden Servers vergleichbar zu DHCP (DHCP = Dynamic Host Configuration Protocol) realisiert werden.
  • Zur effektiven Nutzung von Multicastmechanismen in Ethernet ist das Netzwerk 2, wie oben bereits erwähnt, multicastfähig ausgebildet und verfügt vorzugsweise über die Möglichkeit, dass sich Netzwerkteilnehmer an den Netzwerkknoten für bestimmte Multicastadressen registrieren können. Verfügt das Netzwerk 2 nicht über diese Möglichkeit, so werden Multicastadressen wie Broadcastadressen behandelt und jedem Netzwerkteilnehmer zugestellt. Dies führt jedoch zu einer hohen Netzwerklast und einer hohen Empfangsdatenrate bei allen Netzwerkteilnehmern. Alternativ kann ein logisches Multicast-Datenpaket auch in einzelne Unicast-Datenpakete umgesetzt werden. Hierfür ist ein Server notwendig, welcher dem Sender die für die Umsetzung notwendigen Netzwerkteilnehmer der Multicastdomäne liefert.
  • Aufgrund seiner Paketlänge von mindestens 60 Byte lässt sich in einem Ethernetpaket immer mindestens ein CAN-Telegramm verpacken. Es können auch mehrere zeitlich gepufferte CAN-Telegramme in einem Ethernetpaket verpackt und versendet werden, wodurch der Datenverkehr auf dem Netzwerk vorteilhaft verringert wird. Alternativ oder zusätzlich können noch Begleitinformationen im CAN-Telegramm codiert werden, welche für die Zuordnung der Quittungen notwendig sind. Ein Empfänger einer Nachricht ist bei Ethernet immer bekannt, da jedes Ethernetpaket die Quell- und Zieladresse enthält. Die Rückantwort (Acknowledge-Paket ACK) wird per Unicast-Datenpaket gesendet. Damit der Empfänger jedoch die Empfangsantwort (empfangenes Acknowledge-Paket ACK) einem logischen CAN-Netzwerk zuordnen kann, werden noch zusätzliche Paketelemente definiert. Möglich ist dies beispielsweise über die Definition von SSAP/DSAP (SSAP = Source Service Access Point, DSAP = Destination Service Access Point) oder Ethertypes. Hierüber wird mindestens codiert, dass sich die Rückantwort auf den CAN-Dienst bezieht. Die logische Zuordnung zu einem konkreten CAN-Netzwerk kann dann auch in den Nutzdaten des CAN-Telegramms erfolgen. Um die Latenzzeit von CAN-Telegrammen im Netzwerk 2 zu minimieren, werden Ethernetpakete für die CAN-Telegramme vorzugsweise mit einer hohen Priorität (IEEE 802.3q) versendet, vorausgesetzt das Netzwerk 2 unterstützt dies.
  • Alternativ kann das Netzwerk 2 als IP-Netzwerk (Layer 3, 4) unter Verwendung des Netzwerkprotokolls UDP (UDP = User Datagram Protocol) realisiert werden. Ein Vorteil dieser Realisierung gegenüber einem Ethernetnetzwerk ist, dass der Netzwerkzugang hierfür einfacher ist und keine Abhängigkeit vom konkreten Netzwerk 2 besteht. Bei Verwendung des IP können prinzipiell die gleichen Mechanismen wie bei Ethernet benutzt werden, wobei vorzugsweise die gleichen Anforderungen hinsichtlich der Multicast-Fähigkeit gestellt werden. Alternativ ist auch hier die Umsetzung der logischen Multicastdomäne in Unicast-Verbindungen mit Serverunterstützung möglich. Die Zuordnung von empfangenen IP-Telegrammen zum CAN-Dienst und dem entsprechenden CAN-Netzwerk ist bei Verwendung des IP einfacher als bei Ethernet, da hierfür UDP-Ports verwendet werden können.
  • Das in der DE 10 2005 008 503 B3 beschriebene so genannte Si-DaNet kann ebenfalls als Netzwerk 2 verwendet werden. Es ist ein echtzeitfähiges, verbindungsorientiertes Netzwerk zur Kommunikation innerhalb einer Maschine. Die Multicast-Verbindungen werden in SiDaNet über Punkt-zu-Multipunkt-Verbindungen realisiert. Die Unicast-Verbindungen werden in SiDaNet über Punkt-zu-Punkt-Verbindungen realisiert. Jede Verbindung zwischen zwei Netzwerkteilnehmern hat dabei eine eindeutige Verbindungskennung. Daher sind keine weiteren Telegrammmerkmale zur Zuordnung eines empfangenen CAN-Telegramms zum CAN-Dienst oder einem CAN-Netzwerk notwendig. Die Konfiguration, welcher SiDaNet-Teilnehmer Bestandteil welchen CAN-Netzes ist, erfolgt einfach und symbolisch in einer Netzwerkbschreibung (SND = SiDaNet Network Description). Ein SiDaNet-Network Manager erzeugt daraus automatisch die notwendigen Verbindungen innerhalb des SiDaNet und beschreibt diese in der Konfiguration für die Netzwerkteilnehmer (SDC = SiDaNet Device Configuration SDC) und Switches (SSC = SiDaNet Switch Configuration).
  • 2 zeigt eine einem ersten CAN-Segment 1.1 zugeordnete erste CAN-Schnittstelle 3.1 mit deren einzelnen Komponenten in einem Blockschaltbild. Die einzelnen Komponenten sind ein CAN-Controller 4, ein CAN_Rx-Paketspeicher 5, eine CRC-Ergänzungseinheit 6, eine CAN_Rx-Steuerung 7, ein Netzwerkcontroller 8, ein CAN_Tx-Paketspeicher 9, eine CRC-Überprüfungseinheit 10, eine CAN_Tx-Steuerung 11 und ein Zwischenspeicher 12.
  • Der CAN-Controller 4 weist eine CAN-Netzwerkschnittstelle auf, über die normkonform CAN-Sendetelegramme Tx1 an das zu der CAN-Schnittstelle 3.1 gehörige CAN-Segment 1.1 sendbar und CAN-Empfangstelegramme Rx1 aus dem CAN-Segment 1.1 empfangbar sind. Dabei werden alle CAN-Sicherungsmechanismen eingehalten. Insbesondere wird mit den CAN-Sendetelegrammen Tx1 eine CAN-CRC-Prüfsumme übertragen, und es wird eine CAN-CRC-Prüfsumme der CAN-Empfangstelegramme Rx1 überprüft. Die CAN-CRC-Prüfsumme umfasst beispielsweise 16 Bit.
  • Der CAN-Controller 4 entfernt vorzugsweise die CAN-CRC-Prüfsumme der korrekt empfangenen CAN-Empfangstelegramme Rx1 und stellt dem CAN_Rx-Paketspeicher 5 an einem Ausgang die von der CAN-CRC-Prüfsumme befreiten CAN-Empfangstelegramme Rx1 zur Verfügung. Alternativ kann die CAN-CRC-Prüfsumme mit zu dem CAN_Rx-Paketspeicher 5 übertragen werden. Dies ist aber in der Regel nicht notwendig und erhöht nur unnötig das Datenaufkommen. In Senderichtung zu dem CAN-Segment 1.1 gibt der CAN-Controller 4 die CAN-Sendetelegramme Tx1 normkonform zu dem CAN-Segment 1.1 aus.
  • Der CAN_Rx-Paketspeicher 5 stellt der CRC-Ergänzungseinheit 6 die CAN-Empfangstelegramme Rx1 zur Verfügung. Aufgrund der in der Regel eingeschränkten Deterministik des Netzwerks 2 können dabei auch CAN-Empfangstelegramme Rx1 temporär in dem CAN_Rx-Paketspeicher 5 zwischengepuffert werden.
  • Die CRC-Ergänzungseinheit 6 fügt den CAN-Empfangstelegrammen Rx1 für die Übertragung im Netzwerk 2 eine neue CRC-Prüfsumme hinzu, die beispielsweise ebenfalls 16 Bit umfasst. Wenn die Sicherungsmechanismen des Netzwerks 2 ausreichend sind, kann die CRC-Ergänzungseinheit 6 auch entfallen.
  • Die CAN_Rx-Steuerung 7 koordiniert die am Netzwerk 2 gesendeten CAN-Telegramme in folgender Weise:
    • – Sie veranlasst die Sendung eines neuen CAN-Telegramms über das Netzwerk 2, wenn das Netzwerk 2 Übertragungskapazität frei hat.
    • – Sie verhindert das Senden von CAN-Telegrammen über das Netzwerk 2, wenn eine andere CAN-Schnittstelle 3.2 bis 3.n Überlast festgestellt hat und dies in unten näher beschriebener Weise durch eine Speicherstatusnachricht Xoff mitteilt, und sie gibt das Senden wieder frei, wenn keine andere CAN-Schnittstelle 3.2 bis 3.n mehr überlastet ist.
    • – Sie überprüft durch Empfang der Acknowledge-Pakete ACK, ob alle Empfänger im Netzwerk 2 das CAN-Telegramm fehlerfrei empfangen haben.
    • – Sie wiederholt die Übertragung eines CAN-Telegramms im Netzwerk 2, wenn ein Empfänger das CAN-Telegramm falsch oder gar nicht (fehlendes Acknowledge-Paket ACK) empfangen hat.
  • Der Netzwerkcontroller 8 weist eine Schnittstelle zum Netzwerk 2 auf, über die die CAN-Telegramme normkonform an das Netzwerk 2 sendbar und aus dem Netzwerk 2 empfangbar sind.
  • Wenn das Netzwerk 2 CAN-Telegramme nicht vollständig in einem Datenpaket übertragen kann, zerlegt der Netzwerkcontroller 8 ferner korrekt empfangene CAN-Empfangstelegramme Rx1 in entsprechend angepasste CAN-Sendedatenpakete Tx2 und setzt in Zusammenwirken mit dem CAN_Tx-Paketspeicher 9 in unten näher beschriebener Weise aus dem Netzwerk 2 empfangene CAN-Empfangsdatenpakete Rx2 zu CAN-Sendetelegrammen Tx1 zusammen (SAR-Mechanismus). Die CAN-Sendedatenpakete Tx2 und CAN-Empfangsdatenpakete Rx2 enthalten somit CAN-Teiltelegramme, falls das Netzwerk 2 CAN-Telegramme nicht vollständig in einem Datenpaket übertragen kann, d. h. in diesem Fall werden die CAN-Telegramme segmentiert über das Netzwerk 2 übertragen; andernfalls enthalten die CAN-Sendedatenpakete Tx2 und die CAN-Empfangsdatenpakete Rx2 vollständige CAN-Telegramme.
  • Bei segmentierter Übertragung der CAN-Telegramme über das Netzwerk 2 nimmt der CAN_Tx-Paketspeicher 9 die über das Netzwerk 2 empfangenen CAN-Empfangsdatenpakete Rx2 auf und puffert die CAN-Empfangsdatenpakete Rx2 eines CAN-Telegramms bis das CAN-Telegramm vollständig empfangen wurde. Erfolgt am Netzwerk 2 keine segmentierte Übertragung, so wird der CAN_Tx-Paketspeicher 9 nicht benötigt.
  • Der CAN_Tx-Paketspeicher 9 weist mindestens n – 1 Speicherplätze auf, wobei jedem der CAN-Segmente 1.2 bis 1.n mindestens ein Speicherplatz zugeordnet ist und jeder Speicherplatz genau ein CAN-Telegramm speichern kann. Ferner ist jeder Speicherplatz in Speicherplatzsegmente unterteilt, deren Anzahl einer maximalen Anzahl von CAN-Empfangsdatenpaketen Rx2 entspricht, in die ein CAN-Telegramm bei der Übertragung über das Netzwerk 2 segmentiert wird, und die jeweils ein CAN-Empfangsdatenpaket Rx2 speichern können. Wenn ein CAN-Empfangsdatenpaket Rx2 über das Netzwerk 2 eintrifft, ordnet der Netzwerkcontroller 8 dem CAN-Empfangsdatenpaket Rx2 aufgrund in ihm enthaltener Ordnungsmerkmale einen entsprechenden Speicherplatz und ein entsprechendes Speicherplatzsegment zu, in das das CAN-Empfangsdatenpaket Rx2 abzulegen ist. Auf diese Weise werden die CAN-Empfangsdatenpakete Rx2 eines CAN-Telegramms in richtiger Reihenfolge in einem Speicherplatz abgelegt, der dem jeweils sendenden CAN-Segment 1.2 bis 1.n zugeordnet ist, und dabei sukzessive zu dem vollständigen CAN-Telegramm zusammengesetzt.
  • Nachdem ein CAN-Telegramm vollständig empfangen wurde, wird es an die CRC-Überprüfungseinheit 10 weitergereicht. Dadurch wird der entsprechende Speicherplatz im CAN_Tx-Paketspeicher 9 frei und für ein weiteres CAN-Telegramm aufnahmebereit.
  • Mittels der CRC-Überprüfungseinheit 10 wird die CRC-Prüfsumme der empfangenen CAN-Telegramme überprüft, falls zur Datensicherung am Netzwerk 2 eine CRC-Prüfsumme eingesetzt wird. Ist dies nicht der Fall, wird keine CRC-Überprüfungseinheit 10 benötigt.
  • Die CAN_Tx-Steuerung 11 regelt das Senden von CAN-Sendetelegrammen Tx1 am CAN-Segment 1.1 auf folgende Weise:
    • – Sie leitet korrekt empfangene CAN-Empfangsdatenpakete Rx2 in den Zwischenspeicher 12 weiter.
    • – Sie leitet die korrekt empfangenen CAN-Empfangsdatenpakete Rx2 aus dem Zwischenspeicher 12 an den CAM-Controller 4 weiter, wenn dieser zu deren Aufnahme bereit ist.
    • – Sie quittiert einen korrekten Empfang eines CAN-Empfangsdatenpaketes Rx2, indem sie ein Acknowledge-Paket ACK an den Sender zurückschickt.
    • – Sie überwacht den Füllstand des Zwischenspeichers 12 und veranlasst bei drohendem Überlauf das Senden einer Xoff-Nachricht und nach Abbau der Überlast das Senden einer Xon-Nachricht an alle Sender im Netzwerk 2.
    • – Dabei sendet sie die Xon- bzw Xoff-Nachrichten zyklisch, um eine Blockade der Datenübertragung aufgrund von Übertragungsfehlern zu verhindern.
    • – Sie sendet ein so genanntes Backpressure-Telegramm BP, d. h. ein CAM-Telegramm höchster Priorität zum Blockieren der Aktivitäten der CAM-Teilnehmer C.1 bis C.m im CAM-Segment 1.1 an das CAM-Segment 1.1, wenn der eigene CANRx-Paketspeicher 5 zu voll wird oder die CAN_Rx-Steuerung 7 eine Speicherstatusnachricht Xoff eines anderen CAM-Segmentes 1.2 bis 1.n empfangen hat. Dadurch wird verhindert, dass bei der Überlastsituation neue CAM-Sendedatenpakete Tx2 in das Netzwerk 2 eingespeist werden. Vor dem Senden eines Backpressure-Telegramms BP wird versucht, den eigenen Zwischenspeicher 12 zu leeren.
  • Der Zwischenspeicher 12 bildet einen Puffer für korrekt empfangene CAM-Telegramme vor deren Übertragung an den CAM-Controller 4. Der Zwischenspeicher 12 ist vorzugsweise derart ausgebildet, dass er mehrere CAM-Telegramme gleichzeitig zwischenspeichern kann. Dabei ist er vorzugsweise als ein Fifo-Speicher (Fifo = First in – first out) ausgebildet, bei dem diejenigen CAM-Telegramme, die zuerst gespeichert wurden, auch zuerst wieder aus dem Speicher entnommen werden.
  • 3 zeigt schematisch einen Ablauf einer fehlerfreien Übertragung eines CAM-Telegrammes von dem ersten CAM-Segment 1.1 zu den anderen CAM-Segmenten 1.2 bis 1.n über das Netzwerk 2 in einem Blockschaltbild. Dabei werden eine segmentierte Übertragung des CAM-Telegramms und die Sicherung des CAM-Telegramms mit einer CRC-Prüfsumme bei der Übertragung über das Netzwerk 2 angenommen. Bei einer nicht segmentierten oder einer nicht CRC-gesicherten Übertragung vereinfacht sich der Ablauf entsprechend.
  • Sobald der CAM-Controller 4 der ersten CAM-Schnittstelle 3.1 ein empfangenes CAM-Empfangstelegramme Rx1 meldet, wird dieses ausgelesen und in den CAN_Rx-Paketspeicher 5 der ersten CAM-Schnittstelle 3.1 geschrieben, der mehrere CAM-Empfangstelegramme Rx1 speichern kann.
  • Liegt mindestens ein CAM-Empfangstelegramm Rx1 im CAN_Rx-Paketspeicher 5 der ersten CAM-Schnittstelle 3.1, wird dieses mittels deren CRC-Ergänzungseinheit 6 mit der CRC-Prüfsumme versehen, von dem Netzwerkcontroller 8 in CAN-Sendedatenpakete Tx2 segmentiert, die über das Netzwerk 2 als Multicast-Datenpakete an alle anderen CAM-Schnittstellen 3.2 bis 3.n übertragen werden, die logisch demselben CAM-Netzwerk angehören.
  • In jeder das CAM-Telegramm empfangenden CAM-Schnittstelle 3.2 bis 3.n werden die empfangenen CAM-Empfangstelegramme Rx2 dieses CAM-Telegramms zunächst wie oben beschrieben in einen dem sendenden ersten CAM-Segment 1.1 zugeordneten Speicherplatz des CANTx-Paketspeichers 9 geschrieben bis das CAN-Telegramm vollständig empfangen ist. Da für jeden potentiellen Sender in dem CANTx-Paketspeicher 9 wenigstens ein Speicherplatz existiert und jeder Speicherplatz genau ein CAN-Telegram aufnehmen kann, können über das Netzwerk 2 auch mehrere CAN-Segmente 1.1 bis 1.n gleichzeitig CAN-Telegramme senden, ohne dass ein Paketverlust auftritt.
  • Liegt das von der ersten CAN-Schnittstelle 3.1 gesendete CAN-Telegramm vollständig im CAN_Tx-Paketspeicher 9 einer anderen CAN-Schnittstelle 3.2 bis 3.n vor, wird von deren CRC-Überprüfungseinheit 10 die CRC-Prüfsumme des empfangenen CAN-Telegramms überprüft.
  • Wenn die CRC-Überprüfung erfolgreich ist, wie hier angenommen wird, wird das empfangene CAN-Telegramm in den Zwischenspeicher 12 der jeweiligen CAN-Schnittstelle 3.2 bis 3.n geschrieben und von dort über den CAN-Controller 4 in das jeweilige CAN-Segment 1.2 bis 1.n eingespeist. Gleichzeitig wird eine positive Quittierung in Form eines Acknowledge-Pakets ACK als Unicast-Datenpaket an die erste CAN-Schnittstelle 3.1 zurückgesendet.
  • Die erste CAN-Schnittstelle 3.1 sammelt und zählt die erhaltenen Acknowledge-Pakete ACK der anderen CAM-Schnittstellen 3.2 bis 3.n. Wenn alle n – 1 Acknowledge-Pakete ACK innerhalb der Timeout-Zeit eingetroffen sind, wertet die erste CAM-Schnittstelle 3.1 die Übertragung des CAM-Telegramms über das Netzwerk 2 als erfolgreich. Dazu wird die Anzahl n der CAM-Segmente 1.1 bis 1.n, die logisch zu dem CAN-Bus 1 zusammengeschaltet sind, in jeder CAM-Schnittstelle 3.1 bis 3.n bei deren Konfiguration eingetragen, so dass die CAN_Rx-Steuerung 7 der ersten CAM-Schnittstelle 3.1 die Anzahl der erwarteten Acknowledge-Pakete ACK kennt.
  • 4 zeigt schematisch einen Ablauf einer Übertragung eines CAM-Telegramms von dem ersten CAM-Segment 1.1 zu den anderen CAM-Segmenten 1.2 bis 1.n über das Netzwerk 2 in einem Blockschaltbild, wobei im Unterschied zu der in 3 gezeigten fehlerfreien Übertragung ein Übertragungsfehler im Netzwerk 2 auftritt. Wiederum werden eine segmentierte Übertragung des CAM-Telegramms und die Sicherung des CAM-Telegramms mit einer CRC-Prüfsumme bei der Übertragung über das Netzwerk 2 angenommen.
  • Die erste CAM-Schnittstelle 3.1 sendet zunächst ein CAM-Telegramm wie oben anhand von 3 beschrieben segmentiert über das Netzwerk 2 an alle anderen CAM-Schnittstellen 3.2 bis 3.n desselben logischen CAM-Busses 1.
  • Es wird nun angenommen, dass ein CAM-Datenpaket des CAM-Telegramms bei der Übertragung über das Netzwerk 2 zu einer zweiten CAM-Schnittstelle 3.2 aufgrund eines Übertragungsfehlers im Netzwerk 2 verloren geht, so dass der zweiten CAM-Schnittstelle 3.2 eines der CAM-Empfangsdatenpakete Rx2 des CAN-Telegramms fehlt.
  • Aufgrund des fehlenden CAM-Empfangsdatenpaketes Rx2 erkennt die CRC-Überprüfung in der zweiten CAM-Schnittstelle 3.2 einen CRC-Fehler und damit eine fehlerhafte Übertragung des CAM-Telegramms. Die CAN_Tx-Steuerung 11 der zweiten CAN-Schnittstelle 3.2 sendet daraufhin kein Acknowledge-Paket ACK an die erste CAM-Schnittstelle 3.1 zurück. Alternativ kann von der zweiten CAM-Schnittstelle 3.2 auch eine negative Bestätigungsnachricht an die erste CAM-Schnittstelle 3.1 gesendet werden, dass eine fehlerhafte Übertragung anzeigt.
  • Die CAN_Rx-Steuerung 7 der ersten CAM-Schnittstelle 3.1 sammelt wiederum während der Timeout-Zeit die Acknowledge-Pakete ACK und zählt diese. Da die zweite CAM-Schnittstelle 3.2 kein Acknowledge-Paket ACK oder eine negative Bestätigungsnachricht sendet, stellt die erste CAM-Schnittstelle 3.1 nach der Timeout-Zeit ein fehlendes Acknowledge-Paket ACK fest und erkennt dadurch die fehlerhafte Übertragung des CAM-Telegramms.
  • Das komplette CAN-Telegramm wird daraufhin von der ersten CAN-Schnittstelle 3.1 erneut über das Netzwerk 2 an alle anderen CAN-Schnittstellen 3.2 bis 3.n desselben logischen CAN-Busses 1 gesendet, wobei die Anzahl von Wiederholungen im Fehlerfall konfigurierbar ist.
  • Derjenige CAN-Teilnehmer C.1 bis C.m im ersten CAN-Segment 1.1, der das CAN-Telegramm ursprünglich gesendet hat, erfährt dabei nichts von einer wiederholten Sendung des CAN-Telegramms im Netzwerk 2. Er erfährt auch nicht, wenn alle Wiederholungen fehlschlagen. Dies führt zu einem Telegrammverlust, wie er auch in einem üblichen CAN-Bus vorkommen kann und durch die jeweilige Anwendung abgefangen werden muss.
  • 5 zeigt schematisch einen Ablauf einer Übertragung von CAN-Telegrammen von dem ersten CAN-Segment 1.1 zu den anderen CAN-Segmenten 1.2 bis 1.n über das Netzwerk 2 in einem Blockschaltbild, wobei ein Überlauf des Zwischenspeichers 12 der zweiten CAN-Schnittstelle 3.2 auftritt. Wiederum werden eine segmentierte Übertragung der CAN-Telegramme und deren Sicherung mit einer CRC-Prüfsumme bei der Übertragung über das Netzwerk 2 angenommen.
  • Die erste CAN-Schnittstelle 3.1 sendet CAN-Telegramme wie oben anhand von 3 beschrieben segmentiert über das Netzwerk 2 an alle anderen CAN-Schnittstellen 3.2 bis 3.n desselben logischen CAN-Busses 1.
  • Die zweite CAN-Schnittstelle 3.2 empfängt die von der ersten CAN-Schnittstelle 3.1 gesendeten CAN-Telegramme und schreibt sie nach erfolgreicher CRC-Überprüfung in ihren Zwischenspeicher 12. Falls in dem Zwischenspeicher 12 mehr CAN-Telegramme auflaufen, als über den nachgeschalteten CAN-Controller 4 an das zweite CAN-Segment 1.2 abgesetzt werden können, läuft der Zwischenspeicher 12 der zweiten CAN-Schnittstelle 3.2 voll.
  • Bei Überschreiten eines vorgebbaren ersten Füllschwellwertes, der eine Speicherauslastung des Zwischenspeichers 12 angibt, wird von der zweiten CAN-Schnittstelle 3.2 an alle anderen CAN-Schnittstellen 3.1 bis 3.n, die zu demselben logischen CAN-Bus 1 gehören, eine Speicherstatusnachricht Xoff als Multicast-Nachricht gesendet.
  • Jede CAN-Schnittstelle 3.1 bis 3.n, die diese Xoff-Nachricht empfängt, stellt das Senden weiterer CAN-Telegramme über das Netzwerk 2 ein und hält die aus dem CAN-Controller 4 ausgelesenen CAN-Empfangstelegramme Rx1 in ihrem CAN_Rx-Paketspeicher 5.
  • Jede CAN-Schnittstelle 3.1 bis 3.n versucht nun ihren Zwischenspeicher 12 zu leeren, und sendet danach an ihr jeweiliges CAN-Segment 1.1 bis 1.n ein Backpressure-Telegramm BP, mit dem das jeweilige CAN-Segment 1.1 bis 1.n blockiert wird. Das Backpressure-Kommando funktioniert dabei nur vollständig, wenn der eigene Zwischenspeicher 12 leer ist, da andernfalls weiterhin CAM-Sendetelegramme Tx1 an das jeweilige CAM-Segment 1.1 bis 1.n gesendet werden. Deshalb versucht jede CAN-Schnittstelle 3.1 bis 3.n zunächst den Inhalt ihres Zwischenspeichers 12 in den CAM-Controller 4 zu schreiben, bevor sie ein Backpressure-Telegramm BP sendet.
  • Nachdem der erste Füllschwellwert im Zwischenspeicher 12 der zweiten CAM-Schnittstelle 3.2 wieder unterschritten wird, sendet die zweite CAM-Schnittstelle 3.2 eine Speicherstatusnachricht Xon als Multicast-Nachtricht über das Netzwerk 2 an alle anderen CAM-Schnittstellen 3.1 bis 3.n desselben logischen CAM-Busses 1 und gibt damit die Übertragung von CAN-Telegrammen im Netzwerk 2 wieder frei. Der Überlauf eines Zwischenspeichers 12 führt daher zur zeitweiligen Blockade des gesamten logischen CAM-Busses 1.
  • In einer bevorzugten Ausgestaltung des Ausführungsbeispiels führen die CAN_Rx-Steuerungen 7 aller CAM-Schnittstellen 3.1 bis 3.n jeweils eine Liste mit dem Xon/Xoff-Status aller anderen CAM-Schnittstellen 3.1 bis 3.n.
  • Die CAN_Rx-Steuerungen 7 der CAN-Schnittstellen 3.1 bis 3.n übertragen ferner vorzugsweise jeweils zyklisch ihren eigenen Xon/Xoff-Status zusätzlich zu den aktuellen Änderungen. Auf diese Weise können eventuelle Paketverluste dieser Kommandos vorteilhaft kompensiert werden.
  • Ein Backpressure-Telegramm BP wird von einer CAM-Schnittstelle 3.1 bis 3.n auch dann an ihr jeweiliges CAM-Segment 1.1 bis 1.n ausgegeben, wenn die Speicherauslastung des eigenen CAN_Rx-Paketspeichers 5 einen zweiten vorgebbaren Füllschwellwert überschreitet. Dadurch wird im Regelfall vorteilhaft verhindert, dass im zugehörigen CAM-Segment 1.1 bis 1.n weiterhin CAM-Telegramme erzeugt werden und der CAN_Rx-Paketspeicher 5 überläuft.
  • Anhand von 4 wurde oben beschrieben, wie Übertragungsfehler durch Paketverlust bei der Übertragung über das Netzwerk 2 erkannt und korrigiert werden. Es wird nun beschrieben, wie Übertragungsfehler bei Paketverlust in einem CAN-Segment 1.1 bis 1.n behandelt werden.
  • Tritt beim Senden eines CAM-Teilnehmers C.1 bis C.m in einem CAM-Segment 1.1 bis 1.n ein derartiger Übertragungsfehler auf, so wird dieser von den anderen normkonformen CAN-Teilnehmern C.1 bis C.m in dem CAM-Segment 1.1 bis 1.n erkannt und dem Sender signalisiert. Dieser führt dann ein erneutes Senden durch.
  • Auch hierbei tritt also eine CAM-Telegrammverdoppelung auf. Diese tritt jedoch auch bei üblichen CAM-Netzwerken auf. Das Netzwerk 2 wird erst eingesetzt, wenn die CAM-Schnittstelle 3.1 bis 3.n des jeweiligen CAM-Segmentes 1.1 bis 1.n aus diesem ein gültiges CAM-Telegramm empfängt. Fehlerhafte CAN-Telegramme werden bereits im CAM-Controller 4 erkannt und nicht weitergeleitet.
  • Die Mechanismen für die Arbitrierung des CAN-Busses 1 für CAN-Telegramme hoher Priorität bleiben innerhalb jedes CAN-Segmentes 1.1 bis 1.n voll erhalten.
  • Tritt beim Senden des CAM-Controllers 4 einer CAM-Schnittstelle 3.1 bis 3.n in das zugehörige CAM-Segment 1.1 bis 1.n ein Fehler auf, so wird dieser von den normkonformen CAN-Teilnehmern C.1 bis C.m des betreffenden CAM-Segmentes 1.1 bis 1.n erkannt und dem CAM-Controller 4 signalisiert. Der CAM-Controller 4 sendet das CAM-Telegramm dann erneut bis es korrekt erkannt wird.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 102005008503 B3 [0057, 0062]
  • Zitierte Nicht-Patentliteratur
    • IEEE 802.3 [0058]
    • IEEE 802.3q [0060]

Claims (13)

  1. Verfahren zur Datenübertragung mit einem CAN-Bus (1), bei dem der CAN-Bus (1) in wenigstens zwei CAN-Segmente (1.1 bis 1.n) aufgeteilt wird und die CAN-Segmente (1.1 bis 1.n) des CAN-Busses (1) durch ein paketorientiertes Netzwerk (2) logisch miteinander verbunden werden, wobei CAN-Telegramme mittels des Netzwerkes (2) zwischen CAN-Segmenten (1.1 bis 1.n) übertragen werden und die Übertragung der CAN-Telegramme über das Netzwerk (2) auf Fehlerfreiheit geprüft sowie ein erkannter Übertragungsfehler korrigiert wird, indem ein von einem sendenden CAN-Segment (1.1 bis 1.n) gesendetes und fehlerhaft übertragenes CAN-Telegramm von diesem CAN-Segment (1.1 bis 1.n) erneut über das Netzwerk (2) gesendet wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass jedes CAN-Segment (1.1 bis 1.n) über jeweils eine zugehörige CAN-Schnittstelle (3.1 bis 3.n) an das Netzwerk (2) gekoppelt wird und das Senden von CAN-Telegrammen aus einem CAN-Segment (1.1 bis 1.n) über das Netzwerk (2) und das Empfangen von CAN-Telegrammen aus dem Netzwerk (2) mittels der zugehörigen CAN-Schnittstelle (3.1 bis 3.n) durchgeführt wird.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass für jede CAN-Schnittstelle (3.1 bis 3.n), mittels derer über das Netzwerk (2) ein CAN-Telegramm empfangen wird, überprüft wird, ob das empfangene CAN-Telegramm fehlerfrei übertragen wurde.
  4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass zur Überprüfung der fehlerfreien Übertragung eines CAN-Telegramms über das Netzwerk (2) eine CRC-Prüfsumme verwendet wird, die dem CAN-Telegramm vor dessen Sendung über das Netzwerk (2) mittels der CAM-Schnittstelle (3.1 bis 3.n) des sendenden CAM-Segmentes (1.1 bis 1.n) hinzugefügt wird und die von jeder ein CAM-Telegramm über das Netzwerk (2) empfangenden CAM-Schnittstelle (3.1 bis 3.n) überprüft wird.
  5. Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass Übertragungsfehler bei der Übertragung von CAN-Telegrammen über das Netzwerk (2) folgendermaßen erkannt und korrigiert werden: – das CAN-Telegramm wird mittels einer sendenden CAN-Schnittstelle (3.1 bis 3.n) an alle anderen CAN-Schnittstellen (3.1 bis 3.n) gesendet; – wenn mittels einer CAN-Schnittstelle (3.1 bis 3.n) ein CAN-Telegramm aus dem Netzwerk (2) empfangen und dessen Übertragung als fehlerfrei eingestuft wird, wird von dieser CAN-Schnittstelle (3.1 bis 3.n) über das Netzwerk (2) eine positive Bestätigungsnachricht (ACK) an die sendende CAM-Schnittstelle (3.1 bis 3.n) gesendet; – mittels der sendenden CAM-Schnittstelle (3.1 bis 3.n) wird das CAM-Telegramm erneut über das Netzwerk (2) an alle anderen CAM-Schnittstellen (3.1 bis 3.n) gesendet, wenn die sendende CAM-Schnittstelle (3.1 bis 3.n) von wenigstens einer der anderen CAM-Schnittstellen (3.1 bis 3.n) innerhalb einer vorgebbaren Timeout-Zeit keine positive Bestätigungsnachricht (ACK) empfängt.
  6. Verfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass ein von einer CAM-Schnittstelle (3.1 bis 3.n) aus dem Netzwerk (2) empfangenes CAM-Telegramm nur dann mittels dieser CAM-Schnittstelle (3.1 bis 3.n) dem zugehörigen CAM-Segment (1.1 bis 1.n) übergeben wird, wenn die Übertragung des CAM-Telegramms als fehlerfrei eingestuft wird.
  7. Verfahren nach einem der Ansprüche 2 bis 6, dadurch gekennzeichnet, dass ein von einer CAM-Schnittstelle (3.1 bis 3.n) über das Netzwerk (2) empfangenes CAM-Telegramm in einem Zwischenspeicher (12) der CAM-Schnittstelle (3.1 bis 3.n) zwischengespeichert wird, bevor es von der CAM-Schnittstelle (3.1 bis 3.n) an das zugehörige CAN-Segment (1.1 bis 1.n) weitergeleitet wird.
  8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass von einer CAN-Schnittstelle (3.1 bis 3.n) an alle anderen CAN-Schnittstellen (3.1 bis 3.n) eine entsprechende Speicherstatusnachricht gesendet wird, sobald die Speicherauslastung ihres Zwischenspeichers (12) einen vorgebbaren ersten Füllschwellwert überschreitet oder unterschreitet.
  9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass von jeder CAN-Schnittstelle (3.1 bis 3.n) zyklisch in vorgebbaren Zeitabständen an alle anderen CAN-Schnittstellen (3.1 bis 3.n) eine Speicherstatusnachricht darüber gesendet wird, ob eine aktuelle Speicherauslastung des Zwischenspeichers (12) der jeweiligen CAN-Schnittstelle (3.1 bis 3.n) einen ersten Füllschwellwert überschreitet.
  10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass von jeder CAN-Schnittstelle (3.1 bis 3.n) anhand der von ihr empfangenen Speicherstatusnachrichten die aktuellen Speicherauslastungen der Zwischenspeicher (12) aller anderen CAN-Schnittstellen (3.1 bis 3.n) überwacht und CAN-Telegramme nur dann versendet werden, wenn die Speicherauslastungen der Zwischenspeicher (12) aller anderen CAN-Schnittstellen (3.1 bis 3.n) den ersten Füllschwellwert unterschreiten.
  11. Vorrichtung zur Datenübertragung mit einem in wenigstens zwei CAN-Segmente (1.1 bis 1.n) aufgeteilten CAN-Bus (1) und einem paketorientierten Netzwerk (2), das die CAN-Segmente (1.1 bis 1.n) logisch derart miteinander verbindet, dass von jedem CAN-Segment (1.1 bis 1.n) ein CAN-Telegramm mittels des Netzwerkes (2) sowohl zu allen anderen CAN-Segmenten (1.1 bis 1.n) als auch gezielt zu einem auswählbaren anderen CAN-Segment (1.1 bis 1.n) sendbar ist.
  12. Vorrichtung nach Anspruch 11, gekennzeichnet durch jeweils eine CAN-Schnittstelle (3.1 bis 3.n) für jedes CAN-Segment (1.1 bis 1.n) zu dessen Ankopplung an das Netzwerk (2) und zur Steuerung des Sendens von CAN-Telegrammen aus dem CAN-Segment (1.1 bis 1.n) über das Netzwerk (2) und des Empfangens von CAN-Telegrammen aus dem Netzwerk (2).
  13. Vorrichtung nach Anspruch 12, dadurch gekennzeichnet, dass jede CAN-Schnittstelle (3.1 bis 3.n) einen Zwischenspeicher (12) zum Speichern aus dem Netzwerk (2) empfangener CAN-Telegramme aufweist.
DE102009050767.1A 2009-10-27 2009-10-27 Verfahren und Vorrichtung zur Datenübertragung Expired - Fee Related DE102009050767B4 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102009050767.1A DE102009050767B4 (de) 2009-10-27 2009-10-27 Verfahren und Vorrichtung zur Datenübertragung
PCT/EP2010/065861 WO2011051157A1 (de) 2009-10-27 2010-10-21 Verfahren und vorrichtung zur datenübertragung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102009050767.1A DE102009050767B4 (de) 2009-10-27 2009-10-27 Verfahren und Vorrichtung zur Datenübertragung

Publications (2)

Publication Number Publication Date
DE102009050767A1 true DE102009050767A1 (de) 2011-05-05
DE102009050767B4 DE102009050767B4 (de) 2017-06-14

Family

ID=43302405

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102009050767.1A Expired - Fee Related DE102009050767B4 (de) 2009-10-27 2009-10-27 Verfahren und Vorrichtung zur Datenübertragung

Country Status (2)

Country Link
DE (1) DE102009050767B4 (de)
WO (1) WO2011051157A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018065215A1 (de) * 2016-10-07 2018-04-12 Robert Bosch Gmbh Verfahren und vorrichtung zum betreiben eines bussystems
DE102020212452B3 (de) 2020-10-01 2022-01-13 Volkswagen Aktiengesellschaft Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11245550B2 (en) 2017-12-24 2022-02-08 Technion Research & Development Foundation Limited Message authentication based on a physical location on a bus
DE102019125693A1 (de) * 2019-09-24 2021-03-25 Beckhoff Automation Gmbh Verfahren zum Betreiben eines Kommunikationsnetzwerks, Kommunikationsnetzwerk und Teilnehmer für ein Kommunikationsnetzwerk

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19514696A1 (de) * 1994-04-18 1995-10-19 Kvaser Consultant Ab Anordnung zur Beseitigung von Störungen bzw. zur Ermöglichung einer Hochgeschwindigkeitsübertragung in einer seriellen Bus-Schaltung sowie mit letzterer verbundene Sende- und Empfangsgeräte
US20060059278A1 (en) * 2002-02-20 2006-03-16 John Doyle Information communication controller interface apparatus and method
DE102005008503B3 (de) 2005-02-24 2006-06-29 Siemens Ag Verfahren und Netzwerk zur Daten- und Signalübertragung
US7599722B2 (en) * 2002-12-13 2009-10-06 Fujifilm Corporation Mobile camera phone with adjustable focal length

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6654355B1 (en) * 1999-12-14 2003-11-25 Schneider Automation Inc. Bridge for CAN to TCP/IP connection
US20050220131A1 (en) * 2004-03-31 2005-10-06 Boris Ginzburg Method and apparatus to multicast transmission
US7599377B2 (en) * 2004-10-15 2009-10-06 Temic Automotive Of North America, Inc. System and method for tunneling standard bus protocol messages through an automotive switch fabric network
FR2878391B1 (fr) * 2004-11-24 2007-04-27 Gen Electric Procede pour realiser un reseau en etoile forme de bus de type can a l'aide d'un repetiteur

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19514696A1 (de) * 1994-04-18 1995-10-19 Kvaser Consultant Ab Anordnung zur Beseitigung von Störungen bzw. zur Ermöglichung einer Hochgeschwindigkeitsübertragung in einer seriellen Bus-Schaltung sowie mit letzterer verbundene Sende- und Empfangsgeräte
US20060059278A1 (en) * 2002-02-20 2006-03-16 John Doyle Information communication controller interface apparatus and method
US7599722B2 (en) * 2002-12-13 2009-10-06 Fujifilm Corporation Mobile camera phone with adjustable focal length
DE102005008503B3 (de) 2005-02-24 2006-06-29 Siemens Ag Verfahren und Netzwerk zur Daten- und Signalübertragung

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
IEEE 802.3
IEEE 802.3q
Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand 22. Oktober 2009, 15:54 UTC, URL: http://de.wikipedia.org/w/index.php?title=Transmis ion_Control_Protocol&oldid=65878533 *
Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand 22. Oktober 2009, 15:54 UTC, URL: http://de.wikipedia.org/w/index.php?title=Transmission_Control_Protocol&oldid=65878533

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018065215A1 (de) * 2016-10-07 2018-04-12 Robert Bosch Gmbh Verfahren und vorrichtung zum betreiben eines bussystems
CN109792448A (zh) * 2016-10-07 2019-05-21 罗伯特·博世有限公司 用于运行总线系统的方法和设备
CN109792448B (zh) * 2016-10-07 2021-11-05 罗伯特·博世有限公司 用于运行总线系统的方法和设备
US11366938B2 (en) 2016-10-07 2022-06-21 Robert Bosch Gmbh Method and device for operating a bus system
DE102020212452B3 (de) 2020-10-01 2022-01-13 Volkswagen Aktiengesellschaft Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft

Also Published As

Publication number Publication date
DE102009050767B4 (de) 2017-06-14
WO2011051157A1 (de) 2011-05-05

Similar Documents

Publication Publication Date Title
EP3248362B1 (de) Datenübertragung in einem kommunikationsnetzwerk
DE19954377A1 (de) Datenübertragungssystem für Luftfahrzeuge
DE102014112082A1 (de) Verteilerknoten, Automatisierungsnetz und Verfahren zum Übertragen von echtzeitrelevanten und nicht-echtzeitrelevanten Datenpaketen
EP2137893A1 (de) Paketvermittlungsvorrichtung und lokales kommunikationsnetz mit einer solchen paketvermittlungsvorrichtung
WO2021037837A1 (de) Übertragung von datenpaketen
WO2011160696A1 (de) Priorisierte übertragung von datentelegrammen
DE102012207952A1 (de) Verfahren zur Übertragung von Daten in einem paketorientierten Kommunikationsnetzwerk und entsprechend eingerichtetes Teilnehmergerät an dem Kommunikationsnetzwerk
DE102009050767B4 (de) Verfahren und Vorrichtung zur Datenübertragung
WO2020157086A1 (de) Teilnehmerstation für ein serielles bussystem und verfahren zur kommunikation in einem seriellen bussystem
EP3977683B1 (de) Einrichtung für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
EP3895384B1 (de) Überlagerungserfassungseinheit für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
DE102010064582B3 (de) Proxy-Knoten einsetzende Übertragungswiederholungsprotokolle für ein Netz
DE102010000995B3 (de) Erhöhung der Echtzeitfähigkeit von Ethernetnetzwerken
WO2014067713A1 (de) Repeater, can-kommunikationssystem und verfahren zur übertragung eines datentelegramms innerhalb eines can-kommunikationssystems
EP1155549A2 (de) Verfahren zum übertragen von ethernet-frames
EP4029202A1 (de) Teilnehmerstation für ein serielles bussystem und verfahren zur kommunikation in einem seriellen bussystem
EP1430634B1 (de) Weiterleitung von datentelegrammen mit koppelknot datenersatz
EP3997580A1 (de) Verfahren und datennetzwerk zum kommunizieren von dateninhalten, insbesondere in einer aufzuganlage
EP2538618A1 (de) Verfahren zur Übertragung von Datenpaketen
US20130191501A1 (en) Procedures for the Transfer of User Data
DE112009000087B4 (de) Fahrzeug-Weiterleitungs-Verbindungseinheit
DE102012210816A1 (de) Datenpaket für eine bidirektionale Übertragung von Datenpaketen bei einer Datenübertragung zwischen einem ersten und einem zweiten Kommunikationsgerät sowie Verfahren zum Übertragen eines solchen Datenpaketes
WO2020088999A1 (de) Teilnehmerstation für ein serielles bussystem und verfahren zum senden einer nachricht in einem seriellen bussystem
WO2006076960A1 (de) Verfahren und vorrichtungen zur datenübertragung
EP2220829A1 (de) Kommunikationssystem

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R016 Response to examination communication
R081 Change of applicant/patentee

Owner name: SIEMENS HEALTHCARE GMBH, DE

Free format text: FORMER OWNER: SIEMENS AKTIENGESELLSCHAFT, 80333 MUENCHEN, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee