DE112015004473T5 - Bestätigen der datengenauigkeit in einem verteilten steuerungssystem - Google Patents

Bestätigen der datengenauigkeit in einem verteilten steuerungssystem Download PDF

Info

Publication number
DE112015004473T5
DE112015004473T5 DE112015004473.6T DE112015004473T DE112015004473T5 DE 112015004473 T5 DE112015004473 T5 DE 112015004473T5 DE 112015004473 T DE112015004473 T DE 112015004473T DE 112015004473 T5 DE112015004473 T5 DE 112015004473T5
Authority
DE
Germany
Prior art keywords
bit
protocol
message packet
bits
additional information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112015004473.6T
Other languages
English (en)
Inventor
Kent Åke Lennart Lennartsson
Lars-Berno Fredriksson
Jonas Henning Olsson
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.)
KVASER AB, SE
Original Assignee
Concio Holdings LLC
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 Concio Holdings LLC filed Critical Concio Holdings LLC
Publication of DE112015004473T5 publication Critical patent/DE112015004473T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0061Error detection codes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0041Arrangements at the transmitter end
    • 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
    • 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/40045Details regarding the feeding of energy to the node from the bus
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • 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

Abstract

Eine Steuerungsnetzwerkkommunikationsanordnung schließt ein zweites Protokoll, eingebettet in ein erstes Protokoll in einer Weise ein, dass Module, die das zweite Protokoll unterstützen, das erste Protokoll wahrnehmen und verwenden, während Module, die nur das erste Protokoll unterstützen, das zweite Protokoll nicht wahrnehmen könnten. Betrieb von Modulen unter Verwendung des zweiten Protokolls stört nicht den Betrieb der Module, die nicht dazu eingerichtet sind, das zweite Protokoll zu verwenden oder zu verstehen. Durch einen Ansatz wird eindeutige zusätzliche Information in einen Ende-des-Rahmens-Teil einer Nachricht eingebettet, um zu bestätigen, dass der Teil der Ende-des-Rahmens-Teil ist. Dies wirkt als eine Qualitätsprüfung, die richtige Synchronisierung und Dekodierung der Nachrichtenübermittlung auf dem Kommunikationsbus bestätigt.

Description

  • Diese Anmeldung beansprucht die Vorteile der U.S. provisional application Nr. 62/057,508, eingereicht am 30. September 2014, und der U.S. provisional application Nr. 62/059,480, eingereicht am 03. Oktober 2014, deren Gesamtheiten hierin durch Bezugnahme eingeschlossen werden.
  • TECHNISCHES GEBIET
  • Diese Erfindung bezieht sich im Allgemeinen auf elektronische Kommunikation und speziell auf ein Hochgeschwindigkeitsprotokoll für Steuerungsnetzwerke.
  • HINTERGRUND
  • Elektronische Geräte kommunizieren miteinander auf unterschiedliche Art und Weise, oftmals basierend auf den Anforderungen eines gegebenen Zusammenhangs. Ein solcher Zusammenhang ist der von Steuerungssystemen. Anders als einfache Kommunikationssysteme, wo das System lediglich die Kommunikation unter den Geräten erlaubt, die auf dem System kommunizieren, kommunizieren Steuerungssysteme zum Zwecke der expliziten Kontrolle über die Module, die verbunden sind, um über das Steuerungssystem zu kommunizieren. Solche Systeme erlauben dann anderen Anwendungen, auf den verschiedenen Modulen zu arbeiten. Diese Anwendungen sollten in einem verteilten, eingebetteten Steuerungssystem allerdings zusammenarbeiten.
  • Um diese Gruppensteuerung bereitzustellen, sind die meisten verteilten eingebetteten Steuerungssysteme um einen Kommunikationsprotokollstandard gebaut, Beispiele für diesen schließen u.a. CAN(ISO 11898), SERCOS, FlexRay, EtherCAT und manchmal sogar Ethernet ein. Protokolle höherer Schichten werden auf dem Kommunikationsstandard eingebettet, um Regeln für den Datenaustausch unter beteiligten Anwendungen bei elektronischen Steuerungseinheiten, die in dem Steuerungsnetzwerk teilnehmen, Zeitwahlregeln, Abfolgeregeln und dergleichen, bereitstellen, um die Kommunikation zwischen den verteilten Anwendungen zu ermöglichen, die Information austauschen. CANopen, DeviceNet, SDS J1939 und NMEA 2000 sind nur einige Beispiele von Protokollen, die auf dem CAN-Standard geschichtet sind. Selbst Metaprotokolle wie CanKingdom werden verwendet, durch die Protokolle höherer Schichten für spezifische, verteilte, eingebettete Steuerungssysteme konstruiert und optimiert werden können.
  • Jeder Protokollstandard hat seine eigenen Stärken und Schwächen. Die ideale Kommunikation würde eine unendliche Bandbreite, keine Latenz und volle Datenintegrität haben. Verfügbare Kommunikationsalternativen sind weit von der Idealen entfernt und Kompromisse müssen gefunden werden. Zum Beispiel hat Ethernet eine große Bandbreite, aber geringe Aktualität aufgrund seiner Handhabung von Nachrichtenkollisionen. CAN hat eine effiziente Kollisionsauflösung aber geringe Bandbreite und keine Synchronisierungsunterstützung. SERCOS ist schnell, aber alle Knoten müssen die Kommunikationsanforderung des anspruchsvollsten Knotens in dem System unterstützen. Entsprechend ist eine große Schwierigkeit, wenn man ein verteiltes, eingebettetes Steuerungssystem entwirft, das Basiskommunikationssystem auszuwählen, um die Bedürfnisse des gegebenen Systems anzupassen. Eine andere Komplikation ist, dass verschiedene Teile eines Systems oft verschiedene Bedürfnisse haben. Manche Teile können fortgeschrittene Rückkopplungsschleifen einbeziehen, die genaue Zeitsynchronisierung und kurze Latenzen erfordern, während andere Teile überhaupt nicht zeitkritisch sein können, sondern stattdessen von einer korrekten Abfolge von Ereignissen abhängen. In einem anderen Beispiel kann ein System während der Laufzeitbedingungen gut mit einem Kommunikationsprotokoll mit geringer Bandbreite arbeiten, würde jedoch eine hohe Bandbreite zur Wiederbeschreibung von Modulen in einem Instandhaltungsmodus erfordern. Außerdem erfordert die Industrie eine Anzahl von Entwicklungs- und Analysewerkzeugen und eine Gruppe von Ingenieuren wird einer in die Tiefe gehenden Vertrautheit mit dem gewählten Kommunikationsprotokoll, um die korrekten Kompromisse zu finden. Die gegebenen Technologien in einer Weise anzuwenden, um den Vorteil aus den guten Eigenschaften eines Protokolls zu ziehen und seine Mängel zu minimieren, erfordert in der Regel eine lange Zeit praktischer Erfahrung in der Gestaltung und Wartung von verteilten, eingebetteten Steuerungssystemen auf der Grundlage des gewählten Protokolls und der zugehörigen Werkzeuge.
  • In dem Beispiel eines CAN-Systems wurde das CAN-FD-Protokoll in einer Bestrebung entwickelt, die Datenbandbreitebegrenzung des CAN-Protokolls zu behandeln. Dieses System ist jedoch nicht rückwärtskompatibel mit früheren CAN-basierten Modulen. Dementsprechend können Module, die das CAN-FD-Protokoll verwenden, nicht in einem Steuerungsnetzwerk installiert werden, das CAN-basierte Module aufweist und Kommunikation mit diesen Modulen bewirken. Ein anderer Mangel ist, dass das CAN-FD-Protokoll darauf basiert, dass die Module nach einem gegebenen zeitlichen Vorgabewert suchen, was erfordert, dass die Module hochgenaue Uhren und Prozessoren haben. Speziell benötigt CAN-FD einen Schalter von einer ersten Bit-Rate zu einer zweiten Bit-Rate relativ zu einer Flanke in Kombination mit der Abtastpunktposition. Diese Lösung verlangt über die Zeit stabile Takte von der Kante zu dem Abtastpunkt und eine gemeinsame Position des Abtastpunkts in der Definition der ersten Bit-Rate. Um eine präzise Definition des Abtastpunkts zu erhalten, begrenzt die mögliche Taktfrequenz, die verwendet werden kann, um die CAN-FD-Steuerung zu betreiben. Obwohl die Geschwindigkeit gegenüber früheren CAN-basierten Systemen verbessert ist, ist die maximale Nachrichtenmenge außerdem immer noch auf 64 Bytes begrenzt. Einem solchen System fehlt es an Flexibilität für Systementwickler.
  • Ein anderes Problem kann in Kommunikationsprotokollen wie etwa CAN bei der Definition eines Endes eines Fehlerprüfabschnitts, d.h. CRC-Abfolge, und dem Gewährleisten, dass alle teilnehmenden Kommunikationsgeräte dieselbe Anzahl von Bits in ihren entsprechenden CRC-Berechnungen verwenden, auftreten. Genauer erfordert die mathematische Theorie einen nützlichen CRC-Teil der Nachricht zu zeugen, um die Qualität des Datenteils und die Unsicherheit in dem Start und der Länge des Datenteils der Nachricht zu bestätigen, das Beginnen des Lesens des CRC bei exakt der korrekten Bit-Position. Genauer gesagt, verwendet das klassische CAN einen 15-Bit-CRC-Wert, der jeden CAN-Rahmen schützt, der einen Hamming-Abstand von sechs aufweist, was bestätigt, dass jeder Rahmen mit weniger als sechs Bit-Umkehr-Fehlern in der Nachricht durch den CRC-Wert detektiert würde. Die Theorie des CRC-Schutzes verlangt, dass sowohl der Sender als auch der Empfänger exakt dieselbe Anzahl von Bits verwenden, wenn der CRC-Wert berechnet wird. Dies kann ein Problem in CAN darstellen, bei dem die Anzahl von Bits zwischen dem Beginn des Rahmens (SOF) und der CRC-Sequenz mit der Anzahl der benötigten Stopfbits und der Anzahl an Datenbytes gegeben durch den 4-Bit-Datenlängenkennwert (DLC) variiert.
  • Es gibt mehrere Lösungen, um CAN gegen diese Unsicherheit in der Anzahl von Bits zwischen dem SOF und dem CRC zu verbessern. Eine leistungsfähige Lösung ist, eine feste Stopfung zu haben. Die Lage der Stopfbits im Voraus zu kennen macht es möglich, exakt zu wissen, wie viele und wo die Stopfbits angeordnet sind. Es besteht immer noch das Risiko, aus der Synchronisation zu geraten, was dazu führt, das CRC-Feld ein oder mehrere Bits zu früh oder zu spät zu lesen, wodurch der Bit-Fehlererkennungsprozess beschädigt wird. Auch ein Bit-Fehler in dem DLC wird Sie außer Synchronisation in Vielfachen von acht Bit bringen.
  • Neun mögliche Probleme könnten zu einem schlechten Vergleich der internen CRC gegen das empfangene CRC-Feld erzeugt durch den Sender in Kommunikationen des CAN-Typs führen.
    • 1) Verpassen des Beginns des Rahmens (SOF). Dies wird zu einem Versatz zwischen den empfangenen Bits um einen oder mehrere Bits führen.
    • 2) Fehlinterpretation des RTR-Bits wird eine Fehlinterpretation des DLC verursachen.
    • 3) Fehlinterpretation des IDE-Bits wird den Empfänger dazu veranlassen, 18-Bit zu viele oder zu wenige zu empfangen.
    • 4) Versatz des FDF-Bits wird manche Probleme verursachen, weil das res-, BRS- und ESI-Bit als DLC-Bits oder umgekehrt behandelt werden. Mit anderen Worten wird das CRC etwa drei Bits außer Synchronisation sein.
    • 5) Fehlinterpretation des res-Bits.
    • 6) Fehlinterpretation des BRS-Bits wird den Empfänger dazu veranlassen, eine falsche Bit-Rate zu verwenden und dies wird die CRC dazu zwingen, vollständig außer Synchronisation zu sein.
    • 7) Fehlinterpretation des DLC-Bits wird den Empfänger um ein oder mehrere Bytes zu viel oder zu wenig veranlassen.
    • 8) Fehlinterpretation der Kanten in den Bits. Dies wird zu einem Phasenfehler führen, der den Empfänger dazu veranlassen könnte, das Abtasten in einem Bit zu früh oder zu spät zu beginnen.
    • 9) Fehlinterpretation der Stopfbits. Dies wird dazu führen, zu wenige oder zu viele Stopfbits zu entfernen. Dies wird den Empfänger dazu bringen, außer Synchronisation zu dem Beginn des CRC-Felds zu sein.
  • Die gesamte Liste beschreibt eine Reihe von Problemen, die zu einer inkorrekten Ausrichtung zwischen der internen CRC und der von dem CAN-Bus empfangenen CRC führen werden. Problemnummern 1, 2, 3, 7, 8 und 9 sind üblich bei sowohl klassischem CAN und CAN-FD. Die hinzugefügte Funktionalität in CAN-FD, gegeben durch die FDF- und res-Bits (Probleme 4 und 5) vergrößert das Problem durch Erzeugen von mehr Möglichkeiten für einen Bit-Umkehr-Fehler, um einen Versatzfehler zu verursachen. CAN-FD unterstützt auch mehr Varianten in dem DLC, was den Fehler, verursacht durch Problem 7 im Vergleich zu klassischer CAN vergrößert. CAN-FD unterstützt auch mehr Datenbytes, was die Risiken mit Bezug auf Problem Nr. 9 vergrößert, weil 12 mehr Stopfbits verpasst werden können. Aufgrund der vergrößerten Anzahl von Bits und Bitkanten wird sich Problem Nr.8 in CAN-FD um etwa 8 Mal verglichen mit klassischer CAN vergrößern.
  • Die Wahrscheinlichkeit, dass irgendwelche dieser Probleme tatsächlich auftreten, kann sehr gering sein, aber es ist möglich, Fälle zu beschreiben, in denen dies auftreten könnte. Wir könnten sogar sagen, dass die Wahrscheinlichkeit sehr niedrig ist, da CAN in den meisten Fällen sehr gut arbeitet und wenn dies ein echt großes Problem wäre, wäre dies der Gemeinschaft bekannt gewesen. Es ist jedoch bekannt, dass, wenn es ein Problem gibt, es um eine gewisse Größe zunehmen wird, wenn CAN-FD in dem vollen Umfang implementiert wird. Zum Beispiel sind diese Fehler im klassischen CAN-Zusammenhang von reduzierter Größe und Frequenz aus einer Vielzahl von Gründen, darunter der relativ niedrigen Bit-Rate von CAN, weniger als ein Mbit/s; der Energie in dem dominanten Bit, die relativ hoch ist, 4 Volt über 60 Ohm, 0,25 Watt; der rezessive Pegel verlangt eine relativ hohe Energie 0,5 Volt über 60 Ohm (4 mW); der abgetastete Bus-Pegel ist derselbe DC-Pegel im gesamten elektrischen Bus, der alle Einheiten abdeckt; die typische Bus-Länge in der Automobilindustrie ist weniger als 40 Meter; das Kabel ist normalerweise nah an einem metallischen Teil befestigt, was die Aussetzung elektrischer Störungen reduziert; die Logik hat Filter, die Störungen davon abhält, schlechte Phasenverschiebungen zu verursachen; und umfassende Fehlerbehandlung hält schlechte Datenteile davon ab, verwendbar zu sein. Der Schluss ist jedoch, dass CAN-FD empfindlicher sein wird, wodurch eine Erwartung von mehr Bits mit Fehler vergrößert wird. Gleichzeitig vergrößern die neuen Bits, die in CAN-FD eingeführt sind, die Wahrscheinlichkeit nicht detektierbarer Fehler.
  • Individuelle Lösungen für jedes der obigen Probleme zielen im Allgemeinen darauf ab, die Fähigkeit dieser neun Fehlerursachen zu reduzieren, das Lesen der Bits an der falschen Position zu bewirken. Ein anderer eingebauter Schutz für klassisches CAN liegt in seiner EOF-Struktur. In einem CAN-Datenformat ist das Muster nach dem CRC-Feld sehr eindeutig (101111111111S). Nach der Abfolge von „10“ wenigstens gefolgt von 1 (ACK-Begrenzer) + 7 (EOF) = 8 rezessiven Bits zusätzlich zu typischen drei mehr rezessiven Bits bevor der nächste Rahmen gestartet wird. Diese Sequenz ist eindeutig und kann nicht innerhalb des CAN-Rahmens existieren, da eine Abfolge von sechs rezessiven Bits die Stopfregel verletzen wird. Entsprechend sind all die CRC-Bits in korrekter Beziehung zu dem internen CRC-Wert, wenn das Muster 1011111,111... direkt nach dem CRC-Feld folgt und indirekt muss der CRC-Vergleich bei der korrekten Position begonnen haben und all die neuen Probleme, die das Verlieren von Bit-Positionen verursachen könnten, existieren nicht.
  • Das Problem mit diesem in klassisches CAN eingebautem Schutz ist, dass dieses Muster schwach ist. Es gibt mehrere Bitmuster, die mit einem Bit-Umkehrung aussehen werden wie ein korrektes EOF. Wenn Sie ein Datenmuster nur mit rezessiven Bits haben mit Ausnahme eines dominanten Bits in einem der ersten fünf Bits wird ein Fehler, der das dominante Bit umkehrt, das Datenkennwertmuster in ein EOF umwandeln.
  • ZUSAMMENFASSUNG
  • Allgemein gesprochen wird gemäß diesen verschiedenen Ausführungsformen ein zweites Protokoll in ein erstes Protokoll eingebettet, so dass Module, die das zweite Protokoll unterstützen, das erste Protokoll kennen und nutzen können, während Module, die nur das erste Protokoll unterstützen, das zweite Protokoll nicht kennen können. Der Betrieb von Modulen, die das zweite Protokoll verwenden, stört nicht den Betrieb der Module, die nicht konfiguriert sind, das zweite Protokoll zu verwenden oder zu verstehen. Durch einen Ansatz werden die Nachrichten, die unter Verwendung des zweiten Protokolls versendet sind, als Nachrichten angesehen, die unter Verwendung des ersten Protokolls versendet sind, aber keine Nachricht haben, die notwendig ist, zu verstehen oder die eine bestimmte Antwort benötigt. In einem anderen Ansatz können Module, die das zweite Protokoll verwenden, dazu eingerichtet sein, eine Nachricht während der Übertragung von Nachrichten des ersten Protokolls durch andere Module zu senden, wobei die Nachrichten des zweiten Protokolls von erwarteten Aspekten der Nachricht ausgelöst werden, die unter dem ersten Protokoll gesendet werden.
  • In einem bestimmten Beispiel kann das erste Protokoll ein CAN-Protokoll sein und das zweite Protokoll ist ein Protokoll, das Bits in Teile des CAN-Protokolls einbettet. Beispielsweise schließen Bits eines CAN-Protokolls typischerweise mehrere Bitquanten ein und das CAN-Protokoll arbeitet, indem es nach bestimmten Signalpegeln in bestimmten Teilen oder Bitquanten der einzelnen Bits sucht. Bei einem Ansatz kann daher das zweite Protokoll das Senden zusätzlicher Information innerhalb des CAN-Nachrichtenpakets unter Verwendung von Bitquanten von Prop-Seg-Bits des CAN-Nachrichtenpakets verschieden von den festgelegten Bitquanten einschließen.
  • Zweite Protokollinformation ist so eingebettet, dass fallende Flanken von Bits in dem zweiten Protokoll den normalen Betrieb von Modulen, die nur das erste oder CAN-Protokoll verstehen, nicht beeinträchtigen wird. Dies kann beispielsweise durch Bewirken einer Synchronisation von Modulen, die sowohl das erste als auch das zweite Protokoll verwenden, mit einem Teil des Nachrichtenpakets erfolgen. Verwenden dieses Ansatzes kann es Modulen erlauben, das zweite Protokoll zu verwenden, Nachrichtensteuerungen der ersten Protokollnachricht, die die zweite Protokollnachricht trägt, dazu zu verwenden, die zweite Protokollnachricht zu steuern, wodurch die Menge an Daten, die mit einer einzigen zweiten Protokollnachricht übertragen werden können, vergrößert wird. Das eingebettete Protokoll kann auch für verbesserte Fehlerüberprüfung der übertragenen Nachrichten verwendet werden. Diese und andere Vorteile können bei der gründlichen Durchsicht und dem Studium der folgenden detaillierten Beschreibung klarer werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 weist ein Blockdiagramm eines beispielhaften Steuerungsnetzwerks auf, das gemäß verschiedenen Ausführungsformen der Erfindung konfiguriert ist;
  • 2 weist eine schematische Darstellung einer CAN-Nachricht auf;
  • 3 weist eine schematische Darstellung eines beispielhaften CAN-Zeitquantums auf;
  • 4 weist eine schematische Darstellung eines beispielhaften CAN-Bits auf;
  • 5 weist eine schematische Darstellung eines Beispiels eines Einbettens einer zweiten Protokollnachricht in einen Teil einer ersten Protokollnachricht, hier eines Prop_Seg-Teils einer CAN-Nachricht, konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung, auf;
  • 6 weist eine schematische Darstellung eines Beispiels auf, wie ein Modul, das unter Verwendung einer zweiten Protokollnachricht innerhalb eines Teils einer ersten CAN-basierten Protokollnachricht konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung eine empfangene Nachricht mit einer Signalstörung interpretieren kann;
  • 7 weist ein Beispiel auf, wie ein zweites Modul, das unter Verwendung einer zweiten Protokollnachricht innerhalb eines Teils einer ersten CAN-basierten Protokollnachricht konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung arbeitet, die empfangene Nachricht von 6 mit einer anderen Signalstörung interpretieren kann;
  • 8 weist einen Vergleich schematischer Darstellungen einer von einem Modul gesendeten Beispielnachricht auf und wie die Nachricht von einem zweiten Modul konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung wahrgenommen wird;
  • 9 weist einen Vergleich schematischer Darstellungen einer von einem Modul gesendeten beispielhaften Nachricht auf und wie ein zweites Modul eine Nachricht in einem zweiten Protokoll in Antwort auf den Erhalt der beispielhaften Nachricht gemäß verschiedenen Ausführungsformen der Erfindung konfiguriert überträgt;
  • 10 weist einen Vergleich von schematischen Darstellungen einer von einem Modul gesendeten beispielhaften Nachricht auf und wie ein zweites Modul eine Nachricht in einem zweiten Protokoll in Antwort auf den Erhalt der beispielhaften Nachricht gemäß verschiedenen Ausführungsformen der Erfindung konfiguriert überträgt;
  • 11 weist ein Blockdiagramm eines beispielhaften Steuerungsnetzwerks mit einer Sterntypologie, konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung, auf;
  • 12 weist ein Blockdiagramm eines beispielhaften Kommunikationsgeräts, konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung, auf;
  • 13 weist schematische Darstellungen von mehreren gesendeten beispielhaften Nachrichten, konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung, auf;
  • 14 weist Zeitablaufdiagramme von zwei CAN-EF-Modulen A und B auf, die einen Synchronisierungspuls während einer CAN-Übertragung übertragen;
  • 15 veranschaulicht den Abtastpunkt(SP)- und Synchronisierungssprungbreite(SJW)-Bereiche für eine CAN-Übertragung;
  • 16 veranschaulicht modifizierte Abtastpunkt(SP)- und Synchronisierungssprungbreite(SJW)-Bereiche für eine CAN-Übertragung in Übereinstimmung mit verschiedenen Ausführungsformen der Erfindung;
  • 17 veranschaulicht die Übertragung einer Abfolge von rezessiven Bits, wo fünf von sechs Bits eine Synchronisierungskante konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung aufweisen;
  • 18 veranschaulicht eine Beziehung von verschiedenen CAN-EF-Parametern in einer Bitzeit (BT), konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung;
  • 19 veranschaulicht einen möglichen Kommunikationszustand zwischen zwei Modulen A und B nach einer Arbitrierungssequenz;
  • 20 veranschaulicht die Inversion des letzten CAN-Bits, um eine Synchronisierungsflanke folgend einem rezessiven und einem dominanten Bit zu erzwingen, zusammen mit einem Bitstopfen-Szenario schlechtesten Falls;
  • 21 veranschaulicht ein beispielhaftes CAN-EF-Rahmenformat, wie es in einem CAN-Bit eingebettet ist und ein erweitertes CAN-Bit, wie es in Übereinstimmung mit verschiedenen Ausführungsformen der Erfindung konfiguriert ist;
  • 22 veranschaulicht, wo eingebettete CAN-EF-Bits innerhalb einer CAN-Übertragung gesendet werden können;
  • 23 veranschaulicht eine beispielhafte Übertragung von 80 CAN-EF-Bits unter Verwendung von zwei CAN-Bytes, wie gemäß verschiedenen Ausführungsformen der Erfindung konfiguriert;
  • 24 veranschaulicht eine Übertragungssequenz, wo der CRC-Begrenzer-Teil einer Übertragung eine Stopfverletzung erzwingt, konfiguriert gemäß verschiedenen Ausführungsformen der Erfindung;
  • 25 veranschaulicht zwei Bitperioden mit anfänglichen Synchronisierungspulsen;
  • 26 veranschaulicht eine Ausbreitungsverzögerung zwischen einem übertragenden Gerät und einem empfangenden Gerät;
  • 27 veranschaulicht Synchronisierungsunsicherheit innerhalb der in 26 veranschaulichten Ausbreitungsverzögerung;
  • 28 veranschaulicht eine Übertragungsdatenüberlagerung, wie in Übereinstimmung mit verschiedenen Ausführungsformen der Erfindung konfiguriert;
  • 29 veranschaulicht den Betrieb einer Übertragungsdatenüberlagerung in einem bidirektionalen Protokoll, wie in Übereinstimmung mit verschiedenen Ausführungsformen der Erfindung konfiguriert.
  • Fachleute werden erkennen, dass Elemente in den Figuren zur Einfachheit und Klarheit dargestellt sind und nicht notwendigerweise maßstäblich gezeichnet wurden. Zum Beispiel können die Abmessungen und/oder die relative Positionierung von manchen der Elemente von den Figuren relativ zu anderen Elementen übertrieben sein, um dabei zu helfen, das Verständnis der verschiedenen Ausführungsformen der vorliegenden Erfindung zu verbessern. Auch sind übliche, aber gut verstandene Elemente, die nützlich oder notwendig in einer kommerziell brauchbaren Ausführungsform sind, oft nicht dargestellt, um einen weniger verstellten Blick auf diese verschiedenen Ausführungsformen zu ermöglichen. Es wird ferner erkannt werden, dass bestimmte Aktionen und/oder Schritte in einer bestimmten Reihenfolge der Erscheinung beschrieben oder veranschaulicht sein können, während der Fachmann verstehen wird, dass solche Genauigkeit mit Bezug auf die Abfolge nicht tatsächlich erforderlich ist. Es wird auch verstanden werden, dass die Begriffe und Ausdrücke, die hierin verwendet sind, die gewöhnliche technische Bedeutung haben, die solchen Begriffen und Ausdrücken durch Fachleute in dem technischen Gebiet wie oben angegeben beigemessen werden, mit der Ausnahme, wo andere spezifische Bedeutungen hierin anders angegeben wurden.
  • DETAILLIERTE BESCHREIBUNG
  • Nun bezugnehmend auf die Zeichnungen und speziell auf 1 wird ein anschauliches System, das mit vielen dieser Lehren kompatibel ist, nun dargestellt. In 1 ist ein Steuerungsnetzwerk 1000 veranschaulicht, das verschiedene Vorrichtungen hat, die über einen Bus 1005 kommunizieren. Aber diese Lehren können für Steuerungsnetzwerke aufweisend irgendeine Vielfalt von Topologien gelten. Die Kommunikationsvorrichtungseinrichtung 1010 kann als ein Modul oder Knoten des Steuerungsnetzwerks 1000 betrachtet werden und einen Kommunikationsanschluss 1012 einschließen, der zum Verbinden mit einem Steuerungsnetzwerk 1000 gemäß der Topologie des Steuerungsnetzwerks eingerichtet ist. Die Kommunikationsvorrichtungseinrichtung 1010 schließt auch eine Verarbeitungsvorrichtung 1014 ein, die mit dem Steuerungsnetzwerk 1000 wirksam verbunden ist, um Erhalten und Senden von Kommunikationen mit anderen Geräten 1020, 1030, 1040, 1050 und 1060 über das Steuerungsnetzwerk 1000 über den Kommunikationsanschluss 1012 zu steuern. Der Fachmann wird erkennen und schätzen, dass solch ein Prozessor eine fest verdrahtete Plattform für einen festen Zweck aufweisen kann, oder eine teilweise oder ganz programmierbare Plattform aufweisen kann. Alle diese architektonischen Optionen sind auf dem Gebiet gut bekannt und verstanden und erfordern hier keine weitere Beschreibung.
  • Eine beispielhafte Umsetzung der Einbettung der zweiten Protokollnachricht in der ersten Protokollnachricht wird mit Bezug auf die 210 im Zusammenhang mit einem CAN-basierten System beschrieben werden. Der Controller Area Network(CAN)-Standard (Steuergerätenetzwerk(CAN)-Standard) (Internationale Organisation für Normung (ISO) 11898) ist ein häufig verwendetes Protokoll für ein verteiltes, eingebettetes Steuerungssystem, obwohl diese allgemeinen Lehren auch auf andere Protokolle angewendet werden können.
  • In dieser Implementierung können Module, die das CAN-Protokoll ISO 11898 unterstützen, mit Modulen, die ein zweites Protokoll auf demselben Bus unterstützen, durch Verzicht auf Vorteilsziehung aus einem oder mehreren Merkmalen von CAN koexistieren. 2 zeigt manche Hauptcharakteristiken von CAN. CAN ist für eine Bustopologie entworfen und arbeitet mit zwei Spannungspegeln, keine Spannung 101, was den Wert „1“ repräsentiert, und Spannung 102, was den Wert „0“ repräsentiert. Diese Gestaltung impliziert, dass eine Null über eine Eins dominant ist; mit anderen Worten, wenn ein erster Sender eine Eins überträgt und ein zweiter Sender eine Null zur selben Zeit, kann nur die Null detektiert werden. Ein Bus im Leerlauf kann als ein kontinuierlicher Strom von Einsen angesehen werden. Eine Nachricht 103 beginnt mit einem Nullbit, dem Beginn des Rahmens (Start of frame, SOF) 104, gefolgt von einem Identifizierer (Identifier) 105 von elf (Standard) oder 29 (erweitert) plus 2 Protokollbits (insgesamt 31 Bits) und einem Entfernte-Übertragung-Anforderung(remote transmit request, RTR)-Bit 106. Die SOF- und Identifizierer-Nachrichtenteile stellen das Arbitrierungsfeld 107 dar, wo BUS-Kollisionen durch bitweise Arbitrierung aufgelöst werden. Während des verbleibenden Teils der Nachricht 108 bis zum Bestätigungsbit (Acknowledgement bit, ACK) 109 gibt es nur einen Sender auf dem Bus, weil andere Sender gesteuert werden in Reaktion auf diesen anfänglichen Nachrichtenteil nicht aktiv zu sein; im Besonderen wird nach dem Arbitrierungsteil der Nachricht, der mit dem RTR endet, nur ein Sender senden, während alle anderen Kommunikationseinheiten nur Bits durch das Protokoll empfangen werden. Dieser verbleibende Teil der Nachricht 108 beginnt mit einem Steuerungsfeld (Control Field, 110) mit zwei dominanten Bits und Vier-Bits-Datenlängenkennwert (Data Length Code, DLC) 111, das die Länge des folgenden Datenfeldes (Data Field, 112), anzeigt, das keine Daten enthalten kann (DLC = 0) oder bis zu 8 Byte (DLC = 8). Mit anderen Worten kann das Datenfeld 112 der Standard-CAN-Nachricht von 0 bis 64 Bits lang sein. Die Nachricht wird soweit durch einen 15-Bit-CRC-Kennwert angeordnet in dem 16-Bit-CRC-Feld 113 geprüft, wo das letzte Bit der CRC-Begrenzer 114 ist. Das ACK-Feld 115 enthält das ACK-Bit 109 gefolgt durch ein rezessives Bit, den ACK-Begrenzer 116. Der verbleibende Teil der Nachricht 103 ist das Ende-des-Rahmens(End of Frame, EOF)-Feld 117, das sieben aufeinanderfolgende rezessive Bits enthält. Drei rezessive Bits, die Unterbrechung (Intermission) 118 müssen vorübergehen, bevor der Bus frei für neue Nachrichten ist.
  • Gemäß der CAN-Spezifikation (ISO 11898-1) ist ein Bit aus Zeitquanten konstruiert. Mit Bezug auf 3 ist ein einziges Bitquantum für die Standard-CAN-Nachricht als Zeitquantum 130 veranschaulicht, welches eine feste Zeiteinheit abgeleitet von der Oszillatorperiode 131 des Taktgebers des Senders/Empfängers ist. Die Zeitticks 131 können alternativ von einem separaten Oszillator oder Taktgeber abgeleitet werden. Ein programmierbarer Vorteiler mit ganzen Werten reicht von wenigstens 1 bis 32, um das Zeitquantum als eine gegebene Anzahl von einem Mindestzeitquantum festzulegen. Entsprechend soll das Zeitquantum beginnend mit dem Mindestzeitquantum die Länge von Zeitquantum = m·Mindestzeitquantum haben,
    wobei m der Wert des Vorteilers ist.
  • Im Betrieb ist daher ein anderes beispielhaftes CAN-Bit 132 wie in 4 veranschaulicht aus individuellen Zeitquanten konstruiert. Das erste Zeitquantum ist das Sync_Seg 133, gefolgt von dem Prop_Seg (Ausbreitungssegment) 134, bestehend aus einem bis zu wenigstens 8 Zeitquanten. Das Ausbreitungssegment ist gemäß einer Zeitperiode festgelegt, um sicherzustellen, dass sich eine Signalwelle von dem Sender zu dem fernen Ende des Buses und zurück ausbreiten kann, was auch mit der Menge an Zeit korrespondiert, die gebraucht wird, so dass das am weitesten entfernte Modul in dem Steuerungsnetzwerk die Nachricht empfangen und antworten kann. Entsprechend ist die Prop_Seg-Länge bestimmt, um es dem Bit-Arbitrierungsaspekt des CAN-Protokolls zu erlauben, zu arbeiten. Der Schlussteil des CAN-Bits 132 schließt die Phasesegmente, Phase_Seg 1 135 und Phase_Seg 2 136, ein. Die Phasesegmente sind symmetrisch, wobei jedes ein oder bis zu wenigstens 8 Zeitquanten lang hat. Die Phasesegmente nehmen dem Zeitversatz zwischen verschiedenen Knoten in dem System auf. Ein CAN-Bit sollte dann programmierbar von 4 bis zu wenigstens 25 Zeitquanten sein.
  • Alle Taktgeber in einem CAN-System werden als unsynchronisiert angenommen. Wenn ein SOF 104 übermittelt wird, wird die Bit-Darstellung jedes Moduls auf die fallende Flanke 140 synchronisiert und jedes Modul zählt die Anzahl von Zeitquanten, die für Prop_Seg und Phase_Seg 1 vorgegeben sind. Beispielsweise kann der interne Taktgeber eines Moduls, das die fallende Flanke empfängt, die Zeitwahl des erwarteten Abtastpunktes innerhalb der Auflösung dieses internen Taktgebers bestimmen; d.h. durch Kenntnis der Definition der Bits in dem internen Taktgeber kann das Modul die Position des Abtastpunktes relativ zu dem internen Taktgeber berechnen. Im CAN wird dies typischerweise durch Zeitquanteneinheit durchgeführt, wo jede Zeitquanten eine Anzahl lokaler Taktelemente ist. Die Spannung des Signals wird beim Abtastpunkt 141 gemessen. Wenn die Spannung noch vorhanden ist, entscheidet das Modul, dass ein SOF detektiert wird und die folgenden Spannungsverschiebungen werden entsprechend der CAN-Spezifikation dekodiert. Wenn es keine Spannung an dem Abtastpunkt 141 gibt, wird die fallende Flanke als Störung angesehen und ignoriert. Dieses Merkmal kann als ein Tiefpassfilter angesehen werden, das Störungen auf dem Bus, beispielsweise aufgrund von Wellenreflektionen, herausfiltert. Solche Merkmale machen CAN verlässlich und nachsichtig in schlechten Verdrahtungsinstallationen.
  • Spannungsränder können in bestimmten Kommunikationssystemen hohe Frequenzen ausstrahlen, wodurch Probleme mit elektromagnetischer Verträglichkeit (EMV) verursacht werden. Um solche Probleme zu reduzieren, legt CAN eine Keine-Rückkehr-nach-Null(Non Return to Zero, NRZ)-Dekodierung von Bits fest, mit anderen Worten aufeinanderfolgende Bits desselben Werts erzeugen keine Kanten; stattdessen werden die Bits durch Koppelberechnung dekodiert. Die Taktgeber der individuellen Module werden nur bei fallenden Flanken resynchronisiert, die als Übergänge von rezessiven (1)-Bits zu dominanten (0)-Bits definiert sind. CAN hat eine Bitstopfenregel, dass nach einer Abfolge von fünf aufeinanderfolgenden Bits desselben Werts ein Stopfbit von entgegengesetztem Wert eingefügt werden soll, um sicherzustellen, dass Resynchronisierungen stattfinden werden. Daher wird eine Resynchronisierung wenigstens nach zehn Bits unter normalen Bedingungen stattfinden. Die CAN-Spezifizkation verlangt, dass der Abtastpunkt für mindestens 13 Bits innerhalb der Phasesegmente bleibt.
  • Ausführlichere Information über CAN kann in dem ISO-Standard 11898 und dem Artikel „The Configuration of the CAN Bit Timing (Die Konfiguration der CAN-Bit-Zeitwahl)“ von Florian Hartwig und Armin Bassemir (Robert Bosch GmbH, Abt. K8/EIS) präsentiert auf der 6. Internationalen CAN-Konferenz, 02.–04. November, Turin, Italien, veröffentlicht von CAN in Automation (CiA), Nürnberg, Deutschland, welche Materialien in ihren Gesamtheiten hierin durch Bezugnahme aufgenommen sind, gefunden werden.
  • Sich 5 zuwendend ist eine beispielhafte Lösung des Bandbreitenproblems, ein erstes Protokoll zu modifizieren, hier das CAN-Protokoll, um ein zweites Hochgeschwindigkeitsprotokoll in Teile einer Standard-CAN-Nachricht einzubetten. In solch einem Ansatz kann ein Verarbeitungsgerät eines Steuerungsnetzwerkmoduls dazu eingerichtet sein, das zweite Protokoll zu steuern, eine Bitrate zu verwenden, die höher ist als die Bitrate des ersten Protokolls, beispielsweise das zweite Protokoll zu steuern, eine Bitrate zu verwenden, die ein ganzzahliges Vielfaches höher ist als die Bitrate des ersten Protokolls. Alternativ kann die Bitrate des zweiten Protokolls auch eine Rate mit einem nicht-ganzzahligen Vielfachen höher als das erste Protokoll haben. Beispielsweise kann das erste Protokoll eine Bitrate von 100 Bits/Sekunde und das zweite Protokoll kann eine Bitrate irgendwo von 400 Bit/Sekunde bis 6 Mbit/Sekunde haben. Die Bitrate wird sein (Anzahl der Bits des zweiten Protokolls in jedem Bit des ersten Protokolls)/((zeitliche Länge des Ausbreitungssegments) × Nutzung) Bits/Sekunde. Die Rate der Bits in dem zweiten Protokoll ist nur durch die Taktgeberauflösung in der Steuerungslogik für das zweite Protokoll begrenzt. Die Anzahl von Bits in jedem Zeitquantum kann beispielsweise 20 pro 3 Zeitquanten sein. In jedem Fall ist der Effekt, dass das Verarbeitungsgerät konfiguriert ist, das zweite Protokoll durch Hinzufügen von Bits innerhalb von individuellen Bitquanten des ersten Protokolls zu implementieren. Mit anderen Worten kann ein CAN-Nachrichtenpaket durch Bits festgelegt sein, die eine Vielzahl von Bitquanten aufweisen und Daten für das CAN-Nachrichtenpaket sind durch einen Signalpegel bei festgelegten Bitquanten eines Bits festgelegt, wo die festgelegten Bitquanten weniger als jede Bitquanten eines Bits sind. Beispielsweise verwendet ein Standard-CAN-Bit festgelegte Bitquanten einschließlich eines ersten Bitquantums eines entsprechenden Bits, welches erstes Bitquantum ein Sync_Seg-Bit und ein Abtastpunktbitquantum des entsprechenden Bits ist. Der Abtastpunkt ist typischerweise zwischen dem Phase_Seg 1- und Phase_Seg 2-Teil des Bits, wie in 4 veranschaulicht. Die verbleibenden nicht festgelegten Bitquanten sind zur Verwendung in dem zweiten Protokoll verfügbar. Daher ist, in einem Beispiel, zur Einbettung des zweiten Protokolls die Verarbeitungsvorrichtung konfiguriert, zusätzliche Information innerhalb des CAN-Nachrichtenpakets unter Verwendung von Bitquanten von Prop_Seg-Bits des CAN-Nachrichtenpakets zu senden, die andere sind als die festgelegten Bitquanten, die durch die Knoten unter Verwendung des Standard-CAN-Nachrichtenprotokolls geprüft werden.
  • Genauer zeigt 5 ein beispielhaftes CAN-Bit mit einem Ausbreitungssegment 205 von acht Zeitquanten und zwei Phasesegmenten 203 und 204 mit jeweils einem Zeitquantum. Die Bits starten mit dem Sync_Seg 202, wo jede Spannungsverschiebung 201 während dieser Zeit durchgeführt wird. Der Spannungspegel über die Bitzeit ist durch eine fettgedruckte Linie 206 veranschaulicht. Die Module, die das zweite Protokoll unterstützen, würden das Prop_Seg für einen eingebetteten Hochgeschwindigkeitsbitstrom durch Abtasten des Spannungswerts jedes Zeitquantums und Dekodieren des Werts gemäß den CAN-Regeln nutzen, wo eine abgetastete Spannung als Null und keine Spannung als Eins dekodiert sind. Module, die nur das ursprüngliche CAN-Protokoll unterstützen, würden die fallende Flanke 201 als Asynchronisierungs- oder Resynchronisierungsflanke dekodieren und die folgenden Spannungsverschiebungen ignorieren. Das Spannungslevel beim Abtastpunkt 207 ist dominant und das CAN-Modul wird das Bit korrekterweise als eine Null dekodieren. Module, die das zweite Protokoll unterstützen, würden die Abtastpunkte 210 bis 217 wie folgt dekodieren: 210 = 0; 211 = 1; 212 = 1; 213 = 1; 214 = 0; 215 = 0; 216 = 1; 217 = 0. Hier ist die Verarbeitungsvorrichtung für das Modul dazu eingerichtet, dieselben Spannungspegel für Signalkennzeichnungen für sowohl das erste Protokoll und das zweite Protokoll zu verwenden, obwohl dies nicht notwendig ist. In der Tat kann die Verarbeitungsvorrichtung stattdessen dazu eingerichtet sein, das zweite Protokoll durch Hinzufügen von Bits innerhalb von individuellen Bitquanten des ersten Protokolls implementieren, die nicht gemessen sind, ein bestimmter Pegel gemäß dem ersten Protokoll zu sein. Auch sind, obwohl die Breite der veranschaulichten Bits des zweiten Protokolls oder Abtastpunkte als gleiche Breite wie die Abtastpunkte des ersten Protokolls aufweisend veranschaulicht sind, andere Zeitlängen verschieden von denen der Abtastpunkte des ersten Protokolls möglich. Die Anzahl von Bits des zweiten Protokolls, angeordnet in dem Ausbreitungssegment, ist nur durch die Leistungsfähigkeit der physikalischen Schicht und die Taktgeberauflösung in der Steuerungslogik begrenzt, die das zweite Protokoll handhabt.
  • Allgemein gesprochen ist das Verarbeitungsgerät für das Modul, das unter dem zweiten Protokoll arbeitet, dazu eingerichtet, ein Sync-Seg-Bitquantum als dominant zu setzen, bspw. nach rezessiven Abtastungen in dem ersten Protokoll. Der Nachteil dieser Regel ist, dass es, verglichen mit dem ursprünglichen CAN-Protokoll mehr fallende Flanken in CAN-Nachrichten einführen wird, aber jedes Hochgeschwindigkeitsprotokoll würde gleichermaßen zusätzliche fallende Flanken erzeugen. In einem Beispiel dieses Ansatzes werden Stopfbits in dem ersten Protokoll verwendet, um eine Resynchronisierungsflanke wenigstens alle 10 Bits sicherzustellen. Mit diesem neuen Flankenerzeuger wird die Resynchronisierung auf jedem rezessiven Bit auftreten und niemals nach mehr als 6 Bits. Mit solch einer Anordnung kann das beispielhafte System mit Taktgebern mit 66% weniger Toleranz arbeiten. Ein möglicher Nachteil in solche einem Ansatz ist, dass Vorteile nur verwirklicht werden könnten, wo alle Nachrichten mit dieser zusätzlichen Flanke in dem Synchronisierungssegment gesendet werden und dieser Ansatz könnte nicht arbeiten, wenn die Nachrichten gemäß dem ersten Protokoll gesendet werden. Dieses Merkmal kann auch dafür verwendet werden, den Abtastpunkt in dem ersten Protokoll aus dem Ausbreitungssegment heraus zu bewegen. Durch Vorliegen des ersten Bytes in dem ersten Protokoll nur mit rezessiven Bits ist es möglich, acht Flanken zu haben, die den Abtastpunkt wenigstens acht Zeitquanten aus dem Ausbreitungssegment bewegen werden. Dies wird nicht alle Fälle abdecken, da ein Ausbreitungssegment mehr als acht Zeitquanten in dem Ausbreitungssegment aufweisen könnte. In den meisten Fällen sollte dies mehr als genug sein und andere Umsetzungen können programmiert werden, um jede Einstellung abzudecken, die in dem ersten Protokoll verwendet wird.
  • Noch ein anderer Vorteil des beschriebenen Ansatzes ist das Verwenden des zweiten Protokolls zur Unterstützung bei der Identifizierung von Netzwerkproblemen. Beispielsweise umfassen Störungen auf dem Bus ein übliches CAN-Problem, das oftmals schwer zu finden und zu lösen sein kann. Solche Störungen schließen Wellenreflektionen aufgrund von Impedanzverschiebungen entlang des Buses, Taktfrequenzänderungen aufgrund von Temperaturänderungen über verschiedene Knoten hinweg und vorübergehende Störungen aufgrund von externen Quellen ein. Oftmals kann die Störung bei nur einem Knoten in einem System alleine eine CAN-Nachricht zerstören. Die Spanne bis zum Scheitern ist typischerweise nicht bekannt. Daher kann das zweite Protokoll verwendet werden, solche Probleme zu behandeln. Beispielsweise kann die Hochgeschwindigkeitsabtastfähigkeit des zweiten Protokolls verwendet werden, um Rauschen in den Nachrichten gemäß dem ersten Protokoll zu entdecken. Rauschen in dem Ausbreitungssegment der Nachrichten gemäß dem ersten Protokoll können Schwierigkeiten bei der Verwendung des zweiten Protokolls anzeigen, da das Rauschen Bit-Fehler oder CRC-Fehler in dem zweiten Protokoll verursachen kann.
  • Wie oben beschrieben wird das eingebettete Hochgeschwindigkeitsprotokoll typischerweise nur gelegentlich benötigt. Wenn es nicht verwendet wird, um unter Verwendung des eingebetteten Protokolls zu kommunizieren, kann die Ausrüstung für eine fast kontinuierlichen Qualitätsprüfung der physikalischen Schicht verwendet werden. In diesem Ansatz ist die Verarbeitungsvorrichtung für ein Modul dazu eingerichtet, das zweite Protokoll zu verwenden, um die Signalqualität für das Steuerungsnetzwerk zu testen. Durch einen Ansatz ist die Verarbeitungsvorrichtung dazu eingerichtet, das zweite Protokoll zu steuern, eine höhere Bitrate als die Bitrate des ersten Protokolls zu verwenden und zu bestimmen, ob die Bits des zweiten Protokolls, die in einer empfangenen Nachricht gemäß dem ersten Protokoll eingebettet sind, von einem erwarteten Signalpegel abweicht, verglichen mit einem Signalpegel, der für einen entsprechenden Teil der empfangenen Nachricht gemäß dem ersten Protokoll erwartet wird, wenn die empfangene Nachricht gemäß dem ersten Protokoll keine Nachricht, eingebettet unter Verwendung des zweiten Protokolls, aufweist. Mit anderen Worten ist jedes Modul eingestellt, auf den Bus zu hören und während eines untätigen Buses sollten keine Nullen detektiert werden. Wenn eine CAN-Nachricht übertragen wird, sollten alle Bits in dem Byte in dem eingebetteten Protokoll den gleichen Wert haben, wie das CAN-Bit.
  • Um diesen Punkt zu veranschaulichen, zeigt 6 den Beginn einer empfangenen CAN-Nachricht 600, die von einem anderen Modul gesendet ist, beginnend mit dem rezessiven Pegel 601 und der fallenden Flanke 602, die SOF anzeigt. Auf die fallende Flanke folgen 3 Reflektionen 603, 604, 605. Die beiden ersten beiden werden als 11 dekodiert, was zeigt, dass die beiden ersten Zeitquanten nach einer fallenden Flanke für das eingebettete Protokoll nicht sicher sind. 7 zeigt dieselbe Nachricht bei einem anderen Modul weiter von der Reflektionsstelle entfernt. Hier sind die Reflektionen auf einen für das eingebettete Protokoll sicheren Pegel gedämpft. Eine andere Störung 605 wird erfasst, die leicht als eine falsche Resynchronisierungsflanke gesehen werden könnte oder, wenn diese bei einem Abtastpunkt auftritt, einen Bitfehler verursachen könnte. Module, die das eingebettete Protokoll unterstützen, aber nicht verwenden, könnten solche Störungen erfassen und protokollieren, die CAN-Module veranlassen könnten, auf falschen Kanten wieder zu synchronisieren und/oder falsche Bitwerte abzutasten. Die Störungen wären sehr genau zeitmarkiert gemäß dem lokalen Taktgeber bei dem entsprechenden Modul. Dann kann die Verarbeitungsvorrichtung das Senden von Information bezüglich der Bestimmung, ob die Bits des zweiten Protokolls, eingebettet in die empfangene Nachricht gemäß dem ersten Protokoll, von dem erwarteten Signalpegel abwichen, an eine Vergleichsvorrichtung bewirken, die dazu eingerichtet ist, die Information mit entsprechender Information von anderen Vorrichtungen in dem Steuerungsnetzwerk zu vergleichen, um eine Quelle des Steuerungsnetzwerkfehlers zu lokalisieren. Dies kann durch Nutzung der Zeit umgesetzt werden, die gemäß dem entsprechenden lokalen Taktgeber aufgenommen und in eine gemeinsame Zeit umgesetzt wurde, wobei Beispiele davon in dem US-Patent Nr. 8 065 052 beschrieben sind, dessen Inhalte hierin durch Bezugnahme aufgenommen sind. Störungen, die durch eine Impedanzänderung auf dem Bus hervorgerufen sind, können von anderen Typen von Störungen unterschieden werden, und da die Wellenausbreitungsgeschwindigkeit in dem Bus bekannt ist, ist es auch möglich, die Position der Impedanzstörung in dem Bus durch Korrelation der Zeitstempel der Störung bei dem entsprechenden Knoten und der Buslänge zwischen den entsprechenden Knoten zu bestimmen.
  • Wenn es bestimmt wird, dass für ein gegebenes Steuerungsnetzwerk diese Störungen primär in bestimmten Teilen einer Nachricht gemäß dem ersten Protokoll auftreten, wie bspw. nahe bei Flanken in dem obigen Beispiel, kann das eingebettete Protokoll modifiziert werden, um von der Verwendung von bestimmter Teile des ersten Protokolls für die Einbettung abzusehen. In dem obigen Beispiel könnte das zweite Protokoll dazu eingerichtet werden, das Verwenden einer oder mehrerer der ersten Zeitquanten in dem Prop_Seg zum Einbetten von Daten zu vermeiden. Das Protokoll höherer Lagen CanKingdom zeigt, wie die CAN-Bitzeitwahl durch Verwendung von Kings Seite 8 optimiert werden kann, welches gleiche Verfahren verwendet werden könnte, die Zeitquanten festzulegen, die durch das eingebettete Protokoll verwendet werden sollten. In einem anderen solchen Ansatz könnte das ganze eingebettete Protokoll in einer systemspezifischen Weise durch Anwenden des CanKingdom-Verfahrens aufgebaut sein, immer noch unter Verwendung allgemeiner Module.
  • Bei einem weiteren Qualitätscheck könnte der Taktgeber zum Zählen auf dem zweiten Protokoll verwendet werden, Unterschiede zwischen einem lokalen Taktgeber und dem einer anderen Vorrichtung in dem Steuerungsnetzwerk zu erfassen. In solche einem Ansatz verwendet das Modul typischerweise voneinander gesonderte Zähler zur Dekodierung des ersten Protokolls wie etwa ein CAN-Protokoll und des eingebetteten zweiten Protokolls. Hier ist die Verarbeitungsvorrichtung dazu eingerichtet, in einem Modus zu arbeiten, in dem keine eingebettete zweite Nachricht erwartet wird, und wenn diese in dem Modus arbeitet, einen Zähler für das zweite Protokoll nicht als Antwort auf den Empfang eines Synchronisierungsteils einer empfangenen Nachricht gemäß des ersten Protokolls zu resynchronisieren. Dann zählt die Verarbeitungsvorrichtung Taktgeberticks des Zählers für das zweite Protokoll über einen Teil der empfangenen Nachricht gemäß dem ersten Protokoll um eine Taktrate für ein Modul zu bestimmen, das die empfangene Nachricht gemäß dem ersten Protokoll gesendet hat. Daher könnte ein Knoten parallel zur Teilnahme an der CAN-Kommunikation leicht die Differenz zwischen der lokalen Taktgeberfrequenz und der Taktgeberfrequenz des entsprechenden Senders durch Verzicht auf das Wiedersynchronisieren des Taktgebers des eingebetteten Protokolls durch Vergleichen der Zeit von dem Ende des Arbitrierungsfeldes bis zu der fallenden Flanke des ACK-Bits wie durch den resynchronisierten CAN-Taktgeber und den nicht resynchronisierten Taktgeber des eingebetteten Protokolls registriert bestimmen. Zusätzliche Vorteile können durch Kombinierung der gegenwärtigen Techniken mit Techniken beschrieben gemäß dem US-Patent Nr. 7 934 039 und dem US-Patent Nr. 7 478 234 erhalten werden, von denen jedes in ihren Gesamtheiten hierin durch Bezugnahme aufgenommen sind.
  • Eine weitere beispielhafte Implementierung eines zweiten Protokolls innerhalb eines ersten Protokolls wird mit Bezug auf die 1013 beschrieben werden. In diesem Beispiel hat ein CAN-Bus 701 eine elektronische Steuerungseinheit (ECU) 702 verbunden an dem entfernten linken Ende des Buses 701 und eine zweite ECU 703 verbunden bei dem fernen rechten Ende des Buses 701. Zwischen diesen ECUs 702 und 703 sind mehr ECUs 704, 705, 70n mit dem Bus 701 verbunden. Die zweite ECU 703 überträgt eine Nachricht 1100 gemäß dem CAN-Protokoll, ein Teil derer in 8 veranschaulicht ist. Eine Bitabfolge 1 1 0 1 1 für die Nachricht 1100 gemäß der CAN-Spezifikation wird veranschaulicht. Genauer werden das Sync_Seg 705 und das Phase_Seg 1 und 2 706 des 0 Bits der CAN-Nachricht 1100 veranschaulicht. Als nächstes werden das Sync_Seg 707 und das Phase_Seg 1 und 2 708 des zweiten 1 Bit der CAN-Nachricht 1100 veranschaulicht.
  • Wo die zweite ECU 703 eingerichtet ist, entsprechend dem zweiten Protokoll wie hierin beschrieben zu arbeiten, wird die ECU 703 dieselbe Bitabfolge, wie in der Nachricht 1120 signalisieren. Hier wird das Sync_Seg 710 als ein dominantes Bitquantum verstanden. Der nächste Teil ist rezessiv bis zu dem dominanten Phase_Seg 1 und 2 711 gefolgt von dem dominanten Sync_Seg 712 und dem rezessiven Phase_Seg 1 und 2 713 des ersten 1-Bits folgend auf das Nullbit in der ursprünglichen CAN-Nachricht 1100. Das zweite 1-Bit nach dem Nullbit wird durch das dominante Sync_Seg 714 eingeleitet. Unter dem ursprünglichen CAN-Protokoll wird ein Prop_Seg berechnet, um die Signalverzögerung zwischen den ECUs 702 und 703 zu bestimmen, was angegeben ist, acht Bit Quanten zu sein, die als 715 gezeigt sind. Zusätzliche neun Bitquanten 716 sind zu der linken Seite des Bits hinzugefügt. Das zweite Protokoll ist in diesem Beispiel als ein Byte festgelegt, vertreten durch ein Start-des-Bytes-Bit-Quantums gefolgt von acht Bitquanten.
  • Die ECU 702 wird instruiert, bestimmte Bits in einer bestimmten CAN-Nachricht zur Übertragung von Bytes gemäß dem zweiten Protokoll zu verwenden. In diesem Beispiel zeigt das Segment 716, wo in der Nachricht 110 gemäß dem ursprünglichen CAN-Protokoll diese Bits von der ECU 703 übertragen werden. Um die Zeitverzögerung auf dem Bus zu veranschaulichen und wie die Module Information trotz der Zeitverzögerung senden, veranschaulichen die 12 und 13, was von der ersten ECU 702 gesendet 1200, 1300 ist und was von der zweiten ECU 703 empfangen und übertragen 1220, 1320 ist. 9 ist gemäß Zeit wahrgenommen durch die zweite ECU 703 angeordnet, wohingegen 10 gemäß Zeit wahrgenommen durch die erste ECU 702 angeordnet ist. Die Übertragung 717 von der ersten ECU 702 beginnt mit dem Sync_Seg 710. Es breitet sich entlang des CAN-Buses 701 aus erreicht die zweite ECU 703. Wenn es durch die ECU 702 erfasst wird, überträgt die ECU 702 den Beginn des Byte 718 gefolgt von den Bits 01101011 gemäß dem zweiten Protokoll. Dies ist in 9 veranschaulicht, wo die Bits 01101011 umgehend in Antwort auf das Empfangen des Sync_Seg 710 von der ersten ECU 702 übertragen werden. Die zweite ECU 703 überträgt dann ein zweites Byte 01010101 gemäß dem zweiten Protokoll als Antwort auf das Empfangen des Sync_Seg 712 von der ersten ECU 702. Dieses zweite Protokollsignal von der zweiten ECU 703 breitet sich zurück zu der ersten ECU 702 aus, aber aufgrund von Ausbreitungsverzögerung ist es nun in dem zweiten Teil 715 des ursprünglichen CAN-Signals positioniert, das von der ersten ECU 702 übertragen ist. Die Zeitdifferenz 720 zwischen 710 und 718, d.h. die Ausbreitungsverzögerung zwischen den ECUs 702 und 703 wird dann einfach durch die erste ECU 702 gemessen.
  • Auf diese Weise konfiguriert können nicht nur Signale gemäß einem zweiten Protokoll von verschiedenen ECUs in ein und dieselbe Nachricht gemäß einem ersten Protokoll eingebettet werden, sondern es können auch Ausbreitungsverzögerungen zwischen ECUs einfach gemessen werden. Eine große Vielfalt von Protokollen mit verschiedenen Eigenschaften können durch Kombination dieser Lehren mit solchen von bestimmten früheren Lehren wie solchen beschrieben durch US-Patent Nr. 7 711 880 mit dem Titel Schematisieren von Nachrichten in verteilter Steuerung und Überwachung, US-Patent Nr. 7 472 216 , betitelt Variabler Oszillator zur Erzeugung verschiedener Frequenzen in einem Steuerungsgerätenetzwerk (CAN), US-Patent Nr. 7 899 936 , betitelt Vorrichtung in einem modularisierten System zur Bewirkung von Zeitstempeln von Ereignissen/Bezugsereignissen und US-Patent Nr. 7 478 234 , betitelt Verteilte Steuerungs- und Überwachungssysteme, um nur einige zu nennen, wobei jedes von denen in seiner Gesamtheit hierin durch Bezugnahme aufgenommen ist, erzeugt werden.
  • Die verschiedenen Protokolle, die hierin beschrieben sind, können auch in verschiedenen Steuerungsnetzwerktopologien angewendet werden. In einem Beispiel, das in 11 veranschaulicht ist, hat ein CAN-basiertes Steuerungsnetzwerk 1400 eine Sterntopologie mit einer aktiven Verbindungsvorrichtung 1410 in dem Zentrum. Die aktive Verbindungsvorrichtung 1410 ist dazu eingerichtet, mit einer Vielzahl von CAN-Kanälen 1422, 1424 und 1426 des Steuerungsnetzwerks 1400 verbunden zu sein und als ein Übergang unter zwei oder mehreren der Vielzahl von CAN-Kanälen 1422, 1424 und 1426 zu wirken. Beispielsweise kann die aktive Verbindungsvorrichtung 1410 eine ECU sein, die verbunden ist, um auf jedem der Vielzahl von CAN-Kanälen 1422, 1424 und 1426 zu kommunizieren, wobei jeder Kanal seine eigene Module 1412, 1414, 1415, 1416, 1417, 1430, 1431, 1432, 1433, 1460 und 1462 aufweist. Bei einem anderen Beispiel könnte die aktive Verbindungsvorrichtung 1410 drei gesonderte Steuerungen sein, die nur durch Softwareabbildungsnachrichten oder -Informationen zwischen den drei verschiedenen Bussen verbunden sind. In noch einem anderen Beispiel könnte die aktive Verbindungsvorrichtung 1410 auch eine kombinierte Logik sein, die ausgelegt ist, Nachrichten zwischen den verschiedenen Bussen mehr oder weniger in Echtzeit zu übertragen.
  • In einer zusätzlichen alternativen Ausführungsform kann die Funktionalität oder Logik, die hierin beschrieben ist, in Form von einer Vorschrift ausgeführt sein, die in einem separaten Prozessorschaltkreis ausgeführt werden kann. Wenn als Software ausgeführt, kann jeder Block von Funktionalität oder Logik ein Modul, Segment oder einen Teil einer Vorschrift darstellen, die Programminstruktionen aufweist, um die vorgegebene(n) logische(n) Funktion(en) umzusetzen. Die Programminstruktionen können als Quellvorschrift ausgeführt sein, der vom Menschen lesbare Angaben aufweist, die in einer Programmiersprache oder Maschinenvorschrift geschrieben sind, die numerische Instruktionen aufweist, die durch ein geeignetes Ausführungssystem so wie einen Prozessor in einem Computersystem oder einem anderen System erkennbar sind. Die Maschinenvorschrift kann von der Quellvorschrift umgewandelt werden. Wenn in Hardware ausgeführt, kann jeder Block einen Schaltkreis oder eine Anzahl von miteinander verbundenen Schaltkreisen darstellen, um die vorgegebene(n) logische(n) Funktion(en) umzusetzen. Dementsprechend kann ein computerlesbares Medium (das nicht flüchtig oder berührbar ist) solche Instruktionen speichern, die dazu eingerichtet sind, eine Verarbeitungsvorrichtung dazu zu veranlassen, Abläufe wie hierin beschrieben durchzuführen. Der Fachmann wird verstehen, dass der Hardwareansatz im Feld programmierbare Gatteranordnungen (field programmable gate arrays, FPGA)), Mikrocontroller und dergleichen einschließt.
  • Im Allgemeinen ist Elektronik heute sehr komplex und dynamisch, wo es eine sehr unklare Linie, zwischen dem gibt was Software und was Hardware ist, gibt. Zum Beispiel wird Software eine Art von unterstützender Hardware zur Speicherung von Informationen verlangt und im Grunde wird jede Softwareinstruktion auf einiger Hardware in dem MCU-Kern angewiesen sein, die das erwartete Ergebnis der Instruktionen zurückgibt. Es ist auch möglich, das Gegenteil zu behaupten, weil die Gestaltung der Hardware auf einige Software ist und Dokumente angewiesen ist, um die Hardware, die zu erzeugen ist, zu beschreiben. Es ist auch möglich, Hardware zu haben, die von der Zeichnung an unveränderlich ist, für die es nicht möglich sein wird, diese ohne große Schwierigkeiten zu modifizieren, bis zu Hardware-Gatter-Anordnungs-Vorrichtungen, wo die Basishardware fest ist, es aber möglich sein wird, die Hardwarefunktionen am Ende durch Verwendung von verschiedenen Verbindungen der internen Basisstruktur zu modifizieren. Die am meisten flexible Lösung, die heutzutage verfügbar ist, ist das oben erwähnte FPGA, welche Geräte nicht vor der Lieferung fertiggestellt werden müssen. Stattdessen ist es möglich, die internen Verbindungen zwischen den Basisstrukturen herzustellen, wenn es in dem Produkt eingebaut ist. Die Verbindungen in dem FPGA werden durch Setzen von programmierbaren Werten auf bestimmte Werte hergestellt, in einem binären System wird er auf 0 oder 1 gesetzt. Die am meisten übliche Lösung, ist eine RAM-Technologie zu verwenden, um das Verbindungsmuster zu speichern. Der Nachteil einer solchen Lösung ist, dass die Vorrichtung die Verbindung verlieren wird, wenn die Leistungszufuhr unterbrochen ist, und es wird notwendig sein, das Gerät jedes Mal, wenn die Einheit Leistung empfängt, wieder zu konfigurieren. Der Vorteil einer Konfiguration in einem SRAM ist, dass es möglich sein wird, das Gerät jederzeit wieder zu programmieren. Manche neueren Geräte stellen sogar die Möglichkeiten zur Verfügung, nur einen Teil des Geräts wieder zu programmieren. Manche Geräte verwenden Flash-Speicher, um die Verbindungen in dem FPGA zu konfigurieren. Der Vorteil damit ist die Möglichkeit, ein funktionsfähiges Gerät zu haben sobald die Leistung stabil ist. Der Nachteil ist, dass es in den meisten Fällen verglichen mit einem RAM längere Zeit dauern wird, einen Flash-Speicher zu programmieren. Manche älteren Geräte verwenden eine Sicherungstechnologie, um das FPGA zu programmieren. Der Nachteil einer solchen Lösung ist, dass wenn man das Gerät in der Einheit einmal programmiert hat, es unmöglich ist, die Verbindungen in der Zukunft zu ändern. Dies ist nicht 100% richtig, da die Verbindungen in den meisten Fällen zu Beginn den Binärwert 1 oder 0 haben und man diese von dem Vorgabewert ändern kann, aber man kann diese nicht wieder zurückschalten.
  • Verschiedene Wege der Umsetzung des zweiten Protokolls innerhalb eines CAN-Protokolls unter Verwendung von Hardware- und Softwarekomponenten sind möglich. In einem Ansatz weist das Senden und Empfangen von Daten zwei unabhängige Prozesse mit zwei verschiedenen lokalen Taktgebern mit Ausnahme von Arbitrierung auf, die eine Mischung von Senden und Empfangen zur selben Zeit ist. Der Sender platziert ein Bit nacheinander in den Kommunikationsdraht. Die Länge jedes Bits ist als eine Anzahl von lokalen Taktgeberzyklen definiert. In den meisten Fällen hat jedes gesendete Bit dieselbe Länge in lokalen Taktgeberzyklen, aber das Protokoll kann eine Mischung von verschiedenen Bits mit verschiedenen Längen in den lokalen Taktgeberzyklen unterbringen. In einem Beispiel kann das zweite Protokoll zwei verschiedene Bitlängen verwenden, aber zusätzliche Bitlängen sind möglich. Jedes gesendete Bit wird im Allgemeinen wenigstens einen von zwei verschiedenen Pegeln aufweisen, aber mehr Pegel sind möglich. Der Pegel jedes Bits wird durch das Protokoll festgelegt. Manche festen und andere Bits werden von dem Dateninhalt abhängen, beispielsweise könnte eine digitale 1 als ein Bit 0 und ein zweites Bit 1 gesendet sein, verglichen mit einer digitalen 0 gesendet als ein Bit 1 und ein zweites Bit 0, wobei solch ein Muster Manchester-Kodierung genannt wird. Der Sender wird einen Strom von Bits beginnend mit dem ersten Bit und endend mit dem letzten Bit, das in dem Protokoll eingeschlossen ist, das die Nachricht bildet, senden. Die Zeit zwischen Nachrichten wird Leerlaufbus (idle bus) genannt und könnte ein fester Pegel oder ein Muster von verschiedenen Pegeln sein, die einen untätigen Kommunikationsbus anzeigen.
  • In diesem Beispiel bleibt der Empfänger bei der Dekodierung des Leerlaufmusters auf dem Kommunikationsdraht im Allgemeinen im Leerlauf. Der Beginn einer Nachricht wird ein Muster sein, das verschieden von dem Leerlaufmuster ist und dieses Muster schließt eine Flanke (ein Umschalten von einem Pegel auf einen anderen Pegel) ein. Das Protokoll legt fest, wie diese Flanke zu dem Ort des Abtastpunkts in jedem Bit in Beziehung ist, das in Einheiten von lokalen Taktgebereinheiten folgt. Wenn der Empfängertaktgeber dasselbe Tempo wie der Sendertaktgeber hat, wird der Empfänger jedes Bit entlang der Nachricht korrekt abtasten. Praktisch gesprochen ist es schwierig bis unmöglich, zwei Taktgeber zu haben, die dasselbe Tempo über unendliche Zeit haben. Entsprechend verwendet ein System entweder ein Taktgeber, der gut genug ist, den Abtastpunkt innerhalb der Nachricht zu halten oder die Nachrichten sind ausgelegt, kurz genug zu sein, um sicherzustellen, dass der Taktgeber nicht zu viel über die Nachricht hinweg abweicht. Keine Lösung ist ideal, da oftmals verfügbare Taktgeber nicht genau genug sind oder Nachrichten zu kurz werden können. Um dieses Problem zu lösen, kann das Protokoll bestimmte Flanken festlegen, die verwendet werden, um den Abtastpunkt einzustellen. Normalerweise werden die Flanken als eine Pegelverschiebung zwischen zwei Bits festgelegt. Wenn solche wohldefinierten Flanken zu früh oder zu spät auftreten, kann der Empfänger in der Lage sein, den Ort des Abtastpunktes relativ zu solchen Kanten einzustellen, um die Abtastung in den folgenden Bits besser positioniert zu bekommen, bis es eine neue Flanke gibt, die für die nächste Korrektur verwendet werden kann. Während der Arbitrierung sollte ein Modul das Senden von Bits gemäß dem Empfang von Flanken wie von dem Protokoll festgelegt einstellen. Die Präzision der Taktgeber ist gegeben um wie viel der Abtastpunkt sich in der Zeit verändern kann und immer noch innerhalb des korrekten Bits abtasten kann, zusammen mit wie oft und wieviel der Abtastpunkt durch die Protokollregeln korrigiert werden wird.
  • Sich 12 zuwendend wird eine spezifische Umsetzung der Verwendung eines zweiten Protokolls innerhalb eines CAN-Protokolls beschrieben werden. Im Gegensatz zu den oben beschriebenen spezifischen Umsetzungen, bei denen eine einzige Verarbeitungsvorrichtung sowohl die Nachrichten gemäß dem ersten Protokoll als auch dem zweiten Protokoll in einer kombinierten CAN/Zweite-Protokoll-Nachricht vorbereiten und senden (und empfangen) würde, können zwei oder mehr Verarbeitungsvorrichtungen parallel arbeiten, um verschiedene Teile der zusammengesetzten Nachricht zu behandeln. Dieser Aspekt kann skalierbar sein, wo verschiedene Verarbeitungsvorrichtungen mit der Behandlung spezifischer Bitquanten oder Teilen einer gegebenen gesendeten oder empfangenen Nachricht beauftragt werden.
  • Im Einzelnen schließt in dem Beispiel gemäß 12 eine Kommunikationsvorrichtungseinrichtung 1500 einen Kommunikationsanschluss 1510 ein, der dazu eingerichtet ist, mit einem Steuerungsnetzwerk 1511 verbunden zu sein. Eine Verarbeitungsvorrichtung für die Kommunikationsvorrichtungseinrichtung schließt eine erste Verarbeitungsvorrichtung 1500 ein, die dazu eingerichtet ist, die Kommunikationsvorrichtungseinrichtung zur CAN-Kommunikationsarbitrierung zu steuern und die Kommunikation des CAN-Nachrichtenpakets zu steuern. Die Verarbeitungsvorrichtung schließt auch wenigstens eine zweite Verarbeitungsvorrichtung 1505 und 1507 ein, die dazu eingerichtet sind, die Kommunikation wenigstens eines Teils der zusätzlichen Information über wenigstens eines der Bitquanten verschieden von den festgelegten Bitquanten zu steuern. In dem veranschaulichten Beispiel schließt die wenigstens eine zweite Verarbeitungsvorrichtung gesonderte Verarbeitungsvorrichtungen 1505 und 1507 ein, die jeweils dazu eingerichtet sind, die Kommunikation wenigstens eines Teils der zusätzlichen Information über ein anderes der Bitquanten verschieden von den festgelegten Bitquanten zu steuern. Mehr oder weniger Verarbeitungsvorrichtungen können so hinzugefügt werden und verschiedene Verarbeitungsvorrichtungen können verschiedene Mengen oder spezifische Bitquanten zur Analyse oder Erzeugung zugewiesen haben.
  • In solch einem Ansatz ist der Kommunikationsanschluss 1510 wirksam mit der ersten Verarbeitungsvorrichtung 1500 verbunden, um das CAN-Nachrichtenpaket über das Steuerungsnetzwerk 1511 zu senden und mit der wenigstens einen zweiten Verarbeitungsvorrichtung 1505, um zusätzliche Information über das Steuerungsnetzwerk 1511 zu senden. Außerdem ist der Kommunikationsanschluss 1510 dazu eingerichtet, mit dem Steuerungsnetzwerk 1511 verbunden zu sein, um CAN-Nachrichtenpakete zu empfangen, die über das Steuerungsnetzwerk 1511 übertragen werden, und wirksam verbunden zu sein, um das empfangene CAN-Nachrichtenpaket der ersten Verarbeitungsvorrichtung 1503 zum Lesen der CAN-Nachrichtendaten zur Verfügung zu stellen und das empfangene CAN-Nachrichtenpaket der wenigstens einen zweiten Verarbeitungsvorrichtung 1505, 1507 zum Lesen der zusätzlichen Information in dem CAN-Nachrichtenpaket zur Verfügung zu stellen. In dem veranschaulichten Beispiel schließt der Kommunikationsanschluss 1510 gesonderte Empfangs(Buspegelindikator)- 1513 und Sende-Teile 1515 ein, obwohl andere Konfigurationen, die diese Aspekte im Wesentlichen zusammen kombinieren, möglich sind.
  • 12 veranschaulicht ferner einen beispielhaften Ansatz in Richtung Implementierung eines präziseren Taktgebers der Vorrichtung, um die Fähigkeit zu bewirken, zweite Daten, die innerhalb individueller Bits einer Standard CAN-Nachricht eingebettet sind, zu lesen und. In diesem Beispiel ist ein Zeitereignisgenerator 1520 wirksam mit wenigstens zwei Registern 1532 und 1632 verbunden. Der Zeitereignisgenerator 1520 erzeugt Zeitticks mit einer spezifischen Rate. Die Register 1532 und 1632 sind Teil gesonderter Zeitzähler 1530 und 1630. Ein erstes Register 1532 der wenigstens zwei Register zählt die Ticks, die von dem Zeitereignisgenerator 1520 empfangen wurden und als Antwort auf ein Zählen einer ersten Anzahl von Ticks ein erstes Auslösesignal beim Ausgang 1533 auszugeben und zurückzusetzen. Ein zweites Register 1632 der wenigstens zwei Register zählt Ticks erhalten von dem Zeitereignisgenerator und als Antwort auf das Zählen einer zweiten Anzahl von Ticks zum Ausgeben eines zweiten Auslösesignals bei einem Ausgang 1633 und setzt zurück.
  • Das erste Register 1532 stellt das erste Auslösesignal der ersten Verarbeitungsvorrichtung 1503 zur Verfügung, wobei das erste Auslösesignal zu einer Abtastzeit für das CAN-Nachrichtenpaket korrespondiert. Das zweite Register 1632 stellt das zweite Auslösesignal wenigstens einer der wenigstens einen zweiten Verarbeitungsvorrichtung 1505 zur Verfügung, wobei das zweite Auslösesignal mit einer Abtastzeit für die zusätzliche Information, die innerhalb des CAN-Nachrichtenpakets gesendet ist, korrespondiert. Auf diese Weise helfen die Register 1532 und 1632 der Verarbeitungsvorrichtung, zu verfolgen, wann Spannungssignale in einem empfangenen Paket abgetastet werden sollen oder wann ein Signal in einem gesendeten Paket zur Verfügung gestellt werden soll. Manchmal müssen diese Register zurückgesetzt werden, um eine Resynchronisierung der Kommunikationsvorrichtungseinrichtung mit anderen Kommunikationsmodulen des Steuerungsnetzwerks 1511 zu bewirken. In einem Ansatz bemerkt eine Zurücksetzungsvorrichtung 1536 den Beginn eines Rahmens und ist verbunden, die wenigstens zwei Register 1532 und 1534 als Antwort auf das Bemerken des Beginns des Rahmens zurückzusetzen. In dem veranschaulichten Ansatz empfängt die Zurücksetzungsvorrichtung 1536, 1636 eines jeden der entsprechenden Zeitzähler 1530 und 1630 ein Ausgangssignal, bereitgestellt von dem CAN-Bit-Erkennungsmodul 1550 als Antwort auf das Bemerken eines Signals des Beginns des Rahmens auf dem Steuerungsnetzwerk 1511. Obwohl die verschiedenen Register, die dazu verwendet werden, Zeitereignisse für verschiedene Abtastungsraten bereitzustellen, in verschiedenen Modulen 1530 und 1630 veranschaulicht sind, müssen die Register in einer gegebenen Umsetzung nicht so gesondert sein.
  • Man kann das obige Beispiel im Zusammenhang mit dem Konzept von Zeit verstehen. Die häufigsten Kommunikationsprotokolle basieren auf der physikalischen Sekunde zum Darstellen eines Bits. Beispielsweise legt das Standard-CAN-Protokoll seine Bitzeit fest als „Busverwaltungsfunktionen, die innerhalb des Bitzeitrahmens ausgeführt werden, so wie CAN-Knotensynchronisierungsverhalten, Netzwerkübertragungsverzögerungskompensation und Abtastpunktpositionierung sollen wie durch die programmierbare Bitzeitlogik des CAN-Protokoll-IC-Bausteins gegeben sein. a) Nominale Bitrate (BR) gibt die Anzahl von Bits pro Sekunde an, die in Abwesenheit von Resynchronisierung durch einen idealen Sender gesendet werden. b) Nominale Bitzeit, tB = 1/BR.“
  • Andererseits kann Zeit als Zählen von Bitquanten beschrieben werden, die durch einen Oszillator erzeugt werden. Beispielsweise definiert das Standard-CAN-Protokoll das „Programmieren von Bitzeit“ als „Programmieren von Bitzeit soll unter Verwendung der folgenden Zeitperiode durchgeführt werden ... a) Zeitquantum Das Zeitquantum soll eine feste Zeiteinheit abgeleitet von der Oszillatorperiode sein.“
  • Zeit als solche wird üblicherweise in Kommunikationsprotokollen nicht festgelegt, obwohl manche Kommunikationsprotokolle als Ereignis ausgelöst oder Zeit ausgelöst festgelegt sind. Diese Offenbarung kann mit Blick auf drei verschiedene Zeitkonzepte verstanden werden. Das erste ist NZeit (natürliche Zeit), die das Zeitkonzept ist, das jeder jeden Tag erfährt, ohne dass jemand weiß, was es ist. Durch NZeit kann man Ereignisse in einer Dimension mit Vergangenheit und Zukunft aufnehmen und organisieren, und man kann zwischen vorhersagbaren und unvorhersagbaren Ereignissen unterscheiden. NZeit hat unter normalen Bedingungen keinen Startpunkt und ist kontinuierlich, unumkehrbar, nicht aufzuhalten und endlos.
  • Das zweite ist PZeit (physikalische Zeit), was ein wissenschaftliches Konzept der Zeit in den Gesetzen der Physik zur Beschreibung von NZeit ist, wenn Natur moduliert wird. PZeit ist kontinuierlich und umkehrbar, d.h. jedes Modell, das auf den Gesetzen der Physik basiert, kann in der Zeit umkehrbar ausgeführt werden. Ein Modell wird dann die Bedingungen an jedem Punkt von dem Beginn und dem Ende und umgekehrt gemäß dem Modell zeigen. Die PZeit hat eine Basiseinheit, die Sekunde (s), die eine von sieben Basiseinheiten in dem internationalen Einheitensystem (SI) ist.
  • Das dritte ist LZeit (lokale Zeit oder logische Zeit), welche durch einen Zeittickerzeuger erzeugt wird und von einem Zeitzähler gemessen wird. Eine Kombination der beiden bildet eine LZeituhr (LTC). Eine LTC ist die Zeitquelle einer LZeitdomäne (LTD). Zwei oder mehr LTDs können miteinander korreliert und/oder mit einer von diesen oder alternativ mit einer virtuellen LTD synchronisiert sein. Der Hauptzweck dieses Konzepts der Zeit ist einen Fluss von Ereignissen, Zuständen und Übergängen von Zuständen untereinander als auch mit sowohl PZeit– als auch NZeit-Domänen zu koordinieren.
  • Manche LZeitmerkmale schließen ein, begrenzt zu sein mit einem definierten Beginn und Ende. LZeit kann angehalten und erneut gestartet werden. LZeit kann auch mit PZeit und NZeit in einer nicht/linearen Weise in Beziehung gesetzt werden. Entsprechend können die Zeittickgeneratoren unabhängig von PZeit und NZeit sein.
  • Eine LTD ist typischerweise durch eine LTC festgelegt, wobei die entsprechenden LTCs von mehreren LTDs denselben Zeittickgenerator aufweisen können. Vielfache LTDs können durch Referenzereignisse (RE) synchronisiert werden.
  • Wieder bezugnehmend auf das Beispiel der 12 schließt der Zeitereignisgenerator 1520 einen Oszillator 1522 ein, der ein Zeiteignisse 1524 an einen TC 1526 ausgibt. Der CAN-Standard legt ein „Zeitquantum“ wie folgt fest: „Das Zeitquantum soll eine feste Zeiteinheit abgeleitet von der Oszillatorperiode sein. Es soll ein programmierbarer Vorteiler mit ganzzeiligen Werten existieren, die wenigstens von eins (1) bis zweiunddreißig (32) reichen. Beginnend mit dem Mindestzeitquantum soll das Zeitquantum eine Länge von: Zeitquantum = m·Mindestzeitquantum haben, wobei m der Wert des Vorteilers ist.“
  • Um das Zeitquantum festzulegen, schließt das TC 1526 ein Register 1528 ein, das die Grenze für die LZeit setzt. Jedes Mal, wenn das Register 1528 seine festgelegte Grenze erreicht, überträgt es ein Zeitquantenereignis bei seinem Ausgang 1529 und setzt sich selbst zurück. Das Ergebnis ist ein Strom von Zeittickereignissen, d.h. ein Strom von Zeitquanten 1525. Der Zeitereignisgenerator 1520 legt eine LTD fest, die programmierbar ist, sich von 1 bis 32 Zeitereignissen zu erstrecken, die Zeitquanten gemäß dem CAN-Protokoll erzeugen können. Die LTD oder der Zeitereignisgenerator 1520 handeln als ein Zeittickgenerator und speisen den Zeitzähler 1530 mit Zeitereignissen. Der Zeitereignisgenerator 1520 und der Zeitzähler 1530 bilden einen anderen Lokalzeitzähler 1539.
  • Der Zeitzähler 1530 schließt einen Ereigniseingang 1537 ein, der den Zähler 1530 als Antwort auf das Empfangen eines Ereignisses zurücksetzt. Das erste Register 1532 ist in diesem Beispiel von 2 bis 17 programmierbar und überträgt ein Ereignis an dem Ausgang 1533, wenn das erste Register 1532 den programmierten Wert erreicht. Das zweite Register 1534 ist von 1 bis 8 programmierbar und überträgt ein Ereignis an dem Ausgang 1535 und setzt den Zähler 1530 zurück, wenn der Zähler 1530 den programmierten Wert des ersten Registers 1532 plus den programmierten Wert des zweiten Registers 1534 erreicht. Gemäß der CAN-Spezifikation besteht ein CAN-Bit mindestens aus einem Sync_Seg-Zeitquantum, einem Prop_Seg-Zeitquantum, einem Phase_Seg 1-Zeitquantum und einem Phase_Seg 2-Zeitquantum, d.h. vier Zeitquanten und die maximale Länge ist Sync_Seg + 24 Zeitquanten. Das erste Register 1532 kann programmiert werden, Sync_Seg plus Prop_Seg plus Phase_Seg 1 abzudecken, und das zweite Register 1534 kann programmiert sein, Phase_Seg 2 abzudecken. Der lokale Zeitzähler 1539 wird die Anzahl von Zeitereignisse zählen, die ein CAN-Bit repräsentieren und ein Ereignis nach Phase_Seg 1 zu erzeugen und ein anderes nach Phase_Seg 2.
  • Solch ein lokaler Zeitzähler 1539 ist in der Lage, einen CAN-Bit-Erkenner 1550 genauso wie einen Buspegelindikator 1513 zu unterstützen. In dem veranschaulichten Beispiel hat der Buspegelindikator 1513 einen Ereigniseingang 1514, der Zeitereignisse 1525 von dem Zeitereignisgenerator 1520 empfängt. Als Antwort auf das Empfangen eines Zeitereignisses von dem Zeitereignisgenerator 1520 tastet der Buspegelindikator 1513 die Busspannung auf dem CAN-Bussteuerungsnetzwerk 1511 ab. Wenn eine Spannung detektiert wird, überträgt der Buspegelindikator 1513 ein Spannungsereignissignal 1516 auf einen Ereigniseingangsanschluss 1551 des Biterkenners 1550. Wenn keine Spannung festgestellt wird, sendet der Buspegelindikator 1513 ein Keine-Spannung-Ereignissignal 1517 an einen Ereigniseingangsanschluss 1552 bei dem CAN-Bit-Erkenner 114. In dieser Anordnung empfängt der CAN-Bit-Erkenner 1550 entweder ein Spannungssignal oder ein Keine-Spannung-Ereignissignal bei jedem Zeittickereignis erzeugt durch den Zeitereignisgenerator 1520.
  • Der CAN-Biterkenner 1550 schließt eine Ereignislogikvorrichtung 1553 und einen Ereigniszähler 1554 ein, der die Zeitereignisse 1525 zählt. Die Ereignislogikvorrichtung 1553 ist wirksam an den Eingangsanschluss 1555 gekoppelt, verbunden, um erste Registerereignisse von dem ersten Register 1532 des Zeitzählers 1530 zu empfangen. Wenn unter der CAN-Spezifikation betrieben wird, wird der Wert eines Bits am Ende des Phase_Seg 1 entschieden, in welchem Fall der erste Register 1532 einen Wert speichert, der ein erstes Registerereignis erzeugt, das zu einem erwarteten Abtastpunktereignis für ein gegebenes CAN-Bit korrespondiert. Das erste Registerereignis löst den CAN-Bit-Erkenner 1550 aus, um eine Spannung auf dem Steuerungsnetzwerk 1511 bei dem erwarteten Abtastpunktereignis zu detektieren, wobei als Antwort darauf die Ereignislogikvorrichtung 1553 ein rezessives Bitereignis (korrespondierend zu einer logischen „Eins“) bei dem Ausgang 1556 als Antwort auf das Bestimmen eines Keine-Spannung-Ereignisses von dem Buspegeldetektor 1513 ausgibt. Wenn ein Spannungsereignis bei dem Abtastpunkt erkannt wird, gibt die Ereignislogikvorrichtung 1553 ein dominantes Bitereignis (korrespondierend zu einer logischen „Null“) bei dem Ausgang 1557 aus, es sei denn, das dominante Bitereignis ist ein Beginn-des-Rahmens-Ereignis. Ein Beginn-des-Rahmens-Ereignis ereignet sich bei dem Erkennen einer logischen „Null“ nach dem Erkennen von zehn oder mehr aufeinanderfolgenden rezessiven Bits (logisch „Eins“).
  • Die Ereignislogikvorrichtung 1553 wird auch ausgelöst, um eine Spannung als Antwort auf das Empfangen eines Beginn-des-Rahmens-Registerereignissignals von einem Beginndes-Rahmens-Register 1534 zu detektieren, welches in diesem Beispiel wirksam mit dem ersten Register 1532 verbunden und programmiert ist, zu beginnen, Zeitereignisse als Antwort auf das Empfangen eines Ereignisses von dem ersten Register 1532 zu zählen. Nach Erreichen der Zeitereigniszahl, die in das Beginn-des-Rahmens-Register 1534 einprogrammiert ist, gibt es ein Beginn-des-Rahmens-Prüfereignis über einen Ausgang 1535 an die Ereignislogikvorrichtung 1553 aus, um die Ereignislogikvorrichtung 1553 auszulösen, auf eine Spannung zu prüfen, die zu dem Beginn des Rahmens für ein Bit korrespondiert, dass auf eine Abtastpunktauslesung folgt, die durch das erste Register 1532 ausgelöst ist.
  • Allgemein gesprochen ist der Ereignislogikdetektor 1553 dazu eingerichtet, nicht nur die rezessiven, dominanten und SOF-Bits durch Vergleichen von Spannungsereignissen, Abtastpunktereignisse und Anzahl von Zeittickereignisse gezählt von dem Zähler 1554 zu erkennen. Als Antwort auf das Erkennen eines Beginn-des-Rahmens-Ereignisses erzeugt der Ereignislogikdetektor 1553 ein SOF-Bit-Ereignissignal bei dem Ausgang 1558. Diese Signale von den Ausgängen 1556 und 1557 und 1558 werden von einer Protokolllogikeinheit (PLU) 1560 empfangen, die dazu eingerichtet ist, den Bitstrom empfangen über das Steuerungsnetzwerk 1511 gemäß dem CAN-Protokoll zu dekodieren.
  • Das Folgende beschreibt eine beispielhafte Weise, um das Beispiel von 12 zu programmieren, ein Standard-CAN-Bit, wie das in 13 veranschaulichte, abzutasten. Diese zu empfangenen Daten sind durch einen Spannungspegel 1601 auf dem Steuerungsnetzwerk 1511 festgelegt. Das Standard-CAN-Bit hat hier die folgenden Teile: das Sync_Seg 1602 ist ein Zeitquantum, das Prop_Seg 1604 ist acht Zeitquanten, das Phase_Seg 1 1606 ist drei Zeitquanten und das Phase_Seg 2 1608 ist drei Zeitquanten, der Vorteiler ist auf sechszehn gesetzt, so dass der Oszillator sechszehn Mindestzeitquanten erzeugt, um ein einziges Bit aufzubauen. Entsprechend ist das Register 1528 auf sechszehn gesetzt. Das erste Register 1532 ist auf zwölf gesetzt und das Beginn-des-Rahmens-Register 1534 ist auf drei gesetzt. Mit diesen Einstellungen kann der CAN-Bit Erkenner 114 eine Resynchronisierung als Antwort auf das Detektieren eines harten Sync_Seg durch Melden an die Zurücksetzungsvorrichtungen 1536 und 1636 auslösen. Der lokale Zeitzähler 1539 legt die Zeitquanten des Bits fest und das erste Register zählt bis zu dem zwölften Bitquantum, um ein Abtasten bei dem Abtastpunkt auszulösen, und das Beginn-des-Rahmens-Register zählt bis zu dem dritten Bitquantum nach dem Abtastpunkt, um ein Abtasten des Beginn des Rahmens für ein erwartetes nächste Bit auszulösen. Auf diese Weise ausgelöst leitet der Ereignislogikdetektor 1553 CAN-Bits detektiert auf dem Steuerungsnetzwerk 1511 an die CAN-Protokolleinheit 1560.
  • Genauer nimmt die Empfangsvorrichtung 1500, wenn es die anfängliche fallende Flanke empfängt, an, dass es ein Beginn-des-Rahmens(SOF)-Bit 1652 einer Nachricht ist und führt eine harte Synchronisation (Hard Sync) aus, das heißt, setzt den Zähler der Zeitquanten zurück. In dem Beispiel, in dem eine harte Synchronisierung in einem Bit nach einem Beginn einer neuen Nachricht auftritt, kann auf die SOF 1652 als ein Start eines Bits Bezug genommen werden. Nach zwölf Zeitquanten wird der Abtastpunkt 1607 erreicht, der zwischen dem ersten Zeitquantum 1653 des Phase_Seg 1 1606 und vor dem ersten Zeitquantum 1654 des Phase_Seg 2 1608 liegt. Der Spannungspegel wird bei dem Abtastpunkt 1607 oder SP abgetastet. Wenn der Spannungspegel, wie mit den Spannungslinien 1601 veranschaulicht, dominant ist, dann wird das Bit als ein SOF dekodiert, wobei die fallende Flanke bei dem Zeitquantum 1652 als ein Beginn eines neuen CAN-Bits berücksichtigt wird. Wenn stattdessen ein rezessiver Pegel bei dem Abtastpunkt, wie mit den Spannungslinien 1660, 1670 und 1680 veranschaulicht ist, detektiert wird und das Bit wird ignoriert. Beispielsweise veranschaulicht die Spannungslinie 1670 einen Spannungspegel, der auf einen dominanten Pegel fällt, aber auf einen rezessiven Pegel nach 11 Zeitquanten steigt und wieder auf einem dominanten Pegel nach 12 Zeitquanten fällt und wieder auf einen rezessiven Pegel nach 15 Zeitquanten steigt. Da der Empfänger einen rezessiven Pegel bei dem Abtastpunkt (SP) abtastet, wird das Bit als ein SOF-Bit ignoriert.
  • Mit anderen Worten veranschaulicht 13 einen anderen Fall, indem, weil ein CAN-Empfänger nur zweimal innerhalb eines Standard-CAN-Bits abtastet, während dieser jede Spannungspegelverschiebungen dazwischen ignoriert, diese ignorierten Teile des Bits für Bitübertragungen eines anderen Protokolls bei einer höheren Bitrate verwendet werden könnten. In einem Beispiel kann das zweite Protokoll Bytes auf einem Leerlauf-CAN-Bus, wie mit der Spannungslinie 1680 veranschaulicht, übertragen. Hier benutzt die Übertragungsvorrichtung dieselben Zeitquanten wie das CAN-System, wobei jedes Zeitquantum repräsentiert ein Bit. Ein Quantum, das als rezessiver Pegel abgetastet ist, wird als eine 1 dekodiert und ein Zeitquantum, das als ein dominanter Pegel abgetastet ist, wird als eine 0 dekodiert. Das Protokoll hat dieselbe Definition eines Leerlaufbusses, die CAN aber definiert das Sync_Seg eines CAN-SOF als einen Beginn eines Rahmens (SOF). Nach einem SOF kommt ein erster Datenrahmen von elf Bits gefolgt von zwei rezessiven Bits bei dem Standard-CAN-Abtastpunkt. Die zwei rezessiven Bits werden durch Standard-CAN-Module als rezessiv dekodiert und lösen daher die Standard-CAN-Module aus, die anfängliche fallende Kante bei dem SOF zu ignorieren. Entsprechend berücksichtigen die Standard-CAN-Module den Steuerungsnetzwerkbus als im Leerlauf. Ein zweiter Datenrahmen von zwei Bits folgt auf die zwei rezessiven Bits gefolgt von einem Ende-des-Rahmens-(EOF)-Bit bei einem rezessiven Pegel. Die ersten vier Bits in dem ersten Datenrahmen sind ein Bytezähler, d.h. 15 aufeinanderfolgende Bytes können als eine Nachricht übertragen werden. Die Spannungsnachverfolgung 1680 veranschaulicht dann die Spannungspegelverschiebungen einer Übertragung gemäß dem beispielhaften zweiten oder eingebetteten Protokoll. Nach dem SOF folgt auf die Bytezählerbinärzahl 0100 (dezimal 4) die Binärzahl 11001000 binär (dezimal 200). Unmittelbar danach zeigt das nächste SOF 1685 einen Beginn einer nächsten Abfolge an, die mit einem Bytezählerwert von 0101 binär (dezimal 5) beginnt.
  • Auf diese Weise kann das Beginn-des-Rahmens-Bit für eine für eine Standard-CAN-Kommunikation verwendet werden, eine Resynchronisierung von Modulen zwischen Abfolgen von zweiten oder eingebetteten höherfrequenten Protokollen zu erzwingen, um Übertragungsfehler, die durch mangelhaft synchronisierte Zeitereignisgeneratoren für verschiedene Module auf dem Steuerungsnetzwerk verursacht werden, zu reduzieren. Allgemein gesprochen kann in einer Situation, in der eine zweite Nachricht innerhalb eines Nachrichtenpakets gemäß einem ersten Protokoll eingebettet ist und eine Empfangsvorrichtung eine Position des Abtastpunkts innerhalb des empfangenen ersten Protokollbits als Antwort auf das Erkennen einer Übergangsflanke innerhalb eines festgelegten Teils des empfangenen Bits des ersten Protokolls einstellt, eine Vorrichtung eine Reihe von Bits gemäß dem ersten Protokoll mit der Übergangsflanke übertragen, um Bewegung des Abtastpunkts für eine empfangene Kommunikationsvorrichtung zu bewirken, um zusätzlichen Raum innerhalb eines Bits eines ersten Protokolls zu schaffen, in das die zweite Nachricht unter Verwendung des zweiten Protokolls eingebettet werden soll. In solch einem Ansatz, in dem das CAN-Protokoll das erste Protokoll ist, würden die Oszillatorgenauigkeitsprobleme über die Module hinweg reduziert sein, da alle Taktgeber der Module bei jedem Bit resynchronisiert würden, wenn das Sync_Seg, das auf ein rezessives Bit folgt, auf einen dominanten Pegel gesetzt würde. Die Resynchronisierungs- und Synchronisierungssprungbreite (SJW)-Regeln von CAN würden nicht benötigt werden. Module in dem Steuerungsnetzwerk, die dazu eingerichtet sind, nur die Standard-CAN-Nachrichten zu verstehen, werden innerhalb Phase_Seg 1 und Phase_Seg 2 dreizehn Bitquanten nach der letzten Resynchronisierung abtasten. Da das beispielhafte neue Protokoll ein dominantes Sync_Seg erzeugt, werden solche ursprünglichen CAN-Steuerungen wenigstens bei jedem zweiten rezessiven Bit resynchronisieren, aber nur, bei dem sechsten Bit nach fünf aufeinanderfolgenden dominanten Bits. Trotzdem ist diese Resynchronisierung zweimal so früh wie die 13-Bit-Anforderung und erhält dadurch die verschiedenen Module ausreichend synchronisiert.
  • Zudem können die ursprünglichen CAN-Module dazu gebracht werden, ihre Abtastpunkte zu bewegen, um mehr Raum innerhalb eines CAN-Bits zu erlauben, um Information gemäß dem zweiten Protokoll zu übertragen. Beispielsweise kann die Verarbeitungsvorrichtung eines Moduls des zweiten Protokolls die Abfolge von Bits gemäß dem ersten Protokoll mit der Übergangsflanke durch Senden einer Reihe von rezessiven Bits, in denen ein Sync_Seg-Bitquantum eines folgenden Bits dominant ist, um die Übergangsflanken zur Verfügung zu stellen, um die Bewegung des Abtastpunkts zu bewirken, übertragen. Die Verarbeitungsvorrichtung des Moduls des zweiten Protokolls kann auch die zweite Nachricht unter Verwendung des zweiten Protokolls wenigstens in Teilen innerhalb von Bits übertragen, die unter Verwendung des CAN-Protokolls in Teilen der Bits verschiedenen von dem Sync_Seg-Bitquantum und des Abtastpunktes, wie etwa unter Verwendung von Prop_Seg-Teilen des CAN-Nachrichtenpakets, übertragen werden. Die Übergangsflanke muss nicht die volle Breite eines Sync_Seg haben, wie innerhalb eines CAN-Protokolls festgelegt; stattdessen kann die Flanke die Länge haben, die ausreichend für die Erfassung durch die Module in dem Kommunikationsnetzwerk ist.
  • Um Spannungspegel bei jedem Zeitquantum zu detektieren, kann das zweite Register 1630 mit bestimmten Anzahlen programmiert sein, um entweder den Ereignislogikdetektor 1553 oder eine zweite Verarbeitungsvorrichtung 1505 auszulösen, Spannungen bei anderen Bitquanten als solchen, die für den typischen CAN-Standard festgelegt sind, abzutasten. Auf diese Weise können Bits bei Bitraten verschiedenen von der Dekodierung von Spannungspegeln auf dem Bus gemäß der CAN-Spezifikation zusätzlich zu anderen eingebetteten Protokollen unter Verwendung der LZeitdomäne abgetastet werden. Das System erfordert nicht die Verwendung von physikalischer Zeit oder natürlicher Zeit, in der die Verbindung zur NZeit über den Oszillator 1522 besteht. Der Oszillator 1522 könnte durch irgendetwas ersetzt werden, das einen Strom von Ereignissen erzeugt, wie etwa ein magnetischer Aufnehmer, der die Spitzen eines sich drehenden Zahnrads erfasst. Entsprechend könnte ein CAN-Netzwerk gebaut werden, in dem alle ECUs mit dem magnetischen Aufnehmer verbunden sind, und CAN-Nachrichten würden korrekt kodiert und dekodiert werden, aber die Bitrate pro Sekunde würde mit den Umdrehungen pro Minute des Zahnrads variieren.
  • Besondere Überlegungen zur Umsetzung in einem Alt-CAN-Kommunikationssystem
  • In Alt-CAN-Systemen tritt Resynchronisierung von Modulen auf, wo ein dominantes Signal in dem Synchronisierungssegment einem rezessiven Bit folgt. Dies ist die Regel für alle Alt-CAN-Systeme, um den Abtastpunkt besser relativ zu dieser Flanke einzustellen. Im Allgemeinen lassen Alt-CAN-Systeme einen Raum, um den Abtastpunkt offen, um den Empfang des Signals zu bestätigen, da Fehler in der Zeitbestimmung zu einem Empfang des Signals um einige Zeit vor oder nach dem Abtastpunkt führen können. Durch Bewirken solch einer Resynchronisierung einige Male wird ein Modul, das unter Verwendung des oben beschriebenen zweiten Protokolls kommuniziert, die Position des Abtastpunkt des CAN-Altsystems bestätigt haben, viel genauer zu sein als die übliche Zeit, zugeteilt vor oder nach dem Alt-CAN-Abtastpunkt unter Verwendung von SJW-Regeln, wodurch zusätzlicher Raum innerhalb eines Alt-CAN-Bits für Zweites-Protokoll-Kommunikationen sichergestellt wird. Wenn beispielsweise mehr Flanken, die eine Resynchronisierung von Alt-CAN-Systemmodulen bewirken, erzeugt werden, kann der Abtastpunkt zu der theoretisch richtigen Position zwischen Phasen-Segment 1 und Phasen-Segment 2 bewegt werden, so dass nahezu die Gesamtheit des Phasen-Segment 1 und Phasen-Segment 2 für Daten des zweiten Protokolls verfügbar ist. Kurz gesagt werden alle rezessiven Bits gefolgt von diesem dominanten Sync_Seg den Abtastpunkt für die Alt-CAN-Systeme einstellen und dieses Merkmal kann von einem zweiten Kommunikationsprotokollmodul verwendet werden, zusätzlichen Raum innerhalb eines Alt-CAN-Bits für Kommunikationen mit dem zweiten Protokoll zu schaffen.
  • Arbitrierungsversatz und Systemsynchronisierung
  • Während der Arbitrierung kann die Zeitdifferenz zwischen zwei beliebigen Knoten so groß wie eine Ausbreitungsverzögerung sein, wenn die zwei Einheiten bei der Kabellängengrenze sind. Um die Arbitrierungssituation zu veranschaulichen, zeigt 14 Einheit A, die um eine Ausbreitungsverzögerung früher als Einheit B überträgt. Der schlimmste Fall tritt auf, wenn Einheit B die Arbitrierung gewinnt. Die zwei Einheiten treten in diesem Fall in die unidirektionale Phase mit dem maximalen Versatz ein und das ganze Ausbreitungssegment wird für die Kompensation verwendet. In einem Szenario des schlechtesten Falls könnte die CAN-Rahmendatenabfolge ein Minimum an Synchronisierunginformation ergeben, ergebend eine dominante Flanke alle zehn Bits, gerade den zulässigen Frequenzversatz kompensierend. In diesem Fall wird die Größe des Teils des Rahmens, der für den eingebetteten Rahmen des zweiten Protokolls verwendet werden kann, durch die Ausbreitungsverzögerung begrenzt, wenn Arbitrierung auftritt.
  • Die Synchronisierungsverzögerung, die durch die Arbitrierung erzeugt wird, kann um einen Faktor zwei reduziert werden, wenn die Einheiten die Übertragung zur selben absoluten Zeit beginnen. Ein Synchronisierungspuls ist ein dominanter Puls, der während Busleerlaufperioden gesendet wird, der kurz genug ist, nicht als ein Beginn eines Rahmens wahrgenommen zu werden. 14 zeigt zwei Kommunikationseinheiten, die eingerichtet sind, gemäß einem CAN-EF-Ansatz zu übertragen, die einen Synchronisierungspuls übertragen. Beide Einheiten beginnen bei derselben absoluten Zeit. Die fallenden Flanken der Einheiten A oder B werden alle Einheiten auf dem Bus innerhalb einer Ausbreitungsverzögerung erreichen. An dem Ende der Arbitrierung wird die maximale Differenz die Summe einer Ausbreitungsverzögerung und der Differenz sein, hinzugefügt durch Unsicherheit in dem Taktgeber einer gegebenen Einheit.
  • Der vor dem Beginn der Übertragung gesendete Synchronisierungspuls stellt sicher, dass alle CAN-Einheiten mit den Einheiten A und B synchronisiert sein werden, und dass die Arbitrierung mit synchronisierten Einheiten beginnt.
  • Um Synchronisierung zu erreichen, kann eine Zeitwahlreferenz verwendet werden. Zum Beispiel kann eine der Einheiten (A oder B) bestimmt werden, als eine Zeitwahlreferenz zu handeln und Zeitreferenzpulse zu übertragen. Um absolute Zeit zu erreichen, muss die Ausbreitungsverzögerung von der Referenzeinheit zu allen anderen Einheiten abgeschätzt werden.
  • Beispiel: Eingebetteter Rahmen im Ausbreitungssegment, keine Arbitrierung
  • Wenn die CAN-Synchronisierung erfüllt ist, kann das Ausbreitungssegment für eingebettete Daten verwendet werden. Keine Flanke, die in diesem eingebetteten Rahmen erzeugt wird, sollte in der Lage sein, die CAN-Rahmensynchronisierung zu ändern.
  • Die Definition des Phasesegments 1, veranschaulicht in 15, wird in der unidirektionalen Phase verändert. Die Abtastung bei dem empfangenden Ende ist innerhalb des Bereichs SJW + SP (Abtastpunkt) vor und SJW nach dem Übergang von dem Phasesegment 1 zu dem Phasesegment 2. Das Abtastpunkt-SP-Feld ist die Unsicherheit, die durch das Sync-Quantum hinzugefügt wird. Abhängig von der kürzeren maximalen Synchronisierungsverzögerung kann das SJW so niedrig wie 60% der vollen CAN-SJW sein. Die sich ergebende Phasesegment-1-Anforderung wird dann sein tps1 = 1 + 0,6SJW, während der unidirektionalen Phase (siehe 16).
  • Die unten stehende Ungleichung wird verwendet, um brauchbare Werte für SJW zu berechnen, so dass die Taktgebertoleranzanforderung nicht durch SJW bestimmt wird, wobei PS die Phasesegmentlänge und BT die Bitzeit ist, üblicherweise ausgedrückt als eine Anzahl von Quanten. SJW > 20BT·PS / 2(13BT – PS)
  • Das Phasesegment 2 wird angenommen, gleich dem Phasesegment 1 zu sein und die Verarbeitungsverzögerung wird angenommen, kleiner als oder gleich PS1 zu sein.
  • Das erforderliche Phasesegment 1 während des eingebetteten Formatteils des Rahmens ist dann tps1 = 1 + 6BT·PS / 13BT – PS
  • Die erforderliche Phasesegmentlänge kann auch in Bezug auf eine bekannte Taktgebertoleranz ausgedrückt werden, wobei df der Frequenzversatz für den Taktgeber ist: SJW > 20BT·df tps1 = 1 + 12BT·df
  • Die von dem nominalen Abtastpunkt benötigte Spanne nähert sich einem Zeitquantum, indem sich die Tastgebertoleranz verbessert.
  • Synchronisierung nach Arbitrierung
  • Unter Verwendung des in dem vorigen Abschnitt beschriebenen Verfahrens können dominante Flanken in rezessiven Bitabfolgen erzeugt werden. Wenn stattdessen eine Abfolge von rezessiven Bits gesendet wird, werden fünf von sechs Bits eine Synchronisierungsflanke wie in 17 veranschaulicht haben. Jede Synchronisierungsflanke wird den Versatz um SJW Zeitquanten reduzieren, jedoch wird für jedes Bit aufgrund des Frequenzversatzes zwischen Einheiten etwas Zeitversatz hinzugefügt. Die durchschnittliche Verbesserung in Anzahl an Zeitquanten für ein Bit ist dann wenigstens: 5 / 6SJW – 2·df·BT
  • Die Länge des eingebetteten Rahmens könnte dann mit der Rate der dominanten Flanken erhöht werden und das Maximum des eingebetteten Datenkanals könnte verwendet werden.
  • Wenn die Taktgebertoleranz nicht bekannt ist, kann der schlechteste Fall aus dem SJW berechnet werden und ausgedrückt werden als: 5 / 6SJW – 1 / 10SJW = 11SJW / 15
  • Das Verfahren baut auf einer Zeitspanne auf, die groß genug ist, um das eingebettete Synchronisierungssegment zu senden.
  • Der eingebettete Rahmen ist durch die folgenden Parameter charakterisiert:
    Name Beschreibung
    tsync Anzahl an Taktgeberzyklen verwendet für das Synchronisierungssegment. Max (tbit, tQuanten)
    tbit Anzahl der Taktgeberzyklen verwendet für ein Bit
    tsp Anzahl an Taktgeberzyklen von Beginn des Bits zum Abtastpunkt
    tcan Anzahl an Taktgeberzyklen verwendet für den verbleibenden CAN-Rahmen (wenigstens Phasesegment 1 und 2)
    nbits Anzahl an eingebetteten Bits in einem CAN-Bit
    tesjw Eingebettete Synchronisierungssprungbreite
    sjwmin Minimale CAN-Synchronisierungssprungbreite verwendet von irgendeiner Einheit auf dem Bus.
    tAbweichen Die Anzahl an Taktgeberzyklen von Synchronisierungsabweichen zwischen Einheiten pro CAN-Bit
    tmmin Minimale Zeitwahlspanne nach Arbitrierung.
  • Die folgende Beziehung zwischen CAN- und Eingebetteter-Rahmen-zeitwahl (veranschaulicht in 18) gilt auch.
    Figure DE112015004473T5_0002
  • Nur Synchronisierungsflanken, die um tesjw früh oder spät sind, werden für die Synchronisierung verwendet werden. Die tsync-Länge wird eingestellt, so dass diese bei dem empfangenen Wert wenigstens ein Zeitquantum ist, selbst in dem Szenario des schlechtesten Falls eines Dominant-rezessiv-dominant-Übergangs. Ein kurzer rezessiver Puls wird durch die CAN-Buscharakteristiken mit aktivem dominantem Treiben und Heraufziehen für rezessive Werte gekürzt. Das Empfängerfiltern könnte auch Verkürzen von Pulsen detektiert von dem Empfänger einführen.
  • Die Zeitwahlspanne ist der verbleibende Teil des Ausbreitungssegments, wenn die Ausbreitungsverzögerung berücksichtigt wurde. Das Szenario in 19 ist ein möglicher Zustand nach Arbitrierung. Jede Veränderung von Daten nach dem Teil innerhalb der Zeitwahlspanne könnte als ein CAN-Fehler interpretiert werden.
  • Bitstopfen
  • Die Zeitwahl in dem eingebetteten Feld erfordert eine präzisere Zeitwahl als das Abtasten in dem CAN-Bit. Diese Zeitwahlverbesserung kann ohne jede Protokollkosten erreicht werden, wenn das Synchronisierungssegmentbit immer als der invertierte Wert der letzten CAN-Abtastung, wie in 20 veranschaulicht, übertragen wird. Dieses Verfahren wird die erforderliche Flanke folgend einer rezessiven Abtastung ergeben. Eine Synchronisierungsflanke wird spätestens in einer CAN-Bitperiode folgend einem dominanten CAN-Bit erzeugt werden. Ein Stopfbit mit falscher Polarität wird einen Stopffehler erzeugen.
  • Die Oszillatortoleranzanforderung für den schlechtesten Fall für den eingebetteten Rahmen ist durch die folgende Gleichung gegeben:
    Figure DE112015004473T5_0003
  • Um den obigen Ansatz umzusetzen, werden einige andere Parameter bestimmt. Zuerst wird die Anzahl von CAN-Bits seit der letzten Synchronisierungsflanke gezählt. Der Zähler wird für eine vor dem RTR-Bit detektierte Synchronisierungsflanke auf Null gesetzt, da eine Synchronisierungsflanke in dem RTR-Bit nur von dem Sender erzeugt werden kann, wird die Synchronisierungsflanke als eine Zeitwahlversatzkorrektur gezählt. Der Wert des Zählers ist die Anzahl von Taktgeberabweichenbits (ncdb). Die ncdb ist proportional zu den im schlechtesten Fall akkumulierten Taktgeberversatz.
  • Als nächstes wird die Anzahl dominanter Synchronisierungsflanken (nse) ausgehend von und einschließend das RTR-Bit gezählt. Jede Synchronisierungsflanke vergrößert die Zeitspanne, um wenigstens die minimale tsjw.
  • Die ganze Zeitspanne, tmtot, die verwendet werden kann, um eingebettete Daten zu senden, wird unter Verwendung der folgenden Gleichung berechnet: tmtot = tmmin + nse·sjwmin – ncdb·sjwmin/10 wobei sjwmin/10 an die Stelle des echten maximalen Taktgeberabweichens gesetzt werden kann.
  • Während tmtot weniger als tsync ist, werden CAN-Bits mit abwechselnden rezessiven und dominanten Werten übertragen, um den erforderlichen Platz zu gewinnen. Wenn tmtot größer als oder gleich tsync ist, wird tsync von tmtot substrahiert und das Synchronisierungssegment wird gesendet.
  • Während tmtot größer als oder gleich tbit ist, wird tbit von tmtot substrahiert und ein eingebettetes Bit wird gesendet. Ein neues tmtot wird für jedes neue Bit berechnet und der Entscheidungsprozess wird erneut begonnen, bis alle eingebetteten Bits in eine Bitperiode passen.
  • Wenn Synchronisierung erreicht wird, kann das CAN-Bitfeld des CAN-EF-Bits verwendet werden, Paketdateninformationen zu tragen. Die Auffüllbits werden mit Diagnosenachrichtbits gesendet, bis die Anzahl von CAN-Bits, gegeben durch den DLC gesendet wird. Der Datenteil wird immer von einem eingebetteten DLC (EDLC) begonnen und mit einer eingebetteten CRC (ECRC) beendet.
  • Dieses Verfahren wird präzise sein und wird sich dynamisch an die Daten auf dem Bus anpassen. Auch berücksichtigt dieses Verfahren die tatsächliche Anforderung des Phasesegments, die weniger sein kann als die SJW abhängig von der Zeit seit der letzten Synchronisierung.
  • Eingebettetes Rahmenformat
  • Der vorangehende Abschnitt hat beschrieben, wie die CAN-EF-Datenbits in ein gewöhnliches CAN-Bit eingebettet werden sollen. In diesem Abschnitt wird das Rahmenformat für den eingebetteten Datenteil mit Bezug auf die 28 und 29 beschrieben. Der eingebettete CAN-Rahmen wird als eine Abfolge verwendend die verfügbaren eingebetteten Plätze und CAN-Bitplätze gesendet. In der Praxis hängt der tatsächliche Beginn des eingebetteten Rahmens von den EF-Busparametern ab.
  • Der Beginn eines eingebetteten Rahmens (ESOF) wird auf dieselbe Weise wie ein CAN-FD-Rahmen durch Senden eines rezessiven R0- oder R1-Bits signalisiert. Das Beginn-des-Rahmens-Feld wird verwendet, um einen eingebetteten CAN-Rahmen von einem üblichen CAN-Rahmen und von der Resynchronisierungsphase eines eingebetteten Rahmens zu unterscheiden. Eine CAN-EF-Einheit, die ein rezessives R0/R1 empfängt, wird eine harte Synchronisierung bei der nächsten rezessiv auf dominanten Flanke durchführen. Wenn die Synchronisierungsspanne groß genug ist, wird die Synchronisierung dem ESOF-Bit unmittelbar folgend ausgeführt. Ein rezessives ESOF signalisiert, dass der Rahmen ein CAN-EF-Rahmen ist, aber der echte Beginn des eingebetteten Rahmens wird verzögert, bis ausreichende Synchronisierung erreicht ist. Die Synchronisierungsanforderung steht sowohl mit CAN-Einheiten als auch mit CAN-EF-Einheiten in Beziehung.
  • Der Kennwert der eingebetteten Datenlänge (EDLC) ist die ersten 6 Bits nach dem ESOF. Der EDLC erlaubt eingebettete Pakete von 0–64 Bytes an Daten. Der EDLC zählt sowohl eingebettete Bits als auch Datenbits gesendet mit der CAN-Bit-Zeitwahl. Der eingebettete Datenrahmen (EDATA) wird unter Verwendung jedes verfügbaren Bits während und nach Synchronisierung und bis zu und einschließlich dem CRC-Begrenzer gesendet. Wenn kein Paket an Daten mehr übrig ist, gesendet zu werden, werden Diagnosebits als Auffüllung gesendet.
  • 23 veranschaulicht 80 CAN-EF-Bits, gesendet mit zwei CAN-Bytes. Die Erhöhungsphase zu Beginn ist Teil der Gestaltung, so viele Bits wie möglich während der Arbitrierungsversatzkompensationsperiode zu verwenden.
  • Die eingebettete CRC (ECRC) wird am Ende des Rahmens auf dieselbe Weise wie die Daten-Bits übertragen. Die ECRC wird zu einer Zeit in dem Rahmen begonnen, über die sich Sender und Empfänger einigen können und die ECRC sollte vollständig spätestens in dem CRC-Begrenzer übertragen werden.
  • In der eingebetteten Phase wird die CAN-Senderlogik synchron zu dem Rahmen bleiben, wird aber nicht auf den Bus übertragen und sie wird keine Busfehler detektieren. Der eingebettete Sender und Empfänger werden asynchron betrieben, um die rx/tx-Schleifenverzögerung zu kompensieren. Die übertragenen Daten werden in einem FIFO-Speicher zum Vergleich mit den erhaltenen Daten gespeichert, um Busfehler zu detektieren.
  • In diesem Beispiel werden nicht alle verfügbaren eingebetteten Rahmenbits maximal genutzt, stattdessen wurde das Protokoll für die Einfachheit der Umsetzung eng an dem CAN-Protokoll gehalten. Die CAN-Stopfbits und die zusätzlich eingebetteten Felder in DLC-, DATA-, CRC- und CRC-Begrenzer-CAN-Felder können auch für Datenübertragung verwendet werden. In manchen Konfigurationen könnte eine ziemlich große Anzahl von zusätzlichen Bits für Daten verwendet werden. Das Auftreten von Stopfbits ist nicht einfach vorhersagbar und die maximale Anzahl von Bits in diesem Kanal wird abhängig von den übermittelten Daten variieren. Zusätzlich könnte der Kanal für das Prinzip „größte Bemühungen“ (best effort) für Diagnosenachrichten verwendet werden, einschließlich bspw. Fehler-Zähler-Werte, Passivfehlermarkierungszeichen, verwendete Busparameter, Senderidentifizierung, Senderfähigkeiten und Störungsanzahl. Wenn jeder Nachricht eine Nachrichtenkennung vorangestellt wird, kann die EF-Einheit dem Kanal für das Prinzip „größte Bemühung“ (best effort) auf Nachfrage oder auf Änderung Diagnosenachrichten hinzufügen.
  • Der gegenwärtige Vorschlag verwendet die CAN-Bits für Datenübertragung. Wenn der CAN-Bitwert verwendet wird, das Stopfen des Datenfelds zu steuern, können alternative Rahmenformate gesendet werden. Beispiele schließen das Senden einer minimalen Anzahl an Stopfbits in dem CAN-Kanal und das Senden einer maximalen Anzahl an Stopfbits in dem CAN-Kanal ein, in denen die Anzahl der Stopfbits in der CRC noch schwer zu kontrollieren ist.
  • Eine andere optionale Konfiguration besteht darin, Bestätigungen nur für Identifizierungen (IDs) zu senden, die mit einem Filter übereinstimmen. Dieser Ansatz kann sicherstellen, dass eine gültige Einheit das Paket erhalten hat.
  • Reiner EF-Modus für höhere Geschwindigkeit.
  • Um in der Lage zu sein, eine bessere Leistung zu erzeugen, kann das CAN-EF-Protokoll in einer Umgebung angeordnet werden, in der CAN-Kompatibilitätsbeschränkungen aufgegeben werden können. Verschiedene Eigenschaften können in dieser Umgebung geändert werden, um ein effizienteres Protokoll zu erhalten, darunter beispielsweise eins oder mehrere von: Aufweisen einer variablen ID-Länge, Kurzhalten von Nachrichten hoher Priorität, Entfernen des IDE-Bits, Entfernen der Entfernte-Übertragung-Anforderung, aufweisen eines Hochgeschwindigkeitsdatenfelds und Verkürzen des Endes-des-Rahmen-Feldes. Einige der wichtigen Eigenschaften von CAN bleiben erhalten, darunter: Arbitrierung, Fehlerrahmen und ein angepasster Ansatz zu einem Rahmensynchronisierungsverfahren.
  • Um ein effizienteres Bitformat zu erreichen, werden die Stopfbits weiterhin mit Arbitrierungsbitintervallen eingesetzt, aber es werden keine Lücken in die Daten eingesetzt (tcan = 0), um CAN-Kompatibilität zu erreichen. Die tcan wird erwartet, größer zu sein als tbit, weil ein Resynchronisierungsintervall von CAN des schlechtesten Falls 6 CAN-Bits ist, verglichen mit den weniger als 2 CAN-Bits für das eingebettete Protokoll. Die zusätzliche Spanne kann möglicherweise mehr als einem eingebetteten Bit erlauben, den CAN-Bit-zugeteilten Teil der Bitperiode zu ersetzen. Der Synchronisierungsversatz nach Arbitrierung wird mit einer harten Synchronisierung behandelt und als eine Folge können eingebettete Plätze sofort verwendet werden.
  • Ein System mit relativ guten Taktgebertoleranzen kann die Abstände zwischen Stopfbits durch Erhöhen der Anzahl von eingebetteten Bits vergrößern. Dieses Verfahren wird den Platz angegliedert durch die Stopfbits verringern, so dass der Datenstrom entweder als ein Fehlerrahmen oder ein Busleerlauf fehlinterpretiert werden kann und Fehlerrahmen werden nicht detektiert werden, weil kein Stopfbit überschrieben wird. In dieser Situation muss ein alternativer Mechanismus für Fehlerrahmen und Rahmensynchronisation verwendet werden.
  • Einer der größeren Nachteile von der CAN-Kompatibilität ist die Länge des ID-Feldes. Dies kann durch Einführung eines ID-Feldes variabler Länge verbessert werden. Den kürzeren Identitäten werden die Nachrichten hoher Priorität und die häufigsten Nachrichten zugewiesen.
  • Ein neues Rahmenformat kann verwendet werden, welches in einigen Fällen wesentlich kürzer ist. Der neue Rahmen wird in der nachstehenden Tabelle dargestellt.
    Arbitrierung 1 2·id_sz 2 1 1 1
    hohe Geschwindigkeit 8 8·nbytes 24 3
    SOF ID ANSCHLUSS DLC Daten CRC CRC-Begrenz. ACK ACK-Begrenz.
  • Das ID-Feld, das eine variable Länge nbits = 2k aufweist, wobei k zwischen 0 und 15 ist. Das ANSCHLUSS-Feld ist immer zwei dominante Bits. Eine DLC mit acht Bits erlaubt 0 bis 255 Bytes Daten in einem Paket. Wenn die Größe des ID-Feldes auf 0 gesetzt ist und keine Daten in dem Datenfeld übertragen werden, werden die minimale Paketgröße von 6 Arbitrierungsbits und 35 Hochgeschwindigkeitsbits gesendet.
  • Das ID-Feld wird unter Verwendung von 2-Bit-Symbolen kodiert. 00 wird als das Beendigungssymbol verwendet und kann nur als das letzte Symbol der ID verwendet werden. 01, 10, 11 werden in der Arbitrierung verwendet. Der kürzeste Kennwert gewinnt. Die höchstmögliche Prioritäts-ID ist 00. Die folgenden sind vier Beispieleinheits-IDs:
    Einheit a: 01 10 10 0*1 11 11 00
    Einheit b: 01 10 1*1 00
    Einheit c: *11 11 11 11 11 11 11 11 00
    Einheit d: 01 10 10 00
  • Der Stern markiert den Punkt, an dem eine Einheit Arbitrierung verliert und ein Empfänger wird. Einheit d gewinnt die Arbitrierung nach 8 Bits und beendet die Abfolge. Mit diesem Ansatz werden 25% aller möglichen ID-Werte verloren, aber die verlorenen ID-Nummern könnten durch Hinzufügen eines zusätzlichen ID-Bits kompensiert werden. Wenn die Datenpaketbeschränkungen von CAN-FD behalten werden, verwendet das neue Protokoll 23 Arbitrierungsbits weniger als CAN-FD und ein HS-Bit mehr in diesem Fall. Die Differenz schrumpft für längere ID-Felder.
  • Das Verhältnis von Stopfbits zwischen den Protokollen ist datenabhängig. Das eingebettete Format verwendet ein Stopfbit für jedes CAN-Bit. Wenn 8 eingebettete Bits für jedes CAN-Bit verwendet werden, hat das eingebettete Format ein Stopfbit für alle 8 Bits. Das CAN-FD-Protokoll verwendet ein Stopfbit alle fünf Bits, wenn die Daten alles Einsen oder alles Nullen sind. Der Überlastungsrahmen (Overload frame) kann nicht mit nur einem ACK-Begrenzer-Bit verwendet werden, ein Unterbrechungsbit sollte hinzugefügt werden, wenn diese Funktionalität gebraucht wird. Wenigstens ein Bit ist für Protokollerweiterung reserviert. Reservierte Bits sollten gestaltet sein, zukunftskompatibel zu sein. Wenn ein neueres Protokoll als unterstützt detektiert wird, soll die Einheit in den Zuhörmodus (listen mode) eintreten und auf rückwärtskompatible Synchronisierungssequenzen warten.
  • Das Ende des Rahmens-Feld hat mehrere Funktionen. Zunächst kann das EOF-Feld eine Einheit detektieren, die das DLC-Feld fehlinterpretiert hat und immer noch Daten empfängt oder eine Einheit, die Daten empfängt, wenn das EOF gesendet wird. Das EOF-Feld ist lange genug, um einen Stopffehler zu erzeugen. Das EOF-Feld kann es auch neuen Einheiten erlauben, mit dem Bus zu resynchronisieren.
  • Eine Einheit, die versucht mit der Buskommunikation zu synchronisieren, wird zwei Fälle zu behandeln haben. Zunächst wird der Leerlaufbus durch eine Periode von 11 rezessiven Bits, wie in CAN erkannt. Zweitens, muss wenn der Bus aktiv ist, das CRC-Begrenzer-Bit detektiert werden. Der CRC-Begrenzer ist gestaltet, Resynchronisierung möglich zu machen. Eine Einheit, die nach Synchronisierung sucht, wird Bitsynchronisation auf die fallende Flanke setzen. Der CRC-Begrenzer wird lange genug rezessiv gehalten, um eine Stopfbitverletzung, wie in 24 veranschaulicht, zu erzeugen. Die Kombination des dominanten Hochgeschwindigkeitsbits und der Stopfverletzung ist eine einzigartige Kombination für das CRC-Begrenzer-Feld. Im Fall eines detektierten tatsächlichen Stopffehlers, würden die Bitpositionen bei sowohl ACK als auch ACK-Begrenzer überschrieben werden und die Einheit würde auf das Ende des Fehlerrahmens resynchronisieren.
  • Die Stopfverletzung fester Form in dem CRC-Begrenzerfeld wird als ein Ende-der-Daten-Feldmarkierer verwendet. Eine Einheit, die das DLC fehlinterpretiert und die immer noch Daten sendet, wird einen Stopffehler an diesem Punkt erzeugen. Eine Einheit, die den CRC-Begrenzer erreicht, wenn der Sender noch in dem Datenfeld ist, wird einen Fehler fester Form erzeugen.
  • Der Fehlerrahmen wird als sechs Symbole bei einer CAN-Bitrate gesendet und arbeitet wie in CAN, mit der Ausnahme des Fehlerrahmenbegrenzers. Der Fehlerrahmenbegrenzer wird entfernt. Der Fehlerrahmen sollte durch eine Abfolge beendet werden, die dem CRC-Begrenzer, ACK-Platz und ACK-Begrenzer entspricht, aber ohne die erste dominante Flanke. Diese Abfolge stellt eine Resynchronisierungsflanke in dem ACK-Platz bereit, was eine gute Synchronisierung für einen Beginn eines Rahmens dem ACK-Begrenzer unmittelbar folgend ergibt. Das RTR-Feld eines üblichen CAN-Protokolls wird durch einen ID-Maskenanpassungsantwortpuffer ersetzt.
  • Leerlaufbit-Kommunikationsprotokoll
  • Während des Busleerlaufs wird jede fallende Flanke von den CAN-Empfängern verwendet werden, eine harte Synchronisierung durchzuführen. Wenn das dominante Busereignis, das die Flanke verursacht, kürzer als das Ausbreitungssegment des Bits ist, wird es nicht als ein Beginn-eines-Rahmens-Bit berücksichtigt werden. Ein zweckbestimmtes Koordinatormodul kann verwendet werden, Informationen in den Perioden zwischen der dominanten Flanke und dem Ende des Ausbreitungssegments zu senden. Mit ausreichender Bandbreite und -länge des Ausbreitungssegments könnten mehrere Bits an Information während dieser Periode gesendet werden. Der zweckbestimmte Koordinator kann jedes Modul (wie etwa solche, die hierin beschrieben sind, mit einer Verarbeitungsvorrichtung, die dazu eingerichtet ist, seine Aktivität zu steuern und mit einem Kommunikationsanschluss, der dazu eingerichtet ist, Kommunikation in dem Netzwerk zu erlauben) in dem Kommunikationsnetzwerk sein, aber vorzugsweise wird es bei einer physikalischen Mitte des Busses positioniert werden, um die längste Distanz zu einem Kommunikationsmodul auf dem Netzwerk zu verkürzen. Der zweckbestimmte Koordinator könnte das Modul sein, das bei der Mitte eines gegebenen Busses 701 angeordnet ist.
  • Der zweckbestimmte Koordinator könnte in einer oder mehrerer der folgenden Weisen verwendet werden: um Auto-Baud zu unterstützen, um Busparametereinstellungen zu verteilen, so dass jede Einheit, die sich mit dem Bus verbindet, unmittelbar die richtigen Busparametereinstellungen erhalten kann, um Zeit zu verteilen, um Ablaufplanungsinformation zu senden (setzen gegenwärtiger Minimalpriorität, Maske und dergleichen), um ein Signal zu senden, um Diagnoseinformationen zu nehmen und zu senden, um Bussignalqualitätsmessungen zu machen und Messungen zu verzögern. Wenn allen Knoten eine eindeutige Identität zugeordnet ist, könnte der Koordinator jeweils einen Knoten ansprechen. Die Leerlaufbitkommunikation würde ein nicht-aufdringlicher Kanal für das „Beste-Bemühung“(best effort)-Prinzip sein. Der Koordinator könnte Anfragen an einen bestimmten Knoten senden und diesem Knoten könnte es dann erlaubt sein, eine Antwort zu senden. Eine Beginn-des-Rahmen-Bedingung würde den Rahmen verzögern, bis das Paket gesendet wurde und der Bus in seinem Leerlaufzustand zurückkehrt. Selbst wenn der Koordinator eine Lösung ist, die nicht als ein allgemeines Kommunikationskonzept akzeptierbar ist, könnte das Konzept als Teil einer Testausrüstung nützlich sein.
  • In anderer Anwendung ist es während Arbitrierung möglich, dass der erste Abtastpunkt sich in das Ausbreitungssegment bewegen wird; um den Ausbreitungspunkt zu bewegen, können rezessive und dominante Flanken in dem Synchronisierungssegment übertragen werden, um sicherzustellen, dass solche Empfänger, die den Abtastpunkt in dem Ausbreitungssegment haben, den Abtastpunkt aus dem Ausbreitungssegment bewegen, wie durch die CAN-Protokollregeln vorgegeben. Wenn der zweckbestimmte Koordinierer in der Mitte des physikalischen Mediums platziert wird, wird das Senden eines dominanten Synchronisierungssegments während der Leerlaufphase die Einheiten zwingen, das CAN-Protokoll zu nutzen, um mit diesem Muster synchronisiert zu sein. Bei Vorliegen dieser Synchronisierung beginnen alle Einheiten innerhalb von 25% des Ausbreitungssegments zu senden. Dieses Verhalten kann in zwei verschiedenen Weisen verwendet werden. Es kann verwendet werden, um sicherzustellen, dass der Abtastpunkt des ersten Protokolls sich niemals mehr als 50% in das Ausbreitungssegment bewegen wird, wodurch der Beginn des Sendens eingebetteter Bits in wenigstens 50% des Ausbreitungssegments ermöglicht wird, ohne auf eine Anzahl von Flanken zu warten, um den ersten Abtastpunkt aus dem Segment zu bewegen. Die andere Verwendung wird sein, die Kabellänge in einem Kommunikationssystem unter Verwendung des ersten Protokolls zu vergrößern. Wenn die Leerlaufphasensynchronisierung von einer Einheit in der Mitte des physikalischen Mediums gesendet wird, wird es möglich sein, doppelte Verzögerung zwischen den äußersten Einheiten in dem CAN-System verglichen mit den Regeln zu haben, die normalerweise für ein System gemäß dem ersten Protokoll (CAN) gelten. In diesem System wird es immer noch möglich sein, eingebettete Bits wie beschrieben zu verwenden; allerdings ist es mit der erweiterten Kabellänge nach einer Arbitrierung möglich, dass der Abtastpunkt des ersten Protokolls in jedem Teil des Ausbreitungssegments sein kann, wodurch eine Anzahl von Rezessiv- auf Dominant-Flanken in dem Synchronisierungssegment benötigt wird, um sicherzustellen, dass die eingebetteten Bits des zweiten Protokolls nicht den Abtastpunkt des ersten Protokolls treffen werden.
  • Das Leerlaufbitkommunikationsverfahren kann verwendet werden, die Busparameter des schlechtesten Falls verwendet auf dem Bus zu bestimmen. Das Absuchen wird durch einen dominanten Synchronisierungspuls begonnen, der verlängert wird, bis ein Fehlerrahmen detektiert wird. Der Fehlerrahmen wird erzeugt, wenn der dominante Synchronisierungspuls bei einem der Abtastpunkte des Empfängers abgetastet wird. Die Länge des Synchronisierungspulses ist eine Messung des maximal nutzbaren Ausbreitungssegments auf dem Bus.
  • 25 veranschaulicht zwei Bitperioden mit anfänglichen Synchronisierungpulsen. Das tatsächliche Abtasten wird innerhalb einer Unsicherheitsperiode um den nominalen Abtastpunkt geschehen. Die gegenwärtige Einstellung wird bestimmt werden, wenn der Synchronisierungspuls lange genug ist, um in das Abtastintervall zu reichen. In diesem Moment wird ein fälschlicher Beginn des Rahmens detektiert und ein Fehlerrahmen wird erzeugt.
  • Das Leerlaufbitkommunikationsprinzip arbeitet nicht nur während des Leerlaufbusses, sondern in jedem rezessiven Bit unter bestimmten Umständen. Dessen einfachste Verwendung würde eine Synchronisierungspuls-Überlagerung (overlay) sein. Die Synchronisierungspuls-Überlagerung kann verwendet werden, um alle Einheiten auf dem Bus mit einem koordinierenden Synchronisierungspulssender zu synchronisieren. Der Synchronisierungspuls wird in jedem Bitzeitintervall als ein dominanter Puls zu Beginn eines jeden Bits gesendet. Der Synchronisierungspuls muss kurz genug sein, nicht als ein dominantes Bit von irgendeinem Empfänger auf dem Bussegment wahrgenommen zu werden. Das Synchronisierungspulsintervall muss kürzer oder gleich der kürzesten Bitzeit eines jeden Empfängers auf dem Bus sein, um alle Einheiten dazu zu zwingen, mit dem Koordinator synchronisiert zu bleiben. Der Synchronisierungspuls wird auch in der Buslehrlaufperiode gesendet, um sicherzustellen, dass alle Einheiten mit der Synchronisierungseinheit hart synchronisiert sind. Wenn alle der obigen Anforderungen erfüllt sind, werden alle Einheiten auf dem Bus mit dem Koordinator synchronisiert bleiben.
  • Die Vorteile dieses Verfahrens wären, dass die maximale Anzahl von Bitperioden zwischen Synchronisierungsflanken 6-Bit-Perioden wären, verglichen mit den 10-Bit-Perioden eines Standard-CAN-Busses. Die Synchronisierungspulse können auch verwendet werden, um einige Informationen über die Position der Knoten auf dem Bus zu sammeln. Da alle Einheiten mit dem Koordinator synchronisiert gehalten werden, kann der Abstand zwischen dem Koordinator und dem Knoten abgeschätzt werden, wenn die Einheit ein dominantes Bit folgend einem rezessiven Bit überträgt.
  • Die obere Zeitleiste der 26 zeigt den Bus bei dem Empfänger des Koordinators. Der Koordinator empfängt seinen eigenen Synchronisierungspuls, wie er auf dem Bus gesendet wird. Die untere Zeitleiste zeigt die von dem Sender gesendeten Daten. In diesem Fall wird der Sender mit perfekter Synchronisierung mit dem Synchronisierungspuls gezeigt und er wird deshalb das dominante Bit zu der genauen Zeit senden, zu der der Synchronisierungspuls ankommt. Das dominante Bit wird bei dem Koordinator genau zwei Ausbreitungsverzögerungen nach dem Start des Synchronisierungspulses detektiert werden.
  • 27 veranschaulicht die Synchronisierungsunsicherheit, worin die Synchronisierung bei dem Sender innerhalb seines Synchronisierungssegments abweichen wird und die Ausbreitungsverzögerung schließt die Sende-Empfänger-Verzögerungen des Senders ein. Der Synchronisierungsfehler kann mit statistischen Methoden entfernt werden, wenn genügend Abtastungen verfügbar sind, die die Identität des Senders betreffen. Die Sende-Empfänger-Verzögerung wird eine Unsicherheit hinzufügen, die nicht entfernt wird.
  • Der Koordinator kann Nachrichten nach dem Prinzip „beste Bemühung“ (best effort) während der Busleerlaufperioden übertragen. Jedes Bit in der Nachricht wird mit einem Synchronisierungspuls begonnen und der Rest des verfügbaren Ausbreitungssegments kann verwendet werden, um Information zu senden. Die gesendeten Nachrichten werden nicht in die CAN-Buskommunikation eingreifen, sondern die gesendeten Nachrichten selbst werden bei jedem dominanten CAN-Protokollbit zerstört werden. Die Sendedatenüberlagerung wird dieselben Grundeigenschaften wie die Synchronisierungspulsüberlagerung haben mit einem angehängten zusätzlichen Datensegment. Die Länge des Synchronisierungspulses muss lang genug sein, um sicher von jeder CAN-Steuerung auf dem Bussegment detektiert zu werden.
  • Die Sendedatenüberlagerung kann verwendet werden, um ein bidirektionales Protokoll zu unterstützen, wenn ein eindeutiges Adressierungsschema verwendet werden kann. Die Adresse wird in einem oder mehreren Nachrichtenbits gesendet und die Antwort von einer einzigen angesprochenen Einheit folgt nach einer konfigurierbaren Verzögerung. Die eindeutige Adresse könnte möglicherweise die CAN-Identifizierer sein, die in dem System verwendet werden, und nur das Gerät, das für einen bestimmten Identifizierer konfiguriert ist, würde antworten. Eine beispielhafte Nutzung wäre Diagnoseinformation von einer Einheit mit einem bestimmten Identifizierer zu erhalten, der als sich fehlerhaft verhaltend wahrgenommen wurde. 28 zeigt den Koordinator, der eine Leerlaufnachricht mit dem eindeutigen 11-Bit-Identifizierer sendet und die Einheit, die den Identifizierer zeigt, antwortend nach einer ausreichenden Verzögerung. Das Sende- und Antwort-Protokoll kann aus einer Abfolge von Leerlaufbits aufgebaut sein.
  • Auf diese Weise eingerichtet kann auf dem CAN-Protokoll unter Verwendung der Leerlaufbitkommunikation ein vollständiges Protokoll nach dem Prinzip „beste Bemühung“ (best effort) umgesetzt werden. Das Protokoll wird die laufenden CAN-Protokollvorgänge nicht beeinträchtigen und es wird möglicherweise die Buszeitwahl durch zur Verfügungstellen von Synchronisierungsflanken verbessern.
  • Zusätzlich zur Verwendung als eine Leerlaufbus-, Hochgeschwindigkeitskommunikationsmögichkeit kann das eingebettete Format für Diagnose verwendet werden. Beispielsweise kann das Muster, wie oben beschrieben, auch verwendet werden, die maximale Leistungsfähigkeit eines Kommunikationsmediums in einem physikalischen Medium 1511, wie in 12 gesehen, zu prüfen. Es gibt Millionen CAN-Busse, die bereits in Autos, Lastwagen und Maschinen installiert sind, die bestens mit der nominalen Bitrate arbeiten. Die häufigste Bitrate ist zwischen 125 bis 500 kbit/s. Einige sind höher, bis zu 1 Mbit/s und manche sind so niedrig wie 20 kbBit/s. In vielen solchen Systemen ist es möglich eine höhere Bitrate zu nutzen, aber es ist unsicher, wieviel es möglich ist, die Bitrate ohne Probleme zu vergrößern. In CAN-FD wird die Bitratenumschaltung in dem Abtastpunkt durchgeführt, was das Umschalten ein wenig komplexer macht, da es keine Flanke in naher Entfernung von der Position gibt, wo man die Bitratenumschaltung machen kann. Um die Bitratenumschaltung bei derselben in dem Bit in dem CAN-FD-Ansatz zu platzieren, wird die Bitratenumschaltung über fast zwei Bits durchgeführt. Zunächst folgt auf ein rezessives Bit gemäß dem ersten Protokoll ein dominantes Bit. Durch die Abfolge aus einem rezessiven und dann einem dominanten Bit, ergibt sich eine Flanke in dem Synchronisierungssegment. Diese Flanke hat zwei Funktionen. Erstens misst die Flanke die interne Verzögerung von wann die Kante zu dem Teil bezeichnet als 1515 in 12 gesendet wird, bis diese zu der Logik zurück als eine Ausgabe von 1513 in 12 erhalten wird. Wenn diese Verzögerung bekannt ist, wird es möglich sein zu prüfen, dass jedes Bit mit demselben Wert wie auf dem Kommunikationsmedium ausgesendet, empfangen wird. Dies ist erforderlich, um Fehler gemäß dem Protokoll zu detektieren und zu behandeln. Die zweite Verwendung dieser Flanke ist, den Abtastpunkt zu lokalisieren, wo die Vorrichtung von der nominalen Bitrate zu der höheren Bitrate umschaltet. Dieses Umschalten kann nicht in diesem Bit ausgeführt werden, da dieses Bit ein nominales Bit ist, das reserviert ist, in der Zukunft festgelegte Protokolle anzugeben. Das Bit, das diesem reservierten Bit folgt, wird das BRS-Bit (Bitratenumschaltbit) genannt und wenn man den Abtastpunkt in dem nominalen Bit erreicht, gibt es eine Umschaltung auf die höhere Bitrate. Diese Lösung ergibt ein kleines Problem, eine Präzisionsmessung auf flexible Weise zu machen. Zuerst werden fast zwei nominale Bits von der Kante vorüber gehen, bis der Abtastpunkt erreicht wird. Während dieser Zeit weicht die Zeit ab, weil verschiedene Einheiten Taktgeber mit verschiedenem Tempo haben. Die Einheiten auf dem Bus sollten auch ähnliche Zeitquanten haben, da die Zeit, die man erhält, wenn man die Zeitquanten von der Flanke zu dem Abtastpunkt hinzfügt, dieselbe sein muss, um sicherzustellen, dass man die Umschaltung zum selben Zeitpunkt in allen Modulen macht. Ohne einen sehr guten Taktgeber wird es schwierig sein, ein Verhältnis über 20 mal zwischen der nominalen Bitrate und der hohen Bitrate zu haben. In dem Diagnosefall möchten wir eine Präzision so hoch wie möglich erhalten.
  • Durch Umschalten auf das Hoch-Bit bei der Flanke in dem Synchronisierungssegment wird es möglich sein, das Umschalten mit einer Präzision zu machen, die nur durch Zittern in der Kante begrenzt ist und wie schnell die Logik den von der Busleitung empfangenen Pegel abtasten kann. Die Lösung wird auch von der Stelle des Abtastpunktes abhängen. Mit dieser Freiheit wird es möglich sein, die höhere Bitrate unabhängig von der nominalen Bitrate zu setzen. Für den Test wird es möglich sein, die EF-Protokollbits kürzer und kürzer um einen Taktgeberzyklus in jedem Schritt zu machen. In der heutzutage verfügbaren kostengünstigen FPGA-Logik, ist es möglich, einen 100 MHz Taktgeber zu haben und jeder Schritt kann so klein wie 10 Nanosekunden sein. Mit teureren Vorrichtungen wird es möglich sein, Taktgeber nahe an ein Gigahertz zu haben und die Auflösung wird so hoch wie eine Nanosekunde sein. Gleichzeitig ist es durch Phasenverschiebungslogik möglich, acht Mal schneller abzutasten als die Basistaktrate, was heutzutage schon benutzt wird. Das Basismuster ist dasselbe, das in 2 gezeigt ist, wo eine nominale Bitrate für alle Bits außer Bits in dem Teil bezeichnend 108 verwendet wird.
  • Bestätigen der Konsistenz in CRC-Berechnung
  • Für Probleme bezüglich des Bestätigens von Datengenauigkeit in einer empfangenen CAN- oder CAN-FD-Nachricht ist eine Lösung das EOF zu ändern, um es toleranter gegenüber Bitfehlern zu machen. Wenn das EOF-Muster einem Vertrauensniveau von bis zu 6 Standardabweichungen hätte, könnte es einen sehr guten Schutz der CRC-Vergleichsstelle sicherstellen.
  • Das EOF ist eine einfache Sequenz von wenigstens sieben rezessiven Bits. Die einfache Lösung wäre, dieses Muster einfach zu erweitern. Für alle sechs rezessiven Bits würde ein weitere Bitumkehrung gebraucht werden, um ein Datenmuster in ein EOF-Muster umzuwandeln. Mit anderen Worten würde Ihnen ein EOF mit 36 rezessiven Bits einen Hamming-Abstand von sechs geben, was ein sehr guter Schutz ist, da das Umschalten eines dominanten Bits in ein rezessives Bit sehr viel externe Energie erfordert. Das Problem an dieser Lösung ist, dass diese nicht rückwärtskompatibel mit existierenden CAN-Lösungen sein wird und die Verwaltungsdaten (Overhead) in einer CAN-Nachricht mit einem Byte um 60% erhöhen wird.
  • Eine bessere Lösung behält das Basismuster des gegenwärtigen EOF und macht es eindeutig relativ zu jedem anderen Datenmuster innerhalb eines CAN- oder CAN-FD-Nachrichtenpakets. Durch Verwenden der CAN-EF-Lösung, die oben beschrieben ist, werden zusätzliche Bits in das EOF hinzugefügt. Beispielsweise können zusätzliche Bits in das Ausbreitungssegment jedes Bits des EOF hinzugefügt werden. Die zusätzlichen Bits können eindeutig gemacht werden und optional mit Fehlerprüfung geschützt werden, um mit einer hohen Wahrscheinlichkeit zu bewirken, dass dieser Abschnitt weder Daten auf dem Bus, ein Muster verursacht durch Störung noch Daten kombiniert mit Störung ist. Um zu helfen, eine Missdeutung von Daten durch klassische CAN-Module zu vermeiden, könnte diese zusätzliche Information nur zu den sieben bis zwölf rezessiven Bits in dem EOF hinzugefügt werden. Angesichts der Fähigkeit von CAN-EF, eine relativ große Datenmenge innerhalb von Bits vom CAN-Typ einzubetten, stellt dies eine Möglichkeit bereit, einen langen und eindeutigen Identifizierer einzubetten, der in Form eines Datenmusters vorliegen könnte.
  • Da dieser Identifizierer bezogen auf andere existierende Muster auf dem Bus für ein gegebenes Nachrichtenpaketprotokoll eindeutig ist, wird das EOF als ein wahres EOF bestätigt, was indirekt bestätigt, dass das CRC-Feld korrekt bezogen auf dieses EOF angeordnet sein muss. Wenn das CRC auch korrekt ist, muss der Datenteil auch mit einer korrekten Anzahl von Bits korrekt sein. Diese Lösung kann auf klassische CAN-Nachrichtenpakete oder CAN-FD-Nachrichtenpakete angewendet werden. Mit dem oben beschriebenen CAN-EF-Ansatz kann der Abtastpunkt in jedem Bit nachverfolgt werden, um als rezessiv bestätigt zu werden, um das Muster rückwärtskompatibel mit klassischer CAN zu machen, das erwartet, dass alle Bits in dem EOF rezessiv sind. Mit anderen Worten, ist das Muster dass das EOF bestätigt, in dem Ausbreitungssegment angeordnet, so dass es von den klassischen CAN-Einheiten ignoriert wird.
  • Der Fachmann wird erkennen, dass eine breite Vielzahl von Modifikationen, Änderungen und Kombinationen mit Bezug auf die oben beschriebenen Ausführungsformen gemacht werden kann, ohne von dem Bereich der Erfindung abzuweichen und dass solche Modifikationen, Änderungen und Kombinationen als innerhalb des Bereichs des erfinderischen Konzepts anzusehen sind.

Claims (18)

  1. Verfahren zur Kommunikation unter zwei oder mehr Modulen über ein gemeinsames Steuerungsnetzwerk, wobei das Verfahren aufweist: Senden eines Nachrichtenpakets mit wenigstens einem Datenteil, einem Fehlerprüfteil und einem Ende-des-Rahmens-Teil von einer Kommunikationsvorrichtung über ein Steuerungsnetzwerk, wobei das Nachrichtenpaket durch Bits festgelegt ist, die eine Vielzahl von Bitquanten haben, wobei die Daten für das Nachrichtenpaket durch einen Signalpegel bei festgelegten Bitquanten eines Bits festgelegt sind, wobei die festgelegten Bitquanten weniger als jedes Bitquantum eines Bits sind; Senden zusätzlicher Information innerhalb des Ende-des-Rahmens-Teils des Nachrichtenpakets unter Verwendung von Bitquanten des Ende-des-Rahmens-Teils verschieden von den festgelegten Bitquanten; worin die zusätzliche Information einen eindeutigen Identifizierer aufweist, der ausreicht, einen Teil des Nachrichtenpakets zu bestätigen, der die zusätzliche Information als den Ende-des-Rahmens-Teil einbettet.
  2. Verfahren nach Anspruch 1, weiter aufweisend Fehlerprüfen zusätzlicher Information eines empfangenen Nachrichtenpakets um einen Teil eines empfangenen Nachrichtenpakets zu bestätigen, der die zusätzliche Information einbettet, als ein Ende-des-Rahmens-Teil des empfangenen Nachrichtenpakets.
  3. Verfahren nach einem der Ansprüche 1 und 2, wobei das Senden des Nachrichtenpakets das Übertragen eines CAN-Nachrichtenpakets aufweist.
  4. Verfahren nach Anspruch 3, weiter aufweisend Einbetten der zusätzlichen Information in Prop-Seg-Bitquanten des Ende des Rahmen-Teils.
  5. Verfahren nach einem der Ansprüche 1 und 2, wobei das Senden des Nachrichtenpakets das Übertragen eines CAN-FD-Nachrichtenpakets aufweist.
  6. Verfahren nach einem der Ansprüche 1–5, weiter aufweisend Einbetten der zusätzlichen Information unter Verwendung eines CAN-EF-Protokolls.
  7. Kommunikationsvorrichtungseinrichtung zur Kommunikation mit anderen Vorrichtungen über ein Steuerungsnetzwerk, wobei die Kommunikationsvorrichtungseinrichtung aufweist: eine Verarbeitungsvorrichtung wirksam mit einem Kommunikationsanschluss verbunden, um empfangene Kommunikationen über das Steuerungsnetzwerk zu steuern, wobei die Verarbeitungsvorrichtung eingerichtet ist: einen ersten Teil eines Nachrichtenpakets unter Verwendung einer ersten Bitrate gefolgt von einem zweiten Teil des Nachrichtenpakets unter Verwendung einer zweiten Bitrate höher als die erste Bitrate zu kommunizieren; ein Nachrichtenpaket mit wenigstens einem Datenteil, einem Fehlerprüfteil und einem Ende-des-Rahmens-Teil zu senden, wobei das Nachrichtenpaket durch Bits festgelegt ist, die eine Vielzahl von Bitquanten aufweisen, wobei Daten für das Nachrichtenpaket durch ein Signalpegel bei festgelegten Bitquanten eines Bits festgelegt sind, wobei die festgelegten Bitquanten weniger als jedes Bitquantum eines Bits sind; Senden zusätzlicher Information innerhalb des Ende-des-Rahmens-Teils des Nachrichtenpakets unter Verwendung von Bitquanten des Ende-des-Rahmens-Teils verschieden von den festgelegten Bitquanten; wobei die zusätzliche Information einen eindeutigen Identifizierer, ausreichend um einen Teil des Nachrichtenpakets zu bestätigen, aufweist, der die zusätzliche Information als den Ende-des-Rahmens-Teil einbettet.
  8. Kommunikationsvorrichtungseinrichtung nach Anspruch 7, wobei die Verarbeitungsvorrichtung weiter dazu eingerichtet ist, zusätzliche Informationen eines erhaltenen Nachrichtenpakets Fehler zu prüfen, um einen Teil des empfangenen Nachrichtenpakets, der die zusätzliche Information als ein Ende-des-Rahmens-Teil des empfangenen Nachrichtenpakets einbettet, zu bestätigen.
  9. Kommunikationsvorrichtungseinrichtung nach einem der Ansprüche 7 und 8, wobei die Verarbeitungsvorrichtung weiter dazu eingerichtet ist, das Nachrichtenpaket durch Übertragen eines CAN-Nachrichtenpakets zu senden.
  10. Kommunikationsvorrichtungseinrichtung nach Anspruch 9, wobei die Verarbeitungsvorrichtung weiter dazu eingerichtet ist, die zusätzliche Information in Prop-Seg-Bitquanten des Ende-des-Rahmens-Teils einzubetten.
  11. Kommunikationsvorrichtungseinrichtung nach einem der Ansprüche 7 und 8, wobei die Verarbeitungsvorrichtung weiter dazu eingerichtet ist, das Nachrichtenpaket durch Übertragen eines CAN-FD-Nachrichtenpakets zu senden.
  12. Kommunikationsvorrichtungseinrichtung nach einem der Ansprüche 7–11, wobei Verarbeitungsvorrichtung weiter dazu eingerichtet ist, die zusätzliche Information unter Verwendung eines CAN-EF-Protokolls einzubetten.
  13. Vorrichtung zur Verwendung bei der Kommunikation mit anderen Vorrichtungen über ein Steuerungsnetzwerk, wobei die Vorrichtung aufweist: eine Verarbeitungsvorrichtung, die wirksam mit einem Kommunikationsanschluss verbunden ist, um Empfangen von Kommunikationen über das Steuerungsnetzwerk zu steuern, wobei die Verarbeitungsvorrichtung dazu eingerichtet ist: ein Nachrichtenpaket mit wenigstens einem Datenteil, einem Fehlerprüfteil und einem Ende-des-Rahmens-Teil zu senden, wobei das Nachrichtenpaket durch Bits festgelegt ist, die eine Vielzahl von Bitquanten aufweisen, wobei Daten für das Nachrichtenpaket durch einen Signalpegel bei festgelegten Bitquanten eines Bits festgelegt sind, wobei die festgelegten Bitquanten weniger als jedes Bitquantum eines Bits sind; Senden zusätzlicher Information innerhalb des Endes-des-Rahmens-Teils des Nachrichtenpakets unter Verwendung von Bitquanten des Ende-des-Rahmens-Teils verschieden von den festgelegten Bitquanten; wobei die zusätzliche Information einen eindeutigen Identifizierer, ausreichend um einen Teil des Nachrichtenpakets zu bestätigen, aufweist, der die zusätzliche Information als den Ende-des-Rahmens-Teils einbettet.
  14. Kommunikationsvorrichtungseinrichtung nach Anspruch 13, wobei die Verarbeitungsvorrichtung ferner dazu eingerichtet ist, die zusätzliche Information eines empfangenen Nachrichtenpakets Fehler zu prüfen, um einen Teil des empfangenen Nachrichtenpakets zu bestätigen, der die zusätzlichen Informationen als ein Ende-des-Rahmens-Teils des empfangenen Nachrichtenpakets einbettet.
  15. Kommunikationsvorrichtungseinrichtung nach einem der Ansprüche 13 und 14, wobei die Verarbeitungsvorrichtung weiter dazu eingerichtet ist, die Nachrichtenpakete durch Übertragung eines CAN-Nachrichtenpakets zu senden.
  16. Kommunikationsvorrichtungseinrichtung nach Anspruch 15, wobei die Verarbeitungsvorrichtung weiter dazu eingerichtet ist, die zusätzliche Information in Prop-Seg-Bitquanten des Ende-des-Rahmens-Teils einzubetten.
  17. Kommunikationsvorrichtungseinrichtung nach einem der Ansprüche 13 und 14, wobei die Verarbeitungsvorrichtung weiter dazu eingerichtet ist, das Nachrichtenpaket durch Übertragen eines CAN-Nachrichtenpakets zu senden.
  18. Kommunikationsvorrichtungseinrichtung nach einem der Ansprüche 13–17, wobei die Verarbeitungsvorrichtung weiter dazu eingerichtet ist, die zusätzliche Information unter Verwendung eines CAN-EF-Protokolls einzubetten.
DE112015004473.6T 2014-09-30 2015-09-30 Bestätigen der datengenauigkeit in einem verteilten steuerungssystem Pending DE112015004473T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462057508P 2014-09-30 2014-09-30
US62/057,508 2014-09-30
US201462059480P 2014-10-03 2014-10-03
US62/059,480 2014-10-03
PCT/US2015/053277 WO2016054245A1 (en) 2014-09-30 2015-09-30 Confirming data accuracy in a distributed control system

Publications (1)

Publication Number Publication Date
DE112015004473T5 true DE112015004473T5 (de) 2017-07-06

Family

ID=55585599

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112015004473.6T Pending DE112015004473T5 (de) 2014-09-30 2015-09-30 Bestätigen der datengenauigkeit in einem verteilten steuerungssystem

Country Status (3)

Country Link
US (1) US10673565B2 (de)
DE (1) DE112015004473T5 (de)
WO (1) WO2016054245A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017211860B3 (de) 2017-07-11 2018-09-20 Volkswagen Aktiengesellschaft Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
DE102017012214A1 (de) * 2017-07-11 2019-01-17 Volkswagen Aktiengesellschaft Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
US11343117B2 (en) 2017-08-08 2022-05-24 Volkswagen Aktiengesellschaft Method for transmitting data via a serial communication bus, correspondingly designed bus interface, and correspondingly designed computer program

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101573637B1 (ko) * 2014-11-03 2015-12-01 현대자동차주식회사 데이터량 증대로 통신속도 개선을 위한 can 통신 방법 및 데이터 프레임 구조
FR3029661B1 (fr) * 2014-12-04 2016-12-09 Stmicroelectronics Rousset Procedes de transmission et de reception d'un signal binaire sur un lien serie, en particulier pour la detection de la vitesse de transmission, et dispositifs correspondants
US10142358B1 (en) * 2016-02-29 2018-11-27 Symantec Corporation System and method for identifying an invalid packet on a controller area network (CAN) bus
CN107306237B (zh) * 2016-04-19 2020-09-18 宝沃汽车(中国)有限公司 Can输出信号的处理方法、装置及具有其的车辆
JP6890025B2 (ja) 2016-05-27 2021-06-18 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 電子制御ユニット、フレーム生成方法及びプログラム
WO2018106819A1 (en) * 2016-12-06 2018-06-14 Invidi Technologies Corporation Resource allocation in communications networks using probability forecasts
TWI673720B (zh) * 2016-12-27 2019-10-01 慧榮科技股份有限公司 控制器電路與估計延遲補償方法
CN108241586B (zh) 2016-12-27 2020-03-06 慧荣科技股份有限公司 控制器电路与估计延迟补偿方法
EP3576353B1 (de) 2018-05-31 2021-07-07 Melexis Technologies NV Flexibles datenratenhandling im datenbusempfänger
WO2020033570A1 (en) * 2018-08-07 2020-02-13 Concio Holdings LLC Adaptable and secure can bus
EP3629525B1 (de) * 2018-09-27 2022-08-17 Melexis Technologies SA Verfahren und system zur kommunikation über einen bus
CN109861795B (zh) * 2019-02-28 2021-09-03 广州小鹏汽车科技有限公司 Canfd总线系统采样点配置与测试方法及相应的数据传输方法
KR20200129260A (ko) * 2019-05-08 2020-11-18 현대자동차주식회사 차량용 리프로그래밍 장치 및 그의 리프로그래밍 방법과 그를 포함하는 차량
JP7120156B2 (ja) * 2019-05-29 2022-08-17 株式会社デンソー 通信装置
US10872044B1 (en) * 2019-07-30 2020-12-22 Rockwell Automation Technolgies, Inc. Distributed processing via open ring bus structure
DE102019218715A1 (de) * 2019-12-02 2021-06-02 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem
EP3869742B1 (de) * 2020-02-20 2023-06-07 Nxp B.V. Netzwerkknoten
US11288217B2 (en) * 2020-05-27 2022-03-29 Deere & Company Controller area network sample point detection
US11431439B1 (en) * 2021-04-12 2022-08-30 Nxp B.V. Controller area network transceiver
CN113965468B (zh) * 2021-09-15 2024-01-30 中国航空工业集团公司西安飞机设计研究所 一种公共框架网络设计方法

Family Cites Families (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5400331A (en) 1993-04-28 1995-03-21 Allen-Bradley Company, Inc. Communication network interface with screeners for incoming messages
SE501984C2 (sv) 1994-04-18 1995-07-03 Kvaser Consultant Ab Anordning för att eliminera funktionsstörningar och/eller möjliggöra höghastighetsöverföring i seriell bus-förbindelse och till denna anslutna sändar- och mottagarenheter
US5553070A (en) 1994-09-13 1996-09-03 Riley; Robert E. Data link module for time division multiplexing control systems
US5930302A (en) 1997-02-10 1999-07-27 Delco Electronics Corp. Balanced phase data bus transmitter
US7243143B1 (en) 1999-03-25 2007-07-10 Nortel Networks Limited Flow probe connectivity determination
GB2351884B (en) * 1999-04-10 2002-07-31 Peter Strong Data transmission method
US6430164B1 (en) 1999-06-17 2002-08-06 Cellport Systems, Inc. Communications involving disparate protocol network/bus and device subsystems
JP2001016234A (ja) 1999-06-29 2001-01-19 Mitsubishi Electric Corp Canコントローラおよびcanコントローラを内蔵したワンチップ・コンピュータ
EP1085727A1 (de) 1999-09-16 2001-03-21 BRITISH TELECOMMUNICATIONS public limited company Paketauthentifizierung
US7895342B2 (en) 2000-03-02 2011-02-22 Dearborn Group, Inc. Multi-protocol adapter for in-vehicle and industrial communications networks
US20020141438A1 (en) 2001-02-09 2002-10-03 Smith J. Howard Data communication controller and method
US7051143B2 (en) 2001-06-25 2006-05-23 Schneider Automation Inc. Method, system and program for the transmission of modbus messages between networks
DE50115035D1 (de) 2001-10-31 2009-09-24 Infineon Technologies Ag Bus-Interface
SE525273C2 (sv) 2002-01-07 2005-01-18 Kvaser Consultant Ab Distribuerat styr- och övervakningssystem
US8346951B2 (en) 2002-03-05 2013-01-01 Blackridge Technology Holdings, Inc. Method for first packet authentication
US20040190531A1 (en) 2002-08-20 2004-09-30 Pierre-Yves Sibille Bearer connection signaling in a distributed architecture
CN1689303A (zh) 2002-08-20 2005-10-26 西门子公司 分布式体系结构中的承载连接信令
SE524201C2 (sv) 2002-12-17 2004-07-06 Lars-Berno Fredriksson Anordning vid distribuerat styr- och övervakningssystem
US7460513B2 (en) 2003-11-17 2008-12-02 Telefonaktiebolaget Lm Ericsson (Publ) Encapsulation of diverse protocols over internal interface of distributed radio base station
SE528607C2 (sv) 2004-04-30 2006-12-27 Kvaser Consultant Ab System och anordning för att tidsmässigt relatera händelser i ett fordon
SE0401922L (sv) 2004-07-23 2005-05-31 Kvaser Consultant Ab Anordning för tidsstämpling av referenshändelser
SE533636C2 (sv) 2004-10-25 2010-11-16 Xinshu Man L L C Anordning vid bussförbindelse i CAN-system
DE102004062210B3 (de) 2004-12-23 2006-05-24 Texas Instruments Deutschland Gmbh Dualmodultaktversorgung für CAN-Kommunikationsmodul
DE102005018837A1 (de) 2005-04-22 2006-10-26 Robert Bosch Gmbh Verfahren und Vorrichtung zur Synchronisation zweier Bussysteme sowie Anordnung aus zwei Bussystemen
US7929461B2 (en) 2005-06-09 2011-04-19 Tekronix, Inc. Controller area network performance parameters measurement
JP4435082B2 (ja) 2005-12-15 2010-03-17 株式会社東芝 通信装置、通信方法および通信プログラム
US8165111B2 (en) 2006-07-25 2012-04-24 PSIMAST, Inc Telecommunication and computing platforms with serial packet switched integrated memory access technology
US8897313B2 (en) 2007-01-31 2014-11-25 International Business Machines Corporation Out-of-band signaling support over standard optical SFP
US8948173B2 (en) 2007-02-14 2015-02-03 Marvell International Ltd. Control protocol encapsulation
WO2009109070A1 (zh) 2008-03-07 2009-09-11 上海贝尔阿尔卡特股份有限公司 与兼容第一协议和第二协议的bs交互工作的ms及其方法
US8843241B2 (en) 2008-05-20 2014-09-23 LiveMeters, Inc. Remote monitoring and control system comprising mesh and time synchronization technology
US8311498B2 (en) 2008-09-29 2012-11-13 Broadcom Corporation Multiband communication device for use with a mesh network and methods for use therewith
US20100272102A1 (en) 2009-04-23 2010-10-28 Stmicroelectronics, Inc. System and method for packet messaging and synchronization
TW201111194A (en) 2009-09-18 2011-04-01 Liu I Sheng Auto-meter system with controller area network bus
US20110093639A1 (en) 2009-10-19 2011-04-21 Microchip Technology Incorporated Secure Communications Between and Verification of Authorized CAN Devices
DE102010016283B4 (de) 2010-03-31 2011-12-15 Schneider Electric Automation Gmbh Verfahren zur Übertragung von Daten über einen CANopen-Bus sowie Verwendung des Verfahrens zum Konfigurieren und/oder Parametrieren von Feldgeräten über den CANopen-Bus
DE102010063797A1 (de) 2010-12-21 2012-06-21 Robert Bosch Gmbh Verfahren und Vorrichtung zur seriellen Datenübertragung mit zusätzlich eingefügten Daten
US9015481B2 (en) 2011-02-22 2015-04-21 Honeywell International Inc. Methods and systems for access security for dataloading
DE102011080476A1 (de) 2011-08-05 2013-02-07 Robert Bosch Gmbh Verfahren und Vorrichtung zur Verbesserung der Datenübertragungssicherheit in einer seriellen Datenübertragung mit flexibler Nachrichtengröße
RU2620989C2 (ru) 2011-04-06 2017-05-30 Роберт Бош Гмбх Способ и устройство для повышения пропускной способности при передаче данных в последовательной шинной системе
EP2521319B1 (de) 2011-05-02 2015-10-14 Robert Bosch GmbH CAN mit flexibler Datenrate
EP2726999B1 (de) 2011-06-29 2015-09-09 Robert Bosch GmbH Verfahren und vorrichtung zur seriellen datenübertragung mit flexibler nachrichtengrösse und variabler bitlänge
JP5770935B2 (ja) 2011-06-29 2015-08-26 ローベルト ボッシュ ゲゼルシャフト ミット ベシュレンクテル ハフツング メッセージの大きさがフレキシブルでビット長が可変的な直列データ伝送のための方法及び装置
DE102012200997A1 (de) 2011-08-29 2013-02-28 Robert Bosch Gmbh Verfahren und Vorrichtung zur Prüfung der korrekten Funktion einer seriellen Datenübertragung
US8925083B2 (en) 2011-10-25 2014-12-30 GM Global Technology Operations LLC Cyber security in an automotive network
EP3651437B1 (de) 2012-03-29 2021-02-24 Arilou Information Security Technologies Ltd. Schutz eines elektronischen fahrzeugsystems
WO2013150925A1 (ja) 2012-04-03 2013-10-10 日本電気株式会社 ネットワークシステム、コントローラ、及びパケット認証方法
EP2660726A1 (de) 2012-05-02 2013-11-06 SMSC Europe GmbH Verfahren und Vorrichtung zur Emulation eines Bussystems
FR2990784B1 (fr) 2012-05-15 2014-05-30 Peugeot Citroen Automobiles Sa Organe de communication d’un reseau de communication de type can fd a etats multiples compatibles avec des organes de communication de type can hs
DE102012215765A1 (de) 2012-09-05 2014-05-15 Robert Bosch Gmbh Gateway-Modul für ein Kommunikationssystem, Kommunikationssystem und Verfahren zur Übertragung von Daten zwischen Teilnehmern eines Kommunikationssystems
EP2712123A1 (de) * 2012-09-20 2014-03-26 Robert Bosch Gmbh Standard CAN Implementierung toleriert CAN FD Rahmen
US9471528B2 (en) 2012-11-02 2016-10-18 Nxp B.V. Controller area network (CAN) transceiver and method for operating a CAN transceiver
US9280501B2 (en) 2013-01-31 2016-03-08 Infineon Technologies Ag Compatible network node, in particular, for can bus systems
US8737426B1 (en) 2013-03-15 2014-05-27 Concio Holdings LLC High speed embedded protocol for distributed control system
US8897319B2 (en) * 2013-03-15 2014-11-25 Concio Holdings LLC High speed embedded protocol for distributed control systems
US9419737B2 (en) 2013-03-15 2016-08-16 Concio Holdings LLC High speed embedded protocol for distributed control systems
US9432488B2 (en) 2013-03-15 2016-08-30 Concio Holdings LLC High speed embedded protocol for distributed control systems
US9223736B2 (en) 2013-05-03 2015-12-29 Nxp B.V. Devices and methods for an enhanced driver mode for a shared bus
US20160087737A1 (en) 2013-05-29 2016-03-24 Freescale Semiconductor, Inc. A network receiver for a network using distributed clock synchronization and a method of sampling a signal received from the network
US20150135271A1 (en) 2013-11-11 2015-05-14 GM Global Technology Operations LLC Device and method to enforce security tagging of embedded network communications
US20150230044A1 (en) 2014-02-12 2015-08-13 Continental Automotive Systems, Inc. Updating vehicle software using a smartphone
US10326865B2 (en) 2015-03-24 2019-06-18 Concio Holdings LLC Filter or bridge for communications between CAN and CAN-FD protocol modules
US9729329B2 (en) 2015-05-19 2017-08-08 Nxp B.V. Communications security
WO2017079250A1 (en) 2015-11-02 2017-05-11 Concio Holdings LLC Confirming data accuracy in a distributed control system
US20170235698A1 (en) 2016-02-12 2017-08-17 Nxp B.V. Controller area network (can) message filtering
EP3402129A1 (de) 2017-05-09 2018-11-14 Concio Holdings LLC Bit-codierung für ein bus-kommunikationssystem

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017211860B3 (de) 2017-07-11 2018-09-20 Volkswagen Aktiengesellschaft Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
DE102017012214A1 (de) * 2017-07-11 2019-01-17 Volkswagen Aktiengesellschaft Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
DE102017012214B4 (de) 2017-07-11 2019-06-19 Volkswagen Aktiengesellschaft Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
US10530606B2 (en) 2017-07-11 2020-01-07 Volkswagen Ag Method for transmitting data via a serial communication bus, bus interface, and computer program
EP3661131A1 (de) 2017-07-11 2020-06-03 Volkswagen Ag Verfahren zur übertragung von daten über einen seriellen kommunikationsbus, entsprechend ausgelegte busschnittstelle sowie entsprechend ausgelegtes computerprogramm
US11146420B2 (en) 2017-07-11 2021-10-12 Volkswagen Ag Method for transmitting data via a serial communication bus, bus interface, and computer program
US11343117B2 (en) 2017-08-08 2022-05-24 Volkswagen Aktiengesellschaft Method for transmitting data via a serial communication bus, correspondingly designed bus interface, and correspondingly designed computer program

Also Published As

Publication number Publication date
US10673565B2 (en) 2020-06-02
WO2016054245A1 (en) 2016-04-07
US20160094312A1 (en) 2016-03-31

Similar Documents

Publication Publication Date Title
DE112015004473T5 (de) Bestätigen der datengenauigkeit in einem verteilten steuerungssystem
EP2434695B1 (de) Serielle ringförmige Kommunikationsanordnung und dementsprechendes Verfahren, wobei für die Übermittlung von einem Datenpaket von jedem Slave eine Adressinformation des Datenpakets geändert wird
EP2936747B1 (de) Datenübertragung unter nutzung eines protokollausnahmezustands
EP1875641B1 (de) Vorrichtung zur synchronisation zweier bussysteme sowie anordnung aus zwei bussystemen
DE3506118C2 (de)
DE69432841T2 (de) Verfahren und Vorrichtung für digitale Datenübertragung in einem Nachrichtennetz
CN106464559B (zh) 用于分布式控制系统的高速嵌入式协议
EP2145431A2 (de) Kommunikationsverfahren und apparat zur effizienten und sicheren übertragung von tt-ethernet nachrichten
EP2936746B1 (de) Datenübertragungsprotokoll mit protokollausnahmezustand
DE112020003973T5 (de) Ethernet-schnittstelle und zugehörige systeme, verfahren und vorrichtungen
DE112020003976T5 (de) Ethernet-schnittstelle und zugehörige systeme, verfahren und vorrichtungen
DE102012108696B4 (de) Datenbusteilnehmer und Verfahren zur Synchronisation von Datenbusteilnehmern
EP1639758B1 (de) Verfahren und vorrichtung zum austausch von daten über ein bussystem
EP1193926A2 (de) Verfahren und System zur Echtzeitkommunikation in einem Netz mit Ethernet-Physik
EP1826646B1 (de) Verfahren, Knoten und Netzwerk zum zyklischen Versenden von Ethernet-Telegrammen
WO2015031926A1 (de) Verfahren zur übertragung von nachrichten in einem computernetzwerk sowie computernetzwerk
EP3725042B1 (de) Teilnehmer eines bussystems, verfahren zum betrieb und ein bussystem
DE102012205160A1 (de) Kommunikationsanordnung und Verfahren zur Konfiguration programmierbarer Hardware
EP1436924A2 (de) Verfahren zum betrieb eines endteilnehmers eines isochronen, zyklischen kommunikationssystems
EP1484679B1 (de) Sicherstellung von maximalen Reaktionszeiten in komplexen oder verteilten sicheren und/oder nicht sicheren Systemen
EP3744021B1 (de) Teilnehmerstation für ein serielles kommunikationsnetzwerk und verfahren zur korrektur von einzelfehlern in einer nachricht eines seriellen kommunikationsnetzwerks
EP3477650A1 (de) Verfahren und einrichtung zur kommunikation in einer medizinischen bildgebungseinrichtung und medizinische bildgebungseinrichtung
DE102011112629A1 (de) Verfahren zur Phasensynchronisation räumlich verteilter Hardwarekomponenten
DE102017108578B4 (de) Steuern eines Automatisierungsprozesses über ein Datennetzwerk
DE10206904A1 (de) Kommunikation in einem verteilten Steuerungssystem mit Unterdrücken der zyklischen Kommunikation nach Äquidistanzverletzung

Legal Events

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

Free format text: PREVIOUS MAIN CLASS: H04L0012400000

Ipc: H04L0012407000

R081 Change of applicant/patentee

Owner name: KVASER AB, SE

Free format text: FORMER OWNER: CONCIO HOLDINGS LLC, WINNETKA, ILL., US

R082 Change of representative

Representative=s name: RUEGER ABEL PATENTANWAELTE PARTGMBB, DE

R016 Response to examination communication