DE102011017539A1

DE102011017539A1 - Verfahren und Vorrichtung zur an Speichergrößen angepassten seriellen Datenübertragung

Info

Publication number: DE102011017539A1
Application number: DE102011017539A
Authority: DE
Inventors: Florian Hartwich
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2011-04-26
Filing date: 2011-04-26
Publication date: 2012-10-31

Abstract

Es wird ein Verfahren zur seriellen Datenübertragung in einem Bussystem mit mindestens zwei teilnehmenden Datenverarbeitungseinheiten beschrieben, wobei die Datenverarbeitungseinheiten über den Bus Nachrichten austauschen, wobei die gesendeten Nachrichten einen logischen Aufbau gemäß der CAN-Norm ISO 11898-1 aufweisen, wobei zumindest bei Vorliegen einer ersten Umschaltbedingung das Datenfeld der Nachrichten abweichend von der CAN-Norm ISO 11898-1 mehr als acht Bytes umfassen kann, und wobei zur Feststellung der Größe des Datenfeldes zumindest bei Vorliegen der ersten Umschaltbedingung die Werte der vier Bits des Data Length Codes zumindest teilweise abweichend von der CAN-Norm ISO 11898-1 interpretiert werden, wobei für die Weitergabe von Daten zwischen dem Datenfeld und der Anwendungs-Software wenigstens ein Zwischenspeicher vorgesehen ist und die weitergegebene Datenmenge zumindest, wenn die Größe des Datenfeldes sich von der Größe des verwendeten Zwischenspeichers unterscheidet, entsprechend der Größendifferenz zwischen Datenfeld und verwendetem Zwischenspeicher angepasst wird.

Description

Stand der Technik
Die Erfindung betrifft ein Verfahren sowie eine Vorrichtung zur an Speichergrößen angepassten seriellen Datenübertragung zwischen wenigstens zwei Teilnehmern in einem seriellen Bussystem.
Beispielsweise aus den Normen der Familie ISO 11898-1 bis -5 ist das Controller Area Network (CAN) sowie eine als „Time Triggered CAN” (TTCAN) bezeichnete Erweiterung des CAN bekannt, im Folgenden auch als Norm CAN bezeichnet. Das beim CAN verwendete Medienzugriffssteuerverfahren beruht auf einer bitweisen Arbitrierung. Bei der bitweisen Arbitrierung können mehrere Teilnehmerstationen gleichzeitig Daten über den Kanal des Bussystems übertragen, ohne dass hierdurch die Datenübertragung gestört wird. Die Teilnehmerstationen können weiterhin beim Senden eines Bits über den Kanal den logischen Zustand (0 oder 1) des Kanals ermitteln. Entspricht ein Wert des gesendeten Bits nicht dem ermittelten logischen Zustand des Kanals, dann beendet die Teilnehmerstation den Zugriff auf den Kanal. Bei CAN wird die bitweise Arbitrierung üblicherweise anhand eines Identifiers innerhalb einer über den Kanal zu übertragenden Nachricht vorgenommen. Nachdem eine Teilnehmerstation den Identfier vollständig an den Kanal gesendet hat, weiß sie, dass sie exklusiven Zugriff auf den Kanal hat. Somit entspricht das Ende der Übertragung des Identifiers einem Beginn eines Freigabeintervalls, innerhalb dessen die Teilnehmerstation den Kanal exklusiv nutzen kann. Gemäß der Protokollspezifikation des CAN dürfen andere Teilnehmerstationen so lange nicht auf den Kanal zugreifen, das heißt Daten an den Kanal senden, bis die sendende Teilnehmerstation ein Prüfsummenfeld (CRC Field) der Nachricht übertragen hat. Somit entspricht ein Endzeitpunkt der Übertragung des CRC Fields einem Ende des Freigabeintervalls.
Durch die bitweise Arbitrierung wird also eine zerstörungsfreie Übertragung derjenigen Nachricht über den Kanal erreicht, die das Arbtrierungsverfahren gewonnen hat. Die Protokolle des CAN eignen sich besonders zum Übertragen kurzer Meldungen unter Echtzeitbedingungen, wobei durch geeignete Zuweisung der Identifier sichergestellt werden kann, dass besonders wichtige Nachrichten nahezu immer die Arbitrierung gewinnen und erfolgreich gesendet werden.
Mit der zunehmenden Vernetzung moderner Fahrzeuge und dem Einzug zusätzlicher Systeme zur Verbesserung beispielsweise der Fahrsicherheit oder des Fahrkomforts wachsen die Anforderungen an die zu übertragenden Datenmengen und die bei der Übertragung zulässigen Latenzzeiten. Beispiele sind Fahrdynamikregelsysteme wie z. B. das elektronische Stabilitätsprogramm ESP, Fahrerassistenzsysteme wie z. B. die automatische Abstandsregelung ACC, oder Fahrerinformationssysteme wie z. B. die Verkehrszeichenerkennung (vgl. beispielsweise Beschreibungen in „Bosch Kraftfahrtechnisches Handbuch", 27. Auflage, 2011, Vieweg + Teubner).
DE 103 11 395 A1 beschreibt ein System, bei welchem asynchrone, serielle Kommunikation alternativ über ein asymmetrisches physikalisches oder über das symmetrische physikalische CAN-Protokoll erfolgen kann, und dadurch eine höhere Datenübertragungsrate oder -sicherheit für die asynchrone Kommunikation erzielbar ist.
DE 10 2007 051 657 A1 schlägt vor, in den exklusiven Zeitfenstern des TTCAN Protokolles eine asynchrone, schnelle, nicht CAN-konforme Datenübertragung anzuwenden, um die übertragene Datenmenge zu erhöhen.
G. Cena und A. Valenzano behandeln in „Overclocking of controller area networks" (Electronics Letters, Vol. 35, No. 22 (1999), S. 1924) die Auswirkungen einer Übertaktung der Busfrequenz in Teilbereichen der Nachrichten auf die effektiv erzielte Datenrate.
Es zeigt sich, dass der Stand der Technik nicht in jeder Hinsicht befriedigende Ergebnisse liefert.
Offenbarung der Erfindung
Im Folgenden wird die Erfindung mit ihren Vorteilen anhand von Zeichnungen und Ausführungsbeispielen beschrieben. Der Gegenstand der Erfindung ist nicht auf die dargestellten und geschilderten Ausführungsbeispiele beschränkt.
Vorteile der Erfindung
Die vorliegende Erfindung stellt ein Verfahren bereit, das sich dadurch auszeichnet, dass das Datenfeld von Nachrichten abweichend von der CAN-Norm ISO 11898-1 mehr als acht Bytes umfassen kann, wobei zur Feststellung der Größe des Datenfeldes die Werte der vier Bits des Data Length Codes zumindest teilweise abweichend von der CAN-Norm ISO 11898-1 interpretiert werden, und dass für die Weitergabe von Daten zwischen dem Datenfeld und der Anwendungs-Software wenigstens ein Zwischenspeicher zur Verwendung vorgesehen ist und die weitergegebene Datenmenge zumindest, wenn die Größe des Datenfeldes sich von der Größe des verwendeten Zwischenspeichers unterscheidet, entsprechend der Größendifferenz zwischen Datenfeld und verwendetem Zwischenspeicher angepasst wird. Dadurch wird der Vorteil erzielt, dass die Anwendungs-Software unverändert weitergenutzt werden kann und die Größe des Kommunikationscontrollers nicht unnötig erhöht werden muss, auch wenn die Größe des Datenfeldes gegenüber dem Norm-CAN erhöht sein kann.
Vorteilhafter Weise wird aus dem Datenfeld einer über den Bus empfangenen Nachricht eine der Größe des verwendeten Zwischenspeichers entsprechende, insbesondere acht Byte umfassende Datenmenge nach einem vorgegebenen oder vorgebbaren Auswahlverfahren ausgewählt und an den Zwischenspeicher weitergegeben, wenn die Größe des Datenfeldes über der Größe des verwendeten Zwischenspeichers, typischerweise acht Byte, liegt. In das Datenfeld einer über den Bus zu sendenden Nachricht wird der Inhalt des Zwischenspeichers in wenigstens einen vorgegebenen oder vorgebbaren Bereich des Datenfeldes der Nachricht eingetragen und der oder die verbleibenden Bereiche des Datenfeldes nach einem vorgegebenen oder vorgebbaren Verfahren aufgefüllt werden, wenn die Größe des Datenfeldes über der Größe des verwendeten Zwischenspeichers liegt. Damit die Nachrichtenlange nicht unnötig anwächst, ist es vorteilhaft, die Bits in den aufgefüllten Bereichen des Datenfeldes einer über den Bus zu sendenden Nachricht so aufzufüllen, dass gemäß den Regeln des CAN-Norm ISO 11898-1 in diesen Bereichen keine Stuff-Bits eingefügt werden müssen.
Durch das Aufstellen einer eindeutigen Zuordnung zwischen dem Inhalt des Data Length Code und der Länge des Datenfeldes wird in vorteilhafter Weise eine hohe Flexibilität bezüglich der darstellbaren Größe des Datenfeldes erreicht.
In einer vorteilhaften Ausprägung des Verfahrens erfolgt die Vergrößerung des Datenfeldes und die Anpassung der Interpretation des Inhaltes des Data Length Code in Abhängigkeit von einer ersten Umschaltbedingung, so dass bei Vorliegen der ersten Umschaltbedingung das erfindungsgemäße Verfahren zur Anwendung kommt, während sonst die Datenübertragung gemäß dem normalen CAN Standard erfolgt. Durch eine Kennzeichnung im Arbitration Field und/oder im Control Field sind erfindungsgemäße Nachrichten von CAN-normgemäßen Nachrichten unterscheidbar. Die Kennzeichnung wird in den teilnehmenden Datenverarbeitungseinheiten zur Ermittlung der ersten Umschaltbedingung ausgewertet, so dass abhängig von der ersten Umschaltbedingung der Empfangsprozess an die Größe des Datenfeldes angepasst wird. Dadurch wird der Vorteil erzielt, dass erfindungsgemäße Vorrichtungen sowohl in Standard CAN Bussystemen eingesetzt werden können, als auch in neuen, erfindungsgemäßen Bussystemen mit potenziell größeren Datenfeldern.
Kombiniert man das Verfahren mit einem Umschalten der Bitlänge beispielsweise für die Bits des Datenfeldes und des CRC Feldes, so erzielt man den weiteren Vorteil, dass eine größere Menge an Daten beschleunigt übertragen wird und die mittlere Datenübertragungsrate des Bussystems gesteigert wird. Auch hier ist es von Vorteil, die modifiziert übertragenen Nachrichten mit geänderter Bitlänge mit einer entsprechenden Kennzeichnung zu versehen, um erfindungsgemäße Vorrichtungen sowohl in Standard CAN Bussystemen, als auch in neuen, erfindungsgemäßen Bussystemen einsetzen zu können.
Es ist vorteilhaft für die Nachvollziehbarkeit des jeweils verwendeten Übertragungsverfahrens, ein oder mehrere zusätzliche Status-Bits vorzusehen, welche das Ergebnis der Datenübertragung kennzeichnen. Denkbar sind etwa Status-Bits zur Kennzeichnung des erfolgreichen Sendens, zur Kennzeichnung des erfolgreichen Empfangs oder zur Kennzeichnung der Art des zuletzt aufgetretenen Fehlers. Abhängig von der Häufigkeit des Auftretens von Fehlern in einem von der CAN-Norm ISO 11898-1 abweichenden Datenübertragungsverfahren kann vorteilhafter Weise in das Übertragungsverfahren gemäß CAN-Norm ISO 11898-1 zurückgeschaltet werden und dies durch ein weiteres Status-Bit signalisiert werden.
Im Nachrichtenspeicher und/oder Zwischenspeicher können vorteilhaft ein oder mehrere zusätzliche Nachrichten-Bits vorgesehen sein, welche das für die jeweilige Nachricht verwendete oder zu verwendende Verfahren zur Datenübertragung kennzeichnen. Hier können beispielsweise die in der Nachricht vorgesehenen Kennzeichnungen eingetragen werden.
Das Verfahren ist vorteilhaft einsetzbar im normalen Betrieb eines Kraftfahrzeuges zur Übertragung von Daten zwischen wenigstens zwei Steuergeräten des Kraftfahrzeuges, welche über einen geeigneten Datenbus verbunden sind. Es ist aber gleichermaßen vorteilhaft einsetzbar während der Fertigung oder Wartung eines Kraftfahrzeuges zur Übertragung von Daten zwischen einer zum Zwecke der Programmierung mit einem geeigneten Datenbus verbundenen Programmierungseinheit und wenigstens einem Steuergerät des Kraftfahrzeuges, welches mit dem Datenbus verbunden ist.
Ein weiterer Vorteil ist, dass ein Norm-CAN Controller nur minimal geändert werden muss, um erfindungsgemäß arbeiten zu können. Ein erfindungsgemäßer Kommunikationscontroller, der auch als Norm-CAN Controller arbeiten kann, ist nur unwesentlich größer als ein herkömmlicher Norm-CAN Controller. Das zugehörige Anwendungs-Programm muss nicht geändert werden, und schon dann werden Vorteile in der Geschwindigkeit der Datenübertragung erzielt.
Es können in vorteilhafter Weise erhebliche Teile des CAN-Conformance-Tests (ISO 16845) übernommen werden. In einer vorteilhaften Ausprägung kann das erfindungsgemäße Übertragungsverfahren mit den Ergänzungen des TTCAN (ISO 11898-4) kombiniert werden.
Zeichnungen
Die Erfindung wird im Weiteren anhand der Zeichnungen näher erläutert.
1a zeigt die zwei Alternativen für den Aufbau von Nachrichten im CAN Format gemäß der CAN-Norm ISO 11898-1 aus dem Stand der Technik.
1b zeigt die zwei analogen Alternativen für das Format der demgegenüber erfindungsgemäß modifizierten Nachrichten.
2 stellt verschiedene Möglichkeiten dar, wie der Inhalt des Data Length Code erfindungsgemäß abweichend von der CAN-Norm ISO 11898-1 interpretiert werden kann.
3 stellt schematisch ein Ausführungsbeispiel für den erfindungsgemäßen Empfangsprozess auf einer Teilnehmerstation des Bussystems dar.
4 stellt schematisch ein weiteres Ausführungsbeispiel für den erfindungsgemäßen Empfangsprozess auf einer Teilnehmerstation des Bussystems dar.
5 zeigt zwei Beispiele für das Format von erfindungsgemäß modifizierten Nachrichten, bei denen zusätzlich in festgelegten Bereichen innerhalb der Nachricht eine unterschiedliche Bitlänge verwendet wird.
6 zeigt ein Beispiel für die erfindungsgemäße Anpassung der zwischen dem Datenfeld und der Anwendungs-Software weitergegebenen Datenmenge.
Beschreibung der Ausführungsbeispiele
In 1a ist der Aufbau von Nachrichten, wie sie auf einem CAN Bus zur Datenübertragung verwendet werden, dargestellt. Die beiden unterschiedlichen Formate „Standard” und „Extended” sind dargestellt. Das erfindungsgemäße Verfahren ist in geeigneten Ausführungsformen auf beide Formate anwendbar.
Die Nachricht beginnt mit einem „Start of Frame”(SOF)-Bit, das den Beginn der Nachricht signalisiert. Es schließt sich ein Abschnitt an, der in erster Linie zur Identifizierung der Nachricht dient, und anhand dessen die Teilnehmer des Bussystems entscheiden, ob sie die Nachricht empfangen oder nicht. Dieser Abschnitt wird mit „Arbitration Field” bezeichnet und enthält den Identifier. Es folgt ein „Control Field”, das unter anderem den Data Length Code enthält. Der Data Length Code enthält Informationen über die Größe des Datenfeldes der Nachricht. Hieran schließt sich das eigentliche Datenfeld „Data Field” an, das die zwischen den Teilnehmern des Bussystems auszutauschenden Daten enthält. Es folgt das „CRC Field” mit der 15 Bit umfassenden Checksumme und einem Delimiter, und anschließend zwei „Acknowledge”(ACK)-Bits, die dazu dienen, den erfolgreichen Empfang einer Nachricht an den Sender zu signalisieren. Abgeschlossen wird die Nachricht durch eine „End of Frame”(EOF)-Sequenz.
Bei dem CAN Übertragungsverfahren nach der Norm darf das Datenfeld maximal 8 Byte, also 64 Bit an Daten enthalten. Der Data Length Code umfasst gemäß der Norm vier Bits, kann also 16 verschiedene Werte annehmen. Benutzt werden aus diesem Wertebereich in heutigen Bussystemen lediglich acht verschiedene Werte für die unterschiedlichen Größen des Datenfeldes von 1 Byte bis zu 8 Byte. Ein Datenfeld von 0 Byte ist im Norm CAN nicht empfohlen, Größen oberhalb von 8 Byte sind nicht zulässig. Die Zuordnung der Werte des Data Length Code zu den Größen des Datenfeldes ist in 2 in der Spalte CAN Norm dargestellt.
In 1b sind in analoger Darstellung die erfindungsgemäß zu übertragenden, modifizierten Nachrichten, jeweils abgeleitet von den beiden Norm-Formaten, gegenübergestellt.
Bei dem erfindungsgemäß modifizierten Übertragungsverfahren darf das Datenfeld auch mehr als 8 Byte enthalten, nämlich in der dargestellten Ausprägung bis zu K Byte. Anders als im Norm CAN werden weitere Werte, die der Data Length Code einnehmen kann, ausgenutzt, um größere Datenfelder zu kennzeichnen. Beispielsweise können die vier Bits des Data Length Code benutzt werden, um die Werte von null bis 15 Byte darzustellen. Es können aber auch andere Zuordnungen getroffen werden, beispielsweise ist es eine Möglichkeit, den in heutigen CAN-Nachrichten üblicherweise nicht genutzten Wert des Data Length Code DLC = 0b0000 für eine weitere mögliche Größe des Datenfeldes zu benutzen, beispielsweise für die Größe 16 Byte.
Diese beiden Möglichkeiten sind in 2 in Tabellenform als DLC 1 und DLC 2 dargestellt. Die Maximalgröße des Datenfeldes K hat in diesen Fällen den Wert 15 bzw. 16. Eine weitere Möglichkeit ist es, dass für die Werte des Data Length Code größer 0b1000 und bis 0b1111 die zugehörigen Größen des Datenfeldes um ein größeres Inkrement anwachsen. Ein Beispiel für diesen Fall ist in der Tabelle als DLC 3 dargestellt. Die Maximalgröße des Datenfeldes K erreicht in dieser Variante den Wert 64 Byte. Eine andere Wahl ist selbstverständlich möglich, beispielsweise ein Inkrement von jeweils 4 Byte.
Um zu gewährleisten, dass ein erfindungsgemäßer Kommunikationscontroller feststellen kann, in welcher Art er die Inhalte des Data Length Code zu interpretieren hat, ist es vorteilhaft, dass er selbständig erkennt, ob die Kommunikation des Bussystems nach Norm CAN oder dem erfindungsgemäßen Verfahren abläuft. Eine Möglichkeit hierzu besteht darin, ein reserviertes Bit innerhalb des Arbitration Field oder des Control Field zur Kennzeichnung heranzuziehen, so dass aus dieser Kennzeichnung der Kommunikationscontroller eine erste Umschaltbedingung ableiten kann, abhängig von der er das Übertragungsverfahren auswählt. Beispielsweise kann das in 1b mit r0 bezeichnete, zweite Bit des Control Field zur Kennzeichnung verwendet werden. Eine andere Möglichkeit ist, das SRR-Bit zu verwenden, welches im Norm CAN immer rezessiv gesendet werden muss, aber von den die Nachricht empfangenden Busteilnehmern auch dominant akzeptiert wird. Es können auch Bitkombinationen zur Feststellung der ersten Umschaltbedingung ausgewertet werden.
Eine weitere Möglichkeit wäre, für das erfindungsgemäß modifizierte Übertragungsverfahren die Verwendung des Extended Formates vorzuschreiben. Nachrichten im Extended Format werden von den Busteilnehmern am Wert des IDE-Bits erkannt (vgl. 1a) und dieses Bit könnte gleichzeitig die erste Umschaltbedingung darstellen, so dass für Extended Nachrichten immer das modifizierte Übertragungsverfahren zur Anwendung kommt. Alternativ wäre es auch möglich, in Extended Nachrichten das reservierte Bit r1 zur Kennzeichnung beziehungsweise zur Ableitung der ersten Umschaltbedingung zu verwenden. Das reservierte Bit kann aber auch, wie weiter unten ausgeführt, zur Ableitung einer zweiten Umschaltbedingung zur Umschaltung zwischen mehr als zwei verschiedenen Größen des Datenfeldes beziehungsweise Zuordnungen zwischen Werten des Data Length Code und Datenfeldgrößen genutzt werden.
Es ist alternativ aber auch möglich, das Verfahren in dazu geeigneten Kommunikationscontrollern zur Anwendung zu bringen, die nicht auch zur normgemäßen CAN Kommunikation ausgelegt sind. In diesem Fall kann auch die Festlegung der genannten ersten Umschaltbedingung, beispielsweise abhängig von einer geeigneten Kennzeichnung der Nachrichten, entfallen. Die Kommunikationscontroller arbeiten in diesem Fall vielmehr ausschließlich gemäß einem der beschriebenen Verfahren und sind dementsprechend nur in Bussystemen einsetzbar, in welchen ausschließlich solche erfindungsgemäßen Kommunikationscontroller im Einsatz sind.
Wird, wie in der Erfindung vorgesehen, das Datenfeld von Nachrichten vergrößert, so kann es sinnvoll sein, auch das verwendete Verfahren zum Cyclic Redundancy Check (CRC) anzupassen, um eine ausreichende Fehlersicherheit zu erhalten. Insbesondere kann es vorteilhaft sein, ein anderes CRC-Polynom, beispielsweise mit höherer Ordnung, zu verwenden und entsprechend eine CRC Field abweichender Größe in den erfindungsgemäß modifizierten Nachrichten vorzusehen. Dies ist in 1b dadurch dargestellt, dass das CRC Field der erfindungsgemäßen Nachrichten im dargestellten Beispiel eine Länge von L Bit aufweist, wobei L abweichend vom Norm CAN ungleich, insbesondere größer als 15 sein kann.
Die Verwendung eines modifizierten Verfahrens zur Berechnung der CRC Checksumme kann durch eine Kennzeichnung, welche eine dritte Umschaltbedingung darstellt, den Busteilnehmern signalisiert werden. Diese Kennzeichnung und die dritte Umschaltbedingung kann aber auch mit der ersten Kennzeichnung und/oder Umschaltbedingung übereinstimmen. Auch hier kann, wie weiter oben beschrieben, beispielsweise das reservierte Bit r0 aus 1b zur Kennzeichnung dienen, oder es kann das SRR-Bit verwendet werden. Auch eine Verwendung des IDE-Bit in Verbindung mit der Anwendung des Verfahrens in Extended Nachrichten, oder auch des Bit r1 kommt in Frage.
In den Norm CAN-Controllern wird der CRC-Code von zu sendenden CAN-Nachrichten mittels eines rückgekoppelten Schieberegisters erzeugt, in dessen Eingang die seriell gesendeten Bits der Nachricht sequenziell eingespeist werden. Die Breite des Schieberegisters entspricht der Ordnung des CRC-Polynoms. Die CRC-Codierung erfolgt durch eine Verknüpfung des Register-Inhalts mit dem CRC-Polynom während der Shift-Operationen. Wenn CAN-Nachrichten empfangen werden, werden entsprechend die seriell empfangenen Bits der Nachricht in das CRC-Schieberegister geschoben. Der CRC-Test ist erfolgreich, wenn am Ende des CRC-Feldes alle Bits des Schieberegisters auf Null stehen. Die CRC-Code-Generierung im Sendefall und der CRC-Test im Empfangsfall erfolgen beide in Hardware, ohne dass ein Eingriff der Software notwendig ist. Eine Modifikation der CRC-Codierung hat also keine Auswirkung auf die Anwendungs-Software.
In einer möglichen Ausführungsform wird der Kommunikationscontroller so ausgelegt, dass er Kompatibilität zum Norm CAN aufweist, also in einem Norm CAN Bussystem normgemäß arbeitet, während er in einem erfindungsgemäß modifizierten Bussystem einerseits größere Datenfelder in den Nachrichten zulässt und andererseits auch die angepasste Berechnung und Prüfung des CRC-Code durchführt.
Da am Anfang des Empfanges einer Nachricht noch nicht feststeht, ob eine Norm-konforme CAN-Nachricht oder eine erfindungsgemäß modifizierte Nachricht empfangen wird, werden in einem erfindungsgemäßen Kommunikationscontroller zwei CRC-Schieberegister implementiert, die parallel arbeiten. Nach dem Empfang des CRC Delimiter, wenn der CRC-Code im Empfänger ausgewertet wird, steht aufgrund der erfindungsgemäßen Kennzeichnung beziehungsweise der beispielsweise aus der Kennzeichnung oder dem Inhalt des Data Length Code abgeleiteten dritten Umschaltbedingung auch fest, welches Übertragungsverfahren angewendet wurde, und es wird dann das diesem Übertragungsverfahren zugeordnete Schieberegister ausgewertet. Die dritte Umschaltbedingung kann, wie früher bereits dargestellt, mit der ersten Umschaltbedingung, die die Größe des Datenfeldes und die Interpretation des Data Length Code betrifft, übereinstimmen.
Am Anfang des Sendens einer Nachricht steht zwar für den Sender bereits fest, nach welchem Übertragungsverfahren gesendet werden soll. Da es jedoch vorkommen kann, dass die Arbitration um den Buszugriff verloren wird und die begonnene Nachricht nicht gesendet, sondern stattdessen eine andere Nachricht empfangen wird, werden auch hier beide CRC-Schieberegister parallel angesteuert.
Die beschriebene Implementation zweier parallel arbeitender CRC-Schieberegister ermöglicht auch eine weitere Verbesserung:
Das CRC-Polynom des Norm CAN-Protokolls (x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1) ist für eine Nachrichten-Länge von weniger als 127 Bits ausgelegt. Wenn erfindungsgemäß übertragene Nachrichten auch längere Datenfelder verwenden, ist es sinnvoll, zur Aufrechterhaltung der Übertragungssicherheit ein anderes, insbesondere längeres CRC-Polynom zu verwenden. Die erfindungsgemäß übermittelten Nachrichten erhalten dementsprechend ein geändertes, insbesondere längeres CRC Field. Im laufenden Betrieb wechseln die Kommunikationscontroller dynamisch zwischen den beiden CRC-Schieberegistern, also dem Norm CAN-gemäßen und dem erfindungsgemäßen Schieberegister, um das jeweils passende Polynom zu verwenden.
Natürlich können auch mehr als zwei Schieberegister und dementsprechend mehr als zwei CRC-Polynome abgestuft in Abhängigkeit von der Länge des Datenfeldes oder der gewünschten Übertragungssicherheit zum Einsatz kommen. In diesem Fall muss, sofern eine Kompatibilität zum Norm CAN erhalten bleiben soll, die entsprechende Kennzeichnung und die damit verbundene Umschaltbedingung angepasst werden. Beispielsweise könnte durch das reservierte Bit r0 oder das SRR-Bit in 1b eine erste Umschaltbedingung ausgelöst werden, welche ein Umschalten auf längere Datenfelder, beispielsweise gemäß DLC 1 auf 2, und ein zugehöriges zweites CRC-Polynom kennzeichnet. Für Nachrichten im Extended Format könnte zusätzlich, etwa durch das reservierte Bit r1 oder das IDE-Bit in 1b, eine zweite Umschaltbedingung ausgelöst werden, welche die Umschaltung auf einen weiteren Satz von Datenfeldgrößen, beispielsweise DLC 3 aus 2, und ein drittes CRC-Polynom kennzeichnet.
Es ist im übrigen auch möglich, dass die erste Umschaltbedingung, etwa durch das reservierte Bit r0 oder das SRR-Bit, auf die Möglichkeit längerer Datenfelder und die entsprechende Interpretation des Inhaltes des Data Length Code umschaltet, und dass Ermittlung der dritten Umschaltbedingung und damit einhergehend die Auswahl des für die CRC-Prüfung auszuwertenden CRC-Polynoms dann abhängig vom Inhalt des Data Length Code erfolgt. Die dritte Umschaltbedingung kann dementsprechend auch mehr als zwei Werte annehmen. Beispielsweise könnten die Datenfeldgrößen gemäß DLC 3 ausgewählt werden, also Werte zwischen 0 und 64 Byte annehmen, und es könnten dann drei CRC-Polynome parallel über geeignete Schieberegister gerechnet werden, zum Beispiel das Norm CRC-Polynom für Datenfelder bis zu 8 Byte, ein zweites CRC-Polynom für Datenfelder bis zu 24 Byte und ein drittes CRC-Polynom für Datenfelder bis zu 64 Byte.
3 zeigt in vereinfachter Darstellung einen Ausschnitt des erfindungsgemäßen Empfangsprozesses, wie er auf einer Teilnehmerstation des Bussystems abläuft. Dargestellt ist hier der Fall, bei welchem eine Kompatibilität zum Norm CAN erreicht wird, indem abhängig von der ersten Umschaltbedingung das Verhalten des Kommunikationscontrollers angepasst wird. Obwohl in 3 eine für die Beschreibung von Programmabläufen in Software übliche Darstellung gewählt wurde, ist das Verfahren vollständig zur Implementierung in Hardware geeignet.
Die Teilnehmerstation befindet sich zunächst in einem den Bus abtastenden Zustand, so lange auf dem Bus kein Kommunikationsverkehr herrscht. Die Abfrage 302 wartet also auf ein dominantes Bit auf dem Bus. Dieses Bit kennzeichnet den Beginn einer neuen Nachricht.
Sobald der Beginn einer neuen Nachricht festgestellt wurde beginnt im Block 304 die Berechnung der wenigstens zwei parallel zu berechnenden Checksummen. Die erste Checksumme entspricht der CRC Berechnung des Norm CAN, während die zweite Checksumme nach dem neuen Verfahren berechnet wird.
Es werden anschließend ab dem Schritt 306 die weiteren, auf das SOF-Bit folgenden Bits der Nachricht, beginnend mit dem Arbitration Field, empfangen. Falls mehrere Busteilnehmer eine Nachricht versenden wollen, wird hierbei nach dem aus dem Norm CAN üblichen Verfahren unter den Busteilnehmern ausgehandelt, welcher Busteilnehmer den Zugriff auf den Bus erhält. Der dargestellte Block 306 kennzeichnet den Empfang aller Bits, bis die erste Kennzeichnung empfangen wurde beziehungsweise die erste Umschaltbedingung feststeht. In den aufgeführten Beispielen wird die erste Umschaltbedingung aus dem Arbitration Field, beispielsweise aus dem SRR-Bit oder dem IDE-Bit, oder aus dem Control Field, beispielsweise aus einem reservierten Bit desselben, ermittelt (vgl. 1). Anschließend können in Block 308 noch weitere Bits der Nachricht empfangen werden, bis ab einem bestimmten Bit der Nachricht abhängig von der ermittelten ersten Umschaltbedingung unterschiedlich verfahren wird. Diese Aufspaltung in unterschiedliche Verfahrensweisen wird durch eine entsprechende Abfrage oder Verzweigung 310 gewährleistet, wie im Folgenden beispielhaft dargestellt.
Liegt bei der Verzweigung 310, beispielsweise nach Empfang der ersten zwei Bits des Control Field, die Information vor, dass gemäß der ersten Umschaltbedingung die Kommunikation nach Norm CAN erfolgt (der mit „1” bezeichnete Pfad der 3), so werden im Schritt 312 die weiteren Bits des Control Field eingelesen. Aus diesen Bits wird gemäß Norm CAN der Data Length Code ausgewertet und es wird anschließend in Schritt 316 die zugehörige Menge an Daten, maximal 8 Byte, entsprechend dem Datenfeld, empfangen. Im Schritt 320 wird dann das 15 Bit umfassende CRC Feld empfangen. Liegt bei der Verzweigung 324 die Information vor, dass die die vom Sender übermittelte und die vom Empfänger selbst ermittelte CRC Checksumme übereinstimmen, wird in Block 328 ein dominantes Acknowledge-Bit gesendet. Es ist zu beachten, dass in diesem Fall die normgemäße CRC Checksumme verglichen wird, da die Kommunikation nach Norm CAN erfolgt. Wird keine Übereinstimmung festgestellt, wird (Block 330) das Acknowledge-Bit rezessiv gesendet. Anschließend folgen ACK Delimiter und EOF Bits (siehe 1b, in 3 nicht dargestellt).
Liegt hingegen bei der Verzweigung 310, beispielsweise nach Empfang der ersten zwei Bits des Control Field, die Information vor, dass gemäß der ersten Umschaltbedingung das erfindungsgemäß modifizierte Kommunikationsverfahren anzuwenden ist (der mit „2” bezeichnete Pfad der 3), so werden im Block 314 die weiteren Bits des Control Field eingelesen. Aus dem Ergebnis wird der Data Length Code nach der neuen Interpretation, für die einige Beispiele tabellenartig in 2 aufgeführt sind, ermittelt. Im Block 318 wird die entsprechende Menge an Daten, also für das Beispiel DLC 1 aus der Tabelle in 2 bis zu 15 Byte, für das Beispiel DLC 2 bis zu 16 Byte, für das Beispiel DLC 3 bis zu 64 Byte Daten empfangen. Im Block 322 wird das erfindungsgemäß abweichende, insbesondere längere CRC Feld empfangen. Liegt bei der Verzweigung 324 die Information vor, dass die vom Sender übermittelte und die vom Empfänger selbst ermittelte CRC Checksumme übereinstimmen, wobei in diesem Fall der Vergleich auf der erfindungsgemäß abweichenden CRC Checksumme basiert, wird in Block 328 ein dominantes Acknowledge-Bit gesendet. Andernfalls wird (Block 330) das Acknowledge-Bit rezessiv gesendet. Anschließend folgen in Schritt 332 beziehungsweise 334 der ACK Delimiter und die EOF Bits. Damit ist ein Empfangsprozess für eine Nachricht beendet.
In 3 wurde der Fall dargestellt, in welchem die dritte Umschaltbedingung, welche die zu verwendende CRC bestimmt, mit der ersten Umschaltbedingung, die die Größe des Datenfeldes und die Interpretation des Data Length Code betrifft, übereinstimmt. Es wurde also vor dem Empfang 320 beziehungsweise 322 der CRC Checksummen nicht nochmals abgefragt, welche CRC gemäß der dritten Umschaltbedingung zu empfangen und für die Verzweigung 324 auszuwerten ist. Durch eine einfache Modifikation des Ablaufdiagrammes aus 3 ist diese zusätzliche Abfrage in den Ablauf aufnehmbar, wie in 4 dargestellt ist.
Bei dem derartig modifizierten Empfangsprozess gemäß 4 wird nach Empfang der gemäß der Information aus dem Data Length Code erwarteten Anzahl von Datenbytes des Datenfeldes in Block 316 beziehungsweise 318 in der Abfrage oder Verzweigung 410 ermittelt, welchen Wert die dritte Umschaltbedingung aufweist. Diese Information kann, wie früher beschrieben, beispielsweise aus der entsprechenden dritten Kennzeichnung, oder aus dem Inhalt des Data Length Code ermittelt worden sein. Im dargestellten Beispiel gibt es drei verschiedene Werte für die dritte Umschaltbedingung, nämlich A, B und C. Abhängig vom Wert der Umschaltbedingung wird dann in den Blöcken 420, 422 und 424 eine unterschiedliche Anzahl von Bits des CRC Field eingelesen, beispielsweise für den Wert A 15 Bits, für den Wert B 17 Bits und für den Wert C 19 Bits. Anschließend wird bei der Verzweigung 324 analog zu 3 geprüft, ob die vom Sender übermittelte und die vom Empfänger selbst ermittelte CRC Checksumme übereinstimmen und abhängig davon weiter verfahren.
5 zeigt für weitere Ausführungsbeispiele des erfindungsgemäßen Übertragungsverfahrens nochmals die Struktur von Nachrichten in den zwei möglichen Varianten, dem Standard Format und dem Extended Format. Für beide Varianten sind in 5 Bereiche eingezeichnet, in denen zwischen zwei Zuständen, hier bezeichnet mit Fast-CAN-Arbitration und Fast-CAN-Data umgeschaltet wird. Diese Umschaltung zwischen den beiden Zuständen bewirkt in diesem Beispiel, dass nach Abschluss der Arbitrierung für einen Teil der Nachricht, insbesondere für das Datenfeld und das CRC Feld, die Bitlängen verkürzt und somit die einzelnen Bits schneller über den Bus übertragen werden. Dadurch kann die Übertragungszeit für eine Nachricht gegenüber dem normgemäßen Verfahren verkürzt werden. Der zugehörige Wechsel der zeitlichen Bitlänge kann beispielsweise durch Verwendung mindestens zweier unterschiedlicher Skalierungsfaktoren zur Einstellung der Bus-Zeiteinheit relativ zu einer kleinsten Zeiteinheit oder dem Oszillatortakt im laufenden Betrieb realisiert werden. Die Umschaltung der Bitlänge, sowie die entsprechende Veränderung des Skalierungsfaktors sind in 5 ebenfalls beispielhaft dargestellt.
Der Übergang zwischen den Zuständen Fast-CAN-Arbitration und Fast-CAN-Data kann abhängig von einer vierten Umschaltbedingung erfolgen, welche mit einer Kennzeichnung der Nachrichten korrespondiert, die den Teilnehmern der Datenübertragung signalisiert, dass die verkürzte Bitlänge angewendet wird. In dem hier dargestellten Ausführungsbeispiel ist die gewählte Position dieser Kennzeichnung das „reserved bit” r0, das vor dem Data Length Code übertragen wird. Sie entspricht also einer möglichen Position der ersten Kennzeichnung, welche zur ersten Umschaltbedingung korrespondiert und die mögliche Verwendung längerer Datenfelder und einer geänderten Interpretation des Data Length Code kennzeichnet, und auch der dritten Kennzeichnung, welche zu einer geänderten CRC Berechnung korrespondiert.
In diesem Fall, in dem also die erste Umschaltbedingung mit der dritten und vierten Umschaltbedingung zusammenfällt, werden im erfindungsgemäßen Übertragungsverfahren Nachrichten übertragen, deren Bitlänge deutlich verkürzt, deren Datenfeldgröße auf Werte oberhalb 8 Byte ausdehnbar, und deren CRC an das größere Datenfeld angepasst ist. Erhebliche Steigerung der Übertragungskapazität über das Bussystem bei gleichzeitig verbesserter Übertragungssicherheit werden so erreicht.
Die schnellere Übertragung beginnt beispielsweise unmittelbar nach Versenden der zugehörigen Kennzeichnung und wird unmittelbar nach Erreichen des für die Rückumschaltung festgelegten Bits beendet oder dann, wenn ein Grund zum Start eines Error-Frames erkannt wurde.
Das Verfahren eignet sich im normalen Betrieb eines Kraftfahrzeuges zur Übertragung von Daten zwischen wenigstens zwei Steuergeräten des Kraftfahrzeuges, welche über einen geeigneten Datenbus verbunden sind. Es ist aber gleichermaßen vorteilhaft einsetzbar während der Fertigung oder Wartung eines Kraftfahrzeuges zur Übertragung von Daten zwischen einer zum Zwecke der Programmierung mit einem geeigneten Datenbus verbundenen Programmierungseinheit und wenigstens einem Steuergerät des Kraftfahrzeuges, welches mit dem Datenbus verbunden ist.
Insgesamt stellt das Verfahren ein Übertragungsverfahren dar, welches sich dadurch auszeichnet, dass ein Norm-CAN Controller nur minimal geändert werden muss, um erfindungsgemäß arbeiten zu können. Ein erfindungsgemäßer Kommunikationscontroller, der auch als Norm-CAN Controller arbeiten kann, ist nur unwesentlich größer als ein herkömmlicher Norm-CAN Controller. Das zugehörige Anwendungs-Programm muss nicht geändert werden, und schon dann werden Vorteile in der Geschwindigkeit der Datenübertragung erzielt. Durch Verwendung der erweiterten Größe des Datenfeldes und der zugehörigen DLC und CRC kann die Geschwindigkeit der Datenübertragung weiter gesteigert werden, die Anpassungen in der Anwendungs-Software sind minimal. Es können weite Teile des CAN-Conformance-Tests (ISO 16845) übernommen werden. Es ist auch möglich, das erfindungsgemäße Übertragungsverfahren mit den Ergänzungen des TTCAN (ISO 11898-4) zu kombinieren.
Zumindest für bestimmte Anwendungszwecke oder in einer Einführungsphase ist es sinnvoll, für das erfindungsgemäße Datenübertragungsverfahren und die Vorrichtungen, welche es ausführen, eine Variante vorzusehen, welche sich vollständig oder weitgehend kompatibel hinsichtlich der verwendeten Anwendungs-Software verhält. Diese Anwendungs-Software kann beispielsweise die Regelungs-Software eines elektronischen Stabilitätsprogrammes für Kraftfahrzeuge oder die Ansteuerungs-Software für einen Verbrennungsmotor eines Kraftfahrzeuges sein: Die Anwendungs-Software unterliegt insbesondere für sicherheitskritische Systeme umfangreichen Absicherungsprogrammen und es ist daher vorteilhaft, die Einführung von erfindungsgemäß geänderten Datenübertragungsvorrichtungen bei unveränderter Anwendungs-Software durchführen zu können.
Die Weitergabe von Daten zwischen dem Datenfeld einer Nachricht und der Anwendungs-Software erfolgt in Kommunikationscontrollern über einen für diese Verwendung vorgesehenen Zwischenspeicher, der im Norm-CAN eine vorgegebene Größe von beispielsweise acht Byte aufweist, und einen zugehörigen Nachrichtenspeicher. Mit Zwischenspeicher und Nachrichtenspeicher kann im Zusammenhang mit der vorliegenden Erfindung auch ein für die entsprechende Verwendung zugewiesener Bereich innerhalb einer größeren Speichereinheit gemeint sein.
Dementsprechend werden in Systemen, welche eine Datenübertragung per Norm-CAN durchführen, von der Anwendungs-Software Datenpakete von höchstens acht Byte Größe über meistens zahlreiche Nachrichtenspeicher und Zwischenspeicher mit dem Datenfeld von CAN-Nachrichten ausgetauscht. Bleibt die Anwendungs-Software unverändert, so kann man auch die Nachrichtenspeicher und Zwischenspeicher bei der vorgegebene Größe von beispielsweise acht Byte belassen, um die Größe beziehungsweise Chipfläche des erfindungsgemäßen Kommunikationscontrollers nicht unnötig zu erhöhen. Wenn die Größe des Datenfeldes einer erfindungsgemäßen Nachricht (beispielsweise 16 Byte) sich nun von der Größe des verwendeten Zwischenspeichers (beispielsweise acht Byte) unterscheidet, ist es notwendig, das Protokoll-Steuerwerk des Kommunikationscontrollers entsprechend der Größendifferenz zwischen Datenfeld und Zwischenspeicher anzupassen.
Ein weiteres, in 6 am Beispiel einer Nachricht im Standard Format mit einem Datenfeld von 16 Byte Größe illustriertes Ausführungsbeispiel des erfindungsgemäßen Datenübertragungsverfahrens sieht daher vor, dass bezüglich der seriellen Übertragung von Bits über den Bus die volle Funktionalität des Verfahrens ausgeführt wird, dass jedoch lediglich acht Bytes an relevanten Nutzdaten im Datenfeld übertragen werden. Während also bei entsprechendem Vorliegen einer Umschaltbedingung über den Bus beispielsweise eine Nachricht mit einem Datenfeld von 16 Byte Größe und einer zugehörigen Kennzeichnung übertragen wird und die Nachricht durch ein entsprechend angepasstes CRC-Polynom auf korrekte Übertragung geprüft wird, werden an die Anwendungs-Software 640 über den Zwischenspeicher 620 und beispielsweise einen Nachrichtenspeicher 630 im erfindungsgemäßen Kommunikationscontroller lediglich acht Bytes an Nutzdaten übergeben. Im Sendefall werden von der Anwendungs-Software 640 acht Bytes Nutzdaten beispielsweise über einen weiteren oder denselben Nachrichtenspeicher 630 in den Zwischenspeicher 620 geschrieben, welche nach einem vorgegebenen oder vorgebbaren Verfahren in das beispielsweise 16 Byte große Datenfeld der zu versendenden Nachricht eingetragen werden. Natürlich ist es auch möglich, das Verfahren auf eine von acht Byte abweichende Größe des Zwischenspeichers zu beschränken, beispielsweise sechs oder vier Bytes, sofern die Anwendungs-Software ebenfalls diese Beschränkung vorsieht. Auch die Wahl der Größe des Datenfeldes von 16 Byte ist nur beispielhaft zu verstehen. Zahlreiche andere Möglichkeiten sind etwa der 2 zu entnehmen.
Das Protokoll-Steuerwerk des Kommunikationscontrollers platziert in diesem Ausführungsbeispiel, wie in 6 durch den Doppelpfeil 600 symbolisiert, bei der Serialisierung der zu übertragenden Daten beispielsweise die acht Nutzdaten-Bytes aus dem Zwischenspeicher 620 in den ersten acht seriellen Bytes des Datenfeldes und füllt die weiteren Bits des Datenfeldes, wie in 6 durch den Pfeil 610 dargestellt, mit vorgegebenen, vorgebbaren oder auch beliebigen Fülldaten auf, beispielsweise mit einem bestimmten Bit-Muster. Es ist sinnvoll, dass hierbei eine Bitfolge verwendet wird, welche nicht zu einem Einfügen zusätzlicher Stuff-Bits nach den Regeln der CAN-Norm ISO 11898-1 führt, da sonst das Datenfeld unnötig vergrößert wird. Es kann also beispielsweise für jedes ungenutzte Byte des Datenfeldes eine Bitfolge 0b00110011 oder 0b11001100 eingefügt werden.
Es ist auch möglich, dass die beispielsweise acht Nutzdaten-Bytes des Zwischenspeichers 620 nicht in den ersten acht Bytes des Datenfeldes, sondern an einer anderen Position oder in mehreren anderen Bereichen innerhalb des Datenfeldes eingetragen werden. Die Position der Nutzdaten-Bytes muss lediglich für die Busteilnehmer einheitlich vorgegeben oder vorgebbar sein.
Die empfangenden Busteilnehmer lesen die Nachricht gemäß dem erfindungsgemäßen Verfahren, führen beispielsweise die CRC-Prüfung durch und bestätigen korrekten Empfang durch Acknowledge. Das Protokoll-Steuerwerk im Kommunikationscontroller der empfangenden Busteilnehmer setzt die seriell empfangenen Bits der Nachricht um und extrahiert aus den beispielsweise 16 Byte des Datenfeldes dabei die acht Bytes an Nutzdaten, welche in den Zwischenspeicher 620 geschrieben werden. Dies ist in 6 ebenfalls durch den Doppelpfeil 600 symbolisiert. Die restlichen Fülldaten werden verworfen. An die Anwendungs-Software 640 werden also lediglich die acht Byte Nutzdaten über den Zwischenspeicher 620 und beispielsweise den Nachrichtenspeicher 630 übergeben. Die Anwendungs-Software 640 stellt selbst keinen Unterschied im Vergleich zur Verwendung des normgemäßen Übertragungsverfahrens fest.
Zur fehlersicheren Implementierung der verschiedenen Ausführungsformen des erfindungsgemäßen Datenübertragungsverfahrens, also insbesondere der Verfahren mit in Teilbereichen der Nachricht verkürzter Bitlänge, mit geänderter Länge des Datenfeldes und modifizierter, eventuell auch mehrstufig modifizierter Interpretation des Inhaltes des Data Length Code, mit Verwendung unterschiedlicher CRC-Checksummen oder auch mit Anpassung der weitergegebenen Datenmange an die Größendifferenz zwischen Datenfeld und Zwischenspeicher, sind weitere Ergänzungen sinnvoll.
Durch geeignete Statusregister wird beispielsweise im Norm-CAN gewährleistet, dass das Erreichen eines Fehler-Status (Error-Warning, Error-Passive, Bus-Off), welcher bei einer entsprechenden Häufung von Fehlern in der Datenübertragung eingenommen wird, abgelesen werden kann. Weiterhin werden erfolgreiche Sende- und Empfangsvorgänge durch Flags signalisiert (TxOK, RxOK) und es wird eine Information über das jeweils letzte Busereignis bereitgehalten (LEC, Last Error Code). Einige oder alle dieser Informationen können in erfindungsgemäßen Kommunikationscontrollern in dafür vorgesehenen Speicherbereichen mehrfach vorgehalten werden, so dass die jeweilige Information je nach aktuell ausgeführtem Datenübertragungsverfahren separat erfasst und abgespeichert wird. Dadurch kann festgestellt werden, ob bei einem gegenüber der CAN-Norm modifizierten Übertragungsverfahren, beispielsweise einem längeren Datenfeld oder eine kürzeren Bitlänge in Bereichen der Nachricht, ein bestimmtes Fehlerbild häufiger auftritt, als dies im Norm-CAN-Übertragungsverfahren der Fall ist.
Es kann ein zusätzlicher Fehler-Status eingeführt und durch ein Status-Bit signalisiert werden, der bei Fehlerhäufung im modifizierten Übertragungsmodus die Datenübertragung permanent in das Norm-CAN-Übertragungsverfahren zurückschaltet. Es können die Informationen TxOK, RxOK und LEC separat für die verschiedenen Datenübertragungsverfahren erfasst werden. Es kann alternativ für den LEC die Information zusätzlich abgelegt werden, in welchem Übertragungsmodus der Fehler auftrat.
Weiterhin kann es sinnvoll sein, für empfangene Nachrichten festzuhalten, nach welchem Verfahren und mit welcher der möglichen Kennzeichnungen sie empfangen wurden und für zu sendende Nachrichten individuell festzulegen, nach welchem Verfahren und mit welcher Kennzeichnung sie versendet werden sollen. Bestimmte oder alle Empfangs-Nachrichtenspeicher und/oder Zwischenspeicher können hierzu mit einer Anzahl von zusätzlichen Bits ergänzt werden, welche zu den möglichen Kennzeichnungen korrespondieren. Es kann auch in weiteren dafür vorgesehenen Bits die Information separat abgelegt werden, in welchem Zustand beziehungsweise unter welcher Umschaltbedingung die jeweilige Nachricht empfangen wurde. Analog können auch bestimmte oder alle Sende-Nachrichtenspeicher und/oder Zwischenspeicher mit zusätzlichen Bits versehen werden, in welche eingetragen wird, dass die jeweilige Nachricht in einem modifizierten Verfahren und/oder mit einer entsprechenden Kennzeichnung versendet werden soll.
Schließlich kann es sinnvoll sein, einen erfindungsgemäßen Kommunikationscontroller so auszulegen, dass er durch eine geeignete Umkonfiguration zwischen dem Anwendungs-Software-kompatiblen Modus mit eine Begrenzung der zwischen Datenfeld der Nachricht und Anwendungs-Software weitergegebenen Datenmenge auf beispielsweise 8 Byte und einem Datenübertragungs-optimierten Modus mit Nutzung der vollen Größe des Datenfeldes unter Nutzung eines entsprechend großausgelegten verwendeten Zwischenspeichers umgeschaltet werden kann. In diesem Fall kann zwar nicht die entsprechende Einsparung bei Größe beziehungsweise Chipfläche durch Verwendung entsprechend kleinerer Zwischenspeicher und/oder Nachrichtenspeicher erzielt werden, der Kommunikationscontroller ist jedoch sehr flexibel in Busteilnehmern, welche eine bestehende Anwendungs-Software weiternutzen und auch in Busteilnehmern, für welche eine neue, Datenübertragungs-optimierte Software erstellt wurde, einsetzbar.
Dieser umschaltbare Kommunikationscontroller sollte dann auch seinen aktuell genutzten Modus, also den Anwendungs-Software-kompatiblen Modus oder den Datenübertragungs-optimierten Modus, in einem hierfür vorgesehenen Speicherbereich beispielsweise durch ein entsprechendes Status-Bit sichtbar machen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 10311395 A1 [0005]
DE 102007051657 A1 [0006]

Zitierte Nicht-Patentliteratur

ISO 11898-1 bis -5 [0002]
„Bosch Kraftfahrtechnisches Handbuch”, 27. Auflage, 2011, Vieweg + Teubner [0004]
G. Cena und A. Valenzano behandeln in „Overclocking of controller area networks” (Electronics Letters, Vol. 35, No. 22 (1999), S. 1924) [0007]
CAN-Norm ISO 11898-1 [0010]
CAN-Norm ISO 11898-1 [0010]
CAN-Norm ISO 11898-1 [0011]
CAN-Norm ISO 11898-1 [0015]
CAN-Norm ISO 11898-1 [0015]
ISO 16845 [0019]
ISO 11898-4 [0019]
CAN-Norm ISO 11898-1 [0021]
CAN-Norm ISO 11898-1 [0023]
ISO 16845 [0059]
ISO 11898-4 [0059]
CAN-Norm ISO 11898-1 [0064]

Claims

Verfahren zur seriellen Datenübertragung in einem Bussystem mit mindestens zwei teilnehmenden Datenverarbeitungseinheiten, die über den Bus Nachrichten austauschen, wobei die gesendeten Nachrichten einen logischen Aufbau gemäß der CAN-Norm ISO 11898-1 aufweisen, dadurch gekennzeichnet, dass zumindest bei Vorliegen einer ersten Umschaltbedingung das Datenfeld der Nachrichten abweichend von der CAN-Norm ISO 11898-1 mehr als acht Bytes umfassen kann, wobei zur Feststellung der Größe des Datenfeldes zumindest bei Vorliegen der ersten Umschaltbedingung die Werte der vier Bits des Data Length Codes zumindest teilweise abweichend von der CAN-Norm ISO 11898-1 interpretiert werden, wobei für die Weitergabe von Daten zwischen dem Datenfeld und der Anwendungs-Software (640) wenigstens ein Zwischenspeicher (620) vorgesehen ist und die weitergegebene Datenmenge zumindest, wenn die Größe des Datenfeldes sich von der Größe des verwendeten Zwischenspeichers (620) unterscheidet, entsprechend der Größendifferenz zwischen Datenfeld und verwendetem Zwischenspeicher (620) angepasst wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass aus dem Datenfeld einer über den Bus empfangenen Nachricht eine der Größe des Zwischenspeichers entsprechende Datenmenge nach einem vorgegebenen oder vorgebbaren Auswahlverfahren ausgewählt und an den Zwischenspeicher weitergegeben wird, wenn die Größe des Datenfeldes über der Größe des verwendeten Zwischenspeichers liegt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass in das Datenfeld einer über den Bus zu sendenden Nachricht der Inhalt des Zwischenspeichers in wenigstens einen vorgegebenen oder vorgebbaren Bereich des Datenfeldes der Nachricht eingetragen und der oder die verbleibenden Bereiche des Datenfeldes nach einem vorgegebenen oder vorgebbaren Verfahren aufgefüllt werden, wenn die Größe des Datenfeldes über der Größe des verwendeten Zwischenspeichers liegt.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der wenigstens eine Zwischenspeicher acht Bytes umfasst und bei einer Größe des Datenfeldes einer über den Bus empfangenen Nachricht von mehr als acht Bytes über den wenigstens einen Zwischenspeicher acht vorgegebene oder vorgebbare Bytes des Datenfeldes an die Anwendungs-Software übergeben werden.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der wenigstens eine Zwischenspeicher acht Bytes umfasst und bei einer Größe des Datenfeldes einer über den Bus zu sendenden Nachricht von mehr als acht Bytes die verbleibenden Bits des Datenfeldes mit vorgegebenen, vorgebbaren oder beliebigen Werten aufgefüllt werden.
Verfahren nach einem der Ansprüche 3 bis 5, dadurch gekennzeichnet, dass die Bits in den aufgefüllten Bereichen des Datenfeldes einer über den Bus zu sendenden Nachricht so aufgefüllt werden, dass gemäß den Regeln des CAN-Norm ISO 11898-1 in diesen Bereichen keine Stuff-Bits eingefügt werden müssen.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass gegebenenfalls in Abhängigkeit vom Wert der ersten Umschaltbedingung jede der möglichen Wertekombinationen der vier Bits des Data Length Code einer der zulässigen Größen des Datenfeldes zugeordnet ist.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Nachrichten, in denen das Datenfeld der Nachrichten abweichend von der CAN-Norm ISO 11898-1 mehr als acht Bytes umfassen kann und zur Feststellung der Größe des Datenfeldes die Werte der vier Bits des Data Length Codes zumindest teilweise abweichend von der CAN-Norm ISO 11898-1 interpretiert werden müssen, durch eine erste Kennzeichnung im Arbitration Field und/oder im Control Field von CAN-normgemäßen Nachrichten unterscheidbar sind und die erste Kennzeichnung in den teilnehmenden Datenverarbeitungseinheiten zur Ermittlung der ersten Umschaltbedingung ausgewertet wird, so dass abhängig von der ersten Umschaltbedingung der Empfangsprozess an die Größe des Datenfeldes angepasst wird.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die erste Kennzeichnung durch ein reserviertes Bit r0 oder r1 des Control Field und/oder durch das SRR-Bit des Arbitration Field erfolgt.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass zumindest in Abhängigkeit vom Wert einer vierten Umschaltbedingung die zeitliche Bitlänge innerhalb einer Nachricht mindestens zwei unterschiedliche Werte annehmen kann, wobei für wenigstens einen zweiten vorgebbaren Bereich innerhalb der Nachricht die zeitliche Bitlänge eine im Vergleich zu einem ersten Bereich einen höchstens halb so großen Wert aufweist.
Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass die mindestens zwei unterschiedlichen Werte der zeitlichen Bitlänge innerhalb einer Nachricht durch Verwendung mindestens zweier unterschiedlicher Skalierungsfaktoren zur Einstellung der Bus-Zeiteinheit relativ zu einer kleinsten Zeiteinheit oder dem Oszillatortakt im laufenden Betrieb realisiert werden.
Verfahren nach Anspruch 10 oder 11, dadurch gekennzeichnet, dass die Nachrichten, in denen in Abhängigkeit vom Wert einer vierten Umschaltbedingung die zeitliche Bitlänge innerhalb einer Nachricht mindestens zwei unterschiedliche Werte annehmen kann, durch eine vierte Kennzeichnung im Arbitration Field und/oder im Control Field erkennbar sind, wobei die vierte Kennzeichnung mit der ersten Kennzeichnung übereinstimmen kann.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass der Wert der vierten Umschaltbedingung in den teilnehmenden Datenverarbeitungseinheiten in Abhängigkeit von der vierten Kennzeichnung ermittelt wird oder mit der ersten Umschaltbedingung übereinstimmt oder aus der ersten Umschaltbedingung abgeleitet wird, wobei abhängig vom Wert der vierten Umschaltbedingung der Empfangsprozess an die unterschiedlichen Werte der Bitlänge innerhalb einer Nachricht angepasst wird.
Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass für die von der CAN-Norm ISO 11898-1 abweichenden Datenübertragungsverfahren, welche in Abhängigkeit von der ersten und/oder vierten Umschaltbedingung ausgeführt werden, wenigstens ein zusätzliches Status-Bit vorgesehen ist, welches das Ergebnis der Datenübertragung kennzeichnet.
Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass das wenigstens eine zusätzliche Status-Bit ein Status-Bit zur Kennzeichnung des erfolgreichen Sendens und/oder ein Status-Bit zur Kennzeichnung des erfolgreichen Empfangs und/oder ein oder mehrere Status-Bits zur Kennzeichnung der Art des zuletzt aufgetretenen Fehlers umfasst.
Verfahren nach Anspruch 14 oder 15, dadurch gekennzeichnet, dass abhängig von der Häufigkeit des Auftretens von Fehlern in einem von der CAN-Norm ISO 11898-1 abweichenden Datenübertragungsverfahren in das Übertragungsverfahren gemäß CAN-Norm ISO 11898-1 zurückgeschaltet wird und wenigstens ein Status-Bit zur Kennzeichnung der erfolgten Rückumschaltung vorgesehen ist.
Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass in dem wenigstens einen Zwischenspeicher und/oder wenigstens einem zugeordneten Nachrichtenspeicher wenigstens ein zusätzliches Nachrichten-Bit vorgesehen ist, welches das für die jeweilige Nachricht verwendete oder zu verwendende Verfahren zur Datenübertragung kennzeichnet.
Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass das wenigstens eine zusätzliche Nachrichten-Bit wenigstens einem der Werte der ersten oder vierten Kennzeichnung entspricht oder aus deren Werten abgeleitet wird oder wenigstens einem der Werte der Bits r1 oder r0 des Control Field oder SRR des Arbitration Field entspricht.
Vorrichtung zur seriellen Datenübertragung in einem Bussystem mit mindestens zwei teilnehmenden Datenverarbeitungseinheiten, die über den Bus Nachrichten austauschen, wobei die gesendeten Nachrichten einen logischen Aufbau gemäß der CAN-Norm ISO 11898-1 aufweisen, dadurch gekennzeichnet, dass zumindest bei Vorliegen einer ersten Umschaltbedingung das Datenfeld der Nachrichten abweichend von der CAN-Norm ISO 11898-1 mehr als acht Bytes umfassen kann, wobei zur Feststellung der Größe des Datenfeldes zumindest bei Vorliegen der ersten Umschaltbedingung die Werte der vier Bits des Data Length Codes zumindest teilweise abweichend von der CAN-Norm ISO 11898-1 interpretiert werden, wobei für die Weitergabe von Daten zwischen dem Datenfeld und der Anwendungs-Software wenigstens ein Zwischenspeicher vorgesehen ist und die weitergegebene Datenmenge zumindest, wenn die Größe des Datenfeldes sich von der Größe des verwendeten Zwischenspeichers unterscheidet, entsprechend der Größendifferenz zwischen Datenfeld und verwendetem Zwischenspeicher angepasst wird.
Vorrichtung nach Anspruch 19, dadurch gekennzeichnet, dass die Vorrichtung durch geeignete Mittel dafür eingerichtet ist, zumindest eines der Verfahren zur Datenübertragung gemäß Anspruch 2 bis 18 auszuführen.
Vorrichtung nach Anspruch 20, dadurch gekennzeichnet, dass die geeigneten Mittel zumindest ein Protokoll-Steuerwerk zur Anpassung der zwischen dem Datenfeld und dem Zwischenspeicher weitergegebenen Datenmenge entsprechend der Größendifferenz zwischen Datenfeld und Zwischenspeicher umfassen.
Vorrichtung nach einem der Ansprüche 20 oder 21, dadurch gekennzeichnet, dass die geeigneten Mittel zumindest ein zusätzliches oder erweitertes Statusregister umfassen, dessen Inhalt die Art und/oder den Erfolg und/oder das Ergebnis des jeweils verwendeten Datenübertragungsverfahrens kennzeichnet.
Vorrichtung nach einem der Ansprüche 20 bis 22, dadurch gekennzeichnet, dass die geeigneten Mittel zumindest einen zusätzlichen oder erweiterten Nachrichtenspeicher und/oder Zwischenspeicher umfassen, in welchem wenigstens ein zusätzliches Nachrichten-Bit das für die jeweilige Nachricht verwendete oder zu verwendende Verfahren zur Datenübertragung kennzeichnet.
Verwendung des Verfahrens nach einem der Ansprüche 1 bis 18 im normalen Betrieb eines Kraftfahrzeuges zur Übertragung von Daten zwischen wenigstens zwei Steuergeräten des Kraftfahrzeuges, welche über einen geeigneten Datenbus verbunden sind.
Verwendung des Verfahrens nach einem der Ansprüche 1 bis 18 während der Fertigung oder Wartung eines Kraftfahrzeuges zur Übertragung von Daten zwischen einer zum Zwecke der Programmierung mit einem geeigneten Datenbus verbundenen Programmierungseinheit und wenigstens einem Steuergerät des Kraftfahrzeuges, welches mit dem Datenbus verbunden ist.