CAN Bus Einführung

---

Der „Controller Area Network“ Bus ist eine Spezifikation der International Standard Organisation nach ISO/CD 11898. Die gesamte Busspezifikation mit allen im Standard verfügbaren Varianten teilt sich auf in:

• ISO/CD 11898-1 Part 1: Data Link Layer and physical signaling
• ISO/CD 11898-2 Part 2: High speed medium access unit
• ISO/CD 11898-3 Part 3: Low speed fault tolerant medium dependant interface
• ISO/CD 11898-4 Part 4: Time Triggered CAN
• ISO/CD 11898-5 Part 5: High speed medium access unit with low power mode

Der CAN Bus ist ein Multimaster-Bus mit Zugriffsprioritäten. Die Bus Arbitrierung basiert auf der Vermeidung von Kollisionen und optimiert deshalb die ausnutzbare Bandbreite. Der CAN Bus ist für heutige Verhältnisse kein Hochgeschwindigkeitsbus und erlaubt deshalb auch keine Übertragung von grossen Datenmengen. Darauf ausgelegt ist auch das Format der Datenpakete das maximal 8 Byte an Information innerhalb eines Paketes erlaubt.

In einer neuen hinzugekommenen Spezifikation des „CAN-FD“ (Flexible Datarate) wurde daher eine Möglichkeit geschaffen die maximale Übertragungsrate zu erhöhen ohne die Kompatibilität zum „normalen“ CAN-Bus zu verlieren. Beim CAN-FD wird nur das „Datenfeld“ mit einer erhöhten Taktrate übertragen und kann bis zu 64 Byte enthalten.

Eine Besonderheit des CAN-Busses ist die Identifizierung des Dateninhalts anstatt einer Sende bzw. Empfangs Adresse. Daten werden im Broadcast Verfahren gesendet und von jeder an der spezifischen Information interessierten Node ausgewertet.

Zwei unterschiedliche Übertragungsschemas werden durch den CAN Bus unterstützt.

Das freie Absetzen von Nachrichten auf dem Bus bzw. das gezielte Abfragen von Informationen durch einen „Remote Request“. Dafür existieren in der Spezifikation unterschiedliche Übertragungsrahmen.

Bei Verlust des Zugriffsrechts bzw. bei fehlerhafter Übertragung greift ein automatisches „Retransmission“ Verfahren das die sichere Übertragung gewährleistet ohne die Node unnötig zu belasten.

Durch die Kennzeichnung der Dateninhalte haben Busteilnehmer keine spezifische Kennung (Adresse) und die gesamte Businfrastruktur ist für den Betrieb des CAN Busses unerheblich. Teilnehmer können jederzeit auf den Bus aufgeschaltet bzw. vom Bus genommen werden ohne die Funktionsfähigkeit zu beeinträchtigen. Es gibt nur eine Einschränkung, zwei Nodes dürfen nicht die gleiche CAN-ID (Message-ID) benutzen, jedoch darf jede Node mehrere IDs benutzen.

Der CAN Bus ist auf eine hohe Fehlersicherheit ausgelegt. Fehler können erkannt und in einem gewissen Rahmen auch abgestellt werden. Die Fehlerhäufigkeit führt zu unterschiedlichen Eskalationsstufen, die bis zum Abschalten einer Node über einen definierten Zeitraum führen kann.

Open System Interconnect

Die CAN Bus Spezifikation setzt auf der „Open System Interconnect“ Struktur auf. Diese Struktur basiert auf dem ISO 7-Layer Modell:

 

Figure 1: OSI 7 Layer Model

Innerhalb der CAN Spezifikation sind nur Layer 1 „Physical Layer“ und der Layer 2 „ Data Link Layer“ relevant.

Figure 2: CAN Layer Model

Bit Übertragungsschicht (Physical Layer)

Der CAN-Bus ist normalerweise ein differenzieller Zwei-Draht-Bus.

Da die Implementierung eines CAN-Busses immer in einer „spezifischen“ Umgebung (z.B. einem Fahrzeug) definiert ist, gibt es keine allgemein gültige Spezifikation mit der alle mit einem „CAN-Bus“ ausgerüsteten Geräte in allen Systemen zusammen kommunizieren können. Diese Freiheit in der  CAN Spezifikation erlaubt neben dem differenziellen Zwei-Draht-Bus (High-speed CAN und Fault tolerant CAN) auch eine andere Implementierung, wie den „single-ended“ Bus (nur eine Leitung) der teilweise in low-speed CAN Systemen eingesetzt wird.

Die physikalischen Pegel auf CAN Bus Systemen.

Aus Gründen der Übertragungssicherheit wird ein differenzieller Bus bevorzugt eingesetzt. Auf einem „differenziellen“ CAN-Bus erfolgt die Bit-Codierung durch aktivieren unterschiedlicher Pegel auf den beiden „symetrischen“ Leitungen. Dabei werden aber keine symetrischen Spannungen benutzt wie bei einem RS232/V.24 Interface (z.B. +/- 12 Volt) sondern 0 und 5Volt bzw. 0 und 3.3 Volt bedingt durch die „Physical Layer Bausteine“ die üblicherweise mit 5 bzw. 3.3 Volt betrieben werden.

Die drei Varianten des „Physical Layers“ werden bezeichnet als:

• Differential CAN  („rezessiv“ = floating, differentielle Terminierung)
• Fault Tolerant CAN  (“rezessive” = Ruhepegel, Vcc/Gnd Terminierung )
• Single Ended CAN( single “wired-OR”, Pull up Terminierung )

Durch die unterschiedliche Terminierung des Ein- bzw. Zweidraht-Busses ergeben sich unterschiedliche Bus-Pegel für die binäre Information. Die Differenzspannung ergibt sich aus der Formel:

V_diff = V_{CAN_H} – V_{CAN_L}

Single Ended CAN

Im Fahrzeugbau war bzw. ist noch immer die Karosserie der elektrische Bezugspunkt für Lastströme und Signale. Es ist also denkbar für den CAN-Bus nur eine Leitung zu verwenden und diesen Leitungspegel auf das gemeinsame Massepotential zu referenzieren.

 

Durch die im Fahrzeug auftretenden sehr hohen Lastströme und die damit verbundene Verschiebung des Referenzpotentials an den einzelnen Kontaktpunkten ist der Störspannungsabstand für die Übertragung von Daten auf einem „Single Ended Bus“ wesentlich schlechter als bei einem differentiellen System. Eine Fehlertoleranz bezüglich physikalischer Verbindungsfehler besteht natürlich auch nicht.

Differential CAN Bus Pegel

Der Differential CAN wird an beiden Enden der Busleitung mit 120 Ohm Widerständen (R_L = 100 .. 130 Ohm nach ISO )  zwischen den beiden Busleitungen terminiert. Die Parallelschaltung der beiden 120 Ohm Widerstände ergibt eine Last von ~ 60 Ohm.

Laut ISO Spezifikation 11898-2 gilt für die differenzielle Spannung auf den Busleitungen:

Table 1 : Bus-Pegel Differential CAN

Um an einem 60 Ohm Widerstand (2 x 120 Ohm parallel) einen Spannungsabfall von 1,2 Volt (minimum „High“-Level) zu erzeugen müssen mindestens 20 mA Querstrom fliessen, bei einem nominalen Pegel von 2.0 Volt sogar 33 mA. Der CAN-Bus erfordert deshalb eine gewisse Treiberleistung wobei zu der rein „Ohm´schen“ Last noch die kapazitiven Lasten der einzelnen Nodes hinzukommen.

Fault Tolerant CAN Bus Pegel

Im Gegensatz zum Differential CAN werden die CAN-Bus Leitungen durch Terminierungs-Widerstände auf einen definierten Ruhepegel gebracht. CAN_H wird dabei gegen 0 Volt (Masse) , CAN_L gegen die Betriebsspannung (Vcc, nominal 5 Volt) über einen Widerstand von mindestens 500 Ohm terminiert. Der resultierende Abschlusswiderstand  auf dem Bus sollte dabei 100 Ohm nicht unterschreiten.

 

 

Ebenfalls im Gegensatz zum Differential CAN Bus ist eine solche Terminierung an jedem Bus-Teilnehmer (Node) vorgesehen, aber nicht zwingend notwendig. Übliche „Physical Layer“ Bausteine für einen „Fault Tolerant CAN“ bieten gesonderte Anschlüsse für die Referenzpegel der Terminierungswiderstände, diese Anschlüsse sind in der ISO Spezifikation definiert als RTH und RTL.

 

 

Laut ISO Spezifikation 11898-3 gilt für die Spannung auf der Busleitung:

Table 2 : Bus-Pegel Fault Tolerant CAN

„Fault tolerant“ heisst diese Art von CAN Bus deshalb weil jede der beiden Leitungen sowohl gegen Masse als auch gegen Vcc kurzgeschlossen werden kann und eine Übertragung damit immer noch möglich ist. Auch die Unterbrechung einer der beiden Leitungen kann damit kompensiert werden und es ist weiterhin eine Übertragung, wenn auch mit verringertem Störspannungsabstand, möglich.

Eine Besonderheit in einem fehlertolerantem CAN-Bus System ist der „Low Power Mode“. Dabei können einzelne Bus-Teilnehmer (Nodes) die Terminierung gegen die Batteriespannung abschalten um die zu treibende Bus-Last zu verringern.

Da bei solchen Systemen die gesamte Node in einen „Power Down“ Zustand geschaltet werden kann ist eventuell auch keine Betriebsspannung mehr vorhanden.

Die Terminierung über den Schalttransistor erfolgt deshalb nicht gegen V_cc sondern gegen V_Bat.

Spannungsfestigkeit der CAN Systeme

Die oben aufgeführten Signalpegel geben die im normalen Betrieb auftretenden Signal-Spannungen an. Die CAN Nodes müssen aber auf weitaus höhere Spannungen getestet werden. Im Fehlerfall oder beim Fahrzeugstart können wesentlich höhere aber auch hohe negative Spannungen bezogen auf das Massepotential auftreten.

In ISO 11898-3 werden folgende Spannungspegel für die Bus-Leitungen CAN-H und CAN_L als Zustände angegeben bei denen ein Betrieb noch möglich ist. Dabei werden 12V und 42V Bordnetze in Betracht gezogen.

 

Table 3 : Spannungsfestigkeit

Die angegebenen Spannungen dürfen keine Schäden verursachen und die Dauer des auftretenden Fehlerfalles ist nicht begrenzt. Die Spannungen beziehen sich auf Masse als gemeinsamen Referenzpunkt.

Die Bit-Codierung der Daten auf dem Bus

In der Übertragung der Daten auf dem CAN-Bus ist kein Anteil des Übertragungstaktes vorgesehen (asynchron), deshalb ist auch kein spezieller „Linecode“ (eine Umcodierung der Daten in ein Signal mit vermehrten, bzw. garantierten Signalübergängen) notwendig.

Wichtig war bei der Definition des CAN-Busses vor Allem die Übertragungssicherheit, weshalb die einfachste und mit der geringsten Taktrate mögliche Daten-Codierung gewählt wurde, das NRZ-Verfahren . „Non Return to Zero“ deshalb weil der Signalpegel innerhalb eines Bits nicht notwendigerweise in den Ruhezustand zurückkehrt. Eine logische „0“ wird also durchgehend als der „Eine“ Zustand und eine logische „1“ als der binär alternative Zustand dargestellt.

 

Idle Zustand auf dem Bus

Im „Idle“-Zustand ist der Bus statisch auf einem, dem Zustand „1“ entsprechenden Pegel.

Die CAN-Bus Leitungen werden wie oben beschrieben, je nach Implementierung, differenziell oder gegen feste Pegel terminiert. Diese Terminierungswiderstände haben zwei Aufgaben.

• Die Busleitungen haben ohne Einwirkung eines angeschlossenen Gerätes einen definierten Pegel (der einer logischen „1“ entspricht).
• Bei dynamischer Nutzung des Busses treten keine Signal-Reflektionen an den Bus-Enden auf.

Die Eine der beiden Leitungen die vom CAN-Transceiver Baustein gegen Masse gezogen wird ist als CAN_L  (bzw. CAN-), die andere Leitung die gegen die Versorgungsspannung geschaltet wird als CAN_H (bzw. CAN+) bezeichnet.

Rezessiver und Dominanter Zustand

Der Bus kennt zwei mögliche Zustände – einen „rezessiven“ Zustand der dem Pegel „1“ entspricht bzw. einen „dominaten“ Zustand der dem Pegel „0“ entspricht.

Wie oben erwähnt ist der Ruhezustand des CAN-Busses der Pegel der einer logischen „1“ entspricht. Dieser Zustand ist „rezessiv“, das heisst er kann von jedem angeschlossenen Gerät durch eine logische „0“ überschrieben werden. Diese Möglichkeit einen „rezessiven“ Pegel durch einen „dominanten“ Pegel zu überscheiben wird benutzt für:

• die Bus-Arbitrierung Vergabe des Bus-Zugriffs
• die Message Priorisierung Einordnung der Wichtigkeit von Messages

Im Endeffekt sind beide genannten Punkte identisch, da eine im jeweiligen System mit höherer Wichtigkeit eingestufte Information natürlich bevorzugt übertragen werden soll. Wertmässig niedrigere „IDs“ haben also höhere Priorität (siehe 2.2 ).

Der CAN-Bus ist ein asynchroner Bus

Die auf dem CAN-Bus übertragenen Daten beinhalten keinen „Taktanteil“ der auf der Empfängerseite durch eine geeignete Schaltung (PLL) in einen Empfangstakt umgewandelt werden könnte und es wird kein Systemtakt separat in irgendeiner Form übertragen. Die Synchronisation und Dekodierung der Daten erfolgt, ähnlich wie bei einer

UART (Universal Asynchronous Receiver Transmitter) durch Über-Abtastung (Oversampling).

Oversampling und Oszillator Toleranzen

Die „Oversampling“ Frequenz wird von einem Quarzoszillator hergeleitet der in jeder CAN-Node vorhanden sein muss. Da aber selbst Quarzoszillatoren Toleranzen aufweisen müssen diese gegebenenfalls kompensiert werden. Die genaue Berechnung der erlaubten Toleranzen in Referenz zu den eingestellten Bittiming-Parametern ist in der ISO Norm 11898-1 , Kapitel 12.4.2.5 „Tolerance Range of Oscillator Frequencies“ definiert.

Die Abweichung df von der nominalen Oszillatorfrequenz f_nomist definiert durch die Gleichung:

(1-df)· f_nom  ≤  f_osc  ≤  (1+ df)· f_nom

Die erlaubte Abweichung df in einem CAN System richtet sich dabei nach den Einstellungen von PhaseSeg1, PhaseSeg2, SJW und der Bit-Zeit (siehe 1.3.4.1).

Die nachfolgenden Gleichungen müssen beide erfüllt werden um einen störungsfreien Betrieb eines CAN Busses zu gewährleisten:

df ≤	(PhaseSeg1, PhaseSeg2) min.
	2 · ( 13 · bittime – PhaseSeg2)

df≤	SJW______
	20 · bittime

Die maximale Differenz der Frequenz zwischen zwei Oszillatoren ist: 2 · df  ·  f_nom

Figure 5 :CAN Bit Übertragung

Oversampling setzt zwei Dinge voraus:

• Einen annähernd gleichen Verarbeitungstakt aller angeschlossenen Geräte
• Ein spezielles „Pattern“ bzw. eine spezielle Zustandsfolge als „Start“ Kennung

Im Gegensatz zur UART, bei der jedes übertragene Zeichen (8, 9 oder 10 Bit je nach Spezifikation) mit einem Start-Bit neu synchronisiert wird, erzeugt der CAN-Bus nur eine „Start“-Kennung für jeden Übertragungsrahmen (Message).

Die Übertragungsgeschwindigkeit

Neben den Unterschieden in der physikalischen Darstellung der Bits in verschiedenen CAN-Bus Systemen gibt es auch keine einheitliche Definition der Bit-Übertragungsraten. Grundsätzlich wird zwischen einem „Low Speed“ und einem „High Speed“ CAN Bus unterschieden.

Die Übertragungsgeschwindigkeit eines CAN Systems wird durch die „Oversampling“ Frequenz und das eingestellte Timing (die Anzahl der Zeit Quanten pro Bit) definiert.

Low Speed CAN

Low speed CAN Implementierungen werden dort eingesetzt wo eine hohe Übertrag-ungsgeschwindigkeit nicht notwendig ist aber die zusätzliche Sicherheit bei niedrigen Bitraten und geringe Störstrahlung von Vorteil sind.

Low speed CAN Systeme arbeiten mit „Fault Tolerant“ Transceivern als auch im „Single Ended“ Betrieb bei Übertragungsraten von 1kBit/s bis 125 kBit/s. Teilweise gibt es bei den CAN Transceiver Bausteinen auch Limitierungen hinsichtlich der minimalen Übertragungsrate.

High Speed CAN

Bei Systemen bei denen es auf „zeitnahe“ Informationen ankommt ist eine höhere Übertragungsrate von Vorteil, deshalb wurde der „High Speed CAN“ implementiert.

High Speed CAN Systeme arbeiten immer mit differenziellen Bussignalen um die Störanfälligkeit zu reduzieren. Mit entsprechenden Transceiver Bausteinen sind solche System im Bereich von 125 kBit/s bis zu 1000 kBit/s einsetzbar. Die maximale Spezifikation im ISO Standard ist mit 1 Mbit/s angegeben.

Frame Start und „Hard synchronisation“

Im „Bus Idle“ Zustand werden keine Informationen übertragen und der Bus bleibt im rezessiven Zustand. Der Beginn eines Übertragungsrahmens wird durch einen Übergang vom „rezessiven“ („1“) Zustand in den „dominanten“ („0“) Zustand gekennzeichnet, damit wird sowohl eine Synchronisation auf den Übertragungsrahmen als auch eine Synchronisation der Bit-Subschritte (Time Quanten) auf den Anfang des ersten übertragenen Bits möglich.

Figure 6 : Harte Synchronisation

Die Synchronisation zu Beginn eines zu übertragenden Rahmens wird als „Hard-Synchronisation“ bezeichnet. Dem gegenüber steht die „Re-Synchronisation“ die innerhalb eines Übertragungsrahmens mehrfach vorkommen kann.

Resynchronisation innerhalb eines Rahmens

Die Re-Synchronisation auf der Empfängerseite erfolgt während eines kompletten Protokoll-Rahmes durch das automatische Einfügen oder Auslassen von sogenannten „Zeit-Quanten“, (Sub-Schritte innerhalb eines Bits).

Um eine zu „harte“ (weil teure) Spezifikation für die Genauigkeit der Quarzfrequenz der einzelnen Systeme zu vermeiden, gleichzeitig aber mit nur einer Daten-Synchronisation zu Beginn des Übertragungsrahmens auszukommen, wird ein „Re-synchronisationsverfahren“ eingesetzt, das den „Sampling“-Zeitpunkt (den Zeitpunkt zu dem der Wert, sprich der „Bus-Value“ eines Bits auf der Empfangsseite ermittelt wird) verschiebt bzw. adaptiert.

Bit Segmentierung

Eine Bit-Zeit wird in 4 Segmente mit einer unterschiedlichen Anzahl von „Zeit-Quanten“ unterteilt. Diese Segmente sind: Sync-Segment, Propagation-Delay-Segment, Buffer-Phase1-Segment, Buffer-Phase2-Segment .

Figure 7: Bit Segmentierung

„Oversampling“ heisst, alle Busteilnehmer, das Sendende und die empfangenden Systeme, arbeitet mit einem Vielfachen der Bitrate die für die Übertragung der Daten auf dem Bus vereinbart worden ist. Damit kann das empfangene Signal während eines übertragenen Bits genau analysiert werden und es können Vorkehrungen getroffen werden wenn Übergänge zwischen entgegengesetzem Signalpegel (0>1 bzw. 1>0 Übergänge) sich innerhalb eines erlaubten Fensters verschieben. Eine „Re-Synchronisation“ ist also nur möglich wenn Bit-Übergänge vorhanden sind.

Per ISO 11898-1 Spezifikation muss die Anzahl von Zeit-Quanten pro Bit, die ein CAN Controller nutzen kann in einem Bereich von mindestens 8 – 25 programmier-bar sein.

Mögliche Verschiebungen entstehen wie gesagt durch die Toleranzen der einzelnen Systemtakte, sowie durch die Laufzeiten der Signale zwischen den einzelnen Bus-Teilnehmern auf einem physikalischen Bus.

Eine Bitzeit wird auf dem CAN-Bus daher in vier Segmente unterteilt. Diese Unterteilung gilt sowohl für die Sender- als auch die Empfängerseite, da alle Busteilnehmer mit einem gemeinsam „vereinbarten“ Takt arbeiten müssen :

• Sync-Segment, innerhalb diese Segments muss ein Bit-Übergang stattfinden, falls keine Re-Synchronisation vorgenommen werden soll. Das Sync-Segment ist nach ISO 11898-1 immer genau ein „Time Quantum“ lang.
• Propagation Delay, zur Kompensation der Signallaufzeit für den Sampling- Zeitpunkt. Dieses Segment kann im Bereich von mindestens 1 bis 8 oder mehr Time-Quanten programmiert werden. Tritt beim Empfang ein Bitübergang „erst“ im Propagation Delay Segment auf wird „re-synchronisiert“.
• Buffer Phase 1, Puffer zwischen Laufzeit- Kompensation und Sampling Zeitpunkt. Dieses Segment kann ebenfalls für mindestens 1 bis 8 oder mehr Time-Quanten programmiert werden.
• Buffer Phase 2, Zeit zwischen dem Sampling Zeitpunkt und dem nächsten zu erwartenden Bit-Übergang. Buffer-Phase-2 wird nach ISO Spezifikation mit der selben Anzahl Time-Quanten programmiert wie Buffer-Phase-1. Tritt der Bitübergang beim Empfang schon im Buffer-Segment-2 auf muss „re-synchronisiert“ werden.

Die in integrierten Schaltungen implementierten CAN-Controller ermöglichen teils die Programmierung der Anzahl von Sub-Schritten (Time Quanten) für jede dieser vier Phasen. Per ISO 11898-1, genügt aber für „Propagation Delay“ und Buffer Phase 1 eine einzige Einstellmöglichkeit.

Empfangstakt langsamer als Sendetakt

Die „Re-Synchronisation“ erfolgt durch Einfügen bzw. Unterdrücken einzelner „Time Quanten“ innerhalb einer Bit-Zeit.

Figure 8 : Re-Synchronisation T1 < T2

Wird festgestellt dass sich beim Empfang ein Bitübergang relativ zur Abtastung nach vorne verschiebt (also früher eintritt als erwartet), so wird im Phase Buffer Segment 1 des folgenden Bits ein einzelnes Time Quantum unterdrückt und damit der Sample Zeitpunkt ebenfalls nach vorne verschoben. Eine Verschiebung in Richtung eines früheren Zeitpunkts bedeutet einen „schnelleren“ Sende-Takt in Relation zum eigenen Empfangs-Takt, mit dem das Signal abgetastet (gesampled) wird.

Empfangstakt schneller als Sendetakt

Arbeitet der Sender mit einem geringfügig langsameren Takt, so verschiebt sich der Bitübergang auf einen späteren Zeitpunkt. Summiert sich der Fehler auf ein ganzes Bit-Quantum bei der Abtastung so wird im Phase Buffer Segment 2 ein Bit Quantum zusätzlich zu der im CAN Controller programmierten Zahl von Bit-Quanten eingefügt.

 

Figure 9 : Re-Synchronisation T1 > T2

In den hier gezeigten Beispielen wird jeweils ein Bit eingefügt bzw. unterdrückt. ISO 11898-1 spezifiziert aber eine weitere Variable, die „Resynchronization Jump Width“ welche im CAN Controller programmiert werden kann. Damit kann festgelegt werden ob ein oder mehrere Bits eingefügt bzw. unterdrückt werden sollen falls eine Resynchronisation eintritt. Die Resynchronisation Jump Width kann zwischen 1 und 4 Bit programmiert werden.

Die „Re-Synchronisation“ ist nicht zu verwechseln mit „Bit Stuffing“, bei dem ganze Bits ein- bzw. ausgeblendet werden um den „Taktgehalt“ beziehungsweise die Anzahl von Pegelübergängen eines Datenstromes zu erhöhen.

Alle Teilnehmer an einem physikalischen CAN-Bus System müssen mit einem definierten Takt innerhalb einer erlaubten Abweichung arbeiten (Quarzgenauigkeit).

Die „Re- bzw. Neu-Synchronisation“ kann natürlich nur in einem bestimmten Toleranzbereich arbeiten. Daher gibt es Einschränkungen bezüglich der erlaubten Quarzabweichungen innerhalb eines Systems.

Alle Teilnehmer an einem dedizierten CAN Bus System müssen mit einem nominal gleichen Takt (plesiochron) und mit denselben Einstellungen hinsichtlich der Anzahl von Zeit-Quanten arbeiten um störungsfrei miteinander kommunizieren zu können.

Mit den bisher aufgeführten Eigenschaften eines CAN Physical Layer Bausteins ist es möglich Bits in sequentieller Folge zu übertragen. Der CAN Bus kann dabei von allen Busteilnehmern (angeschlossene CAN Geräte) gleichberechtigt benutzt werden. Bus Konflikte können zwar entstehen werden aber durch die „rezessiven“ bzw. „dominanten“ Pegel aufgelöst und führen zu keiner Totzeit auf dem Bus selbst.

Für eine geordnete Datenübertragung muss aber definiert werden welches Bit in einer sequenziellen Folge welche Information trägt. Diese Zuordnung einzelner Bits, Bytes oder Felder in einem Übertragungsprotokoll wird vom „Data Link Layer“ beschrieben.

Die Datenübertragungsschicht (Data Link Layer)

Entsprechend dem OSI (Open System Interconnect) Standard wird auf der physikalischen Schnittstelle zur Übertragung auf Bit-Level (ISO Layer 1) eine „Daten-Übertragungs-Schicht“ (ISO Layer 2) aufgesetzt. Die Hauptaufgaben dieser Schicht ist die definierte Zuordnung übertragener Bits, die Flusskontrolle sowie Fehlerbehandlungen.

Eine Besonderheit des CAN Bus besteht in der Tatsache dass Daten nicht zwischen zwei Bus-Teilnehmern ausgetauscht werden, sondern dass grundsätzlich ein „Broadcast“ erfolgt. Eine gesendete Nachricht hat also keine Zieladresse sondern wird mit einer Kennung (CAN „ID“) versehen die den Inhalt der Nachricht kennzeichnet. Damit kann jeder Busteilnehmer die Nachricht lesen falls sie für die entsprechende „Node“ von Bedeutung ist.

Einzelne „Nodes“ eines CAN Busses benötigen keine Kenntnisse der jeweiligen Bus Infrastruktur. CAN Nodes können jederzeit hinzugefügt oder abgetrennt werden ohne die Kommunikation zu stören oder eine aufwendige „Enumeration“ oder Anmeldung im Netzwerk zu erfordern.

Eine weitere Betrachtung die dem CAN Bus Protokoll zu Grunde liegt ist die angestrebte „Echtzeitfähigkeit“ des Bus-Systems. Wichtige Nachrichten sollen möglichst ohne Verzögerung übertragen werden. Dies bedingt ein möglichst kompaktes Protokoll das den Bus nur kurzzeitig belegt.

Bit stuffing

Im Kapitel 1.3.4 „Re-Synchronisation innerhalb eines Rahmens“ wurde beschrieben wie auf dem CAN Bus der Abtastzeitpunkt durch Einfügen oder Unterdrücken eines „Bit-Quantums“ verschoben werden kann. Referenz für eine solche Verschiebung ist ein „Bit-Übergang“.

Um während der Übertragung eines Rahmens genügend „Bit-Übergänge“ zu gewährleisten wird auf der Senderseite nach einer Anzahl von fünf gleichen logischen Zuständen automatisch ein complementäres Bit eingefügt – das auf der Empfängerseite natürlich wieder entfernt werden muss um die Daten nicht zu verändern.

Figure 10: Bit Stuffing

Diesen Vorgang des automatischen Einfügens von Bits in den Datenstrom nennt man „Bit Stuffing“.

Ergänzend ist zu bemerken dass nicht alle Felder eines Übertragungsrahmens diesem „Bit Stuffing“ unterliegen. Der „CRC-Delimiter“, das „ACK-Feld“ und das „End of Frame“ Pattern (siehe nachfolgende Kapitel über die Übertragungsrahmen) werden nicht mit „Bit Stuffing“ bearbeitet.

Framing

Mit den bisherigen Vereinbarungen kann man auf dem CAN Bus nur einzelne Bits übertragen ohne eine Zuordnung der Information. Da mehrere Teilnehmer den Bus nutzen wurde ein Paket-Übertragungsverfahren vereinbart. Jeder Teilnehmer an einem CAN Bus System kann Daten in Form eines Übertragungsrahmens senden.

Der “MAC” (Media Access Control) Layer als Teil des “CAN Data Link Layer” spezifiziert vier Rahmenformen:

• Data Frame (Daten Rahmen)
• Remote Frame (Remote Rahmen bzw. Kontroll-Rahmen als Abfrage)
• Error Frame (als Bus Fehler Kennung)
• Overload Frame ( als Fluss-Steuerung)

Während der „Daten-Rahmen“ zur eigentlichen Übertragung von Daten benutzt wird, wurde der „Remote-Rahmen“ zur Abfrage von Informationen im Bussystem definiert. Ein „Fehler-Rahmen“ dient zur allgemeinen Information bei einem erkannten Übertragungsfehler und ein „Overload-Rahmen“ verlängert die Bus Totzeit zwischen zwei CAN Messages.

Innerhalb eines Rahmens werden Datenfelder oder Bytes immer mit dem „höchstwertigen“ (most significant) Bit zuerst übertragen (vom CAN Controller festgelegt).

Die Sequenz der Datenbytes im „DATA Field“ ist nicht spezifiziert und wird durch die Software der CAN-Node bzw. durch die Systemspezifikation festgelegt.

 

Figure 11 : Übertragungs Sequenz

Data Frame

Ein Daten-Rahmen besteht aus 7 Bit-Feldern mit unterschiedlichen Aufgaben und Bedeutungen.

Figure 12:  Daten Rahmen

Start Flag

Jeder Rahmen beginnt mit einem „Start Flag“ um den Rahmenbeginn zu kennzeichnen. Da im Ruhezustand ein „rezessiver“ Pegel (logisch „1“) auf dem Bus anliegt wird ein Übertragungs-Rahmen mit einem „dominanten“ Pegel (logisch „0“) beginnen.
Das Start Flag ist bei einem CAN Rahmen (gilt für alle CAN Rahmenformate) nur ein „Bit“ lang. Alle Bus- Teilnehmer werden bei einem erkannten Start Flag eine „harte“ Synchronisierung ausführen (siehe 1.3.3 Frame Start und „Hard synchronisation“) und die Bit- und Time-Quantum Zähler auf null setzen.

Arbitration Field

Der Name „Arbitration Field“ (Entscheidungsfeld) bezieht sich gleichzeitig auf zwei Entscheidungen.

• Bus Arbitration – welcher Teilnehmer „gewinnt“ den Buszugriff bei „simultanen“ Zugriffsversuchen von zwei oder mehr Teilnehmern.
• Data Arbitration – welcher Teilnehmer ist an der Information interessiert und möchte sie weiterverabeiten.

Das „Arbitration Field besteht in der „Basis Version“ aus dem

• CAN Base Identifier (ID-28 .. ID-18), der den Inhalt des Rahmens kennzeichnet (11 Bit)
• Und dem RTR (Remote Transmission Request) Bit das diesen Rahmen als Antwort auf einen „Remote“ Rahmen als Informations-Anforderung kenn-zeichnet. In einem Data Frame ist das RTR Bit immer „dominant“.

Figure 13: Arbitrierungs Feld

Der ursprüngliche CAN Identifier hatte in der Version CAN 2.0 A eine Länge von 11 Bits. Da im Laufe der CAN Entwicklung mehr als 2.048 Identifier benötigt wurden, entstand eine erweiterte CAN Spezifikation in der Version CAN 2.0 B die einen Identifier von 29 Bit spezifiziert. Durch die Erweiterung änderte sich das „Arbitration Feld“ und weitere Sub-Felder wurden eingeführt:

• CAN Base Identifier (ID-28 .. ID-18), zur Angabe der „Basis-ID“ oder Informations-Gruppe
• SRR (Substitute Remote Request), wird anstelle des RTR Bits in einem Base Frame gesendet (immer rezessive = 1).
• IDE (Identifier Extension) Bit, zur Kennung des nachfolgenden Bit-Feldes als Erweiterung des Identifiers. (immer rezessive „1“ = Extended Format).
• CAN Identifier Extension(ID-17 .. ID-0)
• RTR (Remote Transmission Request) Bit, immer dominant .

Figure 14 : Erweitertes Arbitrierungs Feld

Control Field

Das Kontroll-Feld mit einer einheitlichen Länge von 6 Bit, unterteilt sich in zwei Sub-Felder:

• IDE (Identifier Extension, r0, r1 ) Bits , 2 Bits
• DLC (Data Length Code) Bits, 4 Bits

Figure 15:  Control Feld

Die beiden ersten Bits im Control-Feld haben je nach Rahmenformat unterschiedliche Bedeutungen.

Im „Base Frame“ Format wird das erste Bit (r1 = IDE) mit einem dominanten Pegel (logisch „0“) übertragen. Das zweite Bit (r0) wird zwar ebenfalls als „0“ übertragen hat aber bisher keine Funktion, sondern ist für zukünftige Verwendung reserviert.

Im „Extended Frame“ Format haben beide Bits (r1, r0) in der gegenwärtigen Spezifikation keine Funktion sondern sind für zukünftige Verwendung reserviert.

Die beiden Bits werden im extended Modus ebenfalls als dominante Pegel übertragen.

Der extended ID Modus wird ja schon mit dem IDE Bit im Arbitration Feld definiert.

Das uniforme DLC Feld ist 4 Bits lang und beschreibt die Länge des Datenfeldes das dem Control Feld folgt. Mit 4 Bits könnten zwar Datenfelder von 0 bis 15 Byte gekennzeichnet werden aber in der aktuellen CAN Spezifikation ISO/CD 11898-1 sind nur Datenfelder mit einer Länge bis zu 8 Byte spezifiziert (siehe Tabelle).

Table 4: Datenlängen Code

Wenn das Bit DLC3 gleich “1” ist, wird immer ein 8 Byte Datenfeld angenommen.

Data Field

Figure 16 : Daten Feld

Das Daten-Feld enthält die im Control Field und dort speziell in den DLC[3..0] Bits spezifizierte Anzahl von Daten-Bytes. Bei den Datenbytes wird das weniger wertige Byte zuerst übertragen.

CRC Field

Das Cyclic Redundancy Check, CRC Feld wird über die vorhergehenden Felder des Rahmens berechnet. Die Berechnung started dabei mit dem „Start Flag“ und endet mit dem letzten der 15 übertragenen CRC Bits im „CRC Feld“.

Für die Berechnung des CRC auf dem CAN Bus wird folgendes Polynom verwendet:

X¹⁵ + X¹⁴ + X¹⁰+ X⁸ + X⁷ + X⁴ + X³ + 1

Die Exponenten repräsentieren dabei die Ausgänge eines 15 Bit Schieberegisters (z.B. X⁸ ist der Ausgang des achten FlipFlops des Schieberegisters). Diese Ausgänge werden zusammen mit den übertragenen Bits über ein XOr-Gatter zusammengeführt und liefern schliesslich nach dem letzten übertragenen Datenbit den 15 Bit CRC Wert.

An dieser Stelle sei erwähnt dass der CRC Check beim Senden immer vor dem „Bit Stuffing“ und auf der Empfängerseite immer nach dem „De-Stuffing“ ausgeführt wird.

Nachfolgend zum 15 Bit CRC Wert wird ein CRC delimiter Bit übertragen. Dieses Bit ist immer ein „rezessives“ Bit.

Acknowledge Field

Das Acknowledge Field ist ein 2 bit langes Feld das sich zusammensetzt aus:

• ACK slot – ein 1 Bit langer Zeitraum der es jeder angeschlossenen Einheit ermöglicht die fehlerfrei Übertragung zu quittieren. Damit CAN- Busteilnehmer dieses Bit setzen können und damit eine fehlerfreie Übertragung quittieren, muss es rezessive sein falls keiner der Teilnehmer eine Quittierung sendet.
• ACK delimiter – ein weiterer 1 Bit langer Zeitraum der einen Puffer schafft, falls eine Bus. Einheit das ACK Signal zu spät vom Bus nimmt.

End of Frame

Nach der Übermittlung des Acknowledge Feldes wird zur Beendigung eines Rahmens ein 7 Bit langes Flag bestehend aus „rezessiven“ Pegeln als Kennung für das Rahmen-Ende übermittelt.

Da das in Kapitel 2.1 „Bit Stuffing“ beschriebene Verfahren ab dem CRC Delimitter nicht mehr angewand wird, gelangen diese sieben logischen 1-en auch auf den Bus und definieren ein einwandfrei erkennbares Signal für das Rahmen-Ende.

Remote Frame

Im Gegensatz zu einem Data Frame besteht ein „Remote Frame“ nur aus 6 Feldern, da das Daten Feld entfällt.

Figure 17 : "Remote" Rahmen

Ein Remote Frame dient dazu im Bedarfsfall eine gewünschte Nachricht mit einer genau definierten CAN-„ID“ abzurufen. Damit ist neben einem „Push Verfahren“ bei dem die Nachrichten zyklisch auf den Bus gesendet werden auch ein „Poll Verfahren“ machbar bei dem Informationen nur auf Grund eines „Remote Frame“ übermittelt werden.

Die Felder eine „Remote Frames“ sind im Wesentlichen identisch belegt wie die Felder eines Daten Rahmens. Es wird hier also nur der Unterschied zwischen den Rahmen aufgeführt.

Arbitration Field

Im Arbitration Field wird durch das RTRBit (Remote Transmission Request Bit) ein „Remote Frame“ gekennzeichnet. Dies gilt sowohl für das Base- als auch für das Extended Format, wobei das RTR Bit immer an der letzten Stelle des Arbitration Feldes liegt.

In einem Remote Frame wird das RTR Bit immer mit einem „rezessiven“ Pegel also entsprechend einer logischen „1“ gesendet.

Control Field

Das Control Feld enthält wie in 2.2.1 Data Frame beschrieben ein 4 Bit langes DLC Feld das die Anzahl der nachfolgenden Datenbytes beschreibt. Da ein „Remote Frame“ keine Daten enthält könnte diese Feld theoretisch entfallen. Die CAN Spezifikation fordert aber ein DLC-Feld auch für „Nicht-Daten-Rahmen“ mit einem Wert (Länge des Datenfeldes) der dem des angeforderten Datenrahmens entspricht.

Error Frame

Error Frames stellen eigentlich nicht wirklich einen Übertragungsrahmen dar sondern sind vielmehr Bit-Patterns die die „Bit-Stuffing“ Regeln verletzen.

Ein Empfänger würde nach fünf übertragenen „0“en oder „1“en, ein Bit mit einem komplementären Pegel erwarten. Trifft das nicht zu, so wird dem Empfänger ein besonderer Zustand signalisiert.

Fehler-Rahmen (Error Frames) bestehen aus einem Error Flag und einem Error Delimiter:

Error Flag

Das Error Flag kann je nach Fehlerkondition ein:

• Aktives Error Flag (sechs aufeinander folgende dominante Bits)
• Passives Error Flag (sechs aufeinander folgende rezessive Bits)

sein.

Figure 18 : Activ Error Frame

Ein „aktives Error Flag“ wird gesendet wenn sich die Node im „Aktiven Error Modus“ (siehe 4.1 ) befindet und während der Übertragung einen Übertragungsfehler erkennt. Durch das Senden des aktiven Flags erkennen alle anderen Busteilnehmer ebenfalls einen Übertragungsfehler (Verletzung der Bit-Stuffing Regel) und senden auch ein „aktives Error Flag“ (bzw. einen Error Frame). Durch die Überlagerung der Error Rahmen kann der „dominante“ Zustand auf dem Bus zwischen min. 6 Bit-Zeiten und max. 12 Bit-Zeiten andauern.

Figure 19 : Passive Error Frame

Ein „passives Error Flag“ wird von einer Node (einem Bus-Teilnehmer) genutzt die sich im „Passive Error Modus“ (siehe 4.2) befindet. Eine solche Node, deren Error Counter einen bestimmten Schwellwert erreicht hat sendet nur noch rezessive Error Flags um den Datenverkehr nicht weiter zu belasten.

Error Delimiter

Der Error Delimiter ist immer eine Folge von 8 rezessiven Bits. Dabei wird von der sendenden Einheit der Bus überwacht bis ein „rezessives Bit“ erkannt wird (es könnte ja noch ein Busteilnehmer Daten senden). Nach dem Detektieren eines rezessive Bits sendet die Node noch weitere 7 rezessive Bits als Error Delimiter Feld.

Overload Frame

Ein Overload Frame ist genau wie ein Error Frame kein „echter“ Übertragungsrahmen, sondern eine „Bit-Folge“ die die „Bit Stuffing“ Regel (siehe 2.1 Bit Stuffing) des CAN Bus verletzt und daher als Fehler behandelt wird. Darüber hinaus unterscheidet sich ein Overload Frame, als reine Bitfolge, nicht von einem „aktiven Error Rahmen“.

Der Unterschied zwischen „Error Frame“ und „Overload Frame“ liegt in der Ursache für das Senden eines solchen Rahmens. Während ein „Error Frame“ einen auf dem Bus aufgetretenen Fehler kennzeichnet, ist ein Overload Frame für die Fluss-Steuerung zuständig, also mehr präventiv, bevor ein Fehler entstehen kann.

Overload Frames dürfen nach ISO/CD 11898-1 nur

• Während der Intermission-Bits (siehe 2.3 „Inter Frame Spacing“)
• Während eines EoF-Bits (End of Frame)

gestartet werden. Damit wird verhindert dass Overload Frames eine gültige Datenübertragung stören.

Figure 20 : Overload Frame

Die beiden Felder eines Overload Frame sind:

Overload Flag

Das Overload Flag besteht aus sechs aufeinander folgenden „dominanten“ Bits (logischen „0“en). Diese Regelverletzung wird von allen anderen Bus-Nodes erkannt die ihrerseits durch senden von „aktiven“ Error Rahmen quittiert. Der wesentliche Effekt dabei ist ein erzwungener „Bus Stillstand“ (ohne Übertragung von Daten) der der Node die denOverload ausgelöst hat, Zeit verschafft die vorher empfangenen Daten Rahmen abzuarbeiten.

Overload Delimiter

Ebenfalls identisch zu den Error Frames ist der Delimiter eines Overload Frames. Bestehend aus 8 aufeinander folgenden „rezessiven“ Zuständen (Bits), ermöglicht er die Rückkehr zu einem normalen Bus Zyklus.Wie bei einem Error Frame wartet die Node auf einen „ersten“ rezessiven Zustand und sendet dann weitere 7 rezessive Bits.

Inter Frame Spacing

Daten-Frames und Remote Frames können nicht unmittelbar hintereinander übertragen werden. Zwischen solchen Frames wird ein „Interframe Spacing“ gefordert das aus zwei Feldern besteht:

Figure 21: Intermission Bits

Intermission

Das Intermission Feld besteht aus 3 rezessiven Bits die auf einen vorausgegangenen Rahmen folgen. Während der Übertragung der Intermission Bits darf keine Node senden ausser:

• Zur Übertragung eines Overload Frames
• Zur Übertragung eines SoF (Start of Frame) Flags während des dritten Interframe Bits

Bus Idle

Das Bus Idle Feld ist kein Feld im herkömmlichen Sinne sondern stellt den Bus Ruhezustand dar. Nach einem Intermission Feld geht der Bus in den Idle Zustand (rezessive) und jede Node kann zu jeder Zeit mit der Übertragung eines Rahmens beginnen.

Das Interframe Spacing (Rahmen Zwischenraum) kann auch als rezessiver Buszustand nach einem gesendeten Frame betrachtet werden, wobei die ersten beiden Bits (beim dritten Bit kann ja schon ein Start of Frame gesendet werden) zwingend als rezessiver Zustand ohne Busaktivität gesehen werden können. Als Ausnahme gilt hier das Senden eines Overload Frames.

CAN Funktionalität

Nach den Vereinbarungen innerhalb der Bit-Übertragungsschicht und dem Data Link Layer besteht jetzt grundsätzlich die Möglichkeit Daten auf dem CAN Bus zu übertragen. Dazu muss eine Bus-Einheit mit dem Senden eines Rahmens beginnen.

Bus Access

Der CAN Bus ist ein „Multi-Master“ Bus, d.h. alle an den Bus angeschlossenen Einheiten haben die Möglichkeit zu senden. Voraussetzung dazu ist allerding, dass sich der Bus im Idle-Zustand befindet.

Die einzelnen aktiven Nodes „überwachen“ den Bus um jederzeit über den Status des Busses informiert zu sein. Dieses Verfahren nennt man „Carrier Sense“ oder kurz CS.

Zusammen mit der Multi-Master Fähigkeit des CAN Busses, die sich daraus ergibt dass ein „Multiple Access “  oder in der Abkürzung MA möglich ist, nennt man das Verfahren „CSMA“.

Viele serielle Bussysteme arbeiten nach dem CSMA Verfahren. Ein Unterschied ergibt sich aber aus der Art und Weise wie „Bus-Kollisionen“ behandelt werden.

In üblichen Systemen mit grosser Busbandbreite stellt eine Kollision zweier Nodes beim Buszugriff kein grösseres Problem dar, es geht etwas Buszeit verloren aber im Verhältnis zur verfügbaren Bandbreite (z.B. bei Ethernet) nur ein sehr geringer Teil.

Bei einem „Collision Detection“ oder kurz CSMA/CD Verfahren ziehen sich alle in die Kollision verwickelten Nodes vom Bus zurück und versuchen es nach unterschiedlichen Wartezeiten erneut.

Der CAN Bus , spezifiziert für „zeitnahe“ Übermittlung von Daten kann solche Kollisionen nicht tolerieren. Basierend auf der Fähigkeit des Physical Layers einen rezessiven Zustand durch einen dominanten Zustand zu überschreiben, besteht die Möglichkeit während der Arbitrierung des Busses zu entscheiden welche Nodes sich vom Bus zurückziehen müssen. Die Node die die Arbitrierung gewinnt kann weiter ohne Zeitverlust das begonnene Datenpaket übermitteln.

Diese Verfahren nennt man „Collision Avoidance“ oder in der Abkürzung CSMA/CA.

Bus Vergabe (Arbitrierung)

Welche Node muss sich bei einer Kollision nun vom Bus zurückziehen und welche Node kann weiter senden. Dazu muss noch einmal die Rahmenstruktur betrachtet werden.

Angenommen zwei Nodes beginnen absolut zeitgleich mit der Übermittlung eines zu übertragenden Rahmens.

Das erste Bit das von beiden gesendet wird ist das SoF (Start of Frame) Bit, welches ein dominantes Bit ist. Die beiden Nodes werden keinen Unterschied zwischen den von ihnen gesendeten Bit und dem auf dem Bus aktiven Zustand feststellen und weiter fortfahren.

Nach dem SoF Bit folgt das „Arbitration Feld“ – das wie der Name schon sagt für die eigentliche Bus Arbitrierung sorgt. Sowohl im „Base Format“ als auch im „Extended Format“ der CAN Spezifikation bilden die nächsten 11 gesendeten Bits den CAN Base Identifier. Dieser Message Identifier ist innerhalb eines „Basic“-CAN Systems für eine Node einzigartig (Forderung in ISO 11898-1) – d.h. die Rahmen der beiden Nodes werden sich in der CAN-ID unterscheiden.

Da der Zustand „0“ als dominant vereinbart wurde, wird die Node die eine „0“ sendet eine Node die eine „1“ (rezessive) sendet, überschreiben. Sobald eine Node feststellt dass das gesendete Bit nicht mit dem Buspegel übereinstimmt, gilt die Arbitrierung für diese Node als „verloren“ und die Bus-Unit wird keine weiteren Daten mehr senden.

Dieser Arbitrierungs-Vorgang setzt sich über die 11 ID-Bits fort und kann eventuell erst nach dem 11ten übermittelten Bit entschieden werden. Da eine „0“ den dominanten Zustand darstellt wird die Node die Arbitrierung gewinnen die die wertmässig niedrigste ID sendet (höchste Priorität ist „000 0000 0000“).

Arbitrierung und Extended Format

Im Kapitel 2.2 „Framing“ wurde auf die unterschiedlichen Rahmen für das „Basic-Format“ und das „Extended Format“ eingegangen. Bezogen auf das eben besprochene Szenarium für die Bus-Arbitrierung kann es also im Extended Format durchaus vorkommen dass die Base-Identifier Bits 18 – 28 die von zwei Nodes gesendet werden, identisch sind.

Es wird also nach den 11 gesendeten ID Bits noch keine Entscheidung über die Bus-Arbitrierung stattgefunden haben. Daher wird die Arbitrierung innerhalb der Extended ID bit (ID0...ID17) stattfinden. Die „Base-ID“ ( ID18 .. ID28) und die „Extended-ID“ (ID0 .. ID17) bilden zusammen den 29 Bit Identifier für das „extended Format“ und die Arbitrierung wird über den gesamten 29 Bit Identifier stattfinden.

Arbitrierung bei zwei Formaten

Für den Fall, dass an einem CAN Bus System sowohl Nodes mit dem „Base Format“ als auch mit dem „Extended Format“ arbeiten, kann nach dem 11-ten ID Bit (also ID18) eventuell noch keine Entscheidung über die Busvergabe getroffen werden da zwei Units mit den gleichen „Base-IDs“ möglich bzw. erlaubt sind.

Figure 22: Arbitrierung mit gemischten Rahmen Formaten

Nach dem „Base Identifier“ Feld wird von einem „Base Format“ Rahmen das RTR Bit , von einem „Extended Format“ Rahmen das SRR Bit gesendet. Wie in 2.2.1 beschrieben ist ein RTRBit in einem Data Frame immer dominant, ein SRR Bit aber immer rezessive.

Daher wird ein „Base Data Frame“ bei gleichem Base Identifier immer den Bus gegen einen „Extended Frame“ gewinnen.

Im Falle eines rezessiven RTR Bits (Remote Frame), auch im „Base Format“ Rahmen wird die Arbitrierung auf das IDEBit verschoben.

Das IDE (Extended ID) Bit unterscheidet zwischen dem „Base Format“ und dem „Extended Format“ und wird bei Base Format und Extended Format Rahmen immer als 14-tes Bit gesendet. Im Base Format Rahmen ist das IDE Bit Teil des Control Feldes, im Extended Format Rahmen aber noch Teil des Arbitration Feldes.

IDE - Base Format	dominant	IDE = 0
IDE - Extended Format	rezessiv	IDE = 1

Das Base Format besitzt bei der Bus-Arbitrierung durch den „dominanten“ Pegel des IDE Bits die Priorität, daher wir eine „Base Format“ Node die einen Rahmen mit gleichem Base Identifier wie eine „Extended Format“ Node sendet den Bus gewinnen.

Durch das RTR Bit wurde ein Base Data Frame ja bereits mit höherer Priorität eingestuft. Es verbleibt also im nächsten Schritt der Arbitrierung nur noch ein „Remote Frame“ im Base Format. Dieser wird bei der Arbitrierung über das IDEBit gegenüber „Extended Format Frames“ gewinnen.

Zu guter Letzt muss, falls auch das „Extended Identifier“ Feld eines Data- und eines Remote-Rahmens identisch sind das RTRBit des Extended Rahmen entscheiden welche Art von Rahmen den Bus gewinnt.

Da das RTR Bit in einem Base- und Extended Data-Frame immer dominant ist, wird es sich gegen ein rezessives Bit eines Remote-Rahmens durchsetzen.

Durch den eben beschriebenen Mechanismus der RTR/SRR und IDE Bits ergibt sich bei gleichen CAN Base Identifiern in Base Frames und Extended Frames folgende Prioritisierungsmatrix:

Priorität		RTR/SRR	IDE		Frame
Höchste = 1		dominant	dominant		Base Data Frame
Prio 2		dominant	rezessiv		Base Remote Frame
Prio 3		rezessiv	dominant		Extended Data Frame
Niedrigste = 4		rezessiv	rezessiv		Extended Remote Frame

Table 5: Rahmen Prioritäten

Übertragungs Fehler

CAN Rahmen bieten verschiedene Mechanismen um Übertragungsfehler zu erkennen:

• die Regel für das Bit Stuffing
• die Rahmen Überwachung
• einen 15 Bit CRC (Cyclic Redundancy Check)
• eine Acknowledgement Überwachung

Aus diesen Fehlererkennungs-Massnahmen können folgende Fehler abgeleitet werden.

Bit Stuffing Fehler

Bei der Übertragung eines Rahmens wird die Anzahl der aufeinander folgenden gleichen Bit-Zustände innerhalb der Felder gezählt die mit Bit-Stuffing beaufschlagt werden (SoF, Arbitration-Field, Control-Field, Data-Field und CRC-Checksum). Werden sechs oder mehr aufeinander folgende gleiche Zustände ermittelt so wird unmittelbar danach ein Error-Frame gesendet.

Bit Fehler

Wie schon mehrfach angesprochen überwacht eine Node die Daten auf dem CAN Bus nicht nur während die Node passive (lesen) ist sondern auch während die Node selbst sendet. Mit Ausnahme von bestimmten Bit-Feldern (Arbitration-Feld, ACK Bit) wird ein Fehler erkannt falls die gesendeten Daten mit den Daten auf dem Bus nicht übereinstimmen.

CRC Fehler

Jeder Empfänger am CAN Bus der ein Datenpaket empfängt bildet wie die sendende Node eine CRC Check-Summe (in 2.2.1 beschrieben) über die vor dem CRC Feld übertragenen Bits. Ist der Cyclic Redundancy Check gebildet wird er mit der im Paket übertragenen Checksum verglichen und bei Differenzen wird ein CRC Error ausgelöst.

Format Fehler

oder wie in der ISO Spezifikation bezeichnet, „Form Error“ – ist eine Abweichung von der Spezifikation eines Rahmens. Hier insbesondere werden Bits innerhalb eines Rahmenformats erkannt die einen definierten Pegel haben müssen aber diesen Pegel nicht einnehmen.

Acknowledgement Error

Wie in der Spezifikation der Datenrahmen beschrieben kann eine oder mehrere Nodes den Empfang eines Rahmens während des „Acknowledge Feldes“ und im spezifischen während des „Acknowledge Slots“ (ein Bit) quittieren (siehe 2.2.1 Acknowledge Field im Daten Rahmen). Da davon ausgegangen wird, dass eine gesendete CAN Message auch einen Empfänger im System hat, würde keine Quittierung einen Systemfehler – eben einen Acknowledge Error darstellen.

CAN Betriebs Modi

Jede einzelne CAN Node kann im normalen Betrieb verschiedene Modi durchlaufen. Auslöser für Übergänge zwischen einzelnen Modis ist die von der eigenen Node überwachte Fehlerhäufigkeit. Unglücklich von der Begriffswahl ist der Standard-Betriebsmodus der „Error Active“ Modus. Dabei bezieht man sich auf den Begriff „active“ als aktiv überwachende und Fehler signalisierende Einheit.

Aktiver Fehler Modus - „Error active“

Normal arbeitende Nodes (Busteilnehmer) befinden sich im „Error active“ Modus. In diesem Betriebszustand kann die Node Fehler auf dem Bus erkennen und mit einem „aktiven“ Error Rahmen (siehe 2.2.3) diesen Fehler auf dem Bus signalisieren und damit eine neue Übertragung des fehlerhaften Übertragungsrahmens auslösen. Beide Nodes, die Sendende und die Empfangende (sowie auch alle anderen empfangenden Nodes die den Fehler erkannt haben) werden Ihre entsprechenden Error Counter incrementieren.

Passiver Fehler Modus - „Error passive“

Häufen sich die Fehler bei Übertragungen entweder in Sende- bzw. in Empfangsrichtung, wird ein Problem mit einer spezifischen Node angenommen. Die Indikation der Fehlerhäufung erfolgt durch die „Error Counter“ der jeweiligen Node. Um weiteren Problemen vorzubeugen wird eine Node nach einer bestimmten Fehlerhäufigkeit in den „Error passive“ Modus versetzt. Dabei wird diese Node keine „aktiven Error Rahmen“ mehr senden sondern nur noch passive um die Busaktivität mit aktiven Fehlerrahmen nicht zu stören. Statt der dominanten Fehlerrahmen werden nur noch rezessive Fehlerrahmen gesendet die aber von anderen Nodes überschrieben werden können.

Bus „Off“ Modus

Eine CAN Node kann, bei ständig auftretenden Fehlern, in einen „Bus Off“ Zustand versetzt werden. In diesem Zustand kann die Node weder senden noch empfangen und wird den Bus in keinster Weise belasten (Bus Treiber hochohmig) oder stören (keine dominanten Bits).

Der „Bus Off“ Status wird vom „Fault Confinement“ (Fehler Begrenzung) ausgelöst falls ständige Irregularitäten auftreten und die Node zeitweise oder ständig vom Bus genommen werden soll.

Figure 23: CAN Error Mode

Bus „Monitoring“ Modus

In bestimmten Situationen oder Applikationen kann es notwendig sein Daten vom CAN Bus zu empfangen ohne selbst an der Kommunikation beteiligt zu sein. Für solche Fälle ist ein Bus „Monitoring“ Mode in der ISO 11898-1 vorgesehen. Der Bus Monitoring Mode ist kein Standard-Betriebszustand sondern eine mögliche Eigenschaft für eine CAN-Bus überwachende Einheit.

Die CAN Node kann dabei Daten- bzw. Remote Rahmen empfangen und auswerten und sogar ACK-Bits, Overload bzw. Error Frames senden, allerding werden die gesendeten „dominanten“ Bits nicht auf den Bus ausgegeben. Der „eigene“ MAC Layer wird aber diese Signale empfangen und verarbeiten.

Copyright Notiz

Copyright 2017 by Dipl.Ing.(FH) Franz Henkel

Dieses Dokument sowie dessen Inhalt, insbesondere Texte, Fotografien und Grafiken, unterliegt dem Copyright (© 2017) und sind nur mit einer schriftlicher Zustimmung des Autors, Dipl.Ing.(FH) Franz Henkel zur vollständigen oder auszugsweisen Weiterverwendung in Form einer gedruckten oder elektronischen Kopie oder Replikation bzw. einer vollständigen oder auszugsweisen Bereitstellung des Inhalts in schriftlicher, gedruckter oder elektronischer Form, zu verwenden.